先不要從 OpenAI 開始。
先問一個比較荒謬的問題：
一顆不見的滷蛋，為什麼可以解釋企業 AI 最大的假象？
晚上七點半，店門口站著等位的客人，外送平台的鈴聲每隔幾秒就響一次，後廚的牛肉麵已經出到第 47 碗。湯鍋邊都是白霧，出餐口貼滿了被湯汁弄皺的單子。
老闆拿起其中一張，皺著眉頭問：「為什麼又少放一份滷蛋？」
這時候，如果有人衝進來說：「我有一個 AI，可以幫你把菜名寫得更漂亮，還能幫你回客人五星評論。」
老闆大概不會太感動。
因為滷蛋沒有消失。
它是被一條破掉的工作流吞掉了。
前台改了單，後廚沒看到；昨天外送退單沒有補回庫存；POS、外送平台、Excel 各記一套；新人不知道加點滷蛋要貼哪一張貼紙；店長以為還有 30 顆，其實冰箱只剩 8 顆。
這就是今天很多企業導入 AI 的真實樣子。
大家以為自己缺的是更聰明的模型。結果模型來了之後，才發現真正麻煩的不是回答不夠漂亮，而是公司的工作現場本來就很亂：資料散在不同系統，流程卡在不同部門，責任藏在不同人的腦袋裡。
AI 可以幫業務寫一封很流暢的 email。
但寄出之前，業務還是要自己去 CRM 查客戶狀態，去 Slack 問交期，去 Excel 找上一版報價，去合約資料夾確認付款條件，再憑經驗判斷：這封信到底能不能寄？寄了會不會承諾過頭？會不會踩到法務紅線？
所以企業 AI 的問題，從來不只是「模型會不會回答」。
真正的問題是：AI 能不能進到那個會延遲、會漏單、會互相踢皮球、會有人臨時插單、也會有人負責收拾殘局的工作現場。
很多企業不是還沒準備好用 AI。
是 AI 一進來，大家才看見：公司其實沒有一條清楚的工作流。
企業不是缺聊天框，是缺一條能跑的線
過去幾年，很多公司第一次接觸生成式 AI 的方式都很像。
先開一個聊天框。
行銷拿它寫文案，業務拿它修 email，客服拿它摘要對話，工程師拿它解釋程式碼。每個人都覺得「有幫助」，但過一陣子之後，管理層開始問一個很尷尬的問題：
那為什麼公司的流程沒有變快多少？
原因很簡單。聊天框可以幫個人變快，但它不會自動改掉公司的工作流。
客服主管每天早上打開 300 張未結案工單。AI 摘要每一張都很漂亮，但主管真正需要的不是 300 份漂亮摘要。她要知道哪 20 件可能違約，哪 10 件其實是同一個產品 bug，哪 5 件要立刻通知客戶成功經理，哪幾件只是文件寫得不清楚。
業務總監也一樣。他不缺一個會寫 follow-up email 的 AI。他缺的是一個系統，在他打開客戶頁面時，自動把過去往來、付款風險、客服抱怨、產品使用下降、續約日期和下一步建議放在同一個地方，並且清楚標出哪些建議可以直接採用，哪些一定要人批准。
這兩件事差很多。
前者是「AI 幫人寫一句話」。後者是「AI 被放進一條公司真的每天在跑的流程裡」。
也就是說，企業 AI 真正值錢的地方，不是多一個聊天框，而是把一條工作流拆成幾個可以被設計、被審核、被追蹤的環節：
- Context：它到底讀了哪些上下文？
- Tools：它可以使用哪些工具、寫回哪些系統？
- Permission：它能看什麼、不能看什麼，能做什麼、不能做什麼？
- Human review：哪一步需要人類確認？
- Trace / Eval：做錯之後，錯誤會不會留下來，變成下一輪改進的材料？
沒有這些東西，AI 再會說話，也只是站在後廚門口喊：「我覺得滷蛋應該放進去。」
真正的改變，是有人進去把出餐線重排。
FDE 為什麼突然變重要？
這也是 FDE 重新被看見的原因。
FDE 可以理解成 Forward-Deployed Engineering，或 Deployment Engineering。中文翻成部署工程有點乾，但它的角色其實很好理解：不是在會議室裡放 demo 的人，也不是做完售前簡報就離開的人。
FDE 是那個捲起袖子進後廚的人。
他要看點餐單從哪裡來，庫存怎麼扣，退單怎麼記，尖峰時段誰有權限插單，哪一步可以讓系統先做，哪一步一定要人按確認。
換到企業裡，他要看的也不是「要不要加一個 AI chatbot」。他要看一張工單怎麼進來，一筆訂單怎麼被修改，一份合約誰可以看，一個客訴什麼時候要升級，一個 AI 建議如果被員工覆寫，理由要不要留下來。
這些問題聽起來不像 AI 發表會。
但它們才決定 AI 能不能真的上線。
你可以把 OpenAI、Anthropic、MCP、企業顧問合作這幾類動作放在一起看。表面上，它們像是不同公司各自推出平台、職缺、合作案或技術標準。放在更長的時間線裡，它們其實都在回答同一個問題：
模型已經夠會回答了，接下來要怎麼進公司真正的工作流？
OpenAI 強化 forward-deployed engineers 與企業 agent 部署能力；Anthropic 透過企業合作把 Claude 推進銀行、保險、航空、製造這類流程更重的產業；MCP 這類協定則在處理更底層的連接問題：AI 要怎麼接上工具、資料和系統，而不是每次都重新做一套客製整合。
這些不只是「AI 公司開始做企業市場」。
更像是模型公司發現，真正的戰場不在模型回答的那一秒，而在回答前後的整條線：它讀了什麼資料、用了什麼工具、寫回哪個系統、誰批准、誰覆寫、錯誤如何進入下一輪 eval。
以前我們說，每家公司都是軟體公司。
那句話的意思不是每家公司最後都要賣軟體，而是銀行、零售、物流、教育、製造、醫療，都會靠軟體重新組織自己的工作方式。
但 AI agent 時代，這句話可能要再往前推一步：
每個高價值工作流，都有機會變成一個 agent system。
不是每家公司都會變成 AI 公司。
而是每家公司裡那些重複、高價值、跨系統、又需要判斷的流程，會被重新拆開、接起來、加上權限與回饋機制。
所以判斷一個企業 AI 專案有沒有真正落地，不要先看 demo 有多炫。
先問三個比較土的問題：
第一，它有沒有讀到真正決策需要的上下文？
第二，它有沒有在正確的權限裡，寫回正確的系統？
第三，當人類不同意它的判斷時，這次覆寫會不會變成下一次改進？
如果三個答案都是沒有，那它大概還不是工作流，只是一個比較會說話的搜尋框。
PoC 很漂亮，不代表正式環境能用
很多 AI 專案一開始都很漂亮。
丟 20 份 PDF，模型可以摘要。丟一段客服紀錄，模型可以分類。丟一份合約，模型可以抓風險。會議室裡大家點頭，覺得這東西應該很快就能上線。
然後一進正式環境，問題就開始冒出來。
誰能讀這些 PDF？舊版本合約要不要排除？摘要要存在哪裡？業務能不能把模型回答直接轉寄給客戶？如果 AI 標錯風險，法務要怎麼覆寫？覆寫理由要不要保存？下次類似合約進來，系統會不會記得這次修正？
這些問題沒有 demo 那麼性感。
但它們決定 AI 到底能不能從「看起來很強」變成「每天有人敢用」。
想像一個 B2B SaaS 的客戶成功團隊。
某天早上，一張 enterprise support ticket 進來，標題很普通：「系統登入異常」。如果只看 ticket 本身，AI 很可能把它分類成一般登入問題，丟給一線客服照 SOP 回覆。
但資深 CSM 一看就覺得不對。
這個客戶下個月要續約，合約金額很大；上週才因為資安審查延遲抱怨過；昨天產品團隊剛好在修一個權限 bug；財務那邊還有一張未結發票。這不是單純的登入異常，這是一個可能擴大成 churn risk 的訊號。
真正有用的 AI，不是把「系統登入異常」摘要成三點。
真正有用的是把 CRM、billing、CSM note、product issue、合約條款和客服紀錄串起來，告訴主管：「這張 ticket 看似普通，但建議升級處理。原因是續約日期接近、過去 14 天已有兩次負面訊號、相關 bug 尚未關閉。」
然後更重要的是：主管如果不同意，能不能覆寫？覆寫原因會不會留下？下次模型遇到類似情況，會不會把這次修正變成 eval 或規則調整？
這才是企業 AI 的難點。
不是把答案寫出來，而是讓答案出現在正確的資料、權限、責任和回饋迴路裡。
這也是很多企業 AI 會卡住的真正原因：它不是技術展示題，而是組織現場題。
錯誤如果不能留下來，就不會變聰明
很多公司談 AI 轉型時，喜歡講「讓專家更有效率」。
但真正困難的地方是：專家的判斷要怎麼被系統吸收？
法務看完 AI 抓出的合約風險，說：「這條不算風險，因為我們跟這類客戶一直用這個條款。」如果這句話只是留在 Slack 裡，下次 AI 還是會犯一樣的錯。
客服主管把 AI 排出的高風險工單往下調，原因是：「這個客戶每次都用很急的語氣，但歷史上沒有違約風險。」如果這個判斷沒有被記錄，下次系統還是會把同一類客戶排到最前面。
餐廳也是一樣。
客人抱怨少放滷蛋，如果店員只是在群組裡罵一句「今天後廚又出包」，下週還是會少放。真正有用的是回頭看：是哪個平台的單？哪個時段？哪個品項？是備料不足、標籤不清，還是出餐檢查沒有設計好？
AI 也是這樣。
錯誤如果不能被追蹤，就不能被改進。人工修正如果不能變成 trace、eval、test case 和下一輪工程任務，它就只是一次性的救火。
這也是 FDE 和 deployment engineering 的價值：他們不只是把模型接進去，而是把「人怎麼修正 AI」這件事產品化。
誰可以覆寫？覆寫要填理由嗎？理由要不要分類？哪些覆寫代表模型問題，哪些覆寫其實是流程規則沒寫清楚？哪些修正應該進 eval，哪些只是單次例外？
這些問題很細。但所有真正能落地的企業 AI，最後都會走到這裡。
FDE 是補丁，還是新常態？
這裡也有一個值得懷疑的地方。
如果 AI 產品真的成熟，為什麼還需要這麼多人進企業現場？
FDE 可能代表 AI 產品還不夠標準化。就像有些 SaaS 看起來是產品，其實背後靠大量 customer success、solutions engineer 和 professional services 才能交付。當每個客戶都要客製，每個流程都要人肉接起來，這當然不像一個漂亮的軟體生意。
這是「FDE 作為補丁」的那一面。
但另一面也要承認：企業工作本來就不是乾淨的 API。
越高價值、越專業、越有風險的流程，就越多例外、權限、責任和歷史包袱。金融、保險、醫療、製造、政府，不可能只靠一個 self-serve 按鈕完成部署。
餐廳也不會因為買了新的 POS，就自動解決尖峰時段的出餐混亂。有人還是要站在現場，看單子怎麼貼、誰先煮麵、誰補滷蛋、誰回外送訊息，然後把規則改掉。
所以 FDE 可能同時是補丁，也是新常態。
說它是補丁，是因為它暴露出 AI 產品還沒辦法完全自助落地。模型公司需要用人力服務，把還不夠標準化的部署問題包起來。
說它是新常態，是因為只有進入現場，模型公司才知道哪些流程真的有價值，哪些錯誤會反覆發生，哪些人工修正可以轉成 eval，哪些部署模式最後能沉澱成平台能力。
這不是「AI 公司變成顧問公司」那麼簡單。
比較準確地說，是 API 正被放進一個更完整的企業部署包裡：模型、agent runtime、connector、MCP、資料權限、治理、FDE、系統整合，以及持續改進的 eval loop。
最後爭奪的不是聊天框，是工作流的定義權
當 AI 真的進入企業工作流，它就不只是工具。
它會開始影響：哪張 ticket 先處理，哪個客戶被視為高風險，哪個合約條款被標成問題，哪個員工可以覆寫模型判斷，覆寫紀錄會不會進入下一版 eval。
以前導入軟體，很多時候是把既有流程搬進系統。
現在導入 agent，可能是重新決定流程本身。
客服單進來，誰先看？AI 能不能先分類？分類錯了誰修？修正會不會留下來？下次同樣客訴出現，系統會不會自動升級？哪些客戶不能讓 AI 自動回覆？哪些內容一定要主管批准？
這些不是單純的技術設定。
這是在重新分配工作裡的權力：誰能定義流程，誰能覆寫判斷，誰擁有修正紀錄，誰承擔錯誤後果。
所以，下一階段的企業 AI，真正值得問的不是「AI 會不會取代 SaaS」，也不是「每家公司會不會變成 AI 公司」。
這些說法都太大，也太空。
更具體的問題是：
哪些工作流會先被 agent 化？
哪些流程必須保留人類判斷？
哪些企業會因為 AI 變得更自主，哪些企業反而會更依賴外部 AI 基礎設施？
當模型公司、FDE、顧問、SI、SaaS 和企業內部團隊一起重寫工作流時，誰會掌握新的流程定義權？
回到那顆不見的滷蛋。
如果你只把 AI 放在前台，它會幫你把道歉訊息寫得很漂亮：「很抱歉造成您的不便，我們會加強內部訓練。」
但如果你真的想讓下週五晚上不要再少放滷蛋，你要改的不是道歉文案。
你要改點餐單、庫存、貼紙、出餐檢查、退單紀錄、尖峰時段的分工，還有出錯之後怎麼回頭修流程。
企業 AI 也是一樣。
真正關鍵的不是 AI 能不能講得像人。
而是它能不能進入一條真實工作流，知道自己該看什麼、能做什麼、哪一步要停下來問人、做錯後又怎麼把錯誤變成下一次改進。
上一個時代，我們說每家公司都是軟體公司。
AI agent 時代，下一句可能是：
每個高價值工作流，都會變成一個 agent system。
但最後決定價值的，不是誰擁有最漂亮的聊天框。
而是誰能設計那條出餐線，治理那條出餐線，並且在滷蛋又少一顆的時候，讓整個系統真的變得更好。