FDE：AI 時代的職業轉型號角已吹響？

👦🏻 作者: Henry（DeerFlow 團隊）^[1]

筆者最近一個月遇到了四位準備轉型的朋友——前端、解決方案架構師、產品經理、傳統算法工程師，背景、年齡、城市都不一樣，卻問了同一個英文縮寫：FDE^[2]是不是值得我去？

FDE，全稱 Forward Deployed Engineer^[2]。它在兩年前還是 Palantir 圈子裡的一個工種黑話，今天已經悄悄變成獵頭的開場白、招聘啟事的高頻崗位、以及社交媒體上“AI 時代最值錢崗位”的候選答案之一。OpenAI 在 2026 年 5 月直接以這個名字成立了 Deployment Company^[3]，初始投資 40 億美元，明確說要派工程師鑽進客戶的現場辦公，進入客戶的工作流裡；Anthropic 的 Applied AI 團隊也在四個時區同步招聘 FDE。這件事從圈內黑話變成顯性詞彙，只用了一年多一點。

筆者上一篇文章《致超級個體》[4]討論的是“人的發動機”——好奇心、自學、自驅、動手能力，如何在完整的 Closed-loop 裡被激發出來。但人不是懸浮的，人要被一個具體的崗位座標系接住。如果說超級個體是 AI 時代生產關係的“原料”，那 FDE 就是市場在這一年裡長出的、最顯性的一種“崗位形態”。

在筆者看來FDE 不在諮詢那一格，也不在外包那一格。它和超級個體最近——區別只在於，FDE 是在“模型公司 × 客戶”的夾縫裡被組織化的超級個體。

你知道嗎——Forward Deployed 這個詞從哪兒來？它原本是美軍術語 Forward Deployed Forces，指部署在海外或前線、能就近響應的部隊，對照的是留在本土基地的後方部隊。Palantir 在 2000 年代末把這個詞搬進軟件行業，用來描述“派工程師離開總部、住到客戶現場”的工作模式，連內部團隊都按軍用音標命名，叫 Delta 和 Echo。這次它被 OpenAI 和 Anthropic 重新接管，不是巧合——派工程師上前線，這件事的本質從來沒變過。

本文要回答的，是筆者最近被那四位朋友問到的三個具體疑惑：

- FDE 是不是穿了 AI 外衣的諮詢公司？它和傳統諮詢的邊界在哪？

- FDE 是不是高級一點的軟件外包？它和我現在做的乙方有什麼區別？

- 我適不適合做 FDE？哪一類人會被這個崗位放大，哪一類會被磨碎？

筆者的態度是審慎樂觀：FDE 是真的在長出來，但它遠不是所有人的轉型出口。把它講清楚，比把它講熱鬧更重要。

從 OpenAI 的 Deployment 團隊說起

如果只能用一件事來標記 FDE 這一輪重新出圈的時間點，筆者會選 2026 年 5 月 11 日——那天 OpenAI 宣佈成立 Deployment Company^[5]，COO Brad Lightcap 離開原來的商務條線、轉任 special projects 直接向 Sam Altman 彙報，全職負責這件事。同一周，OpenAI 收購了英國 AI 諮詢公司 Tomoro，一次性把 150 名 Forward Deployed Engineer 和 Deployment Specialist裝進了新公司。

值得一提的是，OpenAI 的招聘頁面同時在掛出十幾個 FDE 崗位：舊金山、紐約、華盛頓，外加按行業切的 Life Sciences、Semiconductor、Gov等垂直方向，連FDE 招聘官^[6]這個崗位本身都在招。分析師估算這個團隊在三年內會擴張到 2000–4000 人。這不是一個研究小組的規模，這是一支正規軍。

Anthropic 這邊幾乎是鏡像動作。Applied AI 團隊下面的 Forward Deployed Engineer 崗位^[7]同時在波士頓、紐約、西雅圖、舊金山、華盛頓、倫敦六地放出，要求 25%–50% 的客戶現場出差。一個最近被反覆引用的例子是金融科技公司 FIS——它在公告裡直接寫“Anthropic 的 Applied AI 團隊和 forward-deployed engineers 已經嵌入到 FIS，共同設計 Financial Crimes AI Agent，並把知識轉移給 FIS，讓它後續能獨立擴展更多 agent”。

