11 月 12 日，Anthropic 發布 Claude for Manufacturing。一個外掛，17 個技能，4 個連接器：Autodesk Fusion、Infor、Microsoft 365、Oracle NetSuite。
官方給的例子很具體：一批鋼材晚到兩週，採購員問 Claude 哪些客戶訂單受影響、其他廠區還有多少鋼材；採購員批准後，配合 Infor 自己發布的插件，Claude 可以向另一家供應商下採購單，並在 Infor 裡重排受影響的生產。
這條消息被讀成"AI 開始動 ERP 了"。但 17 個技能裡，最難的既不是下單，也不是排產，是報價。
一、十七個技能裡，報價要翻的是全廠的帳本
插件覆蓋銷售、品質、營運、供應鏈、設計、系統設定六個領域。官方對報價那條技能的描述是：讀取客戶需求、列出缺失資訊、對比類似工單的成本、起草報價供發布。這句話裡有四個動作，每一個都對應一類資料。
| 技能域 | 官方舉例 | 依賴的系統數據 | 出錯的代價 |
|---|---|---|---|
| 銷售 | 新工單報價 | 實際訂單、庫存、生產步驟、工單成本（NetSuite） | 報低了虧錢，報高了丟單 |
| 品質 | 檢驗失敗調查、糾正措施報告 | 歷史同類問題報告、檢驗記錄 | 措施落不到根因，問題復發 |
| 營運 | 生產報告 | 產量目標、設備停機、停機損失 | 停機成本算不清，改善無依據 |
| 供應鏈 | 向其他供應商尋源、RFQ 與報價對比 | 採購訂單、庫存、供應商歷史報價 | 詢價對象選錯，交期補不上 |
| 設計 | Fusion 模型變體與評分 | 現有模型、工程師目標參數 | 變體不可製造，白做一輪 |
| 系統設定 | 對話式接入（"Set us up"） | 各系統帳號、介面與權限 | 以為接通了，其實半通 |
報價要把七類數據拼在一起：BOM 版本、工藝路線與標準工時、工作中心費率、良率與損耗、庫存可用量（含在檢與已預留）、外協與運費、匯率與稅率。任何一類是估計值，報價就是估計值——AI 只是把這個估計值更快地送到客戶手裡。
值得留意的是 NetSuite 連接器取的四樣東西：實際訂單、庫存、生產步驟、工單成本。前三個決定「做不做得出來」，最後一個決定「做完賺不賺」。這四樣湊齊，才是「以實際成本報價」；而多數企業的現狀是標準成本加成，差異留到年底一次性消化。
2025 年 Manufacturing Leadership Council 調查中，仍在手工錄入資料的製造商比例（Anthropic 在發布頁引用）
這個數字把問題拉回地面。如果工單成本、工時、良率本來就是靠人抄進去的，接一個大模型並不會讓報價變準，只會讓錯誤的報價出得更快、更像那麼回事。
還有一個常被混淆的區別：成本可見，不等於成本可報價。工單成本如果只歸集到訂單層，遇到一個新型號就沒有可用的參照；只有歸集到工序層——每道工序的工時、良率、費率——才能把一張新圖紙拆成可估算的工序組合。這也解釋了連接器為什麼取「生產步驟」和「工單成本」兩項，而不是一個總金額。
二、連接器唯讀，寫入留給原廠：這個分工是對的
發布頁裡有一個很容易被跳過的細節：Claude for Manufacturing 的 Infor 連接器只支援查詢記錄；要改資料，得用 Infor 自己發布的那個外掛。
這不是能力不足，是責任劃分。讀操作的風險是"看到了不該看的"，靠權限解決；寫操作的風險是"改錯了還原不回來"，靠業務系統的校驗、審批和留痕解決。把這兩件事放進同一個連接器，等於讓一個外部分析工具繞過原系統的全部控制點。
查詢連接器
唯讀。權限跟隨登入使用者。答錯了可以重問，成本是一次對話。
寫入外掛
改單據。走原系統校驗與審批流。錯了要沖銷、要解釋、要留證據。
官方還寫了兩條設計原則：每項工作以使用者的複核結束；Claude 可以把數字和結論連結回底層資料與文件。第二條比「準確率」更重要——複核的人如果只能看到一段結論，他能做的只是相信或不信；能順著連結回到原始單據，他才是在審核。
別把"能查"順口說成"能改"。
示範現場最容易發生的一幕：採購經理看到 AI 查出受影響的訂單，接著問"那它能不能直接把交期改了"。這句話會把專案從"分析工具"變成"寫入操作專案"——預算、審批層級、驗證範圍、回滾方案全部要重做。寫入操作要單獨立項，不要夾在報表專案裡偷偷上線。
三、權限繼承很省事，但它繼承的是一張過期的授權表
官方明確寫了：Claude 的存取權限跟隨使用者本人在 Infor 中的權限。這句話在架構上很乾淨——不用另建一套帳號體系，審計時也答得清「它代表誰」。
問題在於，它繼承的是「這個人此刻的權限」，而這個權限往往是歷史累積的結果。換崗沒回收、項目結束沒清理、臨時授權忘了關，這些在企業裡是常態，不是例外。把它交給一個會 7×24 小時讀資料的智能體，等於把這些歷史遺留一次性放大。
報價這個場景尤其敏感。銷售該看到的是價格表與交期，成本會計該看到的是工單成本與費率，採購該看到的是供應商報價。三者的可見面本來不同。如果圖省事用一個權限很大的帳號去跑，AI 看到的是全公司的成本結構，再把它寫成一份會被轉發給客戶的報價單——這不是技術故障，是資訊洩露。
最危險的不是 AI 報錯價，是它把不該給銷售看的成本結構，寫進了一份會被轉發出去的報價單。
還有兩個更隱蔽的入口：離職人員的帳號沒有停用，智能體還在替他讀數據；報價的定價審批與成本數據維護由同一個人負責，AI 一接入就把這道職責分離的牆拆了。這兩件事在權限表上都看不出來，只能靠流程查。
四、接進 Odoo 之前，先補四張表
如果要把這套能力落到 Odoo 上，先別急著接模型。四張表不補齊，接什麼模型都一樣。
- 成本口徑表。標準成本、移動平均、實際成本，哪一個是報價口徑；BOM 版本與生效日；哪些物料按批次計價。
- 工時與費率表。工作中心費率、準備工時與批量階梯、外協工序的計價方式。Odoo 裡對應工作中心與工序工時，欄位空著，報價就只能靠猜。
- 良率與損耗表。按工序的良率、報廢率、返工率。這一項最容易被忽略，也最能讓報價差出十幾個點。
- 報價版本與有效期表。價格表、幣種、匯率取數日期、審批人。報價單是有保質期的，模型不知道哪一版還有效。
四張表有一個共同要求：每一項都要有「生效日」。沒有生效日的表，人和模型都只能靠上下文猜，而猜出來的成本，恰好是最像答案的那種錯誤。
給 CIO 的三條動作：
- 先做十張歷史報價的回測。拿已成交和已虧損的真實報價，讓 AI 按現有資料重算，比對差異。差異集中在哪裡，就去修那張表——不要先改提示詞。提示詞治不了髒資料。
- 權限按崗位快照，不按個人帳號。為報價智能體建專用角色，權限等於該崗位應有權限，不繼承任何人的歷史授權；離職與調崗觸發權限複核，而不是等審計發現。
- 讀用通用連接器，寫用原廠外掛。寫入路徑必須經過原系統的驗證與審批，中間保留人工確認和回滾方案。這條不是保守，是讓專案能通過內控。
報價單是製造企業唯一一張同時寫著成本、價格和承諾的紙。AI 可以把它寫得更快，但寫對的前提，是那七類數據本來就有人管、有版本、有生效日。
回到那批晚了兩週的鋼材。真正讓採購員敢按下批准鍵的，不是模型有多聰明，而是它查的訂單、庫存、工單成本都在系統裡，且他能順著連結一條條看回去。智能體進 ERP 的門檻，從來不在模型那一側。
資料來源：Anthropic《Introducing Claude for Manufacturing》（2026-11-12，含 17 個技能、4 個連接器、權限跟隨、人工複核與"不操作設備"說明）；Anthropic 發布頁引用的 2025 年 Manufacturing Leadership Council 調查（79% 製造商仍在手動輸入資料）；Infor 同期發布的製造業外掛說明；AI Soda《每日 AI 熱點 11 月 13 日》對上述發布的中文轉述（2026-11-13）。
口徑說明：技能清單、連接器範圍、權限繼承方式與「每項工作以使用者複核結束」均引自 Anthropic 官方發布頁；鋼材延遲案例為官方示例，非客戶實證，官方頁面未披露具名客戶。79% 為調查受訪者自述，未見樣本量與問卷原文，本文按「廠商引用」處理。報價所需七類資料與四張表為實施經驗歸納，不代表 Anthropic 或 Odoo 官方口徑。
