什麼是 FDE
FDE 在客戶現場，把「不確定的業務問題」推進成「可驗證、可運行、可沉澱」的 AI 應用。
它決定的不是「客製多少」，而是複雜度由誰吸收、如何沉澱。
工作主軸
FDE 的工作主軸是四個問題
業務建模
業務到底是怎麼做的？
方案與執行主體設計
到底哪裡有問題，未來應該怎麼做？
輕量化應用驗證
這個新方法實際上行不行得通？
工程化 · 產品化 · 經營
怎麼生產化運行、產品化，並產生業務成果？
職位比較
FDE 和相近職位的區別
| 職位 | 主要關注 | 和 FDE 的差異 |
|---|---|---|
| 傳統導入 / 交付工程師 | 按既定需求部署、設定、上線 | 需求通常已確定；FDE 要先定義問題 |
| 業務諮詢顧問 | 診斷問題、設計藍圖和流程 | 通常止於方案；FDE 要驗證並落地 |
| 軟體開發工程師 | 按規格實作功能 | 關注「做對」；FDE 還要判斷「做什麼、值不值」 |
| 產品經理 | 抽象共通需求、規劃產品 | 面向多客戶；FDE 紮根在單一客戶現場，再回饋產品 |
| 客戶成功經理 | 推廣使用、續約擴單 | 偏營運；FDE 負責能力建設本身 |
核心能力
FDE 的六項核心能力
業務理解
產業先驗、企業畫像、SOP 拆解
問題收斂
劃出一個有明確價值理由的課題
人機分工設計
每個節點：人工、自動化、AI 輔助或 AI 執行
價值驗證
指標、基線、成功門檻，用證據說話
AI 工程
Workflow、Agent + Skill、評測、生產可靠性
沉澱與回饋
經驗、Skill、資料、失敗案例變成產品能力
交付模式與複雜度
不要依「客製多少」分類，要看複雜度由誰吸收
看起來都像「標準底座 + 局部擴充」，區別在於：誰定義底座、誰控制擴充、誰承擔適配代價。
- 核心目標
- 把不確定的業務變成一次性系統
- 客戶是否改變
- 不需要改變，盡量配合客戶改
- 結束方式
- 一次性驗收，專案結束
- 收益來源
- 按專案一次性收費
模式 ① · 純客製整合類
複雜性全部在專案現場
由「人力現場承接與消化」；人在「替系統完成一切」
模式 ②③ · 底座 + 客製開發 / SAP
複雜性被結構化分攤
產品吸收部分複雜性 + 方法論吸收部分複雜性；人在「補齊產品與現實之間的縫隙」
模式 ④⑤ · 純軟硬體 / SaaS
複雜性被產品前置吸收
由「產品前置吸收與固化」；人在「設定、適配、引導客戶使用標準能力」
AI 專案從模式 ① 起步，FDE 的使命是推動它向 ②③⑤ 遷移：現場人力吞下不確定性 → 方法論沉澱做法（SOP、十步法）→ 產品能力固化（Skill、評測、資料）。
純客製整合類產業背景
FDE 從哪裡來，為什麼現在需要
起源：Palantir
Palantir 內部把 FDE 稱為「Delta」，與產品開發工程師配合，對客戶上線成果負責，並把現場經驗沉澱為可複用資產。
海外：OpenAI / Anthropic
OpenAI 的 FDE 團隊 2025 年約 39 人並計畫擴編；2026 年 5 月 OpenAI 與 Anthropic 先後與資本方成立企業 AI 交付合資公司，把「部署」視為模型之外最大的瓶頸。
國內：需求爆發
2026 年上半年國內 FDE 職缺年增 21 倍；字節、螞蟻、智譜等公開招募 FDE，月之暗面於 2026 年 9 月啟動 FDE 夥伴計畫。
資料來源：Palantir 官方部落格、Business Insider、TechCrunch、脈脈等公開報導（截至 2026 年 10 月）。
常見問題
關於 FDE 服務
+FDE 和外包開發有什麼不同？
外包按需求交付功能；FDE 先定義問題、設定價值基線，再驗證並落地，對業務成果負責，並把做法沉澱為企業自己的 Skill 和方法。
+需要駐場多久？
診斷 1–2 週，單一場景 POC 4–6 週，完整的 90 天駐場涵蓋試點準備到深度整合四個階段。可依專案節奏混合駐場與遠端。
+我們需要哪些人配合？
一名推動負責人（能拍板目標與預算）、試點部門的種子使用者各 1 名，以及 IT 負責人配合帳號、權限與系統串接。
+資料安全如何保障？
依 L1 公開 – L4 機密分級接入，先唯讀、專用整合帳號、寫入操作須經攔截確認；支援專屬雲 / 私有化部署方案。