FDE vs 傳統顧問與外包:企業 AI 專案該找哪一種合作模式?

選型會議的桌上,通常擺著三份報價。

一份來自管理顧問公司,厚厚一疊策略藍圖,結論是「貴司應該導入 AI」;一份來自系統整合商(SI),按人月報價,承諾照規格把東西做出來;第三份寫著 FDE——前線部署工程,聽起來像前兩者的混血,你一時說不清它到底差在哪。

差別其實只有一句話。FDE vs 顧問、外包,不是比誰比較會做,而是比誰的責任邊界畫到哪裡。 顧問的責任止於「告訴你該做什麼」;外包的責任止於「照規格把功能交出來」;FDE 的責任止於「這套 AI 在你的生產環境跑起來,而且你的人真的在用」。三條終點線,中間差了整整兩段上線與採用的距離。

這段距離,在企業 AI 專案裡特別要命。因為 AI 專案的失敗,幾乎都不發生在「做不出來」,而發生在「做出來了沒人用」。我們看過太多案子,demo 那天全場點頭,合約簽得很快,半年後打開後台,實際使用率停在個位數。

FDE vs 顧問、外包:一張表看懂責任邊界

看這張表,關鍵那一列是「誰扛沒人用」。顧問和外包都在這一格寫「不負責」,不是他們不專業,而是這件事本來就不在他們的合約範圍裡。

為什麼 AI 專案偏偏卡在這條邊界

傳統軟體外包能運作,前提是規格寫得出來、也寫得對。你要一個報表功能,長什麼樣、算什麼欄位,規格書講得清楚,外包照做、你驗收,合理。

AI 不吃這一套。一個 RAG 知識系統上不上得了線,取決於你的資料有多髒、部門流程對不對得上、第一線員工信不信任它給的答案——這些東西沒辦法在專案啟動那天寫進規格書。它們只會在系統接觸到真實資料、真實使用者之後才浮出來,然後需要有人待在現場,一輪一輪調 prompt、補評測、盯監控、陪使用者改習慣。

顧問交完簡報就走,外包照規格做完就結案。規格本身是不是對的,沒有人替你驗;上線後那三個月的迭代,合約裡也沒有這一段。於是專案就死在 demo 到生產之間那道沒人負責的縫裡。

那是不是永遠該選 FDE?不是

我們做 FDE,但不會假裝它是萬用解。三種模式各有各的甜蜜點。

如果你連方向都還沒定,需要的是跨部門對齊、董事會 buy-in、或一份有產業標竿的決策依據,那該找顧問。這時候把工程師拉進場太早,反而燒錢——沒有明確用例,再好的 FDE 也無用武之地。

如果你的規格已經非常明確、需求穩定不太會變,而且內部有技術團隊能接手維運,那外包更划算。標準化、變動小的系統,沒必要付 FDE 的價。

FDE 真正的甜蜜點,是用例還帶著不確定性、資料和流程只有你們自己懂、上線後需要有人扛採用,而你手上偏偏沒有內部 AI 工程能量。這三個條件同時成立時,前兩種模式都會漏球。

FDE 也有它的取捨。短期人月單價比外包貴;它要求你開放現場、給資料權限、讓外人走進你的流程裡——這對某些組織的資安規範和內部文化是實實在在的門檻。我們踩過的雷是:客戶想要「一個能上線的系統」,卻不願意讓工程師碰到真實資料,結果系統又退回成一個漂亮的 demo。FDE 的前提,是你願意讓人進場。

選型時,問這三個問題

你不需要記住上面整張表,只要在會議室裡問對方三題:

第一,這份合約結束的那天,是誰按下上線那顆按鈕?答不出來,你買的就是一份簡報,或一個半成品。

第二,規格對不對,是誰負責驗證?如果沒有人替你驗,外包只會忠實地把一份錯的規格,精準地做出來給你。

第三,系統上線後三個月,誰負責讓使用率往上爬?這一題沒有答案,採用率大概就會永遠停在個位數。

我們做 FDE,講白了就是把工程師放進你的營運裡,而不是把規格寄給外包商——模型、系統整合、上線後的待命,全在同一支團隊手上。Demo 很美不算數;上線,而且有人在用,才算數。