FDE 能否規模化，取決於共用平台而不是工程師人數
整理 Kevin Bai 對前線部署工程的判斷框架，說明何時需要 FDE、共用平台如何承接客製工作，以及擴編前必須付出的維護成本。
你把一套要在上面開發才能用的平台賣進企業，合約簽了，第一場導入會議也開了。投影幕上卻只有一張空白的工作流程圖。客戶知道要改善商品上架率或銷售吞吐量，卻不知道該怎麼把平台組成可用的方案。
眼前的問題是交付邊界。當客戶買得起平台，卻沒有工程能力把它變成成果時，供應商應該交付多少客製化，又要如何避免每個案子變成新的維護負債？
FDE 交付的是平台上的客戶成果
FDE 是 Forward Deployed Engineering 的縮寫，指工程師直接和客戶合作，在既有軟體平台上完成客戶需要的方案。Kevin Bai 在演講結尾把這個角色濃縮成一句話：「面對客戶的軟體工程師」。公司必須願意用軟體工程師的標準聘用這樣的人，也願意讓他們直接面對客戶。
本文整理的是 AI Engineer World’s Fair 2026 的演講 Forward Deployed Engineering 101。官方頁面記錄的片長是 17 分 48 秒。Bai 在開場自我介紹時說明他任職於 Anthropic 的 applied AI 團隊，先前是 Rippling FDE 團隊最早加入的成員，更早以前任職於 Palantir。這些經歷決定了他的觀察視角；本文討論的是這場演講，不是 Anthropic 目前的工作。
Bai 在 3:03 到 3:35 說明 FDE 的交付物。客戶同時取得軟體與工程服務，最後驗收的是建立在平台上的商業成果。工程師要理解客戶的業務，再用平台完成應用、工作流程或解決方案。本文會用 GTM（go-to-market）這個詞彙，指公司用什麼方式觸及客戶、完成成交並持續服務。
產品複雜度要和買家能力一起看
Bai 借用 Punnett square（生物學用的 2×2 對照表）說明 FDE 的適用條件。兩個軸分別是使用產品需要多少技術能力，以及買家能不能消化這份複雜度。他在 4:03 到 5:15 談了其中三種組合。
| 產品與平台 | 買家或使用者 | 複雜度由誰處理 | 演講中的判斷 |
|---|---|---|---|
| GitHub、Datadog 這類技術產品 | CTO、CIO、軟體工程師 | 技術使用者自行學習與操作 | 不需要 FDE |
| Rippling、Jira、Slack 這類可配置工具 | 非技術買家與使用者 | 使用者透過設定完成工作 | 不需要 FDE |
| 需要在其上開發的技術平台 | 非技術業務買家 | 供應商派工程師完成客戶方案 | 適合評估 FDE |
這張表是 Bai 在演講裡的分類，不是對這些產品完整能力的評測。演講也沒有討論第四種組合，本文因此不自行補上第四個象限，也不把推測當成講者的結論。
關鍵落在第三列。買家需要的結果明確，卻沒有能在平台上開發的工程團隊。供應商若只交出工具，客戶還得自行招募、培訓與管理工程師。Bai 在 6:00 形容 FDE 是把熟悉平台的工程能力借給客戶。
共用平台把客製需求限制在可維護範圍
FDE 會寫客製程式，但不從空白專案開始。Bai 在 8:42 到 9:05 說，工程師應在既有的共用平台能力上組裝應用與工作流程。這些能力由產品團隊共同維護，客戶方案只處理差異部分。
Foundry Ontology 是演講中唯一點名的例子。Palantir 官方文件 將 Ontology 描述成位於資料集、虛擬資料表與模型之上的操作層。它把資料映射成業務物件、屬性與關係，也提供動作、函式與動態權限。FDE 因此可以直接使用已維護的資料與操作能力，不必為每個客戶重建同一套基礎。
客製工作仍要有邊界。Bai 在 16:10 到 16:48 提出一個簡單原則：只服務單一客戶的行為留在該客戶的實作；能服務多個客戶的能力，長期應回到共用平台。演講沒有提供「幾個客戶算可共用」的數字，這個門檻仍要由產品團隊決定。
把 FDE 當成人力外派會看錯成本結構
一句常見但不準確的說法是：「FDE 就是把工程師派到客戶端接案。」Bai 在 8:13 到 8:52 直接畫出界線。每位工程師若替每個客戶從頭建立一套系統，公司經營的是開發服務，而不是他所說的平台型 FDE。
真正改變成本結構的是客製程式共享了多少已維護的能力，而不是工程師坐在哪裡。沒有平台時，每張新合約都帶來另一套相依套件、部署流程與支援責任。演講用「工程師不想學 55 個 repo」形容這個維護局面，接著指出維護成本會侵蝕損益。
同樣叫 FDE，底層平台會改變工程師每天維護的東西。
演講中的財務數字也不能直接證明這套模式的獲利能力。Bai 在 6:39 到 7:07 以 ACV（average contract value，平均合約價值）比較幾家公司。他口頭列出 Palantir 400 萬美元、ServiceNow 120 萬美元與 Workday 60 萬美元，並用了「上次查看」與「印象中」這類限定語。官方校訂稿 明確註記這些數字沒有量測日期、計算方式或獨立排名。它們只能說明講者的商業論證，不能當成一致口徑的公司比較。
平台只控制維護成本，不能消除它
即使有共用平台，仍然要維護客戶方案。Bai 在 10:38 到 11:12 把平台列為建立 FDE 團隊的必要條件，同時強調就算平台健全，維護負擔仍然可觀。平台能減少重複建造，不能讓客戶差異消失。
知識分散是第二項成本。在 15:05 到 15:29 的問答中，Bai 建議讓多位 FDE 共同參與專案，避免全部脈絡集中在一個人身上。團隊要為交接、支援與建立共同理解保留時間。
人才條件也不會因為角色貼近客戶而降低。Bai 在 16:59 到 17:25 對理想人選的要求有兩項：通過軟體工程師的招募標準，以及讓公司放心把客戶溝通交給他們。這代表 FDE 編制不能直接用售前或客服的人力替換，招募與培養方式都要涵蓋工程與客戶溝通。
兩道門檻決定公司需不需要 FDE
Bai 在 9:50 到 11:12 提出兩道門檻。第一道是公司是否必須把技術複雜的產品賣給非技術買家。第二道是公司是否已經有共用平台，或願意投入資源建立一個。
| 第一道：產品與買家的缺口 | 第二道：共用平台 | 判斷 |
|---|---|---|
| 存在 | 已有，或確定要投資 | 可以評估小規模 FDE 團隊 |
| 存在 | 沒有，也不準備建立 | 暫停擴編，否則客製工作會變成各自維護的專案 |
| 不存在 | 不需判定 | 技術買家可由開發者關係（DevRel）團隊支援；可配置產品可沿用一般銷售與導入流程 |
AI 沒有取消這兩道門檻。Bai 在 11:28 到 12:35 明確把一段話標示為個人假說。他認為 AI 降低了寫程式和製作客製軟體的難度，也讓更多平台具備可客製能力。演講並未提供跨產業資料可以證明「幾乎所有平台」都會走向同一方向。本文只把 AI 當成重新檢查兩道門檻的理由，不把它當成建立 FDE 團隊的充分條件。
用一張表跑一次 FDE 決策
這份推導流程尚待驗證。它能排除明顯不適用的情況，不能估算人力、合約毛利或部署週期。
先把演講中的三類產品代入兩道門檻，結果如下：
| 例子 | 產品需要開發 | 買家能自行吸收複雜度 | 有共用平台 | 推導結果 |
|---|---|---|---|---|
| GitHub、Datadog | 是 | 是 | 不需判定 | 技術型 GTM，不需 FDE |
| Jira、Slack | 以配置為主 | 否 | 不需判定 | 一般銷售與導入，不需 FDE |
| Foundry 與非技術產業買家 | 是 | 否 | 是 | 符合 FDE 的兩道門檻 |
要套用到自己的公司，就拿最近一個企業銷售機會，把下面五個欄位填完。只寫已經知道的內容，空白欄位本身就是下一步的調查工作。
| 欄位 | 要填的內容 |
|---|---|
| 客戶成果 | 客戶用什麼業務結果驗收，不寫產品功能名稱 |
| 開發需求 | 這個結果是否需要在產品上寫程式，還是設定即可完成 |
| 客戶能力 | 客戶是否具備能完成並維護這段開發工作的工程團隊 |
| 共用能力 | 資料模型、權限、動作與部署方式中，哪些由平台集中維護 |
| 長期歸屬 | 客戶特有行為留在哪裡，可共用能力由哪個產品團隊接手 |
產品需要開發、客戶缺少工程能力，而且共用能力已經存在時，才進入 FDE 的小規模試點。前兩項成立但平台欄仍是空白時，先定義平台投資與維護責任。產品與買家之間沒有能力落差時，沿用既有 GTM 方式會更直接。
我的判斷
上面的逐字稿、平台文件與兩道門檻都可以核對；接下來是我的判斷，現有證據不足以證明它能套用到所有 B2B 軟體公司。我把 FDE 視為產品架構與 GTM 的共同決策，工程師人數只是這項決策之後的編制結果。
如果產品團隊沒有定義哪些能力集中維護、客戶差異留在哪裡，以及前線需求如何回到平台，先招聘 FDE 只會增加客戶專案的分支數。相反地，平台邊界清楚之後，FDE 才能把工程時間用在理解業務和組合方案，而不是重建基礎能力。
AI 讓程式碼生成得更快，卻沒有替公司決定支援責任由誰承擔。這也是產品架構必須和 GTM 一起設計的原因。客製化變便宜時，公司更需要說清楚哪些程式由誰長期維護。
先驗證交付缺口，再開職缺
當客戶買得起平台，卻沒有工程能力把它變成成果時，供應商應該交付多少客製化，又要如何避免每個案子變成新的維護負債？
FDE 可以把交付延伸到客戶成果，但客製程式要建立在共用平台上。只服務單一客戶的差異留在該客戶的實作，可重用的能力則回到平台團隊。這條邊界決定公司交付的是可維護的方案，還是一批各自演進的專案。
挑一個最近的企業銷售機會，填完上一節的五個欄位。只有產品與買家確實存在能力落差，而且共用平台能承接重複工作時，FDE 才是需要驗證的下一步。
延伸閱讀
- Forward Deployed Engineering 101：官方頁面提供校訂稿、完整時間戳與演講提到的資源，適合逐句核對本文的分類與限制。
- Palantir Ontology overview：文件列出 Ontology 的物件、關係、動作、函式與權限，可具體理解 Foundry 提供哪些共用平台能力。
- What Is a Forward Deployed Engineer?：Kevin Bai 的補充文章把 FDE 拆成顧問、產品經理與工程師三種工作，並強調這個角色應該用在高價值且定義模糊的問題上。