FDE 比的不是 PoC 多快：AI 轉型真正的勝負，在系統上線後才開始
FDE 職缺一年暴增七倍，但獵頭公司估計市場上真正能穩定交出成果的不到兩千人。落差不在原型跑得多快，在系統上線之後誰還留在現場，把每一次例外變成產品下一版的能力。速度是門檻，決定成敗的是後面那段長期功夫。
五千三百三十個新職缺，和獵頭公司估計的兩千個人
過去一年，「Forward Deployed Engineer」（前線部署工程師，以下簡稱 FDE）從一個小眾職稱，變成整個 AI 產業搶著填的位置。根據 Business Insider 引用 Indeed 職缺數據的分析，FDE 的職缺數在 2025 年 4 月到 2026 年 4 月之間，從 643 個暴增到 5,330 個，年增率達到 729%。TechCrunch 在 2026 年 7 月的報導也引述獵頭公司 Christian & Timbers 的調查：2026 年初只有 5% 到 10% 的受訪企業計畫聘用 FDE，到了第二季末，這個比例已經跳到 70%。
同一篇 TechCrunch 報導點出一個更該被注意的數字：美國市場上掛著 FDE 頭銜的人大約有 17,000 名，但 Christian & Timbers 估計，其中同時具備產業知識、現場信任感、又能動手把系統做到上線這三種能力，足以穩定交出 ROI 的，大概只有 2,000 人左右。這是獵頭公司依經驗給出的估計值，不是一套客觀認證的合格門檻，但落差本身已經夠說明問題。
職缺數字漲了七倍多，這種被獵頭公司認可的複合能力卻沒有跟著等比例出現。市場上談 FDE，多半在講「PoC 做得多快」，但兩週端出一個能動的雛型，正在變成這個角色最基本、最容易被複製的入場門檻，不是它真正稀缺的原因。這篇文章想拆開講的，正是門檻和真正決定成敗的能力之間的差別。
這篇是我們團隊拆解 FDE 現象系列 文章的其中一篇。系列另外幾篇，會分別談到客戶其實說不清楚自己要什麼的需求轉譯真相、FDE 是不是換了名片的顧問這個爭議、技術怎麼真正落地的最後一哩路，以及怎麼分辨真假 FDE。這篇先聚焦在最容易被誤解的一塊：速度到底算不算這個角色的護身符。
我們在導入案筆記裡，一次次看到同一個轉折點
我們最近回顧近半年協助品牌做數據與行銷自動化導入的顧問筆記，注意到一個常見的模式：第一版雛型多半做得很快，品牌看到 Demo 也常覺得驚艷，但真正決定這個案子最後成不成功的時間點，往往落在三個月後，而不是那個讓客戶眼睛一亮的展示第一週。那時系統會遇到品牌自己都沒意識到的例外狀況，比如某個檔期的組合商品折扣算法跟平常邏輯不一樣，或是某個會員分群條件在門市場景完全對不上線上邏輯。
那個當下，決定案子走向的，往往是誰還留在現場，願意把這個例外攤開來搞懂，然後把學到的東西真的改回系統裡。我們讀到 FDE 這個角色被熱烈討論時會覺得似曾相識，正是因為這本來就是我們團隊在做導入服務時，每天在練的功夫。
PoC 做得快，只解決了三層問題裡最外面那一層
把一次成功的 AI 系統導入拆開來看，至少有三層。
| 層次 | 決定的是什麼 |
|---|---|
| 表層：原型速度 | 能不能在一到兩週端出一個看得懂、能操作的雛型 |
| 中層：現場理解深度 | 能不能挖出客戶自己都說不清楚的真實業務規則 |
| 底層：反饋回產品的迴圈 | 現場踩過的坑，會不會變成系統下一版的標準能力 |
部分市場論述談 FDE 時，焦點都停在表層。MIT NANDA 實驗室 2025 年發布的《The GenAI Divide》報告綜合訪談約 150 位高階主管、調查 350 位員工，並分析超過 300 項公開揭露的企業 AI 導入計畫，報告主張多數專案卡關的主要障礙之一，是系統「沒辦法保留回饋、沒辦法因應情境調整、也沒辦法隨時間累積學習」。報告原文用的字是這套系統缺乏「retain feedback, adapt to context, or improve over time」的能力，指的正是上表的底層與中層，不是表層。
一個團隊如果只練表層，最多只能把品牌帶到「看起來很厲害的 Demo」那一步。中層跟底層才是真正決定這個案子能不能撐過第一個檔期、第一次系統改版、第一次窗口人員異動的關鍵，這兩層都跟「原型做得快不快」關係不大，需要另外練的是理解生意與持續修正的能力。
從 Palantir 到 AWS：大型科技公司砸的錢，買的是留下來的人
FDE 這個角色最早由 Palantir 提出並帶起，這套模式的背景可以參考 Wikipedia 上的 FDE 詞條。Palantir 的商業模式從一開始就跟「賣一套標準軟體給最多客戶」的邏輯不一樣，做法是把工程師長期派駐在客戶現場，跟著業務團隊一起把系統磨到堪用。這種模式當年被不少人質疑太貴、沒辦法規模化，但也正是這種長期蹲點，讓客戶很難輕易換掉它。
這套邏輯現在被更多公司複製。AWS 官方公告指出，AWS 在 2026 年成立一個由 10 億美元投資支持的專屬組織，目的是把上千名工程師直接嵌入客戶團隊；Microsoft 官方公告則指出 Microsoft Frontier Company 投入 25 億美元，動員約 6,000 名產業專家與工程師直接進駐客戶端。OpenAI 官方宣布成立獨立的 Deployment Company，Anthropic 官方公告則與 Blackstone、Hellman & Friedman、Goldman Sachs 合資成立新的企業 AI 服務公司。這幾家公司的共通點，都是把「進駐客戶現場、陪著把系統用起來」獨立成一個正式的組織能力，不是工程師個人的加班服務。
這幾家公司真正投入的重點，是怎麼讓陪跑這件事變成一種可以規模化的能力，而不只是讓 PoC 跑得更快。這跟半導體業行之有年的 FAE（現場應用工程師）邏輯很像，數位時代的分析提到，聯發科能撐起自己的生意，靠的正是「陪客戶一路做到成功」這套打法，不是誰的樣品交得快。把這幾個案例放在一起看，會發現一個共同點：投入越多資源的公司，比的越是誰能把「留下來」這件事做成一套可複製的組織流程。
為什麼多數導入案卡在示範之後：反饋循環才是真正的技術門檻
如果把焦點拉回「為什麼職缺暴增，被獵頭公司認可的複合能力卻沒跟著變多」這個落差，答案就更清楚了。原型速度是可以被複製的技能，一個工程師練熟一套框架，兩週端出一個能動的雛型，這件事本身正在快速變得普及。真正稀缺的能力，在於能不能在系統上線半年後還記得當初為什麼要這樣設計，並且在客戶說「我們的需求變了」的時候，準確判斷這是真的變了，還是原本的規格從一開始就沒挖對。
數位時代引述業內工作者的描述很傳神：「假設六個月後系統上線、半夜出包，當初畫出問題架構的人，就是會被叫起來處理的那一個。」這句話點出的是 FDE 工作最核心的部分：對這套系統的因果關係熟到能在凌晨三點做出正確判斷，比誰交付得快重要得多。
市場追捧這個角色的速度，遠遠跑在真正合格人才前面。
也正因為這個門檻真實存在，市場對 FDE 熱潮本身也有不少質疑聲音。LeadDev 的分析引用 Unframe 工程師 Chris Slovak 的看法：用昂貴、難找的人力去取代人力，這件事本身聽起來就不太永續。TechCrunch 也提到一種可能性：如果幾年後 agent 開始自動化其他 agent，FDE 這個角色本身也有可能被自動化取代。
這些質疑其實點出了兩種執行模式，只是外面都掛著同一個 FDE 頭銜。一種是把顧問的名片換成 FDE，卻沒有真的建立起現場理解與反饋回產品的能力，這種模式撐不久；另一種是把陪跑當成長期能力來經營，每一次現場學習都留下痕跡，責任與版本紀錄都有人接手。批評者擔心的其實是前者，但市場常把兩種都算進同一個統計數字裡，才會讓人誤以為整個角色都不永續。這兩種模式的差別，要到原型交付之後才看得出來。當然，少數團隊能同時做到又快又深，簡單標準化的導入場景也不必長期蹲點，這篇文章談的是多數品牌會遇到的情況：兩者只能先求其一時，決定長期成敗的通常是後者。
91APP 的做法：把每一次現場修正，變成產品的下一個版本
我們團隊在服務品牌做 CDMP 與個人化行銷導入時，長期在做的正是這件事：不是把第一版分群邏輯或第一支自動化腳本做出來就結案，而是持續蹲在客戶的實際營運場景裡，把每一次「這裡跟教科書寫的不一樣」的例外，變成系統下一次迭代的養分。
舉例來說，品牌買 CDP AI Agent 時最容易忽略的落差，就是廠商 Demo 環境跟真實應用環境的差距。一個系統在展示環境裡能準確回答問題，不代表它接上品牌真實、混亂、充滿歷史包袱的資料後還能正常運作，這中間的落差只有長期蹲點才補得起來。這也是為什麼 91APP 團隊的 CS 角色這幾年一直在往前走，從單純執行客戶交辦事項的產品顧問，進化成能用數據分析幫客戶創造營收機會的成長顧問，這個轉變的核心，在於是否真的把每一次服務現場學到的判斷，系統化地留下來。
具體來說，這套反饋循環在 CDMP 裡至少反映在三個地方：會員生命週期分群的門檻會依產業特性微調，不是套一個全品牌通用的公式；購買意圖分群的判斷邏輯，會依品類的購買週期做校準；優惠券濫用偵測規則，也是從一次次品牌現場的實際套利案例中，逐步補齊識別邏輯。這些調整靠的是長期蹲在客戶的資料與營運現場裡，一次次把踩過的坑寫進系統，不是一份一次性顧問報告能做到的事。
AI 拉平的是每個品牌都能取得的基本產能，這件事本來不算新現象。工具人人買得到，模型人人用得到，快速做出一個雛型系統的門檻也在快速下降。當表層的能力被拉平，真正拉開差距的地方只會往上游移動，移動到誰真正懂客戶的生意、誰願意留下來把坑填平這兩件事上面。
評估 AI 導入夥伴時，別只看誰的 Demo 做得快
如果一家品牌正在評估要找誰做 AI 或 CDMP 導入，與其只看誰的原型做得快、誰的簡報比較炫，不如換幾個問法，直接問到重點，並要求對方提供可查核的證據，而不是只聽口頭保證。
- PoC 結束之後呢：對方有沒有明確的第二階段迭代機制與上線後的維運分工？如果答案只有「先做出來再說」，代表對方可能還沒想清楚後續誰要負責優化。
- 系統上線半年後，誰在維運：追蹤導入期結束後，實際處理異常與優化的是不是同一群人，有沒有具體的問題紀錄可查，還是每次都要重新溝通交接。
- 上一次的現場學習，有沒有進到產品裡：請對方具體舉例，過去在別的案子學到的教訓，怎麼變成現在系統裡的一個功能或一條規則，而不是每次都從零開始寫。
- 能不能講出這個產業的特殊之處，並說清楚怎麼驗證成效：真正蹲過現場的團隊，應該能具體說出這個品類獨有的眉角，也能講出檢核成果的時間點與指標，不是套用放諸四海皆準的簡報模板。
這幾個問題問下來，通常就能看出對方是真的準備長期蹲點、有東西可以攤開來查核，還是只是把一次性的顧問服務換了一個聽起來比較新的名字。
上線那天不是終點：責任才剛開始
市場願意為 FDE 這個角色開出高薪、瘋狂搶人，說明大家都已經看懂一件事：把 AI 系統真正用進企業日常運作，比訓練一個模型難得多。但如果整個產業只把焦點放在誰的原型跑得快，那五千三百個新職缺，最後可能只換來五千三百次一次性的顧問報告，客戶留下一套沒人繼續照顧的系統。
真正決定一個 AI 轉型案子能不能成功的，從來不是系統上線那天有多風光，而是上線之後那半年、那一年，還有沒有人願意留在現場，把每一次意外變成下一次更好的版本。速度只換得到入場券，留不留得下來才是真正的考題。
品牌最常問的 FDE 與 AI 導入問題
Q1：FDE 是什麼，跟一般的軟體工程師有什麼不同？ A1：FDE 是長期進駐客戶現場，協助把 AI 或軟體系統真正落地並持續優化的工程角色，概念最早由 Palantir 提出並帶起。跟一般工程師最大的不同在於，FDE 花更多時間理解客戶的業務邏輯與現場情境，工作場景也常常不是只在辦公室裡寫程式。
Q2：FDE 跟傳統顧問有什麼差異？ A2：傳統顧問模式多半是交出一份報告或建議書就結案，後續優化責任不在顧問身上。FDE 模式強調持續蹲點與現場迭代，系統上線後仍要負責處理問題、優化規則，並把現場學到的經驗回饋進產品。
Q3：為什麼 FDE 職缺暴增，被認可的合格人才卻很少？ A3：快速做出一個原型的技能相對容易複製，但能理解客戶生意、長期蹲點解決問題、並把經驗系統化回饋的能力需要時間累積，無法速成，這是市場供需落差的主要原因。
Q4：中小型品牌預算有限，也適用這種長期陪跑模式嗎？ A4：長期陪跑不代表一開始就要投入龐大資源。可以先從一個明確的小範圍場景開始，例如單一分群溝通腳本，確認導入夥伴是否真的追蹤成效並持續優化，再逐步擴大合作範圍。
Q5：多久才能看出一個 AI 導入案是不是真的成功？ A5：第一版原型通常一到兩週就能看到，但真正的成敗指標要看系統上線後三到六個月，能否因應品牌實際營運中的例外狀況持續調整，時程會依資料品質與整合範圍而有落差，不是只看最初的展示效果。
Q6：品牌怎麼避免找到換了名片的顧問，而不是真正的長期夥伴？ A6：可以直接詢問對方過去案例中，現場學到的教訓具體怎麼變成產品或服務的一部分，並確認上線後的維運與優化責任歸屬清楚，而不是止於一份報告或一次性的教育訓練。