先說一台充電樁。
無錫博美芯做新能源充電樁，荷蘭 BUCOMEC 集團的全資子公司，產品出口歐洲為主，賣到 50 多個國家。聽起來是標準生意，但真正麻煩的地方藏在細節裡：同一個功率的產品，因為各國電網標準不同，會衍生出好幾個配置版本；核心電控自研，鈑金結構件和電源模組委外加工，進口元器件和國內零部件混著買；每一台出廠的樁，都要用一個唯一的 SN 碼關聯到具體那份 BOM。
夠複雜了。現在問題來了：這樣一家企業要上 AI，第一步該做什麼？
大部分人第一反應是選模型、挑場景、找供應商。但我看 11 月 9 日用友發布的那場啟動會材料，反而覺得答案在另一個地方——他們把一期工程的目標定成「訂單可視、成本可算、品質可溯」，先把主資料集中管理、按需下發，把物料、BOM、客戶、供應商、科目統一了口徑，再做訂單化營運監控和 MRP 聯動。
換句話說：先花半年把地基夯平，再談智能。這不是保守，這是唯一走得通的路。
一、上下文不是資料量，是來龍去脈
為什麼地基這麼重要？看同一天的另一條消息就明白了。
日立 11 月 9 日開始提供 TWX-21 調達 AI，第一批做採購營運。它的底氣不是模型，而是 TWX-21 這個企業間交易平台二十多年攢下的網絡——公開口徑約 8.7 萬家企業掛在上頭。有了這層關係，Agent 才知道這家供應商上次為什麼延期、那個料號上次漲價是哪一年、誰的報價一向偏高。
這類信息有個特點：它不在資料庫裡，它在流程的褶皺裡。郵件、傳真、微信、採購員的筆記、三年前的一次退貨。你把這些東西丟掉，給 Agent 十個大模型也沒用，因為它手裡只有一張乾淨的報價單，看不出任何異常。
Rillet 的故事是另一種證明。這家三個月前剛拿到 1 億美元 C 輪、估值 10 億美元的 agentic ERP，11 月 9 日宣布進英國，目前服務近 1,000 家客戶、覆蓋 75 個國家。它客戶裡 Black Forest Labs 的 CFO Dave Arkell 說了句話，我覺得比所有產品介紹都準：技術棧需要 AI 在核心裡，"而不只是 MCP 連接這類功能"。
這話從一個甲方 CFO 嘴裡說出來，分量不一樣。他不要一個能問數據的聊天框，他要的是同一份數據既能被人操作，也能被 Agent 操作，而且口徑一致、權限一致、審計一致。
把這兩件事合起來看，所謂「上下文」，不是把公司所有資料都塞給模型。它是一段有前因後果的業務紀錄：這筆單為什麼改、這家供應商為什麼留著、這個物料為什麼用替代件。這些答案寫在流程裡，不在文件裡。
二、多組織多口徑，是最貴的一課
回到博美芯這個案例，它把出海製造企業的痛點寫得比方案 PPT 還清楚：
| 業務特徵 | 給系統出的題 | AI 之前必須先解決 |
|---|---|---|
| 三國法人（無錫 / 布科美科 / 香港） | 跨境多法人獨立核算 + 集團財務集中管控 | 科目、幣種、稅則口徑統一 |
| ETO/MTO 混合、按專案客製 | 設計變更頻繁，交期跟著變 | 訂單變更可評估、可重排 |
| 自研 + 委外 + 混採 | 計劃與執行脫節、缺料與呆滯並存 | MRP 能算清採購、委外、生產、庫存聯動 |
| 同一功率多國配置版本 | 版本與工程變更管控壓力大 | BOM 版本與有效性日期說得清 |
| 每台樁唯一 SN 關聯 BOM | 正向與逆向質量追溯 | SN、批次、庫位貫穿進料到出貨 |
| 報價靠經驗 | 成本報價粗放、毛利算不準 | 材料費、製造費、人工費、銷售費用四項可拆 |
這張表裡，沒有一行是「AI 需求」。全是 ERP 的活。但它們決定了後面 AI 能不能接上——如果 SN 和 BOM 版本對不上，你連「這批貨有沒有問題」都答不出來，還談什麼智能質檢、智能追溯。
還有個細節值得抄作業：博美芯在專案組織裡設了主資料守門人。這個角色不是軟體功能，是人，有名字，要對物料、BOM、客戶、供應商的口徑負責。專案按模組分步推進，一般問題對專案經理，重大事項提交指導小組決策。
我在專案裡越來越相信一件事：主資料治理失敗的專案，八成不是缺工具，是缺一個"說了算且願意擔責"的人。上一個 MDM 系統，不如先指定這個人。
研發、營銷、生產、配件銷售與香港財務納入同一底座：主數據集中管理、按需下發，從源頭保證業財一致
三、在老系統上做 AI，現實的選擇是什麼
不是每家企業都能重建一套 Rillet。絕大多數甲方手上是一套跑了五到十年的 ERP，改不動也換不掉。這時候「AI 長在架構裡」這句話該怎麼落地？
我的經驗是三個判斷標準，跟選哪個模型沒關係：
- 資料在不在同一個庫裡。跨三個庫、兩張中間表拼出來的「即時」，其實是「每小時同步一次」。Agent 判斷交期時看到的庫存，可能已經是兩小時前的。
- 規則能不能讀。業務規則如果只存在於某位顧問的腦子裡，或者封在一個看不見原始碼的黑盒裡，你就沒法向稽核解釋「為什麼這單走了特批」。
- 權限能不能細化到紀錄。不是「這個使用者能看銷售模組」，而是「這個使用者只能看自己區域的客戶」。粗粒度的權限，Agent 一接進來就是資料外洩的入口。
以 Odoo 為例，它在這三點上的天然優勢是：單一 PostgreSQL 資料庫、業務邏輯在 Python 原始碼裡可讀可改、權限分到模型級和紀錄級（ir.model.access + ir.rule）。SN 與批次追蹤、MRP、委外加工（subcontracting）這些製造場景是原生模組，不需要外掛。
但也要說清楚它的短板：社群版沒有內建的智慧體能力，要自己搭。這意味著上下文注入、工具封裝、稽核留痕這些活兒，得由實施方一項項做出來，而不是裝個應用就完事。
這裡有個坑我踩過：為了趕進度，把 Agent 的查詢動作寫成以超管權限執行。系統跑得很順，直到某天業務問「為什麼華東的銷售能看到華南的價格」，才發現權限表早就形同虛設。Agent 用的帳號，必須和它服務的那個真人同權限，多一點都不行。
還有一件常被低估的事：歷史資料的遷移量，直接決定 Agent 能往回看多遠。我見過一個專案，新系統上線只遷了期初餘額和未結單據，三年前的出貨紀錄留在老系統裡。結果採購 Agent 判斷供應商交期可靠性時，樣本只有三個月，遇到季節性波動就失靈。後來補遷兩年歷史單據，工作量比原計畫的「資料清洗」整整翻了一倍。
所以規劃階段就得問一句：這個場景需要多長的歷史窗口？採購判斷交期偏差，通常要 12 到 24 個月；品質追溯要看完整的 BOM 版本變更鏈；成本分析至少涵蓋一個完整的報價週期。窗口算清楚了，遷移範圍和工期才有依據，不然一定是在 UAT 時才被發現。
四、給實施負責人的三條
- 先畫「上下文地圖」，再定 AI 場景。拿一張 A3 紙，把這個場景涉及的单據、主資料、歷史紀錄、審批鏈全畫出來。畫不出來的部分，就是 Agent 一定答錯的地方。這張圖比需求清單有用。
- 把口徑統一當成一期工程，不是前置條件。很多專案把主資料清洗放在「上線後優化」，結果第二年還在補。博美芯的做法是把主資料下發機制放進一期範圍，配一個守門人，這個順序值得學。
- 選能讀原始碼的路線。不一定是 Odoo，但一定要能回答「這條規則寫在哪」。AI 時代最貴的能力不是讓系統跑起來，是出問題時能說清為什麼。
Delight.ai 那套客戶 Agent 的做法也能佐證這一點。它把購物、預約、支援、留存放進同一個 Agent，共享客戶身分、偏好與歷史，涵蓋聊天、語音、簡訊、郵件和 WhatsApp。賣點不是「通路多」，而是購買前的推薦和購買後的服務接上了同一份上下文。同一份，意味著不用重複問，也不會自相矛盾。
所以這篇文章的結論其實很樸素：企業不需要先買到更強的智慧，需要先把自己的流程說清楚。SN 怎麼編、BOM 版本怎麼生效、委外回來怎麼檢、變更誰批、成本按什麼口徑攤——這些問題的答案，才是 Agent 真正的能力邊界。
模型會一代代換，流程和口徑不會自己長出來。誰先把地基打完，誰就能在下一輪模型升級時少折騰一次。
資料來源：用友網絡《無錫博美芯選擇用友BIP超級版：讓多組織運營「訂單可視、成本可算、品質可溯」》（2026-11-09）、日立 TWX-21 調達 AI 發布（11-09）、Rillet 英國擴張公告及客戶引述（GlobeNewswire，11-09）、Delight.ai Customer Agent 發布（11-09）。文中客戶規模、客戶數與部署範圍均為廠商公開口徑。
眾諦信息（Zodioo）· 企業數位化觀察 · 2026-11-10