這段話裡藏著 FDE 這份工作的真實樣子。它不是售前架構師，不是 SDR，也不是來給客戶做培訓的佈道師（Evangelist）。它是帶著模型、住到客戶代碼庫裡的工程師。Brad Lightcap 自己說得更直白：“我們的客戶告訴我們，他們需要的是從 pilot 走到 production 的能力。Deployment Company 就是把我們的工程師塞進他們的團隊，給足資源去交付。”

把這件事畫成一張圖，三方關係會變得非常清楚：

注意這張圖裡最有信息量的兩條線，是 FDE 往兩邊輸送的反饋。往客戶方向，FDE 不是把模型當 SaaS 賣，而是把客戶的數據、權限、合規、內部系統擰成一根能跑模型的管道；往模型公司方向，FDE 把客戶的真實痛點和失敗樣本帶回 product 和 research，影響 roadmap——一個反覆出錯的 tool calling pattern，可能就變成 SDK 的下一個內置抽象。

這就是為什麼 FDE 在這一輪被兩家頭部模型公司同時重新啟用，背後不是“我們也要學 Palantir 做諮詢”那麼簡單。它是模型公司的一種信號採集裝置——前線最稠密的客戶痛點，必須有自己人在場才能抓到，靠合作伙伴翻譯過來的需求總是隔了一層。Anthropic 走的是混合路徑：一邊自營 FDE，一邊和諮詢公司、PE 巨頭建合資部署網絡。一個偏自營、一個偏 ecosystem，但內核都一樣：模型公司不再只是 API 供應商，它要直接派工程師進客戶產品裡。

接下來要回答的，是兩個最常見的對照問題——FDE 和傳統諮詢（麥肯錫、埃森哲那一類）的邊界在哪？它和我們熟悉的軟件外包，又是不是一回事？

FDE 不是麥肯錫：模型邊界 vs 流程邊界

很多人第一次聽 FDE 的工作描述，第一反應是：“這不就是新版麥肯錫、埃森哲嗎？”

筆者理解這種聯想。穿西裝、出差客戶現場、坐在客戶會議室裡畫白板、和 C 級高管對齊——從畫面上看，FDE 和諮詢顧問確實長得像。但只要往裡走一層，兩者的工作肌理就完全不同。諮詢賣的是流程邊界，FDE 賣的是模型邊界。

把這兩者並排放在一張表裡，差異立刻顯現。

這張表裡最值得停一下的，是“資產折舊”這一行。

傳統諮詢最賺錢的邏輯是資產複用——一份給某家銀行的方案，下一家稍微改改再賣一次；一份零售行業的數字化 playbook 可以反覆套到三十家客戶身上。這是過去三十年 Accenture、Deloitte、McKinsey Digital 一路做大的底層經濟模型。

FDE 沒有這種資產。模型能力還在快速移動——今天還需要精心設計的 Prompt 鏈路，下一版模型可能一句話就能搞定。諮詢的“方法論沉澱”在這個速度面前會快速貶值。所以 FDE 不能用資產複用模式，必須每次跑閉環都重新跑一遍——重新評估模型邊界、重新選工具棧、重新拼產品形態。看似低效，其實是唯一能跟上模型速度的方式。

你知道嗎——Product Overhang 是什麼？筆者在上一篇《致超級個體》^[4]裡解釋過這個詞：模型能力已經超過現有產品形態，但沒有產品入口、權限和上下文把它兌現出來。FDE 這個崗位的價值，本質上就是把客戶場景裡懸空的 Overhang 兌現成一個具體能跑的產品。客戶買的不是模型 API 的調用配額，而是“有人能把這堆 Overhang 真正落地在我業務裡”的能力。

這也解釋了“項目結構”一行的差異。諮詢項目的標準結構是 SOW（Statement of Work）+ WBS（Work Breakdown Structure）+ 階段驗收：合同裡寫清楚要交付什麼、什麼時候交付、按什麼標準驗收。這套結構的前提是目標在籤合同前就已經定義清楚。

