什麼是 FDE 前線部署工程(Forward-Deployed Engineering)?為什麼企業 AI 導入需要它

前線部署工程(Forward-Deployed Engineering,簡稱 FDE)是一種企業 AI 交付模式:工程師直接進駐客戶現場,和對方的業務、IT 與第一線人員一起工作,把 AI 系統從概念與 Demo 一路推進到生產環境,並對「真的有人天天在用」這件事負責。

它的核心不是把程式寫完。是把系統推上線,而且留得下來。

什麼是前線部署工程 FDE

要搞懂什麼是前線部署工程 FDE,先看它從哪來。這個詞最早在 Palantir 成形。他們發現一件反直覺的事:再強的資料平台,丟給客戶自己配置,大多會躺在後台生灰塵。於是他們讓工程師搬進客戶的辦公室,親眼看對方的流程怎麼跑、資料長什麼樣、決策卡在哪一關,再把產品「長」進那個現場。這批人就是 Forward-Deployed Engineer。

和「交付完就走」的模式最大的差別,在責任邊界。傳統軟體專案交一套系統、一份文件、一場教育訓練,驗收簽字,合約結束,之後有沒有人用是客戶自己的事。FDE 把這條線往後推:採用率沒起來,工程師的工作就還沒做完。

FDE 和傳統顧問、SI、外包差在哪

面向	傳統 SI／軟體外包	前線部署工程 FDE
成功的定義	系統交付、驗收通過	上線且被實際使用
工程師在哪	遠端、乙方辦公室	進駐客戶現場
需求怎麼來	一份規格書	現場觀察、貼身共事
對採用率負責	否	是
迭代節奏	版本週期、變更單	幾乎每天調整
何時算結束	驗收簽字	客戶團隊能自己走

差別不在誰技術強。在「成功」這兩個字怎麼定義。

FDE 工程師到現場都在做什麼

第一週通常不寫程式。是坐在使用者旁邊看他們怎麼工作:報一張價要開幾個系統、客服查一筆保單要點幾次、財務對帳的例外情況藏在哪。真實資料永遠比 Demo 髒——欄位命名不一致、同一個客戶有三種寫法、關鍵知識鎖在某個資深員工的腦子裡。

然後從最窄、最痛的那一個環節切進去,先讓它動起來、被少數人用起來,再一天一天往外擴。這種節奏沒辦法靠遠端遙控加一份規格書完成,得人在現場。

為什麼企業 AI 導入特別需要 FDE

傳統軟體的行為是確定的:同樣輸入,同樣輸出。AI 不是。RAG 會不會答對,取決於你的文件結構;Agent 會不會跑歪,取決於你的流程有多少例外。這些東西在乾淨的 Demo 資料上全都看不出來,一進生產環境就全冒出來。

所以企業 AI 最難的一段,從來不是模型選型,是最後那一哩:接上真實資料、對齊真實流程、讓真實的人願意改掉舊習慣去用它。這一段沒有規格書可以抄,只能在現場一次次校準。買一套為「一般客戶」設計的通用平台,而你的流程偏偏哪裡都不一般,結果往往就是很體面的 Demo,配上個位數的使用率。

什麼時候該用 FDE、什麼時候不用

需求標準、流程通用、風險不高——直接買現成 SaaS 更划算,別請人進場。FDE 值得的場景是另一種:流程非標、資料敏感、上線會影響到營收或法遵,而且「有沒有人用」直接決定這筆投資成不成立。金融、醫療、製造這類產業,特別常落在後者。

常見問題

FDE 和 MLOps、AIOps 一樣嗎? 不一樣。MLOps、AIOps 偏重模型與系統的維運自動化;FDE 是一種交付與協作模式,重點在把人放進客戶現場、對採用結果負責。兩者常一起出現,但不是同一件事。

一個 FDE 專案多久能看到東西上線? 通常先鎖定一個窄場景,幾週內就讓小範圍的人真正用起來,再逐步擴大,而不是憋好幾個月才來一次大爆發。

FDE 一定要長期綁約嗎? 不必。健康的 FDE 目標是讓客戶內部團隊能自走、工程師逐步退場,而不是製造長期依賴。

在 Tenten AI,我們就是照這個標準做事:工程師進場,扛到系統上線、有人天天在用,才算交付完成。Demo 很美不算數——留得下來的採用率,才算。