FDE 是做什麼的What FDEs actually do
FDE 不是「會寫 prompt 的業務」，也不是「被派去客戶那裡的外包」。它是一個要對結果負責的工程角色：在客戶的限制條件下，把系統做到能用，並把學到的東西帶回產品。
An FDE is neither "a salesperson who writes prompts" nor "a contractor lent to a customer". It is an engineering role that owns outcomes: make the system work within the customer's constraints, and bring what you learn back to the product.
讀完這章你能夠After this chapter you can
- 說明 FDE 的產出是什麼、對誰負責、成功怎麼衡量。
- 分辨 FDE 與產品工程師、解決方案架構師、顧問的差別。
- 列出這個角色最常失敗的幾種方式，並知道怎麼避免。
- Explain what an FDE produces, who they answer to and how success is measured.
- Distinguish the role from product engineers, solutions architects and consultants.
- Name the most common ways the role fails, and how to avoid them.
這個角色從哪裡來Where the role comes from
「Forward Deployed Engineer」這個職稱最早因 Palantir 而廣為人知：工程師直接進駐客戶單位，和使用者坐在一起，把平台接上客戶的資料與流程。近幾年許多 AI 公司與企業軟體公司也開了 FDE 或性質相近的職缺，原因很實際：企業導入 LLM 的瓶頸通常不在模型本身，而在資料散落各處、權限複雜、既有系統難以整合、以及沒有人能定義「怎樣算做對了」。
各公司對這個職稱的定義不完全相同。有的偏重寫程式，有的偏重客戶溝通。本課程採用的定義是：以工程交付為主、直接面對客戶的工程師。
The title "Forward Deployed Engineer" became widely known through Palantir, where engineers embedded with customer teams, sat next to users and wired the platform into the customer's data and workflows. In recent years many AI labs and enterprise software companies have opened FDE or similar roles, for a practical reason: enterprise LLM adoption is rarely blocked by the model itself. It is blocked by scattered data, complex permissions, legacy systems that resist integration, and nobody being able to define what "correct" means.
Companies use the title differently: some lean towards coding, others towards customer communication. This course uses one definition: a customer-facing engineer whose primary output is shipped engineering work.
實際的工作內容What the work looks like
一個典型的專案週期裡，FDE 大概會做這些事（順序會反覆來回）：
Over a typical engagement an FDE does roughly the following, looping back as needed:
- 釐清問題Clarify the problem 坐在使用者旁邊看他們現在怎麼做事。客戶說「我們要一個 AI 助理」，你要找出的是「哪個步驟最花時間、出錯代價多高、怎樣算改善」。 Sit with users and watch how they work today. The customer says "we want an AI assistant"; you find out which step costs the most time, what an error costs, and what improvement would look like.
- 拿到資料與權限Get data and access 這常常是最慢的一步：資安審查、帳號申請、找出資料真正的擁有者。越早開始越好。 Often the slowest step: security review, account requests, finding who actually owns the data. Start it on day one.
- 做出能用的第一版Build a usable first version 用真實資料、真實使用者，盡快拿到回饋。不是投影片，是可以操作的東西。 Use real data and real users to get feedback fast. Not slides: something people can use.
- 讓它可靠Make it reliable 加上評測、監控、權限控管、錯誤處理。這一步決定系統能不能活過第一個月。 Add evals, monitoring, access control and error handling. This decides whether the system survives its first month.
- 交接，並把經驗帶回去Hand over, and bring lessons back 讓客戶的團隊能自己維運；同時把「三個客戶都需要的功能」回報給產品團隊，讓下一次不用再客製。 Make the customer's team able to run it themselves, and report "the feature three customers needed" back to your product team so the next deployment needs less custom work.
FDE 有兩個客戶：外部客戶要的是問題被解決，內部產品團隊要的是現場的真實訊號。只服務其中一邊，這個角色就會失去價值。
An FDE has two customers: the external customer, who wants the problem solved, and the internal product team, who wants real signal from the field. Serve only one of them and the role loses its value.
和相近職位的差別How it differs from adjacent roles
下表是常見的分工方式，實際情況依公司而異。
A common division of labour; individual companies vary.
| 產品工程師Product engineer | 解決方案架構師Solutions architect | FDE | |
|---|---|---|---|
| 主要產出Main output | 給所有客戶用的產品功能Product features for all customers | 架構建議、PoC、售前技術支援Architecture guidance, PoCs, pre-sales support | 在特定客戶環境裡運作的系統A working system in a specific customer environment |
| 成功的衡量Measured by | 產品指標、品質、交付速度Product metrics, quality, delivery | 成交、技術驗證通過Deals closed, technical validation passed | 客戶實際使用、業務成果、續約Actual usage, business outcome, renewal |
| 程式碼深度Code depth | 深，集中在自家系統Deep, in your own codebase | 中等，以示範為主Moderate, mostly demos | 廣，要整合客戶的既有系統Broad, integrating the customer's systems |
| 時間尺度Time horizon | 長期維護Long-term ownership | 數週（銷售週期）Weeks (sales cycle) | 數週到數月，然後交接Weeks to months, then handover |
和顧問最大的差別是：顧問的產出常是建議與文件，FDE 的產出是在跑的程式，而且背後有一個會持續演進的產品。
The biggest difference from a consultant: a consultant's output is often recommendations and documents, while an FDE's output is running code, backed by a product that keeps evolving.
需要的能力Skills the role needs
正式環境工程Production engineering
API、資料庫、身分驗證、部署、監控。客戶環境什麼都可能有，你得在陌生的技術堆疊裡快速上手。
APIs, databases, auth, deployment, monitoring. Customer environments can contain anything, so you must get productive in unfamiliar stacks quickly.
LLM 應用工程Applied LLM engineering
結構化輸出、檢索、工具呼叫、評測。重點不是調參數，而是知道模型在哪裡會出錯、怎麼用工程把錯誤擋住。
Structured output, retrieval, tool use, evaluation. Not tuning knobs, but knowing where models fail and how to contain the failures with engineering.
釐清需求Discovery
問對問題、把模糊的期待變成可以量測的條件，並且讓非技術的人聽懂取捨。
Asking the right questions, turning vague expectations into measurable criteria, and explaining trade-offs to non-technical people.
判斷力Judgment
決定什麼不做。範圍控制、說「這個用規則就好，不需要 AI」，以及知道什麼時候該升級問題。
Deciding what not to build. Controlling scope, saying "a rule handles this, no AI needed", and knowing when to escalate.
這四項沒有固定比例。不同專案的比重差很多，重要的是每一項都不能是零。
There is no fixed ratio between these; projects vary a lot. What matters is that none of them is zero.
常見的失敗方式Common ways the role fails
為了趕上線，在客戶那裡寫了一套和產品分岔的程式。半年後沒人敢改，產品升級也接不上。對策：客製部分用設定、外掛或明確的擴充點處理；同樣的需求出現兩次，就推回產品。
To hit a deadline you write code that forks from the product. Six months later nobody dares touch it and product upgrades can't land. Instead: express customisation as configuration, plugins or explicit extension points, and push repeated requests back into the product.
在挑過的十個問題上表現很好，上線後遇到真實輸入就失靈。對策：第一週就開始蒐集真實的問題當測試集（第 7 章）。
Great on ten hand-picked questions, falls apart on real input. Instead: start collecting real questions as a test set in week one (chapter 7).
專案做了三個月，客戶仍說「感覺還不夠好」。對策：開工前和客戶一起寫下可以量測的成功條件，並約定誰來判定（第 2 章）。
Three months in, the customer still says it "doesn't feel good enough". Instead: before building, write down measurable success criteria with the customer and agree who judges them (chapter 2).
系統只有你看得懂，每次出事都要找你。對策：從第一天就寫 runbook、加監控，並讓客戶的工程師一起改程式。
Only you understand the system, so every incident pages you. Instead: write runbooks and add monitoring from day one, and have the customer's engineers change code with you.