FDE 的項目走不通這一套。客戶最常說的一句話是：“我知道 AI 應該能幫我做點什麼，但我不知道是什麼。”目標本身就是項目的一部分。所以 FDE 不接 SOW，接 mission——一個相對模糊的方向；然後用 iteration 一輪一輪把方向變清楚；最後在某一輪裡，把已經積累的模型理解兌現成一個產品形態。

“交付物”這一行也值得展開。FDE 走人之後，留在客戶系統裡的是一個能跑的功能——可能很小、可能醜陋、可能沒什麼用戶界面，但它每天真的在被人調用、被人改、被人罵。諮詢的交付物是 PPT 和變革管理報告，哪怕項目裡寫過代碼、配過 ERP，最後留在客戶高管手裡的仍然是一份方法論文檔。

“護城河”一行是最微妙的。FDE 的護城河是對模型能力邊界的實時手感——你這個月跑了多少個真實客戶場景，你就比別人更知道哪些事 Claude 4.7 能做、哪些事必須等 Claude 5。這種手感不能寫進 PPT，也不能放進知識庫，它只能長在最近 90 天動過手的工程師腦子裡。

所以下次有人說“FDE 不就是新版埃森哲”，可以這樣回答：埃森哲的工程師是去重新設計客戶的流程，FDE 是去重新探明模型的邊界。前者的資產能沉澱十年，後者的資產 90 天后就要重新長一次。

FDE 不是軟件外包：共同探索 vs 需求實現

如果說“FDE 是新版埃森哲”是第一層誤讀，那“FDE 是貴价軟件外包”就是第二層。這一層更具誤導性，因為表面證據看起來非常足：FDE 真的會去客戶現場寫代碼，真的會按客戶業務定製功能，真的會被客戶調用工作時間。乍一看，和外包工程師沒區別。

但只要看一眼反饋迴路這件事，差別就藏不住了。

這張圖裡最關鍵的差別，不是圖上半部分有多簡單，而是圖下半部分多了一條向模型公司延伸的反饋鏈。這條鏈不是裝飾，它是 FDE 這個崗位存在的真正理由。把這層差異拆開來看，至少有四組對比。

接的東西不一樣。外包接 SOW——一份在籤合同前就已經定義清楚的需求清單：要做哪些功能、用什麼技術棧、按什麼標準驗收、違約怎麼賠。FDE 接的是 mission——客戶自己也沒想清楚要什麼，只知道“AI 應該能幫我做點什麼”。SOW 的前提是確定性，mission 的前提是探索。兩者完全不同的項目啟動姿態。

做的範圍不一樣。外包做的是局部交付——一個模塊、一個網站、一個數據 pipeline，做完打包走人，下一家。FDE 做的是端到端——從業務痛點開始，到模型選型、到產品形態設計、到上線後真實用戶的 retention 和 churn。

計費方式不一樣。這一點最反直覺。一家模型公司派 FDE 進客戶場，最終關心的不只是這次項目收多少諮詢費，更是：這個客戶接下來會消耗多少 token？會不會成為 retention 客戶？會不會擴展到更多業務線？FDE 的真正 KPI，是模型 token 的長期消耗曲線，不是項目驗收單上的那個數字。

反饋的去向不一樣。這是四組裡最深的一組。外包項目裡，甲方的反饋最遠只走到外包公司，不會影響外包公司未來賣給別人的產品。FDE 的反饋則迴流到模型公司的 roadmap——客戶在真實場景裡遇到的每一個坑、每一個 Prompt 失敗、每一個工具調用 bug，都會變成下一版訓練數據、下一版工具設計、下一版產品功能的輸入。也就是說，每個 FDE 部署的客戶，對模型公司而言同時也是一個天然的 design partner。

這才是模型公司願意付高薪招 FDE 的真正原因。他們不只是在賣一個服務，他們在客戶場地裡收集真實世界的產品形態信號。這些信號買不到、抓不到、問卷調研不出來——它只能由一個具體的工程師，在一個具體的客戶工作流裡，親手撞過幾次牆之後帶回來。

