FDE vs 內部工程團隊:同樣在寫程式,為什麼上線結果差這麼多?

去年底,一家製造業客戶的技術主管在會議室裡對我攤手:「程式我們自己都寫得出來,為什麼那個 AI 品檢模型放了半年還在測試環境?」

這句話,幾乎是每一次「FDE vs 內部工程團隊」討論的起點。而答案,通常不在程式碼裡。

先把定義講清楚

FDE(前線部署工程,Forward-Deployed Engineering)指的是一種工作型態:工程師直接進駐客戶現場,以「把某套 AI 系統真正推上生產線、扛到上線與被人日常使用」為唯一成功標準,而不是以交付一份可運作的程式為終點。它跟內部工程團隊最大的差別,不是誰技術好,而是兩者被設計來解決的問題根本不同。

內部工程團隊的天職是「維護一個持續運轉的系統」。他們對既有架構、歷史包袱、上下游依賴瞭若指掌,任務是讓服務不掛、迭代不出錯、SLA 不破。這是一種以「穩定」為核心的工作。

FDE 的天職是「把一個還不存在的東西,穿越組織的阻力送到生產環境」。這是一種以「落地」為核心、而且有明確終點的工作。

為什麼內部團隊常卡在最後一哩

不是能力問題,是結構問題。我們反覆看到三個原因。

第一,內部團隊有「本職工作」。AI 導入幾乎永遠是加在既有 roadmap 之上的第 N 個專案。當線上服務出事,人一定先被抽回去救火,AI 專案就順理成章地往後排。半年跑不完,不是因為難,是因為它從來沒被排進「這週一定要做完」的格子裡。

第二,最後一哩不是技術,是採用。模型跑得動,只完成了 30%。剩下的 70% 是:業務流程要不要改、現場老師傅願不願意信這個分數、資料權限怎麼開、出錯了誰負責、KPI 要不要跟著調。這些事需要跨部門去談、去磨、去說服。內部工程師既沒有這個授權,也沒有這個習慣——他們被訓練成寫好程式就交付,不是被訓練成推動組織改變。

第三,沒有人以「上線」作為考績。內部團隊的績效綁在系統穩定度上。一個 AI 專案上不上線,對他的年度考核往往影響有限。當一件事沒有人真正對結果負責,它就會停在「技術上已完成」這個舒適的灰色地帶。

那位製造業主管的模型,程式碼三個月前就寫完了。卡住的是:品檢流程要動到產線節拍,而沒有人敢去跟廠長談這件事。

兩者到底差在哪

這不是二選一

講到這裡,容易被誤讀成「內部團隊不行、要外包」。剛好相反。

內部團隊懂系統、懂資料、懂公司的政治地形,這些是 FDE 進場第一週最需要借力的。理想的分工是:FDE 帶著「非上線不可」的單一目標與跨組織推動的方法進場,把最後一哩的採用問題啃下來;內部團隊在旁邊補上系統知識、接手長期維運。等 FDE 撤場,系統不是變成沒人懂的黑盒,而是內部團隊能自己養下去的資產。

換句話說,FDE 不是要取代內部工程師,是要補上內部團隊在結構上很難自己補的那一塊——把一件「重要但不緊急」的事,變成「這個月必須上線」。

一個誠實的取捨

FDE 這種做法有它的代價。人進場、扛結果、談組織,成本比丟一份需求文件給廠商高;而且它要求客戶願意讓外部工程師碰真實流程、真實資料,信任門檻不低。它不適合「我只想要一個 Demo 看看效果」的場景——那樣反而殺雞用牛刀。

但如果你手上正好有一個模型已經跑得動、卻在測試環境放了好幾個月的專案,問題大概率不在程式碼那一端。

我們在 Tenten 做 FDE,判斷成敗只有一條線:Demo 很美不算數,上線、而且現場有人每天在用,才算數。內部團隊負責讓系統活得久,我們負責先讓它活過那道最難的門檻。