FDE 職位在找什麼樣的人？工程師轉職最常缺的，是端到端交付的完整經歷
FDE 職位近來成為工程師轉職的熱門選項，但本文引用的公開職缺裡，明列的年資門檻從一年到五年以上不等。這篇把 Palantir、Anthropic、OpenAI 的公開職缺攤開來看，把職缺反覆要求的能力整理成交付、轉譯、判斷三層，再對照後端工程師、資料工程師、解決方案架構師、技術 PM、客戶成功五種背景可能卡在哪一層、可以用什麼方式補。每一段也附上給品牌端的判讀，讓要找這種人的公司知道該追問什麼。
同一個職稱，三份公開職缺開出來的年資門檻分別是一年、四年、五年以上。這個落差本身，就說明了 FDE 這個位置在不同公司補的是不同的洞。
同一個職稱，年資門檻從一年到五年以上都有
Palantir 是最早把 Forward Deployed Software Engineer 做成正式編制的公司。翻開它掛在官方招募頁上的 Forward Deployed Software Engineer 職缺，硬性條件那一欄第一句寫的是「1+ years of relevant, post-college work experience」，出社會滿一年就可以投。後面接的是紮實的工程要求：Python、Java、C++、TypeScript 至少一項要寫得好，以及願意接受最高 25% 的出差比例到客戶現場。
Anthropic 的 Forward Deployed Engineer 職缺寫的是「4+ years of experience in a technical, customer facing role」，四年以上，而且限定是面向客戶的技術角色。它還多要一項 Palantir 那份沒有的東西：production experience with LLMs，包含進階提示工程、代理程式開發、評估框架，以及大規模部署。
OpenAI 的 Forward Deployed Engineer 職缺則要求五年以上的工程或技術部署經驗，而且經歷裡必須包含面向客戶的工作。
一年、四年、五年以上。同一個職稱，同樣都寫著 Forward Deployed，門檻卻拉出這麼大的區間。
這個落差常被解讀成「AI 公司比較挑」。我們的看法是，這幾份職缺在找的人本來就不同，補的洞也不同。而對一個正在考慮要不要轉過去的工程師來說，先看懂這件事，比先去背一份能力清單有用得多。
那句被略過的英文，才是這個職位的重點
一個常見的場景是這樣：工程師點開職缺頁面，讀到 engaging directly with customer stakeholders, from technical teams to executives 這一句，把它理解成「要很會做簡報、要懂應酬」，覺得自己不是那塊料，然後關掉頁面。
可惜的是，同一段裡更關鍵的另一句常常被略過：own the end-to-end execution。
這兩句話講的是同一件事的兩面。要能直接跟客戶的技術團隊到高階主管對話，是因為端到端的責任落在你身上。即使交付需要跨團隊協作，你仍然得持續追蹤需求範圍與上線結果，不能把一次交接當成責任的終點。這個角色的難度來自這裡，跟口才好不好關係不大。
能力落差出現在交付、轉譯與判斷
我們把公開職缺裡反覆出現的要求整理成三層能力。以下為本文為了說明轉職落差而提出的分層，不是產業公認標準。
| 能力層 | 公開職缺上的原句 |
|---|---|
| 交付層 | Own technical delivery from first prototype to stable production |
| 轉譯層 | 專案常從一個開放式問題開始，例如「為什麼我們延誤了這麼多航班」 |
| 判斷層 | Responsibilities look similar to those of a hands-on AI startup CTO |
交付層講的是，你寫的東西要能在客戶的正式環境裡穩定運作。這一層最常被低估，因為它的難處不在寫得出來，在於要跟舊系統與既有流程共存，而那段路上可能遇到文件不完整、測試環境受限，或是缺少原系統維護者的情況。
轉譯層講的是，客戶丟過來的問題不會長成規格。Palantir 的職缺直接把問題形態舉例出來，例如「我們要怎麼預測並降低野火風險來調度電網」。從這句話走到一份可以動工的規格，中間要補的判斷相當多，而且通常客戶自己也說不清楚他要的是什麼。
判斷層最抽象，也最難教。它處理的是「做到哪裡算完成」這種沒有標準答案的問題。Palantir 用一句話形容這個角色的職責形態：像動手做的 AI 新創技術長。這句話講的是責任的形狀，範圍你自己界定，停損你自己喊，而且在專案交付完之後，你還在現場面對後果。
職缺門檻已經分成不同的要求組合
把幾份公開職缺並排讀，會看到要求的組合方式明顯不同。
- Palantir 的原版 FDSE：一年以上工作經驗即可投，重點壓在工程通才與現場適應力，出差比例最高 25%，職責形態被形容成新創技術長。它要的是能被丟進陌生產業、在幾週內搞懂狀況並寫出東西的人。
- Palantir 另外開的 Forward Deployed AI Engineer：同一家公司、同一個現場邏輯，但硬性條件換了。它要求 past experience building solutions with LLMs，加上機器學習的基本功，職缺原文把 Evaluation、Training、Problem Decomposition 三項並列。評估能力被寫成明列條件之一。
- Anthropic 的 FDE：四年以上面向客戶的技術經驗，加上大規模部署 LLM 的實作經驗。更值得注意的是它列出來的交付物：MCP servers、sub-agents、agent skills。這已經具體到列出你交出去的東西叫什麼名字。
- OpenAI 的 Forward Deployed Engineer：五年以上工程或技術部署經驗且包含面向客戶的工作，職責從需求探索（discovery）、技術範圍界定（technical scoping）、系統設計、實作一路到上線部署（production rollout），衡量成效的方式是客戶是否真的在正式環境用起來。
現場密度也是一個容易被忽略的篩選條件。Palantir 給日本政府專案的 FDSE 職缺寫的是 25% 到 75% 的出差比例，跟商用版本的最高 25% 差距很大。轉職前把出差比例當成工作條件的一部分來評估，跟評估技術要求一樣重要，它決定的是你未來有多少時間不在自己的辦公室。
把這幾份放在一起讀，至少可以看到兩種要求組合。一種偏工程通才與現場交付，年資門檻反而較低。另一種在這個基礎上，額外要求 LLM 的部署與評估經驗。這是從樣本歸納出來的觀察，不代表所有 FDE 職缺都能這樣二分。所謂把模型行為當成工程變數，指的是你能回答「這個輸出為什麼會變」「怎麼衡量它有沒有變差」「上線後怎麼監看」這一類問題，而不只是把提示詞寫得漂亮。
順帶釐清一個常見的混淆：這跟售前技術支援的 FAE，責任範圍可能有重疊，判斷還是要回到各家職缺寫的交付責任。
不同工程背景，會卡在不同的能力層
看懂三層能力之後，轉職這件事就從「夠不夠格」變成一個可以定位的問題：以你現在的工作內容，這三層裡你已經站穩哪一層、空在哪一層。
以下是依常見分工提出的檢查假設。職稱不能直接決定能力，讀者仍須拿自己實際的交付經歷逐項核對。
後端與全端工程師
可能已經有的：如果你長期負責正式環境的開發與維運，交付層通常是現有優勢。寫得出能上線的東西、懂部署、懂故障排除，這些都是職缺硬性條件裡最難速成的部分。
可能空的是轉譯層。日常工作裡，需求多半已經被產品經理或架構師轉譯過一輪才送到你面前，你練的是把規格變成程式，很少練把混亂變成規格。轉到 FDE 之後，沒有人會先幫你把問題整理好。
補法：主動接一個沒有規格的內部需求，強迫自己先寫下驗收條件再動工。驗收條件要寫到可以被別人拿去判定成敗的程度，例如「這份報表每天早上八點前產出，缺資料時要發出通知，不能靜默跳過」。寫得出這種句子，就是轉譯層開始有東西了。
品牌端判讀：這類人選的工程基本功通常最穩，面試時可以請他示範如何把一段模糊需求寫成可驗收的規格。
資料工程師
可能已經有的：交付層的一半，加上一項很稀缺的資產，就是對資料現實的耐受度。你知道欄位會髒、時區會錯、上游會突然改格式，這種心理準備在客戶現場價值很高。
可能空的是兩塊。一塊是前台體感，你熟悉的是管線，較少直接面對使用者按下按鈕之後看到什麼。另一塊是模型輸出的品質管理方式：資料管線常能用結構定義、完整率與延遲門檻來檢查，模型輸出通常還需要分級判準、樣本評測與分布監看。兩者都可能在沒有報錯的情況下發生品質退化。
補法：做一次帶評估的小型 LLM 工作流。重點不在模型，在你有沒有替它建一組固定的測試題與判定標準，讓你能回答「這次改動之後有沒有變差」。Anthropic 那份職缺把 evaluation frameworks 跟 prompt engineering 並列，是有原因的。
品牌端判讀：他們最懂資料的真實狀況，面試時可以確認他是否具備從使用者端反推需求的經驗。
解決方案架構師與售前技術
可能已經有的：轉譯層通常較強。你每天都在把客戶的模糊需求變成架構圖，也習慣同時面對技術窗口跟決策者。
可能空的是交付層。架構圖交出去之後，多半由別的團隊實作，你不一定會親手處理上線那天的意外。而 FDE 的價值有很大一塊壓在那一段。
補法：把最近一次提案的架構圖，親手做成一個能跑的東西，交給真實使用者用，然後撐過第一次故障。規模可以小，關鍵是「真的有人在用」跟「壞掉時你要修」這兩件事同時成立。
品牌端判讀：轉譯能力好的人容易在面試表現出色，值得追問他親手寫程式並處理上線故障的具體經歷。
技術 PM
可能已經有的：判斷層。你熟悉排序、範圍控制、跟不同角色協調，也習慣在資訊不完整的情況下做決定。
可能空的是動手交付的紀錄。這幾份公開職缺都寫著 strong coder 這類要求，這不能用「會帶團隊」繞過去。
補法：重新建立可驗證的程式交付紀錄。可以選擇經公司核准的內部工具、沙盒環境，或有真實使用者的開源專案，把它從構想寫到上線，再經歷真實的問題回報與修正版。要避開的是未經授權就把練習專案推進公司的正式環境，那會踩到資安與職務邊界。
品牌端判讀：判斷力與協調力好的人選，工程實作能力需要用程式碼審查或小型工作樣本來確認。
客戶成功與技術客服
可能已經有的：現場感與信任關係。你知道客戶最在意的那件事，通常不會寫在需求單上，也知道哪句話會讓對方的主管尷尬。這在職缺裡被寫成 customer facing，但份量比那個詞看起來重得多。
可能空的是交付層，而且缺口通常最大。是否符合職缺要求，取決於能否提出正式環境等級的程式交付與維運證據。
補法：從資料操作開始，先不要挑演算法。把每個月手工整理的報表寫成腳本，再把腳本接成排程，再讓它出錯時會通知你。這條路徑會同時長出程式能力跟正式環境的紀律。
品牌端判讀：現場感與客情是既有優勢，工程交付能力的養成期通常較長，適合當作長期儲備人選來培養。
轉過去以後，第一週常卡住的是資料
我們把話題拉回品牌端這一側，因為這是很多人轉職之後最意外的地方。
在會員分群、推薦與行銷觸發這類零售情境裡，工程師常常得先確認一件事：同一位客人在官網跟門市的資料，能不能正確歸戶到同一個人。這件事沒處理好，你想做的自動化不管多聰明，算出來的名單都會把同一個人數兩次，也會把在門市買過的人當成從未購買的新客。
跨通路的身分整合是 91APP CDMP 的基礎工作之一。對品牌端來說，這決定了後面的分群、推薦、觸發能不能建立在同一份底稿上；對一個剛轉進來的工程師來說，這決定了你的交付有沒有辦法被驗收。
還有一件事同樣重要。你交付的每一份名單、每一次自動發送，事後都要能回答「這批人是怎麼被選出來的」。這聽起來像治理議題，做起來卻是工程議題，因為能不能查回去，取決於你在設計階段有沒有把選取依據留下來。設計階段先留好，可以省下日後補建稽核紀錄的成本。
補洞的順序，決定你轉得成不成
轉職這件事最常見的失敗方式，是把時間花在自己原本就擅長的那一層上，因為那樣做起來最舒服。以下是我們建議的順序與做法。
- 先補最深的那一層。用前面五種背景的對照，誠實找出自己空的是交付、轉譯還是判斷，然後把下一段準備期的力氣集中在那一層（預期效果：履歷上出現的是缺口被補起來的證據，而非既有強項再加強一次；檢查點：每完成一項練習就回頭確認缺口有沒有縮小）。
- 找一個有真實使用者的小案子，跑完整個週期。從需求模糊的狀態開始，一路到上線、故障、修復、被抱怨、再改一版。規模可以小，完整度要夠（預期效果：面試時你講得出具體的取捨與後果，而非只列出用過哪些工具；檢查點：以跑完一次完整交付週期為準，不以投入時間長短為準）。
- 把一次 LLM 工作流做到帶評估。固定一組測試題、寫下判定標準、每次改動都跑一次。這一項是兩種要求組合之間最短的那座橋（預期效果：能回答「怎麼知道有沒有變差」，這是公開職缺明列的要求；檢查點：先完成一個可重跑、結果可以互相比較的評估版本）。
- 動手之前先寫驗收條件。這是轉譯層唯一能刻意練習的動作，成本極低，效果很直接。寫不出驗收條件，通常代表你還沒聽懂需求（預期效果：需求誤解在動工前就被攔下來；檢查點：每一次接需求都做，並回頭比對驗收條件有沒有被滿足）。
- 給要找這種人的品牌端：面試時用職缺的語言問，不要問溝通能力好不好。可以請他描述一次交付上線後出問題的經過，聽他怎麼決定要修到什麼程度；也可以請他描述一次把沒有規格的需求變成可動工方案的過程。口述之後要繼續追問時間線、限制條件、事故紀錄與具體產物，必要時搭配程式碼審查或小型工作樣本，再回頭確認他是否真的有交付證據（預期效果：篩掉履歷關鍵字漂亮但沒扛過現場的人；檢查點：每次徵才都用同一組問題，才比得出高下）。
站到客戶那一側，才知道自己還缺什麼
回到開頭那個關掉頁面的場景。很多工程師重讀 own the end-to-end execution 這句話的時候會想到同一件事：自己寫的東西，每一次都在某個環節被交給別人接手，所以從來沒機會知道自己的判斷到底對不對。
一年跟五年之間的距離，量的是里程。從職缺文字可以推測，Palantir 願意考慮年資較短但工程底子足夠的候選人，Anthropic 與 OpenAI 則期待應徵者進來時已經具備面向客戶與部署 LLM 的經驗。這是依職缺文字所做的推論，不是兩家公司對外說明過的徵才原因。兩條路都通，只是起跑點不同。
對台灣的品牌端來說，這件事的意義也很直接。你要找的人，履歷上多半不會寫著 FDE，因為這個職稱在台灣的招募頁上並不常見。你要找的是願意站到你這一側、把東西交到會被真實使用者罵的地方，然後留下來把它修好的人。這種人一直都在，只是過去沒有一個好用的名字。
常見問題
Q1：FDE 是什麼職位？
A1：Forward Deployed Engineer 是直接與客戶合作、對技術方案在客戶端能否運作負責的工程角色。它最早由 Palantir 制度化，目前 Palantir、Anthropic、OpenAI 都設有相關職缺。與一般軟體工程職位最大的差別在於，它同時承擔需求釐清、系統設計、實作與上線後的責任，而不是接收已經整理好的規格。工作可能包含駐點或出差，現場比例依公司與團隊而異。
Q2：沒有 LLM 或 AI 相關經驗，還能轉 FDE 嗎？
A2：本文引用的職缺裡可以看到兩種要求組合，一種把重點放在工程通才與現場交付，年資門檻反而較低；另一種才額外要求 LLM 的部署與評估經驗。從前者切入之後再補 AI 能力，是可行的順序。最短的一座橋是把一次工作流做到帶評估，讓你能證明自己會衡量輸出品質。
Q3：轉職作品集應該放什麼？
A3：放能證明端到端交付的東西，比放技術清單有用。一份好的作品集會交代需求最初有多模糊、你怎麼把它變成可驗收的規格、上線之後出過什麼問題、你當時怎麼決定修到什麼程度。如果作品有真實使用者、有故障紀錄、有改版歷程，說服力會遠高於只有截圖與功能列表。
Q4：台灣有 FDE 職缺嗎？該怎麼找？
A4：用職稱搜尋不容易找到，比較有效的方式是檢查工作內容是否包含面向客戶、正式環境的程式交付、需求範圍界定，以及上線後的責任。符合其中一部分不代表就是 FDE，仍須確認責任範圍有沒有涵蓋完整的交付週期。實務上這類職缺可能掛在解決方案工程師、技術顧問或導入工程師之下。
Q5：從決定轉職到準備好，大概需要多久？
A5：用時間長度回答容易誤導，因為完成時間取決於專案範圍與你能取得的權限。比較實際的衡量單位是完整交付週期：你至少需要跑完一次從模糊需求到上線再到故障修復的循環，並且能講清楚過程中每個取捨的理由。跑完一次，你在面試裡講的東西就會跟其他人不一樣。
Q6：品牌端要怎麼判斷應徵者有沒有這個能力？
A6：問過去的具體經過，不要問能力形容詞。請他描述一次交付上線後出問題的處理過程，聽他怎麼決定修到什麼程度；再請他描述一次把沒有規格的需求變成可動工方案的過程。口述之後要追問時間線、限制條件與具體產物，必要時搭配程式碼審查或小型工作樣本，才不會只聽到準備好的話術。