台灣誰在做 FDE？開缺的都是賣 AI 的那一方，零售品牌這一側還是空的

Deloitte 開了一個叫「Anthropic 前線部署工程師」的缺

一家全球管理顧問公司，正在徵一個以 AI 模型公司命名的工程師職位。

Deloitte Consulting LLP 的官方招募頁上，職稱寫著「Anthropic Forward Deployed Engineer」，開缺橫跨亞特蘭大、奧斯汀、芝加哥、納許維爾、紐約等 8 個城市。職務描述要求應徵者 embed with clients，也就是進到客戶內部，跟客戶的資深業務與技術人員並肩，快速把生成式 AI 的方案做出原型並交付；產出要求寫的是 production-quality code，還要留下可重複使用的程式庫與文件。平均出差時間 50%。

前線部署工程師（Forward Deployed Engineer，FDE）這個角色在過去兩年被討論得最熱烈的版本，是「工程師取代顧問」。至少在 Deloitte 這一則職缺上看到的實況剛好相反，是顧問公司自己把這個職稱掛上去，用這套方式接 AI 專案。

名單還在往外長。從 Palantir 到 OpenAI、Anthropic，再到 Salesforce 這種既有的大型 SaaS，都能點出名字、查得到公開資料。把問題換成一句「台灣有誰在做」，答案其實也點得出來，只是點出來的那幾家，跟零售品牌想像的完全不一樣。

我們把職缺頁一頁一頁開起來，發現欄位很熟，只有抬頭不一樣

我們團隊做這份盤點時，是把公開查得到的 FDE 職缺一頁一頁開起來對照的。看到後來有點恍神：職務描述裡寫的那幾件事，跟數據顧問每天在客戶端做的事幾乎重疊，進客戶現場、把資料接起來、寫進客戶的正式流程、把現場撞到的問題整理回產品。欄位越看越熟悉，只有最上面那行抬頭不一樣。

這件事目前長在三種完全不同的公司裡

把公開資料攤開來排，FDE 這件事長在三種位置不同的組織裡，各自要的東西也不一樣。

這三群公司之間沒有先後順序。同一件事被三種組織做，主要的誘因看起來也不同：做模型的要現場回饋，做顧問的要專案收入，做平台的要續約。這是從各家公開的職缺與說法讀出來的傾向，不是每一家都親口這樣說過。理解這一點，後面看每家公司的資料才不會覺得只是名字撞在一起。

順帶說明一件容易混淆的事：FDE 跟現場應用工程師（FAE）不是同一個角色。這篇不展開兩者的職稱比較，我們把力氣放在「誰在做」。

三份國際公開資料，三種在做這件事的方式

Anthropic：交付物寫得比職稱清楚

Anthropic 在自家招募系統刊登的 Forward Deployed Engineer 職缺，掛在 Applied AI 團隊底下，地點是紐約、舊金山、西雅圖。這則職缺把交付物定義得極其具體，很值得零售品牌參考：要為客戶交付 MCP server、sub-agent 與 agent skill，而且明寫這些東西會被用在 production workflows，也就是客戶真正在跑的正式流程裡。

這幾個詞對非技術背景的讀者需要一句話翻譯。MCP（Model Context Protocol）是讓 AI 讀取與操作外部系統的一套共通介面，MCP server 就是把某個系統開給 AI 用的那個接口；sub-agent 是被指派專責處理某一段任務的 AI 分身；agent skill 則是把一套做事方法寫成 AI 可以直接執行的說明書。三者的共同點是它們都會被系統呼叫，而不是被人閱讀。

這句話拆開來看，等於把「顧問交什麼」重新定義了一次。交付物不是一份評估報告，是一組會被客戶的系統呼叫的程式資產。職缺同時標出年薪 280,000 到 320,000 美元，資格要求 4 年以上面向客戶的技術經驗、正式環境的大型語言模型經驗與 Python 能力。薪資帶受地點、職級與各家薪酬策略影響，不能單獨當成難度證明，但它至少說明企業把這件事放在什麼位置。

這也是為什麼 AI 系統真正的戰場，是舊系統與正式環境那一段，會是整個 AI 導入過程中最少人願意接的一段。

Deloitte：顧問公司把這個職稱掛上去

