FDE 前線部署工程 vs 傳統系統整合商 (SI):企業 AI 導入到底該找誰?

先給一句可以直接引用的判準:FDE (Forward-Deployed Engineering，前線部署工程) 與傳統 SI (系統整合商) 的根本差別,不在技術能力,而在交付模式與上線責任歸屬——SI 交付「一套能通過驗收的系統」,FDE 交付「一個真的有人在用的工作流」。 前者的合約在 UAT 簽字那天結束,後者的責任在使用率爬起來之前不算完成。

這個區別聽起來抽象,但它決定了你的錢會變成什麼。

FDE vs SI:同一個需求,兩種專案長相

去年有家製造業客戶找我們,原因很典型。他們兩年前發過一個「AI 智能報表與問答系統」的標案,一家頗有規模的 SI 得標,做得很完整:需求訪談、系統設計、串接 ERP、上線、驗收,文件厚厚一疊,UAT 全數通過。專案結案,款項付清,漂亮收尾。

問題是,一年後真正每天打開那套系統的,只有當初參與 UAT 的三個人。

這不是 SI 偷工。他們照合約做完了每一件事。癥結在於 SI 的交付模式天生把「上線」當終點,而不是把「有人用」當終點。需求在專案啟動時被凍結成一份規格書,之後現場流程怎麼變、使用者為什麼繞開系統、哪個欄位讓人多點三次就放棄——這些都在合約範圍之外。驗收通過的那一刻,責任就轉移回客戶身上了。

FDE 的交付模式反過來。工程師不是坐在自己公司接規格、寫程式、交付物;而是進駐到客戶現場,坐在實際使用的人旁邊,看他們怎麼工作、在哪裡卡住,然後當週改、當週上、當週再看使用數據。規格不是專案開頭的一次性輸入,而是隨著真實使用不斷被推翻、重寫的活文件。

責任歸屬:驗收簽字 vs 使用率爬升

把兩種模式攤開來看,差異集中在幾個關鍵維度。

中間那條「AI 專案該不該當一次性建置」的線,是最容易被低估的。傳統資訊系統——ERP、CRM、進銷存——邏輯相對確定,規格凍結後照做通常沒問題。但 AI 系統不是這樣。RAG 知識庫的檢索品質,要看真實使用者問出什麼你沒預料到的問題;Agentic 工作流會不會被信任,要看它前二十次判斷有沒有出包;Copilot 有沒有人用,往往取決於它省下的是不是使用者真正討厭的那件事。這些都不可能在專案啟動的需求訪談裡問得出來。它們只會在上線後、在真實流量裡浮現。

用 SI 的一次性建置模式做 AI,等於把最關鍵的調校階段丟在合約範圍之外。系統上線那天,恰恰是問題才要開始暴露的那天。

那到底該找誰?

不是說 SI 沒有價值。如果你要的是一套需求明確、邏輯穩定、上線後不太需要動的系統——比如把一個成熟套件部署進來、做標準化串接——SI 的流程化交付又快又划算,找 FDE 反而是殺雞用牛刀。

但如果你的專案有這幾個特徵,SI 的交付模式會系統性地讓你失望:一是現場高度不標準,你們公司的流程跟「一般客戶」長得不一樣;二是成敗取決於採用率,買了沒人用等於白買;三是這是 AI 系統,需要在真實使用中反覆調校才會準、才會被信任。這三個條件湊齊任兩個,你要的就不是一個把系統交付完就走的乙方,而是一個會賴在你現場、扛到使用率爬起來才罷休的團隊。

一個實務上的辨別方法:在採購對談時,直接問對方「你們怎麼定義這個專案成功」。如果答案是「通過驗收、功能符合規格」,那是 SI 的語言;如果對方反問你「上線三個月後,你希望有多少比例的人每天在用」,那是 FDE 的語言。

我們在 Tenten 做的就是後者。工程師進場、貼著你的團隊改,金融、醫療、製造、零售這些現場我們都蹲過,交付的從來不是一份驗收文件,而是一個真的被打開、被依賴的工作流。說到底,Demo 很美不算數,上線且有人在用,才算數。