FDE 是分辨真假 AI 導入顧問的判準，不是履歷上的職稱
市場上人人都想自稱在做 AI 落地陪跑，但真假 FDE 差在哪？這篇拆解真正的前線部署工程師怎麼工作，並給品牌主一份可以直接拿去問供應商的檢核清單，問清楚蹲點機制、需求轉譯深度、生產環境證據與經驗反饋機制，找出誰真的願意留到系統穩定為止。
Indeed 上「Forward Deployed Engineer（FDE，前線部署工程師）」的職缺數，從 2025 年 4 月的 643 個，一年內衝到 2026 年 4 月的 5,330 個，年增幅達 729%。同一段時間，AWS 宣布投入 10 億美元成立專屬的前線部署工程團隊，Microsoft 緊接著砸下 25 億美元、集結 6,000 名工程師（根據 TechCrunch 2026 年 7 月的報導）。
這是一場規模罕見的人才與資本雙重加碼。但同一時間，MIT NANDA 在 2025 年發布的《The GenAI Divide: State of AI in Business》報告卻指出，95% 的企業生成式 AI 試辦專案，最後對損益表沒有產生任何可衡量的影響（Fortune 報導）。這兩件事不必然互為因果，但同時發生本身就值得留意：錢砸下去了，職缺開出來了，市場對「落地能力」的渴求，並沒有換來多數 AI 專案真正拿得出成效。
這個落差留下一個空間：當每家廠商都想在提案上寫「我們有 FDE 陪跑」，品牌主要怎麼分辨，對方是真的願意蹲到系統穩定為止，還是把顧問這個詞換了一張新皮而已。
我們最近跟幾個零售品牌的行銷主管聊到這個話題，聽到的抱怨幾乎一模一樣：導入案簽約時聽到的是「我們會全程陪你落地」，結案時拿到的卻是一份簡報和一套沒有人維護的系統。這個場景我們並不陌生，CDP 或 AI 導入案卡在「顧問交完報告就消失」的困境，本來就是零售品牌長年遇到的痛點。這篇是「Forward Deployed Engineer」系列的最後一篇衛星文，前面幾篇分別談過需求轉譯的真相、為什麼落地速度不是成功的關鍵、換皮顧問爭議是怎麼一回事，以及技術怎麼真的走完最後一哩路。這篇要做的事情比較實際：給一份可以直接拿去問廠商的檢核清單。
FDE 這份工作，拆開來看其實是四層
本文為了說明真假 FDE 的差別，把這份工作拆成四層。市場上對 FDE 的討論常常只停在「工程師被派到客戶現場」這個表面動作，但真正決定成敗的是這四層有沒有被完整走過。
- 需求轉譯。客戶說出來的需求，往往不是真正的問題，而是問題的症狀。真 FDE 會反覆質詢、拿數據跟證據去挑戰客戶原本的假設，換皮顧問則是把客戶說的話原封不動寫進規格書。
- 快速原型。真 FDE 用最小可行的版本先驗證方向對不對，跑通一段真實流程給客戶看，換皮顧問常常直接跳過這一層，先畫完整套架構圖再說，等到真的要接資料才發現行不通。
- 系統落地與維運。這一層最容易分辨真假，系統有沒有真的接進客戶的生產環境、扛得住實際流量、通過權限與法遵檢查，還是永遠停在「Demo 環境跑得很順」的那個階段。
- 經驗反饋循環。做過的案子有沒有把學到的東西沉澱下來，變成下一次交付更快、更準的養分，還是每一個案子都從零開始，顧問換了一批人，前面累積的判斷也跟著歸零。
真正的 FDE 是把這四層走完一輪的人，而且是反覆走。換皮顧問通常只做得到第一層跟第二層的表面功夫，第三層和第四層要嘛沒做，要嘛做不到。留意一種容易混淆的情況，因為產品本身漏洞百出、天天要人救火而長期駐點，跟主動走完這四層持續優化，是完全不同的兩件事，判斷真假時值得分開來看。
Palantir 說得直白：複製品都是折扣版
Forward Deployed Engineer 這個角色不是新東西，Palantir 十幾年前就用這套模式，把工程師直接派進政府單位與企業內部，一路陪著把系統做到能用。這波 AI 熱潮讓這個角色被重新炒熱，也讓一堆公司急著把自己的顧問服務貼上 FDE 的標籤。
Palantir 的全球商務主管 Ted Mabrey 在自己的 Substack 上講得很不客氣，他說試圖複製 Palantir 這套模式的科技公司多半都失敗了，市場上看到的複製品清一色是「折扣版」（LeadDev 報導）。這句話背後的邏輯很簡單：真正的 FDE 模式需要公司願意長期承擔駐點的人力成本，換取客戶那邊真正解決問題的信任，而折扣版做的是把顧問的頭銜換掉，內部的交付方式、考核方式、合約條款完全沒變。
Unframe 的全球技術長 Chris Slovak 則從另一個角度提出質疑，公司一邊想建立自動化系統減少人力依賴，一邊又要花大錢請這批昂貴又難找的人來把系統做出來，這個模式長期撐不撐得住，業界目前並沒有共識。這個矛盾本身也是一個有用的提問方向，會把整合工作講得毫不費力、彷彿沒有任何取捨的廠商，通常代表他們沒有正面回答過這個矛盾。
AWS 跟 Microsoft 賭的不是同一件事
AWS 在 2026 年 6 月底宣布投入 10 億美元，成立專屬的前線部署工程單位，把工程師直接嵌進企業客戶內部加速 AI 落地（TechCrunch 報導）。兩天後 Microsoft 跟進，但走了一條不太一樣的路，他們成立的單位叫「Microsoft Frontier Company」，投入 25 億美元、集結 6,000 名工程師，Microsoft 商業事業群執行長 Judson Althoff 特別強調，這個規模已經超出一般所謂「前線部署工程」的定義，要做的是業界最大、最有能力、以成果為導向的工程組織。
這個對比值得注意的地方在於，兩家公司都沒有選擇最便宜的做法，也就是把現有顧問的名片換一張印著 FDE 的新卡。他們選的是真金白銀的長期投資，賭的是企業客戶會為了「真的能落地」這件事付費，而不是為了一個時髦的職稱付費。同一時間，OpenAI 也拉了私募股權夥伴成立專門做企業部署的公司，Anthropic 則跟金融機構合資做類似的事（TechCrunch 2026 年 7 月的報導）。這幾家公司幾乎同時做出同一個判斷，AI 落地這件事的瓶頸不在模型能力，在能不能把工程師留在客戶身邊，把問題真的解決到底。
值得留意的是，AWS 官方對這個團隊的定位並不是要工程師永久待在客戶那裡。AWS 官方部落格說得很明白，交付的系統要走向「自立，而非持續依賴」。這個細節其實補強了本文的判準，真正的長期投資買的是工程師願不願意留到系統穩定、知識也確實交接給客戶團隊為止，跟他們願意留多久沒有直接關係。一直待在客戶身邊不肯離開，反而可能代表產品高度依賴人力、知識沒有被移轉出來。
對台灣品牌來說，這個劇本其實並不陌生。聯發科多年來的 turnkey 解決方案事業，靠的正是台灣硬體業早就有的 FAE（現場應用工程師）角色，陪著客戶一路做到方案真的能量產、能出貨（數位時代報導）。FDE 這個詞看似是矽谷新創出來的名詞，但陪跑到底這件事，台灣供應鏈本來就懂。
換皮顧問為什麼會失敗：誘因結構本來就不一樣
把換皮顧問跟真 FDE 放在同一張提案書裡比較，看起來像是同一種服務，但底層的商業模式常常不一樣。傳統顧問案的收費邏輯多半是按專案計價，交付物做完、驗收單簽了，這筆生意就結束了，顧問公司比較沒有誘因留下來持續維護。真正的 FDE 模式反過來，公司願意承擔駐點的固定成本，換的是客戶長期續約與信任，這筆帳算的是好幾年的關係，而非單張合約上的金額。當然，傳統顧問一樣可以簽長約、用成果計價，合約名目本來就不是唯一的判準，真正該看的是對方有沒有實際走完前面那四層，而不是提案書上寫了什麼服務項目。
這個誘因落差，呼應了 MIT NANDA 那份報告裡最重要的發現。報告作者群觀察超過 300 個企業 AI 導入案例後指出，多數試辦專案失敗的核心原因，出在這些系統沒有辦法保留回饋、根據情境調整、隨時間持續學習，基礎建設、法規或人才反而只是次要因素。這份報告談的是系統本身有沒有學習機制，我們想指出的是，這個機制通常也需要有人持續在旁邊維護跟調整，一次性交付、驗收完就走的合作方式，比較難撐起這種長期調整的工作，這種悄悄失效、沒有人接手排查的狀態，跟自動化流程安靜壞掉的道理是同一件事。換皮顧問模式在誘因上確實比較難撐起這件事，但顧問公司只要真的把系統落地與維運這兩層做完、也留下持續調整的機制，一樣做得到。
真正的 FDE 之所以顯得昂貴又難找，不是因為市場炒作，而是因為需求轉譯、系統整合、生產環境維運、經驗反饋這四層工作本來就需要持續投入人力。會迴避這個成本現實、告訴品牌主「導入很簡單」的顧問，通常代表他們打算在第三層之前就結案離場。
我們自己在做的事，其實就是零售版的長期蹲點
91APP 的數據顧問服務組長年在做的事，操作邏輯跟這篇談的長期蹲點很接近，持續蹲點在品牌的會員生命週期分群、優惠券策略、跨通路歸戶這些問題上，隨著品牌的檔期、商品結構、會員狀態變化，一輪一輪重新校準判斷。這個過程裡發現的新問題、新做法，也會沉澱回饋進 CDMP 產品本身的迭代方向，累積下來的判斷不會因為換了客戶就重新歸零。
如果你手上正在評估的 AI 或 CDMP 導入夥伴，想拿這篇的檢核清單去對照看看對方到底做到哪一層，也歡迎直接找 91APP 的 CDMP 顧問團隊聊聊，看我們怎麼回答同樣的問題。重點不在你最後選了誰，這份清單本來就該拿去問每一家廠商，包括我們自己。
問對問題，才問得出誰真的蹲得住
評估一份 AI 導入提案的時候，光看對方的履歷上寫不寫 FDE 沒有意義，重點是拿具體問題去逼出答案。以下這幾組問題，對應前面拆出來的四層，可以直接照抄拿去問廠商。
- 問蹲點機制與交接計畫。合約裡有沒有明確寫出交付後的持續服務條款、駐點頻率、多久回顧一次成效，以及知識與系統要怎麼交接給你的團隊，還是只有一次性的驗收條款、也沒有交接規劃。真正願意陪跑的夥伴，會主動把檢核週期跟交接計畫都寫進合約，而不是等你追問才含糊帶過，也不會把「一直留在你身邊」講成唯一的成功指標。
- 問需求轉譯的深度。請對方描述他們上一個案子，客戶原本說的需求跟最後真正解決的問題有什麼不同。答不出差異、或是說「客戶怎麼說我們就怎麼做」的，代表他們沒有真的做過需求轉譯這一層。
- 問生產環境的證據。不要只看 Demo，直接問系統上線後跑了多久、遇過什麼問題、怎麼修的。願意講出踩過的坑、講得出實際運行細節的，通常才是真的把東西部署進生產環境過的人。
- 問經驗反饋機制。問對方學到的東西，有沒有變成方法論、工具或產品功能的一部分，還是每個專案都是獨立事件，人員一換，累積的判斷就跟著消失。這是分辨對方有沒有長期投資這個能力，還是只是接案賺一次性收入的關鍵。
- 問失敗案例。請對方講一個沒有做成、或是中途轉向的案子，並解釋原因與後來學到的教訓。講得出具體細節、也講得出怎麼調整的，通常比一長串成功案例更可信；講不出任何學到的教訓，才是真正的警訊。
這五組問題不需要對方當場給出完美答案，重點是看對方願不願意坦白回答，還是繞著問題打太極。願意講清楚做不到什麼的夥伴，通常比只講得出漂亮話的夥伴更值得信任。也可以順便問一句，系統出錯的時候，誰的名字在核准欄上，答不出這一題的廠商，代表他們從沒真的為上線後的結果負過責。
標籤可以買，蹲點買不到
AWS 跟 Microsoft 願意砸下數十億美元養一支長期駐點的工程團隊，說明了一件事，這個市場已經有足夠的錢和人才去證明，前線部署這份工作值得投資。但砸錢買不到的，是那份願意留到系統穩定、把責任交接清楚為止的承諾。一家公司可以在一夜之間把顧問的職稱換成 FDE，卻換不了合約裡有沒有寫明持續服務與交接計畫、換不了他們願不願意講出上一個案子失敗在哪。
品牌主手上握著的這份檢核清單，問的從來不是對方的職稱，而是對方撐不撐得起長期蹲點這件事，以及知不知道什麼時候該放手。問對問題，答案自然會告訴你，眼前這個人是真的準備陪你走到系統穩定，還是準備做完這一單就走。
品牌最常問的 FDE 問題
Q1：FDE（Forward Deployed Engineer）是什麼？跟一般顧問有什麼不同？ A1：FDE 是被派駐進客戶組織內部，親自參與系統建置、整合與上線維運的工程師，工作範圍涵蓋需求轉譯、原型驗證、生產環境落地與長期優化。跟傳統顧問最大的不同，是 FDE 對交付後的結果持續負責，交付不等於結案。
Q2：為什麼最近很多公司都在搶 FDE，甚至砸重金投入？ A2：因為企業普遍發現，AI 專案真正卡關的地方在落地整合，而不只是模型能力本身。MIT NANDA 的報告指出多數生成式 AI 試辦專案對損益沒有可衡量的影響，這讓 AWS、Microsoft、OpenAI、Anthropic 等公司都投入重金，搶著補上讓 AI 真正落地這塊人才缺口。
Q3：小品牌預算有限，沒辦法請專屬 FDE，怎麼辦？ A3：不一定要請一位全職專屬工程師，重點是確認合作的顧問或平台方，有沒有提供類似的長期陪跑機制，例如明訂的服務回應時間、定期的成效回顧與系統健檢，而非簽完約就結束的一次性交付。
Q4：換皮顧問跟真正的 FDE，最容易露餡的地方是哪裡？ A4：最容易露餡的是系統落地與維運這一層。換皮顧問通常只做得到前期的訪談與規劃，一旦問到系統上線後實際運行的細節、遇過的問題、怎麼排除的，就會開始含糊其辭。
Q5：導入 AI 系統後，多久算是驗證「有沒有真的落地」？ A5：沒有統一的天數，但至少要走過一次完整的業務週期，例如零售品牌的一次檔期或一個會員生命週期循環，作為觀察的起點，而不是只看上線當天的展示效果。天數只是最低門檻，真正要盯的是系統有沒有持續穩定運作、有沒有根據新的數據調整判斷。
Q6：91APP 在這件事情上扮演什麼角色？ A6：91APP 的數據顧問服務組長期蹲點在品牌的會員經營與 CDMP 應用上，做法接近零售產業版本的長期陪跑模式。品牌可以直接拿這份檢核清單來對照，評估任何一家導入夥伴，包括我們自己。