回到開頭那則職缺。Deloitte 開這個缺，代表的是這家公司在 AI 專案上調整了交付標準：同一個團隊被要求交出可以進正式環境的程式碼，還要留下可重複使用的資產。這是單一職缺能證明的範圍，整個顧問業是否都在往這個方向走，目前的公開資料還撐不到那麼遠。

這則職缺對台灣的品牌仍然有直接用處。你如果正在跟系統整合商或顧問公司談 AI 專案，可以把這則職缺的三個要求拿去對照：對方交的是原型還是可上線的東西、對方留不留下可重用的資產、對方的人一年有多少時間真的在你的辦公室裡。這三題比任何一份方法論簡報都好用。

Salesforce：把既有團隊重新編成

Salesforce 的做法又不一樣。Salesforce 官方新聞室在 2026 年 3 月的文章寫到，公司在半年內把 FDE 團隊規模擴為三倍，成員來自三個既有團隊：工程、專業服務、客戶成功。文章裡還有一個數字值得記下來：Salesforce 內部 40% 到 50% 的 FDE 人員異動來自內部轉調。

這代表 FDE 不必然是一種要從外部高薪挖來的稀有物種。對一家已經有服務團隊、有客戶成功團隊的公司來說，它更像是把既有的人重新編組，改變他們的責任邊界與交付標準。

同一篇文章引用 Indeed 與《金融時報》的分析，寫 FDE 職缺數在 2025 年 1 月到 9 月之間成長超過 800%。這組數字在商周與數位時代的報導裡也出現過，不過該篇的寫法是「比去年同期成長超過 800%」，比較基準跟 Salesforce 的寫法並不相同。我們沒有取得 Indeed 或《金融時報》的原始資料，所以這個數字在本文只當成方向訊號，不當成可以拿去做規劃的精確值。同一篇報導提到，OpenAI 與 Anthropic 都在建立自己的 FDE 團隊，並記載這個角色源自 Palantir。

台北查得到這個職稱，開缺的都是賣 AI 的那一方

台灣不是零。我們在 2026 年 9 月 4 日，用「Forward Deployed Engineer」與「前線部署工程師」「前端部署工程師」中英文關鍵字，掃 LinkedIn 台灣站、Yourator 與 Cake 三個平台，逐則點開職缺頁確認，開得出這七則，全部位在台北：

1. Google 的 Forward Deployed Engineer, Generative AI, Google Cloud，地點欄寫的是 Taipei, Taiwan 與 Hong Kong，職務內容是把前沿 AI 產品接進客戶的正式環境、把原型變成可上線的 agent 流程、建立準確度與延遲的評估框架，並把現場觀察轉成產品建議。該則已停止收件。
2. Instrumental Inc. 的 Senior Forward Deployed Engineer - Taiwan，這家公司做製造業的 AI 檢測，客戶包含輝達與 Meta，職務明寫要到客戶工廠現場完成軟硬體部署，並在正式產線環境裡調校自家 AI 軟體。該則仍在收件。
3. Wonderful 的 Forward Deployed Engineer，這家公司做的是把企業既有工作流程改寫成可運作的 AI agent，做法是把工程師直接嵌進客戶團隊裡找機會。該則仍在收件。
4. Going Cloud 的 Senior Forward Deployed Engineer (GenAI Solutions)，這是一家生成式 AI 的資訊服務與顧問公司，職務結合客戶端的技術交付與多 agent 系統設計。該則已停止收件。
5. Dcard 為其企業 AI 平台團隊開的 GNTC - Forward Deployed Engineer，要駐點或遠端與企業客戶深度合作，從需求拆解、原型設計到雲端部署與維運，並撰寫技術白皮書與實踐手冊回饋產品規劃。該則已停止收件。
6. OakMega 大橡科技的 Forward Deployed Engineer (FDE) 前端部署工程師，地點台北市中正區，做的是企業 AI 自動化工作流程，職務從需求盤點、方案設計、Demo 與概念驗證一路到技術交付與客戶協作。該則仍在收件。
7. Aiworks 的 Forward Deployed Engineer，地點台北市大安區，年薪標 120 萬到 200 萬、要求 3 年以上經驗，這是一家專注企業 AI 應用的顧問公司，職務把顧問端的策略變成能穩定運作的系統，並交付完整技術文件與程式碼給客戶。該則仍在收件。

