AI時代的兩個新職位：FDE 與 FDD，你該知道的職涯轉機

AI 部署失敗率高達 95% —— 問題出在哪？

根據 MIT NANDA 的調查，企業生成式 AI 試驗專案有高達 95% 無法產生可量測的業務成效。

模型不夠強嗎？不是。提示詞寫得不好嗎？也不是。

真正的問題是：AI 在最後一公里壞掉了。

企業裡十二年沒更新的 Active Directory、安全審查需要三個月跑流程、業務部門和 IT 部門的資料格式根本不相容——這些才是企業 AI 落地失敗的元凶。而這，正是 Forward Deployed Engineer（FDE） 這個職位存在的原因。 但 FDE 夠嗎？Jakob Nielsen——可用性研究的先驅，擁有 43 年 UX 資歷 —— 在 2026 年 5 月提出了他的答案：不夠。我們還需要 FDD。

什麼是 FDE？AI 落地的「最後一公里工程師」

Forward Deployed Engineer，直譯叫「前線部署工程師」。但這個名字太低調了，它其實是目前 AI 圈薪資最高、需求成長最快的職位之一。

數字說話：

• 2025 年 1 月到 10 月，FDE 職缺成長了 1,165%
• 2026 年平均薪資落在 17 萬到 20 萬美元以上
• OpenAI、Anthropic、Google、Palantir、Adobe 都在搶著招募

FDE 跟一般工程師最大的不同在於：他們不坐在總部的辦公室裡。

他們直接嵌入客戶的組織，待在工廠、交易室、醫院後台，理解客戶真實的作業環境。他們的任務是把 AI 系統跟那些混亂的遺留系統、複雜的資安規定、以及真實的業務流程「接在一起」。

一個標準的 FDE 要做什麼？

• 理解客戶的資料架構和 API 接口
• 處理企業 SSO 認證、十幾年前的 ETL 管線
• 跟安全部門談判，拿到生產環境的存取權限
• 把 AI 模型部署到能實際運作的環境

這份工作成長這麼快，是因為業界終於承認一個殘酷的事實：再好的 AI，接不上去就沒用。

FDE 的盲點：把整個舊流程加速，然後呢？

Jakob Nielsen 在他的文章裡點出了一個關鍵問題：

FDE 做得很好，但他們傾向優化「How（如何做）」，而不是質問「Why（為什麼要做）」。

舉個例子。一家銀行的商業貸款審核流程有五個步驟：
A：從客戶收集資料
B：初步風險評估
C：法遵審查
D：定價計算
E：主管簽核

FDE 幫 B 步驟的風險評估員導入 AI，讓他們快了 40%。

結果呢？

風險評估的案件積在法務部門的門口，等著跑 C 步驟。整體貸款審核時間幾乎沒變。客戶的體驗完全沒有改善。

這就是 Nielsen 說的「局部優化陷阱」。加速一個環節，只是換個地方堵車。

更根本的問題是：這五個步驟，在 AI 時代還需要五個步驟嗎？

一個先進的 AI 系統可以在幾秒鐘內讀完 500 頁的法規文件、交叉比對十年的歷史資料、同時進行數千件審核、全年無休。如果我們只是用 AI 讓人類「讀文件讀得快一點」，我們把這個技術的潛力浪費了至少八成。

這個重新設計的任務，不是工程師最擅長的。這是 FDD 存在的理由。

什麼是 FDD？組織改造的「前線設計師」

Forward Deployed Designer，Jakob Nielsen 在 2026 年 5 月提出的新職位概念。

FDD 和 FDE 一樣，不待在總部。他們一樣嵌入客戶組織，但他們關注的不是 API 端點和資料架構，而是：

• 業務目標到底是什麼？
• 哪些工作流程是歷史遺留下來的習慣，不是真的必要的？
• 誰有權決定什麼事？審批權限怎麼分配？
• 員工偷偷用的 Excel 和 Slack 裡，藏著哪些系統沒有捕捉到的知識？

FDD 是三種角色的混合體：

• 民族誌研究者（Ethnographic Researcher）：蹲在工廠裡觀察人怎麼工作
• 宏觀服務設計師（Service Designer）：重新設計整個業務流程的架構
• AI 產品策略師（AI Product Strategist）：知道什麼可以做、什麼不能做

FDE vs FDD：到底差在哪？

兩個職位互補，但不可互換。

Nielsen 的比喻很好：FDE 設計的是「如何」 —— 用什麼工具、怎麼跑。FDD 設計的是「為什麼」——誰有權力做什麼、什麼東西根本不應該存在。

FDD 最重要的四個核心能力

1. 宏觀系統思維
不只看一個介面，要能想像整個企業的運作架構。採購部門流程改了，法務部門下游的認知負荷會怎麼變？這個問題要裝在腦子裡。

2. AI 能力素養
不需要寫生產級別的 Python，但必須真的懂 AI 的「紋理」：context window 的限制、幻覺（hallucination）發生的情境、推理延遲的現實。沒有這個素養，設計出來的東西只是科幻小說。