你知道嗎——OpenAI 和 Anthropic 的 FDE 總包能到多少？ 根據 Levels.fyi 上 Anthropic 軟件工程師的公開數據^[8]，資深 SDE 總包中位數已經到 \$710K。FDE 這個崗位 risk 更高——既要面對模型能力的不確定、又要面對客戶業務的不確定、還要承擔產品形態的不確定，所以 行業整理^[9]中提到，前沿 AI 實驗室 FDE 中高級別的總包基本落在 350K - 550K，Staff 級以上能衝到 \$630K+。這個價錢不是在為“外包工時”付費，而是在為“產品 + 客戶 + 模型”三個 risk 的合成承擔者付費。 > 回想 2006 年，筆者剛參加工作，就職於某央企，當時正在進行信息化轉型，那個時代我們集團邀請的埃森哲顧問駐場，集團需要支付給埃森哲每天 3500 元的諮詢費，一呆就是幾年，被當年的媒體稱為“金領”。筆者後來跳入德國 SAP 公司，SAP 更是定義了一個諮詢行業的名字，SAP 諮詢顧問更是“金領”的象徵。這麼看來，FDE 的薪水至少在 24 - 36 個月內是持續上漲的，需求量也是穩定上升的。

外包是勞動力套利，FDE 是前線感知器。混淆這兩件事，會讓甲方誤以為可以用 SOW 的方式把 FDE 招進來，也會讓候選人用外包的工作姿態對待 FDE。兩邊都會很快撞牆。

國外 FDE 的兩條根：Palantir 與新一代模型公司

很多人誤以為 FDE 這個詞是 OpenAI 發明的。其實不是。它有兩條歷史根脈，一條來自 Palantir，一條來自 2023 之後的新一代模型公司。把這兩條根並排看，能更清楚地理解 FDE 這個崗位真正在做什麼。

先看一張時間線。

第一條根是 Palantir。

Palantir 2003 年由 Peter Thiel、Alex Karp、Joe Lonsdale 等人創立，最早的客戶是美國情報機構。Karp 本人沒有 CS 背景——他在法蘭克福跟隨哲學家 Jürgen Habermas 念博士，回到美國後才被 Thiel 拉進來做 CEO。FDE 這個崗位，恰恰是從 Karp 這種“非典型 CEO + 高度涉密客戶”的組合裡被逼出來的：36Kr 的回顧^[10]裡寫得很直白，Palantir 早期被情報機構罵得很慘，理由是工程師拿不到真實業務場景，需求層層轉譯之後已經走樣。後來 Palantir 談下來一件事——讓自家工程師直接進客戶場地，和情報分析師一起辦公。這套模式後來被 Shyam Sankar 系統化，就成了 FDE 的雛形。

到 2009 年，FDE 擴展到商業領域。JPMorgan 部署 Palantir 的 Metropolis 平臺時，120 名 FDE 進駐做內部威脅監控。從這時候起，FDE 就不再只是“派工程師出差”，而是一種成體系的客戶嵌入打法：把 Foundry / Gotham 真正跑進客戶業務流，而不是丟個 license 就走。

Palantir 的 FDE 招聘有一條反直覺標準——不要求 CS 學歷。這件事可以放進“你知道嗎”。

你知道嗎——Palantir FDE 不要求 CS 學歷？根據 SkillScouter 整理的 Palantir 招聘標準^[11]和 Palantir 官方 careers 頁面^[12]，Palantir 明確歡迎非 CS 專業的候選人，近期 FDE 錄用者來自機械工程、經濟學、哲學等專業。它真正卡的兩件事是：能在不完整信息裡行動，以及能直接和 C 級客戶對話。CS 學位是加分項，不是入場券。Karp 本人就是這條標準最早的樣本——一個學哲學的 CEO，帶出一幫學物理、學數學、學哲學的 FDE。

第二條根是 2023 年之後的新一代模型公司。

ChatGPT 2022 年底發佈之後，OpenAI 很快意識到一件事：把模型 API 掛在文檔上讓客戶自己接，根本接不動。客戶不是不想用，是不知道怎麼用——他們有業務問題，但沒有產品形態。於是 OpenAI、Anthropic、Cohere、Scale、Glean、Sierra、Hebbia、Decagon 這一波公司，開始大規模招 FDE。