樣本限制要先說清楚。這份清單只涵蓋上述三個平台上公開刊登、且我們能實際點開確認的職缺，不含內推、獵才、已下架，或用「解決方案工程師」「技術顧問」這類既有職稱刊登的缺。104 人力銀行擋自動抓取，本次沒有納入，而以搜尋引擎索引到的標題判斷，該平台上還有其他家在開這個職稱的缺。換句話說，實際數量高於這七則，這份清單只會少不會多。

這裡面最值得零售品牌注意的一則，是 OakMega 不只開缺，還在自家部落格公開寫了一篇〈我們如何透過前線部署工程師，讓 AI 真正落地〉，把 FDE 的工作拆成四段：把模糊的業務要求變成技術規格、在真實資料上跑概念驗證、把驗證過的東西接進正式環境、再把學到的東西帶回產品團隊。一家台灣公司願意把這套方法當成對外的招牌來寫，代表這個角色在台灣已經開始有人認真經營。

即使清單只會少不會多，這七則放在一起還是指向同一件事：開缺的全都是賣 AI 或賣雲端的那一方。兩家外商（雲端大廠與製造 AI 公司），四家做企業 AI 的新創、顧問與系統整合商，一家是網路平台自己成立的企業 AI 團隊。沒有一家是零售或電商品牌，也沒有一家是為零售品牌做會員數據的服務商。

零售品牌那一側，在這份名單上是空的。

這份名單短，不代表零售這一側沒有人在做

台灣為什麼慢，產業媒體已經給過答案。CIO Taiwan 在 2026 年 5 月一篇由何信達撰寫的分析直接問「台灣為何沒有跟上」，並歸出四個結構性原因：台灣企業的資訊預算規模撐不起 FDE 這種高人力投入的模式、採購文化偏好最低標與 FDE 的價值計價方式對不上、既有的系統整合商生態已經在做類似但較淺的事、以及頂尖工程師的職涯首選仍是科技大廠與半導體業，願意長期駐點客戶端的人不好找。該文當時的判斷是這個角色在台灣「幾乎看不到蹤影」。

四個月後我們自己去掃，掃出七則公開職缺。這兩件事並不打架：那篇談的是相對於國際的規模，我們查的是絕對存在與否。把兩邊放在一起看反而更清楚，這個角色在台灣正在從沒有變成有，只是它先長在賣 AI 那一側。

上面四個原因之外，還有一個對零售品牌意義最大的可能性：同樣的工作在品牌端一直存在，只是掛在數據顧問、解決方案顧問、客戶成功經理、專案經理這些既有職稱底下，所以在職稱搜尋裡看不見。這幾種解釋並不互斥，我們也沒有資料可以判定哪一個是主因。

職稱這種東西是招募市場的產物：一個職稱要成立，得先有夠多的公司同時想找同一種人、也有夠多的求職者願意用同一組關鍵字搜尋，人力銀行才會生出這個分類。國際上 FDE 之所以成形，是因為一批 AI 公司在同一段時間集體遇到同一個問題：模型做得出來，客戶用不起來。

在零售這一側，做的事情高度重疊：進品牌的辦公室、把散在各系統的會員資料接起來、把行銷團隊講不清楚的需求翻成規格、系統上線後留下來看數字。這套工作方法對零售產業並不新鮮，只是一直沒有一個對外的統一稱呼。其中最難、也最少被寫進職務說明的一段，是把客戶說不出口的真實需求翻譯成規格，因為它沒辦法用交付物的頁數衡量，只能靠系統上線後的使用率反推。

這個角色在維基百科上已經有自己的條目，定義是在客戶端開發與部署軟體、常與客戶員工並肩工作一段期間的工程師，並記載 Palantir 讓這個角色普及，AWS、OpenAI、Anthropic 隨後跟進。條目存在不等於這個職業已經被正式承認，它比較像一個訊號：公共討論已經穩定用同一個詞在指同一件事。

對品牌來說，實際的後果很具體。想找這種人的時候，習慣先想「該找什麼職稱」，然後在人力銀行輸入一個台灣還沒有形成分類的關鍵字，得到很少的結果，接著得出一個錯誤結論：這種人台灣沒有。很多 AI 轉型專案卡在這裡：預算談得下來，技術也找得到，真正卡住的是搜尋條件下錯了。

換個角度想，職稱還沒成形也有它的好處。既然職稱不可靠，品牌就只能回到最原始也最準的做法：看對方交什麼、對誰負責、上線之後還在不在。比 PoC 跑多快更重要的，是系統上線之後那段時間發生什麼事，而這件事在任何職稱底下都藏不住。