3. 流程可觀測性
在重新設計之前，先把看不見的工作「量化」。週期時間、佇列長度、例外狀況頻率、資料重複輸入的次數——這些數字是設計的證據，不是裝飾。

4. 政治識字能力
工作流程不只是任務序列，它是部門之間、預算之間、法規之間的「和解協議」。FDD 要能讀懂非正式的權力地圖：誰可以說不、誰能推翻系統、例外發生時誰被怪罪。

FDD 的核心研究方法：找出「看不見的工作」

傳統使用者訪談不夠用了。人不擅長描述自己怎麼工作 —— 他們會忽略自動化的步驟、不提偷偷用的變通方法。

FDD 使用幾種特殊的研究手法：

認知任務分析（CTA）
觀察的不是「用戶在螢幕上點了什麼」，而是「他們在想什麼」。一個有經驗的保險核保人員評估保單時，調用了哪些記憶？在哪個邊緣案例上停下來？這些思考的軌跡，是設計 AI 智能體的基礎。

影子 IT 考古
員工為了繞過官方系統而發明的非正式工具，往往是最有價值的資訊來源。螢幕旁邊的便利貼、透過 email 流傳的 Excel 巨集、用 Slack 問的問題——這些都是正式系統沒有捕捉到的「真實組織知識」。

魔法棒技術（Magic Wand Technique）
在訪談中問：「如果你有一個無所不知、速度無限快、永不出錯的助理，你會叫他做什麼？你自己會專注在什麼？」這個問題把用戶的思維，從「執行任務」切換到「管理結果」，揭示了真正的業務目標。

當 AI 解決了認知瓶頸，下一個瓶頸是什麼？

Nielsen 點出了一個很多人忽略的問題：

當 AI 夠快了，新的瓶頸不再是「系統能不能做到」，而是「系統被不被允許做」。

如果 AI 每秒能處理一千件貸款申請，但每一件都要等人類主管簽核，我們只是把「慢的認知處理」換成了「慢的官僚審批」。

AI 原生的工作流程設計，必須同步重新設計：

• 決策授權：哪些決定 AI 可以直接做？哪些需要人類確認？
• 責任邊界：AI 做的決定，誰負責？
• 例外升級路徑：什麼情況下 AI 停下來，等人類接手？
• 稽核軌跡：怎麼讓這個系統說得清楚它是怎麼做決定的？

這些不是工程問題，這是設計問題。這是 FDD 的核心工作。

FDE + FDD：AI 部署的最強搭檔

Nielsen 的結論很清楚：FDE 和 FDD 不是競爭關係，是互補關係。他們是「AI 大腦的兩個半球」。

FDD 負責發現該做什麼 —— 研究組織心理、找到真正的工作要完成的事、設計新的 AI 原生業務藍圖。

FDE 負責把設計變成現實 —— 選擇對的基礎模型、處理向量資料庫、確保安全性和企業級穩定性。

但就算有了完美的 FDD/FDE 組合，還有一個東西缺少就會失敗：有授權的高層支持者（Executive Sponsor）。

企業 AI 導入最終不是訓練問題，是許可問題。員工會繼續用舊方式工作，直到領導層明確說：「這個步驟廢掉了。舊的 KPI 改掉了。用新系統不會被懲罰。」

改造從「組織被允許停止表演 AI 已經讓它變得多餘的儀式」那一刻才真正開始。

這對台灣的設計師和工程師意味著什麼？

台灣是全球半導體和硬體供應鏈的核心，但在 AI 軟體和服務的應用上，企業轉型的速度普遍仍偏保守。

FDE 和 FDD 這兩個職位，正在填補「技術存在、但落地失敗」的巨大缺口。

對工程師： 如果你有系統架構能力，又能跟人溝通、待得住客戶現場，FDE 的薪資和職涯軌跡會讓你驚訝。

對設計師/PM： 如果你對 UX 的理解不只是「讓按鈕更好點」，而是真的想重新思考業務流程，FDD 是一個剛被命名、等著被填滿的職位。

對所有人： Nielsen 說的很直接 —— 「傳統 UX 問的是怎麼讓這個表單更容易填。AI 原生設計問的是：這個表單為什麼要存在？能不能讓 AI 自動在背景完成這個資料交換？」 這是一個重新定位自己的機會。

FAQs

Q：FDD 需要會寫程式嗎？
不需要寫生產級程式碼，但需要能用 AI 工具、no-code 平台快速做出低保真原型來驗證想法。AI 工具讓這個門檻已經大幅降低了。

Q：FDE 和 Solutions Engineer（解決方案工程師）有什麼不同？
Solutions Engineer 通常在銷售前段支援技術演示，FDE 是在銷售之後、深度嵌入客戶環境、做實際的生產部署。工作重心完全不同。

Q：FDD 是不是就是升級版的 UX Designer？
不完全是。FDD 來自 UX 的根，但視角更寬：他們不只是設計用戶介面，更在設計 AI 智能體之間的「合約」——資料格式、信心門檻、例外觸發條件。很多 FDD 的工作成果，是沒有任何人直接看到的。