前端、Java／企業後端、DevOps 工程師怎麼轉 FDE？
前端、Java／企業後端與 DevOps 工程師不必清空原有技術棧。本篇依三種背景整理可沿用能力、關鍵缺口與 90 天實作路線，目標是交出一個可部署、可評估、能說明客戶成效的 FDE 案例。
目錄+
熱門貼文常把 FDE 描述成一套需要重新開始的技能。實際上，FDE = Forward Deployed Engineer，前線部署工程師，價值正來自把既有工程能力帶進客戶現場。前端懂採用與互動，Java／企業後端懂商業規則與整合，DevOps 懂可靠部署；三者缺的層不同，不該讀同一份轉職清單。
這份 90 天路線以每週 8–12 小時為假設，目標是完成一個可展示的企業 AI 導入案例。它是練習規劃，不是錄取或薪資保證。開始前先用 FDE 能力地圖自評，再選一條主線。
共同節奏：30 天補缺口，30 天串起來，30 天變可信
| 階段 | 核心問題 | 必須留下的成果 |
|---|---|---|
| 第 1–30 天 | 我缺哪個相鄰層？ | 職缺矩陣、小型 spike、三次 workflow 訪談 |
| 第 31–60 天 | 我能否完成端到端流程？ | 可運行案例、API／資料／權限設計、第一版 eval |
| 第 61–90 天 | 別人敢不敢讓它上線？ | 測試、監控、runbook、rollback、demo 與案例文檔 |
OpenAI、Twilio 與 Palantir 的官方職缺共同指向 production coding、系統設計、既有整合、部署與客戶成效。因此三條路最後都要收斂到同一件事：不只展示模型答案，而是展示一個可控制風險的 workflow。
前端工程師路線
直接沿用的能力
- 使用者流程、資訊層級與可用性
- 非同步狀態、錯誤恢復、權限提示
- 分析事件、A/B rollout 與採用觀察
- TypeScript、測試與 full-stack framework
前端工程師最大的優勢，是知道 AI 信心不等於使用者信任。來源、編輯、確認、拒絕與人工升級怎麼呈現，會直接影響採用。
要補的缺口
補一條可維護的後端 API、資料模型、身份與 RBAC；學會把模型呼叫放在 server side，處理 timeout、重試、rate limit 與敏感資訊。再建立 eval dataset，而不是只用畫面截圖證明品質。
90 天成果
- 1–30 天：完成一個 server endpoint，串接模型與資料庫；畫出身份、資料流與錯誤狀態。
- 31–60 天：做客服工單 copilot，包含來源引用、草稿編輯、人工核准與稽核紀錄。
- 61–90 天：加上回歸 eval、trace、成本與延遲監控、feature flag、runbook；錄一段從需求到故障恢復的 demo。
Java／企業後端工程師路線
直接沿用的能力
- ERP／CRM、交易、一致性與複雜商業規則
- API 契約、身份、權限、稽核與資料治理
- 長期 codebase 維護、測試與故障處理
- 與多系統、多團隊協作的經驗
這些是企業 AI 上線最難臨時補齊的部分。Palantir 特別強調在現有 codebase、基礎設施與第三方整合中工作；你的 brownfield 經驗不是包袱。
要補的缺口
學會快速做小型 prototype、基本 Python 與主流 LLM API；理解 RAG、tool calling、structured output 與 eval。更重要的是把技術細節翻譯成客戶 workflow 與可衡量結果，不要只談架構正確。
90 天成果
- 1–30 天：以熟悉的 Java service 包裝工單與客戶資料，另用小型 Python／TypeScript spike 比較模型介接方式。
- 31–60 天：接上真實風格的權限與稽核模型，建立人工核准後才可回覆的流程。
- 61–90 天：加入 prompt injection 測試、資料遮罩、回歸 eval、部署與觀測；寫一份非工程主管也看得懂的 impact memo。
DevOps／SRE 工程師路線
直接沿用的能力
- 雲端、容器、CI/CD、secret 與環境隔離
- traces、metrics、logs、SLO 與事故回應
- 成本、容量、安全與 rollback
- 跨服務除錯與可靠性思維
AI 系統的 production 問題往往發生在模型之外：資料取用失敗、工具超時、權限錯置、版本漂移或成本失控。你能讓這些問題可見、可控。
要補的缺口
補上應用層程式設計、前端人工覆核介面、LLM eval 與需求訪談。不要只展示 Kubernetes 架構圖；要讓使用者能完成工作，並解釋這個 workflow 為何值得部署。
90 天成果
- 1–30 天：寫一個最小 full-stack 流程，建立模型、retrieval、tool call 的 trace。
- 31–60 天：加入多租戶資料邊界、feature flag、模型 fallback 與人工升級。
- 61–90 天：設計 SLO、成本預算、告警、事故演練與 rollback；用一次故障注入證明 runbook 有效。
三條路都要做的客戶練習
找三位真的處理客服、營運或內部 IT 流程的人，每次帶一筆真實但去識別的案例走完整流程。記錄他原本怎麼判斷、在哪裡等待、哪些錯誤不可接受，以及誰能核准。
第三次訪談時，不要再展示所有功能，只驗證三件事：系統在哪一步節省工作、人工在哪一步保留決策、失敗時如何回復。這份訪談修正紀錄，往往比華麗 demo 更能證明 forward-deployed 思維。
第 90 天應該能交出的申請包
- 一頁案例摘要：問題、使用者、限制、決策、結果與未解風險。
- 可閱讀的 repository：架構、啟動方式、測試、eval 與安全界線。
- 五分鐘 demo：正常路徑、拒絕路徑、人工覆核與一次故障恢復。
- 一份 runbook：監控、rollback、資料事件與升級窗口。
- 一份職缺對照：證據如何對應目標公司的責任。
FDE 作品集案例提供可直接採用的規格；完成後再用 面試與工作現實準備取捨題與角色判斷。
常見問題
90 天真的能轉職成功嗎？
不能保證。90 天是建立第一份端到端證據的時間盒，不是錄取承諾；實際結果取決於既有經驗、目標職級、英文、客戶溝通能力與當地職缺。
轉 FDE 一定要改用 Python 嗎？
不一定。Python 在 AI 生態常見，值得能讀寫與除錯，但 production 系統也大量使用 Java、TypeScript 等語言。作品應優先展現整合、品質與交付，不必為追潮流重寫全部。
沒有真實客戶，怎麼練需求探索？
找實際處理工單、營運或行政流程的人做三次訪談，使用去識別或合成資料，記錄假設與驗收條件。重點是呈現你如何修正理解，而不是假裝有付費客戶。