零售這一側的那一格，91APP 的 CDMP 顧問團隊就是在填它

零售品牌在那份名單上是空的，這一格並非沒有人在做，而是做的人掛著別的職稱。91APP 的 CDMP 顧問團隊就是在做這件事，只是零售版。

91APP 對外公開的品牌成長顧問服務，寫的三件事跟前面那幾份職缺高度對得上：評估品牌目前系統的效能與不足，提出系統導入與 API 整合方案；全程偕同專案經理導入系統，協助品牌跨單位溝通，把線上與線下的系統接起來；定期回顧品牌的行銷與營運成效，依數據分析結果調整。進現場、接系統、上線後持續看數字，這三段就是 FDE 式交付的骨架。

換到 CDMP 的實務裡，這幾件事會長成很具體的樣子。

進客戶現場，指的是坐進品牌的會員資料裡。拿到一份匯出的報表還不算，要實際看見這個品牌的線上訂單、門市交易、票券使用與推播回應各自散在哪裡，哪些對得起來，哪些對不起來。台灣零售品牌最常見的狀況，是同一個消費者在官網、App 與門市各有一筆身分，沒有人有把握說出他們是同一個人。

接進正式流程，指的是把整理好的分群與模型接回品牌每天在跑的行銷動作。在 91APP CDMP 的實務裡，這通常是把會員分群、購買週期與商品偏好變成可以直接被行銷腳本呼叫的條件，讓行銷團隊在設定推播時挑得到人，不必另外開一份名單、手動匯出、再貼回後台。中間這幾個手動步驟每多一步，這套東西被放棄的機率就高一截。

把現場問題帶回產品，指的是顧問在品牌端撞到的限制會變成產品需求。這一段最容易被外包型的合作忽略，因為外包合約結束在交付日，沒有人有義務把客戶現場的坑帶回去修。而這正是為什麼挑 AI 工具之前要先問清楚幾個問題，其中一題就是：你們在品牌端發現的問題，會不會變成你們產品的下一個版本。

誠實講清楚邊界：這件事不是每個環節都由顧問親手寫程式完成，資料界線、個資規範與品牌內部的權限分工都會決定顧問能碰到哪一層。能對外講的是責任的落點：專案不是在交付日結束，成效檢視是週期性的，現場問題有回到產品的路徑。

要找這種人，別從職稱找起

盤點完這份名單，對台灣品牌最實用的結論是把篩選條件從職稱換成交付方式。以下幾個問題可以直接放進下一次的合作評估會議。

1. 要一份交付物清單，不要一份服務範圍簡報。請對方逐項寫出這個專案結束時你會拿到什麼：是簡報、報表、名單，還是會跑在你系統裡的程式與設定。同時要問清楚所有權與授權：訂閱終止、授權不移轉、憑證到期或基礎設施由供應商掌握時，那些會跑的東西一樣會停（預期效果：把合作內容變成可驗收的東西；建議週期：簽約前一次談定，之後每季對照一次）。
2. 問清楚上線之後誰負責。系統上線那天往往才是問題開始冒出來的第一天。實務上責任幾乎都是共同的，資料品質在你這邊、第三方平台在別人那邊、系統穩定在供應商那邊，所以要問的不是誰全責，而是有沒有寫下責任分工表、服務水準、故障分級與往上呈報的路徑（預期效果：避免上線後進入沒有人負責的真空期；建議週期：每次專案啟動前確認）。
3. 問現場撞到的問題會流去哪裡。你這邊發現的限制，是被記在對方的專案文件裡，還是會進到對方的產品規劃。也要接受一個事實：客製需求未必適合產品化，也可能因為隱私、資安或成本被拒絕，重點在對方會不會告訴你結論與理由（預期效果：判斷對方是專案思維還是產品思維；建議週期：合作滿半年時回頭檢視）。
4. 看對方有沒有讀懂你資料結構的義務。零售的資料結構有它的脾氣，會員歸戶、退貨、票券核銷、跨品牌集團的資料界線，每一項都會影響分群結果。這裡也有法規邊界，個資最小化與不可出域的環境會限制對方能看到什麼，所以要問的是在合規前提下對方願意花多少時間讀懂。以 91APP CDMP 的導入為例，前期會先把跨通路的會員歸戶與交易資料結構盤一遍，這一段做不做得完整，第三個月就會反映在分群名單的準確度上（預期效果：降低分群失準與名單重複溝通；建議週期：導入期第一個月盤點完成）。
5. 先問清楚再簽約，不要用簡報品質當判準。品牌該買的是會創造營收的系統，所以最關鍵的一題永遠是「它會不會真的改變你團隊明天的工作方式」。這一題有例外：資料治理、資安與基礎設施類的專案，合理的成果是降低風險或建立能力，不會立刻改變營收流程，評估時要先講好這次要的是哪一種（預期效果：把選型從功能比較改成流程改變；建議週期：每次選型必跑）。