這一波 FDE 學的就是 Palantir 的 playbook——把工程師派到客戶場地，端到端把一個工作流跑通。但產品載體已經完全不同：Palantir 時代的 FDE 乾的是數據集成和 UI 定製，新一代 FDE 乾的是 Prompt 設計、Agent 編排、工具調用、工作流嵌入。

Pragmatic Engineer 關於 FDE 的專文^[13]裡把這種新版本叫做“embedded with enterprises to make Claude solve real, specific, high-value problems”——表述上和 Palantir 當年幾乎一致，只是把“數據”換成了“模型”。

把這兩條根放在一起看，能看到一組很清晰的共同點和差異。

共同點：客戶買的不是軟件。客戶買的是“能解決我問題的工程師 + 工具組合”。這件事在過去三十年的企業軟件歷史裡其實是反常的。SAP、Oracle、Salesforce 賣的都是軟件本身——工程師是為了“讓客戶用得起這個軟件”存在的輔助資源。Palantir 反過來：工具是為了“讓 FDE 在客戶那裡能解決問題”而存在的槓桿。新一代模型公司繼承了這種倒置關係——OpenAI 賣的不是 GPT-4 license，是“我們 FDE 能用 GPT-4 幫你把客服自動化跑通”。

差異：Palantir 時代偏 OPS 集成——重頭戲在數據集成、本體建模、權限治理。新一代偏模型能力落地——重頭戲在 Prompt 設計、Agent 編排、retention 優化。前者像系統集成商的進階版，後者像產品工程師的延伸版。

最後還有一個有趣的事實：Palantir 早期 FDE，後來很多成了創業者，或者直接加入了新一代模型公司。Anthropic、OpenAI、Sierra、Hebbia 的早期團隊裡，能數出一長串 ex-Palantir 名字。這不是巧合——FDE 這個崗位本身就逼著一個人同時承擔產品 risk、客戶 risk、工程 risk，幾乎就是創業者的訓練課。筆者更願意把 Palantir 看成隱形創業訓練營：它培養出的不只是工程師，而是一群知道怎麼在不完整信息裡推動一件事從零到一的人。兩條根，最後在 2023 之後合流。

國內 FDE：從解決方案架構師到 AI 落地工程師

兩條根的合流主要發生在國外。在國內，FDE 這個詞出現的時間不長，但它對應的工作內容並不是憑空冒出來的。理解國內 FDE，得先看清它的兩個本土前身，再看清它和美國版 FDE 的三個水土差異。

兩個本土前身

第一個前身是雲廠商的解決方案架構師。阿里雲、騰訊雲、華為雲在過去十年裡養出了一整套 Solution Architect（SA）隊伍，對著客戶講架構、寫 POC、做遷移方案、配合交付到上線。華為內部還有專門的“交付工程師”序列負責把項目落到客戶機房。這套體系已經在做 FDE 工作的 80%，但重心仍然在售前和部署——端到端的產品迭代責任不在 SA 手上，需求改了要走變更流程，模型換了要等總部排期。

第二個前身是 AI 創業公司裡新長出來的序列。MiniMax 在 BOSS 直聘上掛“AI 售前解決方案專家”，月之暗面、智譜、通義、混元等模型公司也都在掛類似崗位。名字略有差異，但 JD 內容高度趨同：理解客戶場景、做 demo、調 Prompt、跑 RAG、寫交付方案、跟客戶工程團隊對接到上線。這一撥崗位才是真正意義上的“國內 FDE”。

三個水土差異

私有化部署 + 數據合規壓死純模型調用模式。國內 B 端客戶對數據不出域、模型權重可控、審計可追溯的要求遠高於美國市場。一個 FDE 項目裡，純調 API 跑 Prompt 的工作量可能只佔三成，剩下七成是把模型搬到客戶機房、跑通鑑權、對接數據中臺、做合規備案。

