FDE vs 內部工程團隊:企業 AI 該自建團隊還是引入前線部署工程師?

FDE(Forward-Deployed Engineering,前線部署工程)是一種交付模式:工程師直接進駐客戶現場,把企業 AI 從 Demo 推到生產線,扛到上線與真正有人使用;而內部工程團隊,是企業自己招募、長期持有這套能力的組織。兩者不是對立,是回答同一個問題的兩種路徑——這套 AI 系統,誰來讓它在你的流程裡跑起來、跑得住。

多數人以為這是「省不省錢」的題目。其實不是。真正決定成敗的,是時間差。

FDE vs 內部工程團隊:你其實在買不同的東西

當一家企業說「我要自建 AI 團隊」,他買的是一項長期資產:一群懂公司業務、會隨系統成長、離職風險自己扛的工程師。當它說「我要引入 FDE」,買的是一段被壓縮的時間:別人已經踩過的坑、已經寫好的 RAG 檢索與 Agentic 工作流骨架、以及一組能在幾週內就進場動手的人。

一個是持有,一個是加速。搞混這兩件事,決策就會歪。

我們看過太多公司,把「自建」當成預設值,理由通常是「AI 太核心,不能外包」。這句話沒錯,但它跳過了一個現實:你現在連第一版都還沒上線,談什麼長期持有?持有一個還不存在的東西,是空的。

三個真正拉開差距的維度

別看功能清單,看這三件事。

招募週期。 在台灣,要湊齊一個像樣的 AI 工程小隊——懂 LLM、會做檢索、能碰 MLOps——從開缺到到齊,樂觀估計三到六個月,而且好的人選常常在你談薪水時被別家挖走。這半年裡,你的 AI 專案是零產出。FDE 的差別在於,團隊是現成的,簽約後兩週內就能進場。你買的不是人力,是省下的那半年。

領域知識。 這是自建唯一無可取代的優勢,也是 FDE 最大的短板。你公司的核賠規則、產線異常的黑話、業務部門那些沒寫進 SOP 的潛規則——內部人知道,外部工程師一開始不知道。但這裡有個常被忽略的反轉:好的 FDE 不是不懂你的業務,而是懂「如何快速把你的業務知識抽出來變成系統」。我們進場第一週幾乎不寫程式碼,都在坐在使用者旁邊看他們怎麼工作。領域知識可以交接;上線經驗很難速成。

上線速度。 這是最殘酷的一項。自建團隊的第一個專案,往往也是他們第一次踩 AI 生產化的雷:向量庫選型、幻覺控制、權限邊界、監控告警……每一關都要用真實事故換教訓。FDE 帶著別人的事故記憶進場,同樣的坑不用再摔一次。

何時該自建,何時該引入 FDE

判斷準則其實很清楚,不必糾結。

如果你的 AI 應用是公司未來三年的命脈,而且會不斷長出新場景——例如一家銀行要把 AI 鋪進放款、客服、法遵、對帳每一條線——那你遲早要自建,而且愈早開始養團隊愈好。這種持續、深、廣的需求,外部顧問撐不住,也不該撐。

反過來,如果你面對的是「一個明確場景,要在這一季驗證它到底有沒有用」,自建就是最貴的選擇。你花半年招人,只為了做一件三個月能完成的事,而且做的人還是第一次做。這種情況,引入 FDE 幾乎沒有懸念。

麻煩的是,多數企業卡在中間。既不是純命脈,也不是純一次性。

混合模式:多數企業真正的答案

我們給客戶的建議,十次有七次是混合,而不是二選一。

具體長這樣:FDE 團隊負責從 0 到 1,在幾週內把第一個 AI Copilot 或 Agentic 工作流推上線、跑出真實使用數據;同時,客戶指派一到兩名內部工程師「貼身跟」,不是旁聽,是一起寫程式、一起處理線上事故。上線那天,系統交付的同時,知識也交接了。FDE 退場後,內部團隊接得住,而且是站在一個已經在生產環境跑順的系統上繼續長,而不是從白紙開始。

判斷你該不該用混合,問三個問題就夠了。第一,這個場景半年後還會不會持續迭代?會,就得留內部人。第二,你現在有沒有半年可以等?沒有,就得先讓 FDE 進場。第三,你內部有沒有人願意被「帶」?有,混合才成立;沒有,交接就是假的,系統遲早爛在那裡。

三個都命中,混合模式就是最省的路——省的不只是錢,是那半年的機會成本,和那些不必再摔一次的坑。

這也是我們在 Tenten 做 FDE 的方式:工程師進場不是來交一份漂亮 Demo,是來把系統推上線、扛到有人真的在用,然後把能力留在你的團隊裡再走。Demo 那天全場點頭不算數,三個月後使用率還在爬,才算數。