抬頭不一樣，做的事是同一件

回到我們把職缺頁一頁一頁開起來的那個下午。看完之後最強烈的感覺，是這個世界正在替一件老事情重新取名字，而台灣的零售這一側還沒輪到。

這對品牌來說不是壞消息。職稱不可靠的時候，反而只能用交付物、責任邊界與上線後的行為去驗一個合作夥伴，這比看履歷上的抬頭準確得多。

台北的公開職缺已經有這幾個字，只是它們掛在賣工具的那一側。真正決定一家零售品牌 AI 轉型走多遠的，是坐在你會議室裡的那個人，散會之後會不會打開你的系統。

品牌最常問的 FDE 問題

Q1：FDE 是什麼？

A1：FDE 是 Forward Deployed Engineer 的縮寫，中文常譯為前線部署工程師。指的是進到客戶組織內部、在客戶的真實系統與資料上開發並部署軟體的工程師，通常會跟客戶員工並肩工作一段期間。這個角色由 Palantir 讓它普及，近年被 OpenAI、Anthropic 等 AI 公司採用。

Q2：台灣有公司在做 FDE 嗎？

A2：有。2026 年 9 月 4 日掃 LinkedIn 台灣站、Yourator 與 Cake 三個平台，可以逐則點開確認的台北職缺有七則，分別來自 Google、Instrumental、Wonderful、Going Cloud、Dcard、OakMega 大橡科技與 Aiworks，其中部分已停止收件。這份清單不含內推、獵才、已下架與用其他職稱刊登的缺，也未納入擋自動抓取的 104 人力銀行，實際數量高於七則。七家的共同點是都在賣 AI 或雲端服務，沒有零售或電商品牌。零售品牌這一側的同樣工作，通常掛在數據顧問、解決方案顧問或客戶成功經理這些既有職稱底下。

Q3：FDE 跟系統整合商、傳統顧問差在哪？

A3：差別在交付物與責任的終點。要判斷對方屬於哪一種，最準的方法是看合約結束那天你手上留下什麼：是一份會停在原地的文件，還是一組會繼續在你系統裡運作的設定與程式，以及那之後誰負責看著它。

Q4：預算有限的品牌，需要自己養這種人嗎？

A4：不一定要自己養。Salesforce 的公開資料顯示，它的 FDE 有相當高比例是從既有的工程、專業服務與客戶成功團隊內部轉調而來，代表這件事的重點在責任編組而非新增人頭。中小型品牌更務實的做法，是在挑選外部夥伴時把這套標準寫進評估條件，要求對方交付可運作的設定與流程，不必額外編列一個新職位。

Q5：導入之後多久看得到效果？

A5：要看起點。如果品牌的會員資料還沒完成歸戶，前段時間會花在把線上線下的身分對起來，這一段不會馬上產生看得見的成效，卻決定後面所有分群的準確度。跳過這一段直接做行銷自動化，常見的後果是名單重疊、同一個人被不同活動重複溝通。合理的期待是先看流程有沒有真的改變，再看數字。

Q6：如果對方沒有 FDE 這個職稱，要怎麼判斷做不做得到？

A6：用三個問題驗：專案結束時你拿到的是文件還是會運作的東西、系統上線後的責任分工怎麼寫、你這邊發現的問題會不會進到對方的產品規劃。這三題不需要對方有任何特定職稱就能回答，答不出來的合作對象，掛什麼職稱都一樣。

延伸閱讀

1. FDE 是分辨真假 AI 導入顧問的判準，不是履歷上的職稱
2. FDE 是不是換皮顧問？差別在報告交完之後，那個人還在不在
3. 從 CDP、CRM 到 AI Skill：客戶成功經理如何用數據分析為客戶創造營收機會