最近看到一堆智慧製造、Physical AI、工業機器人、企業 Agent 平台的消息，第一反應其實不是「哇，好先進」，而是有點職業病地冒出一句：好，那它出錯時誰接手？
這問題聽起來很掃興。人家在講 AI 工廠、自主決策、機器人協作，我卻在想例外流程、權限、稽核 log、人工交接 SOP。對，技術主管就是這麼不浪漫。但做企業系統久了會知道，真正讓系統能上線的，常常不是 demo 裡最炫的那段，而是 demo 沒演的那段：當資料不完整、設備回報異常、工單狀態卡住、現場人員說「可是今天情況不一樣」的時候，系統要怎麼活下來。
AI 工廠不是一條魔法管線
很多人在談智慧製造時，會很自然地把它想成一條漂亮的自動化管線：訂單進來，系統排程，MES 派工，設備執行，機器人搬運，品質資料回寫，最後 ERP 結案。聽起來很順，畫成圖也很漂亮。
大概像這樣：
graph LR
A[訂單 / 需求] --> B[排程]
B --> C[MES 派工]
C --> D[設備 / 機器人執行]
D --> E[品質檢驗]
E --> F[ERP / 報表回寫]
這張圖沒有錯，但它太乾淨了。真實工廠不是這樣跑的。
真實情況是：料還沒到、設備暫停、品檢抽到異常、工單臨時插單、現場師傅依經驗調整參數、條碼掃不到、半成品被移到另一區、主管口頭說先做這批。更麻煩的是，這些事情很多都不是「錯誤」，而是工廠每天都會發生的正常變化。
如果 AI 只會看標準流程，它會把這些變化全部當成雜訊；如果 AI 太自由，它又可能把人類多年累積出來的安全邊界當成阻礙。兩邊都很危險。
真正要設計的是「交接點」
我現在看 AI 進製造現場，最在意的不是模型能不能回答問題，也不是機器人動作有多漂亮，而是每一個關鍵節點有沒有設計交接點。
所謂交接點，不只是畫一個「人工確認」按鈕而已。它至少包含幾件事：
- AI 為什麼做這個判斷？依據哪些資料？
- 它有沒有權限直接執行？還是只能建議？
- 如果資料缺漏，它是停下來，還是猜一個答案？
- 人接手後，系統狀態怎麼記？
- 後續追查時，看不看得到當時發生什麼事？
這些問題很土，但很救命。
我常覺得企業系統有一種很殘酷的特性：你越想把它做得「聰明」，就越不能省略那些看起來笨笨的紀錄。因為聰明系統一旦開始替人做決策，事後就一定會有人問：它為什麼這樣做？誰允許的？當時資料對不對？人有沒有確認？
沒有這些答案，AI 就算真的做對九十九次，第一百次出事時還是會被整組拔掉。
MES、WMS、ERP 不是資料庫名稱，是責任邊界
做製造系統時，很容易把 MES、WMS、ERP、設備資料平台看成不同資料來源。欄位串起來、API 接起來、事件丟出去，好像就完成整合了。
但從 CTO 視角看，我更傾向把它們視為責任邊界。
ERP 管的是商業承諾：訂單、成本、庫存、帳務。MES 管的是現場執行：工單、製程、報工、品質。WMS 管的是物料流動：入庫、出庫、儲位、搬運。設備系統管的是機台事實：參數、狀態、警報、產出。
AI 要跨系統工作時，麻煩的不是「讀資料」，而是「改變哪個責任邊界裡的事實」。
例如 AI 發現某批料可能不適合繼續生產，它可以做什麼？
它可以提醒？可以自動停工？可以改派另一台機器？可以凍結庫存？可以通知採購？可以改交期？
每往後一步，影響範圍就放大一圈。這不是 prompt 寫得嚴謹就能解決的問題，而是系統設計要先講清楚：哪些動作屬於建議、哪些需要審批、哪些可以自動執行、哪些永遠不能由 AI 單獨決定。
資料語意比模型更早決定上限
還有一個常被低估的點：資料語意。
AI 很會整理文字，也很會從大量資料裡找 pattern。但如果底層資料的語意本來就混亂，它只是把混亂包裝得比較像答案。
同一個「完成」狀態，在不同系統裡可能代表完全不同的事情：
- ERP 的完成，可能是訂單可結案。
- MES 的完成，可能是某製程報工完成。
- 品質系統的完成，可能是檢驗流程完成。
- 現場人員口中的完成，可能只是「這批先放旁邊」。
如果沒有語意模型，AI 看到「完成」兩個字就很容易誤判。更慘的是，它會用很有自信的語氣誤判。
所以我越來越覺得，智慧製造的前置工程不是先買一個很大的 AI 平台，而是把那些大家以為早就懂、其實每個部門理解都不一樣的詞重新定義一次。工單狀態、批號狀態、設備狀態、品質判定、庫存可用性、異常類型，這些老派名詞，才是 AI 能不能可靠工作的地基。
不要把混亂自動化
技術人很容易愛上自動化。看到重複工作就想寫腳本，看到人工判斷就想做 Agent，看到流程卡住就想接 API。這個衝動我完全懂，因為我也一樣。
但這幾年做下來，我反而會先問一個很煩的問題：這件事現在是因為「人做太慢」，還是因為「規則本來就不清楚」？
如果是前者，自動化很有價值。如果是後者，直接上 AI 只會把不清楚的規則放大。原本一個人一天只會做錯三筆，變成 Agent 一分鐘可以做錯三百筆。效率是提升了，災難也是。
所以在我心裡，比較健康的智慧製造路線應該是這樣：
graph TD
A[釐清流程責任] --> B[定義資料語意]
B --> C[建立權限與審批]
C --> D[設計異常交接]
D --> E[導入 AI 建議]
E --> F[逐步開放自動執行]
F --> G[持續稽核與回滾]
也就是先讓系統知道邊界，再讓 AI 在邊界裡變聰明。
最後還是那句老話：AI 也是系統
我不悲觀。相反地，我覺得 AI 進製造業會很有戲，尤其在排程輔助、異常摘要、維修知識庫、品質分析、跨系統查詢、現場操作引導這些場景，價值都很明顯。
但我不太相信「接上 AI，工廠就自動變智慧」這種說法。工廠不是聊天視窗，製造現場也不是 demo 舞台。它有設備、有料、有交期、有安全、有責任歸屬，還有一堆看起來很土但非常真實的例外狀況。
AI 如果要進來，就不能只當一個會回答問題的模型。它必須被放進一套完整的系統設計裡：資料從哪裡來、語意怎麼定義、權限怎麼切、誰能覆核、怎麼回滾、出了事怎麼追。
聽起來一點都不性感。可是企業系統很多時候就是這樣，真正可靠的東西，通常都長得不性感。
如果哪天大家談智慧製造時，不只討論模型多強、機器人多靈活，也開始認真討論人機交接、異常處理、稽核紀錄和資料語意，那我會覺得這波 AI 工廠才真的開始接近落地。