為什麼企業 AI 導入該找 FDE 而不是傳統顧問公司?交付責任歸屬的關鍵差異
傳統顧問交付一份 180 頁簡報就結案,FDE 交付的是真正跑在生產線上、有人每天使用的系統。兩者的分水嶺其實只有一個問題:專案結束後,誰還在為採用率負責?這篇拆解 FDE 與傳統顧問的交付責任歸屬,以及為什麼「最後一哩」不是附加服務,而是整個工程的重點。
作者
Tenten AI FDE 團隊
前線部署工程
发布日期
2026年5月29日
阅读时间
5 分鐘

交付物驗收那天,傳統顧問公司交出來的是一份 180 頁的簡報,外加一份導入路線圖。所有人都很滿意。三個月後,那份簡報躺在共享資料夾裡,沒有一行程式碼跑在生產環境,沒有一個業務單位改變工作方式。
這不是個案。這是「顧問交付模式」的結構性結果。
FDE vs 傳統顧問:差別不在能力,在交付什麼
先把話講清楚。傳統顧問公司裡有很多聰明人,他們的產業分析、流程診斷、變革管理框架都是真本事。問題不在能力,在於他們的商業模式決定了他們交付什麼——他們賣的是「建議」,計價單位是人天與報告,合約的驗收標準是文件送達。
FDE(Forward-Deployed Engineer,前線部署工程師)賣的是另一種東西:一個真正在客戶環境裡跑起來、被人使用的系統。工程師直接進場,坐進客戶的會議室,接上客戶的資料庫,把 AI 工作流一路扛到上線與採用。驗收標準不是簡報頁數,是有沒有人在用。
這個差異用一句話就能區分:專案結束後,誰還在為採用率負責?
顧問模式的答案通常是「沒有人」。報告交了,款項結了,關係轉為下一期的新提案。至於那套建議有沒有落地、上線後使用率是 4% 還是 40%,不在合約範圍內,也不在計價邏輯裡。FDE 模式的答案必須是「我們」——因為交付的定義本身就是可運作、有人採用的系統,採用率低就等於沒交付,款還沒賺到。
| 面向 | 傳統顧問公司 | FDE 前線部署工程 |
|---|---|---|
| 核心交付物 | 簡報、路線圖、診斷報告 | 上線且被使用的系統 |
| 計價邏輯 | 人天 × 資歷 × 報告 | 系統上線與採用結果 |
| 進場方式 | 訪談、工作坊、遠端建議 | 工程師嵌入客戶現場 |
| 驗收標準 | 文件送達、簡報通過 | 生產環境運作、實際使用率 |
| 專案結束後 | 責任移交或另立新約 | 仍為採用率與迭代負責 |
| 失敗成本 | 由客戶承擔 | 由交付方共同承擔 |
「最後一哩」不是附加服務,是整個工程
大部分企業 AI 導入卡住的地方,從來不是模型選型或架構圖,而是那段沒人願意扛的最後一哩:資料要清、權限要接、既有系統要串、內部流程要改、員工要願意打開它而不是繞過它。
顧問公司會把這段標成「落地執行,建議由客戶 IT 團隊主導」。這一句話,就把最難、最髒、最需要工程判斷的部分,推回給了最沒有餘裕處理的那一方。於是你花大錢買來一份正確的建議,然後發現自己得再花一次錢,才能讓建議變成能用的東西。
FDE 的立場相反:最後一哩就是工程本身。我們遇過一家製造業客戶,前一手顧問給的知識庫方案架構完全正確,RAG 選型也沒錯,但沒有人處理它們三十年累積、格式混亂、充滿手寫掃描件的文件資料。系統當然檢索不出東西。我們做的第一件事不是重畫架構,是花兩週把資料管線建起來、把髒資料處理掉——然後同一套架構就活了。
誠實的取捨
FDE 模式不是萬靈丹。它更慢、更貴、更難規模化,因為它靠的是真的把工程師派進去,而不是複製一份簡報範本。如果你要的只是一份董事會報告、一個對標同業的策略觀點,傳統顧問其實更划算,別找 FDE。
但如果你要的是一套真的跑在生產線上、有人每天打開、能扛住真實流量與真實資料的 AI 系統,那你需要的是願意在專案結束後,還為那個使用率數字負責的人。
我們在 Tenten 就是這樣運作的:工程師進場,把責任扛到上線與採用為止。因為 Demo 很美不算數,上線且有人在用,才算數。
