FDE 不只是會寫程式或會跟客戶開會。本篇把 production coding、系統整合、LLM eval、需求探索、部署、採用與溝通拆成可自評的能力地圖，並說明該用什麼成果補足缺口。
目錄+
FDE 的難，不是技能清單特別長，而是必須把不同技能串成一條交付鏈：理解問題、設計邊界、寫 production code、接上既有系統、部署、觀測，最後讓使用者真的改變工作方式。
FDE = Forward Deployed Engineer，前線部署工程師。OpenAI 把角色成功定義為 production adoption 與 measurable workflow impact；Palantir 強調在既有 codebase、基礎設施與第三方整合中工作。這代表「會做 AI demo」只完成地圖的一角。
六個核心面向
| 能力面向 | 能獨立交付的證據 | 常見假象 |
|---|---|---|
| Production coding | 有測試、錯誤處理、版本控制與可維護邊界 | notebook 跑得動就算完成 |
| 系統與資料整合 | API、身份、權限、資料契約、同步與稽核可說清楚 | 只接一份乾淨 CSV |
| LLM eval 與安全 | 有 baseline、失敗分類、回歸集、人工覆核與攻擊面 | 挑幾個成功 prompt 截圖 |
| 需求探索 | 能從訪談收斂 workflow、限制與驗收條件 | 把客戶說的功能逐字照做 |
| 部署與觀測 | 有環境、CI/CD、追蹤、成本、告警與 rollback | 雲端有網址就叫 production |
| 採用與溝通 | 能設計試點、訓練、回饋與成效回顧 | 上線等於有人使用 |
1. Production coding：不只把 happy path 寫出來
Twilio 的 FDE 職缺明列 API design、architecture、testing/debugging、version control 與 CI/CD；OpenAI 要求 production-grade Python、JavaScript 或相當的全端經驗。語言不是唯一重點，真正的門檻是你能不能處理 timeout、重試、冪等、資料驗證、權限拒絕與降級。
自評時不要問「我會不會 Python」，要問：「第三方模型 API 失敗時，系統是否保留工單、記錄原因並安全回到人工流程？」
2. 系統整合：企業現場從來不是空白畫布
FDE 常要接 CRM、ERP、客服、身份供應商與內部資料庫。你需要辨認 source of truth、資料擁有者、同步方向、保留期限與最小權限。Palantir 對既有系統工作的說明，特別強調除錯、延伸既有 codebase，以及處理第三方整合。
Java／企業後端與 DevOps 工程師在這裡通常已有優勢；前端工程師則能補上狀態、權限提示與人工覆核體驗。不要把背景丟掉，應把它接到端到端成果上。
3. LLM eval：把「感覺不錯」變成可回歸
OpenAI 的實務指南建議先建立 eval baseline，再迭代 Agent。最小可行做法是收集 30–50 筆具代表性的任務，定義正確性、引用完整、拒答與升級人工的標準，再依失敗原因分群。
Eval 不只評模型答案。還要測 retrieval 是否取到授權資料、工具呼叫是否越權、提示注入能否改寫系統指令，以及新版是否讓既有案例退步。OWASP 把 prompt injection 與敏感資訊揭露列為 LLM 應用的重要風險，不能等上線後再補。
4. 需求探索：先找到決策，再談功能
有效訪談不問「你想要什麼 AI 功能」，而是追一筆真實工作：誰觸發、查哪些系統、在哪裡等待、誰有決策權、錯了會造成什麼損失。把流程寫成目前狀態、目標狀態、不可違反條件與可驗收結果。
好的 FDE 也會拒絕錯誤範圍。若資料沒有權限邊界、成效無法觀測或使用者不願改流程，先做更小的試點，比承諾「全自動 Agent」負責。
5. 部署與觀測：要知道系統為何失敗
至少要觀測請求延遲、錯誤率、模型與工具成本、retrieval 命中、人工覆核率與升級原因。OpenTelemetry 提供 vendor-neutral 的 traces、metrics、logs 標準；你不一定要用特定平台，但要能沿一筆工單追出模型、工具與資料步驟。
同時準備 feature flag、流量分批、版本標記與 rollback。Production 的定義不是「永不失敗」，而是失敗可見、影響受控、能安全恢復。
6. 採用與溝通：上線不是終點
先選願意合作的小組，定義何時必須人工覆核，建立快速回報入口，再用每週回顧把失敗案例變成 backlog。對主管談時間、品質與風險；對使用者談哪些步驟改變、何時不要相信系統；對產品團隊則帶回可重複的需求，而不是只有客戶抱怨。
15 分鐘自評表
每題給自己 0–2 分：0 是沒做過，1 是在引導下完成，2 是能獨立交付並解釋取捨。
- 我能替一個外部 API 設計 timeout、重試、冪等與錯誤降級。
- 我能畫出資料流、身份與權限邊界，指出 source of truth。
- 我能建立 eval dataset、評分規則、失敗分類與回歸流程。
- 我能用訪談收斂出驗收條件，而不是只收功能清單。
- 我能部署可追蹤、可告警、可 rollback 的版本。
- 我能設計試點、人工覆核與採用回顧。
- 我能向工程、主管與第一線使用者分別說清楚同一個決策。
總分不是錄取預測。真正用途是找下一個作品證據：工程強、探索弱，就做三次 workflow interview；顧問強、部署弱，就把 prototype 加上 CI/CD、觀測與 rollback。
接下來可依背景進入 前端、Java／企業後端、DevOps 的 90 天路線，或直接照 production AI 導入作品集完成整合案例。若仍不確定職稱，先看 四種角色比較。
常見問題
FDE 最重要的是 coding 還是溝通？
兩者不能互相替代。Coding 讓方案能進 production，溝通讓團隊選對問題、控制範圍並推動採用；缺任一側，都容易停在錯誤的 demo 或無法維護的客製案。
一定要會訓練模型才能做 AI FDE 嗎？
多數企業導入更常要求 API、RAG、Agent、eval、資料與安全整合，不一定要求預訓練模型。仍應以目標職缺為準，研究型或模型平台職缺的要求會不同。
能力自評要到幾分才能投履歷？
沒有通用及格線。優先確保每個核心面向至少有一項可展示證據，再針對目標職缺加深兩到三項強項；不要等所有能力都完美才開始投遞。