模型能力還在追趕 SOTA，發揮空間被壓縮到工程層。美國 OpenAI、Anthropic 可以拿模型能力本身打動客戶；國內通義、豆包、Kimi、GLM、DeepSeek 的能力差異化沒那麼大，客戶的判斷點更多落在 Agent 編排、RAG 檢索質量、工具集成、Workflow 設計這些工程能力上。國內 FDE 拼的不是“我家模型多強”，而是“我能不能把這個業務真的跑通”。

B 端付費意願和定價節奏與美國不一致。Palantir 那種“先派 FDE 進駐、再收高單價訂閱”的模式很難直接複製。國內客戶預算跟著年度採購走，付費往項目制偏，FDE 的商業模型經常是訂閱 + 私有化授權 + 項目交付的混合形態。

一個獨特定位：內部 FDE

很多大廠內部的 AI 團隊，開始用 FDE 模式服務“內部客戶”。阿里雲 PAI 派工程師進駐淘寶，騰訊混元也有類似機制對接微信、廣告業務側。JD 上掛的是“行業落地工程師”“AI 應用工程師”“智能化業務專家”，本質上就是內部 FDE——把模型團隊的能力端到端跑到業務側。這給大廠 leader 一個新思路：幾個內部 FDE 蹲點在業務側、把第一個 demo 跑出來、把 ROI 數據交到業務老闆手裡，部門牆會比開十次對齊會消解得更快。

誰適合做 FDE，誰不適合

筆者在上一篇 《致超級個體》^[4]裡講過超級個體的五個發動機：好奇心強、探索和創新精神強、自學能力強、自驅力強、動手能力強。這五件事是 FDE 的入場券，但不是全部。FDE 這種崗位在五個發動機之外，還有一組非常具體的額外特質，也有幾類人格畫像明確不適合。筆者見過太多優秀工程師轉 FDE 之後水土不服，問題大多不在能力，而在性格和工作偏好。

適合 FDE 的五個特質

不抗拒銷售和溝通。FDE 的工作日常不是關起門寫代碼，而是和客戶的 CTO、業務負責人、採購、合規、IT 直接打交道。一個典型節奏：客戶 CTO 在 demo 中途打斷你，FDE 的反應不能是“我回去改一版下週再來”，而是當場打開 IDE 改 Prompt 重跑給他看。“客戶在場，我在改”是 FDE 的常態。

享受模糊地帶。FDE 拿到的不是清晰的 PRD，而是一句“我們想用 AI 做點什麼”。客戶自己也說不清楚要什麼，需要 FDE 陪他把這種模糊期望長成具體形態。如果你只在有清晰需求時才能動起來，FDE 每天都會讓你焦慮。

工程力紮實但不要求 10x。FDE 不需要你是公司裡代碼最乾淨、算法最深的那個人，它需要的是端到端能跑通：前端能糊一個能點的頁面，後端能搭一個能跑的服務，模型能接上業務數據源。在 FDE 的世界裡，“差不多就行”不是缺點，是美德。

喜歡被反饋打磨。FDE 的工作裡有大量“被客戶罵回去重來”的時刻：今天的 demo 明天被業務方說“這不是我要的”；上週對齊過的方案，這周客戶換了一個高管又要重做。適合 FDE 的人會把這種反饋當燃料，能承擔端到端責任，不甩鍋給“需求方沒說清楚”。

對模型邊界敏感。這是最技術性也最隱性的一條。FDE 要能判斷什麼任務讓 LLM 做合適、什麼不行、應該怎麼 fallback——這種敏感度看論文看不出來，只能被失敗 case 砸出來。失敗樣本累積下來，FDE 才會長出對模型邊界的肌肉記憶：什麼場景要用 RAG，什麼場景要走規則，什麼場景必須給人類一個 fallback 入口。

不適合 FDE 的四類人

想躲在代碼裡的純技術控。FDE 大約 50% 的時間不在寫代碼——在客戶會議、內部協調、產品討論、合同推進上。如果你的快樂來源是連續四小時無人打擾地寫代碼，FDE 會讓你長期處於精神耗竭狀態。

