FDE 會退燒，但它背後的能力不會
AI 剛爆紅那陣子，最熱門的職稱是 Prompt Engineer。兩三年過去，這個詞幾乎沒人提了，取而代之的是 FDE，前線部署工程師（Forward Deployed Engineer）。根據《Business Insider》引述 Indeed 的數據，2026 年 4 月的 FDE 職缺數比一年前成長約 7 倍；印度 IT 服務商 TCS 更宣布要建立最多 8,900 人的 FDE 團隊。
看到這波熱潮，我的第一個反應是：這會不會又是一個假議題？讀完《數位時代》近期的兩篇專題，又反覆推敲之後，我修正了自己的看法。結論是：FDE 這個職稱大概會退燒，但它指涉的能力不會，而且門檻只會越來越高。以下是我推演的過程。
FDE 到底在做什麼¶
FDE 這個角色源自 Palantir，原意是把工程師派駐到客戶現場，協助導入解決方案，後來被 OpenAI、Anthropic 等公司大量複製。《數位時代》專訪了台灣 Linker Vision 的 FDE Lead Summit，他把這份工作定義為「翻譯」：客戶說要 A，深入了解後才發現真正的痛點是 B。FDE 的第一件任務，就是把真正的問題翻譯出來。
文中有個例子很傳神。他們替高雄市做「AI 辨識路面坑洞並自動派工」，技術上不難，但照客戶給的規則做出來之後誤報連連。追問下去才發現，該派給哪個單位，全靠承辦人員看一眼的經驗判斷，背後有一整套從沒被寫下來的規則。團隊只能先做出東西給對方看，再來回修正，一點一點把隱性知識挖出來。
Summit 的說法是：「模型能力其實都已經夠強了，真正卡關的是部署。」
職稱是炒作，需求不是¶
說 FDE 有炒作成分，證據其實就在報導裡。Summit 2025 年剛加入公司時，頭銜是「AI 解決方案架構師」，後來才因應業務改名為 FDE，工作內容沒變。TCS 一口氣要招 8,900 名 FDE，比較合理的解讀是把既有的顧問與交付工程師換個名字，而不是市場上突然冒出八千多個新能力。硬體業也早有類似角色，例如 IC 設計公司的 FAE（現場應用工程師）一直都在「陪客戶做到成功」。
但職稱被炒作，不代表需求是假的。這裡 Prompt Engineer 的類比只對了一半。Prompt Engineer 會消失，是因為那個技能太薄：模型越來越懂人話、人人都學會怎麼下指令之後，它就被吸收了。FDE 的核心卻是定義問題、挖出隱性條件、理解 AI 的能力邊界、對結果負責，這些不會因為模型變強而被吸收。Summit 用「乘法」來比喻：模型越強，放大的倍數越高，但如果一開始的問題就定義錯了，再強的模型也只會把錯誤放得更大。
所以我的修正版是：職稱會退燒，能力的需求會留下來，而且隨著 AI 越強，門檻反而越高。當執行越來越便宜，價值就越集中在「知道該執行什麼」上。
為什麼是現在：產品不成熟期的過渡安排¶
報導裡有個觀點值得細想。Summit 認為 AI 公司轉向 FDE 模式，是因為 AI 產品跟傳統 SaaS 本質不同：SaaS 規格明確、可以標準化販售；AI 產品從一開始客製程度就很高，賣的其實更像顧問服務。
換個角度看，這等於承認 FDE 是在用人力補產品的不足。如果這是主因，FDE 熱潮就帶有週期性：等 AI 產品成熟到能開箱即用，大規模駐點的需求就會縮回到少數高價值客戶。這比「AI 讓職位收攏、所以門檻變高」更能解釋為什麼現在特別缺 FDE，也更能解釋為什麼它會退燒。
前車之鑑：DevOps 走過的路¶
比 Prompt Engineer 更貼切的類比，是 DevOps。
DevOps 一開始是一種開發與維運協作的文化，後來變成熱門職稱，人人都在招 DevOps Engineer。之後職稱逐漸淡化，分成兩條路：一條是 platform engineering，由專門團隊打造內部平台，讓各團隊自助部署；另一條是 DevOps 能力變成資深工程師的基本素養，不再是獨立職位。
我猜 FDE 也會走類似的路：一部分沉澱為資深工程師、解決方案架構師、資料分析負責人的必備能力；另一部分則轉化成組織形態，也就是平台加推廣（enablement）。
另一條路：把 FDE 民主化¶
我自己在企業內負責 AI 的底層：決定哪些 AI 工具和共用技能可以用、怎麼讓它們穩定運作。而各種小工具的開發權，其實正逐步移轉到使用者自己手上。
這背後的邏輯很單純：隱性知識在使用者腦中，而不是在 FDE 腦中。FDE 要靠反覆訪談和原型才挖得出來的規則，使用者本人透過 AI 就能直接寫成能跑的程式。這時候，使用者做出的原型本身就是最好的需求規格，比任何需求文件都精準。
如果把挖掘隱性知識的工作全壓在 FDE 身上，很容易回到傳統 PM 的困境：開發者覺得 PM 不懂技術，PM 抱怨開發不照時程，中間的每一層轉述都在流失資訊。讓懂業務的人先動手，正好把第一層翻譯損耗拿掉。
這不是反對 FDE，而是把 FDE 民主化。Palantir 原本的設計也是駐點團隊在平台上幫客戶客製，核心產品團隊再把重複出現的做法收進平台。差別只在於，駐點那一層交給了使用者本人。
整合，是永恆的卡點¶
不過 PM 困境不會消失，只會搬到「整合」那一步。使用者的原型交給平台團隊整合時，衝突會換個形狀回來：使用者覺得工具被改壞或拖太久，平台團隊覺得程式根本沒辦法維護。
實務上我看過兩種做法，適用時機不同。
第一種是先讓開發者做出工具，再拿成品當溝通的錨點。這適合問題還說不清楚的探索期，就像坑洞案例，要先有東西，隱性規則才挖得出來。
第二種是先規劃好出口和入口、介面分離，中間的工具讓大家各自開發，至少確保有東西可看，再隨專案推進逐步併回既有系統。這適合問題輪廓已經清楚的時候。它的風險是介面定得太早，等於在隱性條件浮現前就先把輸入輸出寫死了。坑洞案例裡，原本的輸入只有「有沒有坑洞」，後來才發現派工還需要坑洞大小和路段位置。所以 v0 介面應該被當成假設，預期它會改。
在這兩種做法之上，我認為最有槓桿的一步是：請使用者交出測試案例，而不只是程式碼。隱性知識大多藏在例外情況裡，例如「這種狀況其實不算異常」、「這個情境要另外處理」。只收程式碼的話，整合時一重構，這些規則就可能悄悄消失。若同時收下一組「這個輸入，應該得到這個輸出」的範例，隱性知識就被鎖成可驗證的形式。介面定義輸入輸出的形狀，測試案例定義行為，兩者合起來，才是使用者和平台團隊之間完整的合約。
此外還需要明確的「畢業條件」：什麼情況下，一個小工具要從使用者自行維護升級為平台接手？例如使用人數超過門檻、開始影響正式決策、變成例行排程，或原作者即將調職。沒有規則，整合團隊就會變成新的瓶頸。
至於一次性或小型工具，就該讓每個人都能自己做。但要注意，防止發散的不是「人人會開發」，而是「人人在同一個平台上開發」：共用的資料存取與權限、共用的技能庫、一個查得到別人做過什麼的目錄。
激勵：熱血者之後，還有一道鴻溝¶
要讓使用者願意動手，需要兩種激勵：一是主管或制度的鼓勵，二是分享與被看見的舞台。前者是外在激勵，後者偏內在激勵。核心群體會願意貢獻，邊緣的人至少不會反對。
這很像 Everett Rogers 的創新擴散理論：最熱血的人先加入，再慢慢擴散到大多數人。但 Geoffrey Moore 提醒過，早期採用者和務實多數之間有一道「鴻溝」，不會自然跨過去。熱血者為了好玩和被看見而投入；務實派只問：這能不能省我的時間？同類工作的人用過嗎？壞了誰負責？要跨過鴻溝，靠的是複製改兩行就能用的范本、對方領域裡的成功案例，以及平台會有人維護的保證。
還有一個陷阱：如果制度獎勵的是「做了幾個工具」，就會掉進 Goodhart 定律。工具數量膨脹，發散更嚴重。比較好的指標是使用率、被重用的次數，或實際省下的時間。
結語：別追職稱，追能力¶
回到最初的問題：FDE 是假議題嗎？不完全是。它是一個真實能力被貼上的時髦標籤，標籤會換，能力會留。
對個人來說，與其追逐下一個熱門職稱，不如練好它背後那幾件事：把模糊需求收斂成正確的問題、挖出沒人寫下的規則、知道 AI 能做什麼、不能做什麼，然後對結果負責到底。
對組織來說，AI 時代傳統軟體工程的 know-how 反而更重要，而不是更不重要。AI 讓「做出一個能跑的東西」幾乎零成本，卻沒有降低「讓它三年後還能維護」的成本。失敗有兩種：做錯了東西，和把東西做錯。前者靠定義問題的能力來避免，後者靠架構與工程紀律來避免。少了任何一個，產出的都會是又笨、又無法延續的工具。
Comments
Loading comments…
Leave a Comment