1. 先下定義：FDE 對正式環境結果負責
Forward Deployed Engineer 可直譯為「前線部署工程師」。名稱的重點不在駐點，而在把工程能力推到問題發生的現場：FDE 不只解釋產品，也要讓系統在真實資料、權限、流程與使用者限制下運作。
典型 FDE 同時面向兩端。對外，他與一線使用者、工程團隊和決策者共同拆解問題；對內，他直接寫程式、整合資料、建立評測，並把重複出現的缺口帶回產品與研究團隊。責任因此比售前技術角色更深，也比只做共通能力的產品工程師更貼近特定營運結果。
職稱本身不能保證工作內容。判斷一個職缺是否名實相符，應看它是否同時擁有正式環境交付責任、可改動系統的工程權限，以及把現場學習回饋核心產品的機制。
FDE 與相鄰角色的責任邊界
FIGURE 01 / MATRIX| 項目 | 主要責任 | 正式環境工程 | 成功指標 |
|---|---|---|---|
| FDE | 把客戶問題變成可運作系統，並回饋核心產品 | 通常直接參與 | 採用、工作流影響、可重用部署模式 |
| Product Engineer | 建立多數客戶可用的共通能力 | 直接負責 | 產品品質、使用、可靠性與交付效率 |
| Solutions Engineer | 售前驗證可行性、技術說明與方案設計 | 多以原型或整合示範為主 | 技術阻礙解除、成交與導入啟動 |
| 顧問／SI | 依專案範疇提供轉型或整合交付 | 可能參與，但未必能修改原廠產品 | 時程、預算、範疇與驗收 |
2. 由來：Palantir 把客戶現場變成產品研發迴路
業界通常把現代 FDE 模式追溯到 Palantir。該公司在 2010 年代初期建立 Forward Deployed Software Engineer 職系，內部稱為 Delta；現在的公開職缺仍沿用這個團隊名稱。
Palantir 面對的問題往往沒有乾淨需求書：資料分散、權限敏感、流程特殊，成敗又直接牽動政府或大型企業營運。標準軟體交給客戶自行摸索，常跨不過最後一哩；單靠顧問提出建議，也不足以處理資料模型、應用程式與平台缺口。
Palantir 現在將 Forward Deployed Engineering 描述為產品開發範式。工程師深入客戶環境建置功能，取得現場回饋，再把共通需求帶回平台。難點在於分辨單客例外與可泛化能力；全部接受只會形成互不相容的分支。
3. 2026 市場定位：AI 公司正把 FDE 擴成部署產業
FDE 再度走紅，不只是職缺改名。模型能力快速提升，但企業價值仍卡在資料接取、身分權限、既有系統、評測、合規與使用者採用；這些工作無法靠一個 API 或聊天介面自動完成。
OpenAI 在 2026 年 5 月宣布成立部署公司，預計從 Tomoro 帶入約 150 名 FDE 與部署專家。Anthropic 則透過 DXC 培訓數萬名 Claude 認證 FDE；Google Cloud 也公開由 FDE 支援 FANUC 的實體 AI。
市場出現兩條路線：模型或平台公司自建精銳 FDE，掌握最前線產品學習；大型顧問與系統整合商則把 FDE 變成產業化交付能力。兩者爭奪的都是把通用 AI 轉成可持續企業作業系統的位置。
4. 工作與技能：T 型工程底座，加上現場判斷
FDE 不是每個領域都只懂一點的通才。較合理的模型是 T 型能力：一條足以獨立交付正式系統的工程深度，外加跨資料、產品、資安、流程與利害關係人的廣度。
完整任務通常從開放式問題開始：先觀察工作流、定義可量測結果，再決定模型、資料、介面與控制措施。FDE 可能同一天訪談使用者、確認權限、寫資料管線、修前端、建立評測、看正式環境 Trace，並向主管說明取捨。
技術底座包括前後端、資料、API、雲端、可觀測性、測試與正式環境除錯。AI 場景再加入提示與工具設計、評測資料集、模型失敗模式、延遲與成本、安全護欄。現場工作比例也高：OpenAI 與 Palantir 的職缺都明確列出大量出差或客戶現場需求。
- 工程：正式環境程式、系統設計、資料整合、測試、監控與除錯。
- AI：模型行為、工具調用、評測、成本、延遲、權限與治理。
- 產品：問題發現、範疇控制、驗收指標、快速迭代。
- 現場：跨角色溝通、風險說明、衝突處理與移交。
FDE 從模糊問題到穩定上線的工作鏈
FIGURE 02 / FLOW觀察真實流程，不先假設解法
設定品質、時間、成本與風險指標
釐清資料、權限、架構與失敗處置
建立可重跑案例，先證明行為
接入既有工具、監控與回復機制
改流程、移交，並抽象成產品能力
5. 價值與風險：縮短能力到營運結果的距離
FDE 的價值有三層：讓客戶更快得到可用結果、讓供應商更快理解產品缺口、讓銷售承諾更接近可交付事實。只有第一層成立時，團隊只是高級外包；三層同時成立才有組織槓桿。
管理指標必須防止表面忙碌。工單、程式行數與 Demo 容易增加，卻不代表使用者採用，也不代表下一個專案更便宜。較好的計分方式同時看工作流成效、正式環境可靠性、從原型到穩定上線的時間，以及評測、連接器與 Playbook 的可重用率。
風險與優勢來自同一件事：FDE 有權越過產品既有邊界解決問題。若每個大客戶都配置高薪工程師，收入可能隨人力線性成長；若只有某位 FDE 知道資料例外與部署手法，離開後系統便難以維護。每次交付都需要範疇、不做事項、資產歸屬、Runbook、移交與退出條件。
6. 實例：醫療資訊系統的申報異常預警
假設醫療機構想用 AI 協助申報前的異常初篩。差的起點是要求「做一個能自動判斷對錯的模型」；FDE 會先把目標改寫成可驗收、可稽核且能移交的工作流。
第一階段與申報、資訊、稽核及資安人員觀察流程，找出最耗時的案件類型、可用欄位、既有規則、可接受的漏報風險與不得自動化的動作。成功指標是人工初篩時間、證據完整度、誤報、漏報與回復流程，而非模型分數本身。
接著以去識別化測試資料建立唯讀管線：規則處理明確條件，模型只補充異常排序、理由與證據連結；送出、修改金額或改寫病歷保留給授權人員。最後把資料連接器、評測案例、權限設定、監控與 Runbook 移交，並判斷共通部分是否值得升級成產品能力。
7. 未來與轉型：AI 接手操作，人類保留責任邊界
FDE 不只部署 AI，也開始被 AI 部署。Palantir 的 AI FDE 已正式可用，可用自然語言操作資料轉換、程式庫與 Ontology，並受既有權限、工具紀錄和分支審查約束。
代理最先接手的是可驗證操作：建立資料轉換、修改程式、執行預覽與 CI、查文件、重跑固定評測。人類 FDE 的價值會往上游與邊界移動：選擇問題、理解流程與權力、設計權限和可回復架構、協調採用、處理例外，並決定哪些現場模式應進入核心產品。
企業只有在工作流價值高、問題模糊、整合困難、能接觸真實使用者，而且學習可重用時，才值得配置 FDE。工程師轉型時則應用作品證明完整故事：原始問題、限制、架構、驗收、失敗與回復、實際採用，以及沉澱出的共通資產。面試時要反問工程權限、成功指標與移交條件，避免進入責任無上限的服務角色。