需要 OKR 才能動起來的人。FDE 的目標長在客戶那，不長在你的績效表裡。工作進度由客戶的項目節點、模型的能力變化、自己對場景的判斷共同決定。習慣“先有 OKR 才知道要做什麼”的人會找不到錨點。

把“晉升”看得比“作品”重的人。FDE 在大廠晉升體系裡不佔便宜——客戶滿意度、項目簽單、複用率這些指標，跟代碼量、上線頻次比起來在職級評審裡說不響。如果你的工作動機裡晉升排第一，FDE 不是好選擇。

抗拒商業語境的人。FDE 必須理解客戶的 P&L、ROI、採購流程、合規要求。如果你天然反感談錢、談合同、談商業邏輯，FDE 的工作會讓你覺得自己在出賣技術理想。

Self-Check 清單

7 個問題，每個對應 FDE 的一種真實工作場景。答 5 個以上“是”可以認真考慮 FDE，答 3 個以下建議慎重。

1. 你願意把每天 50% 的時間從代碼挪到客戶會議、回消息和電話上嗎？

2. 客戶告訴你“這個不行，我也說不清為什麼”的時候，你的第一反應是好奇心，還是不耐煩？

3. 沒有人給你寫 PRD，你能不能在一週內和 Claude Code 一起跑通一個能給客戶看的原型？

4. 同一個交付，客戶讓你改了 8 個版本，你還能保持判斷力，而不是機械執行？

5. 當模型給出錯誤答案，你的第一反應是設計 fallback，還是抱怨模型不行？

6. 你願意籤合同、寫彙報、跑客戶驗收、跟法務對合規條款嗎？

7. 你能接受快速原型和快速失敗嗎？

五個特質、四類反向畫像、七道自測題，最終是同一個問題：你願不願意讓自己的產品感、工程力和商業判斷三件事，在同一個工作流裡被同時打磨。

結語：從超級個體到超級崗位

筆者在上一篇文章裡討論的是“人的發動機”：好奇心、探索精神、自學能力、自驅力、動手能力，怎麼在大廠內部被完整閉環激發出來。這一篇討論的是另一件事——崗位形態。FDE 是 AI 工業革命裡第一個有名字、有薪資帶、有招聘 JD、有客戶付費驗證的新崗位形態。它不是“超級個體”概念的同義詞，而是這一波重構裡第一個從虛到實落地的座標。

FDE 不是終點。筆者的判斷是，FDE 只是新分工裡第一個長出名字的形態。後面還會有 Forward Deployed PM、Forward Deployed Designer、Forward Deployed Researcher——所有跟客戶場景緊密耦合、需要在模糊地帶把產品長出來的工種，都會冒出自己的“前置部署”版本。崗位名字會變，但底層邏輯是一樣的：模型能力跑在前面，產品形態在後面追，崗位結構跟著工作流重新切分。

給三類讀者各留一句話。

給技術人：FDE 不要求你是公司裡代碼最強的那個人，但它要求你願意把一半時間從代碼挪到客戶那邊。如果你的回答是“願意”，市場窗口剛開，國內頭部模型公司、雲廠商和大廠內部 AI 團隊的招聘都在加速。如果回答是“不願意”，那也沒什麼問題，新分工裡還會長出別的位置給你。

給 HR 和 OD：警惕“名實分離”。你公司可能已經有一批 FDE 在跑了，只是崗位編碼上掛著“解決方案專家”“行業架構師”“AI 應用工程師”。識別他們、重新分類、給他們一條對得上工作內容的成長通道，比從零招新人更高效。

給管理者：FDE 模式不只能對外，也能對內。在公司內部設幾個“內部 FDE”蹲點在業務側，把模型團隊的能力端到端跑到業務流程裡，可能比新建一個 AI 部門、再開十次跨團隊對齊會要高效得多。部門牆不是被組織設計消解的，是被一個能跑通的 demo 消解的。

AI 時代的職業轉型已經打響，FDE 是第一發信號彈，它告訴我們：模型能力變化的速度，已經快到逼出新崗位的程度。筆者想留給讀者一個具體的問題——如果三年後你的公司組織架構圖上多了三個新崗位，你猜會是哪三個？想清楚這個問題，比讀完這篇文章本身更有用。