FDE、FDSE、Solutions Engineer、AI 顧問差在哪？
FDE、FDSE、Solutions Engineer 與 AI 顧問常被混用，但 coding 深度、介入客戶的階段、交付責任與績效指標並不相同。本篇用官方職缺拆解四種角色，提供比職稱更可靠的判讀方法。
目錄+
同一份工作可能被叫做 FDE、FDSE、Solutions Engineer、Implementation Engineer 或 AI 顧問；同一個職稱也可能在兩家公司代表完全不同的日常。若只追熱門名稱，你很容易投錯職缺。
先固定定義：FDE = Forward Deployed Engineer，前線部署工程師。它描述的不是單一技術棧，而是一種靠近客戶、對落地成果負責的工程工作。判斷角色時，至少要看 coding 深度、介入階段、交付責任與績效指標。
四種角色的常見重心
| 角色 | Coding 深度 | 介入客戶階段 | 主要交付 | 常見績效訊號 |
|---|---|---|---|---|
| FDE | 中至高，常寫 production code | 探索、建置、上線、採用 | 可運行的客製方案與產品回饋 | production adoption、workflow impact、交付速度 |
| FDSE | 通常偏高，Software 責任較明確 | 問題拆解到長期部署 | 應用、資料管線、整合與維運 | 軟體品質、客戶成果、平台擴張 |
| Solutions Engineer | 低至高，依售前／售後定位變動 | 多在評估、POC、成交，也可能延伸上線 | demo、架構方案、技術驗證 | 技術勝率、成交支援、time-to-value |
| AI 顧問 | 低至中最常見，但範圍很廣 | 策略、流程盤點、導入治理 | 分析、roadmap、變革與專案協調 | 商業成效、里程碑、採用與客戶滿意 |
這張表是常見分布，不是產業標準。Apple 的 FDE 職缺就設在 Sales 團隊，卻要求把模糊需求翻譯成可交付程式；Twilio 的 FDE 也同時承擔客戶採用與 API、架構、測試、CI/CD。組織歸屬不能單獨決定工程深度。
FDE：從問題探索一路負責到 rollout
OpenAI 的 FDE 工作涵蓋 discovery、technical scoping、system design、build 與 rollout，成功不只看「有沒有上線」，還看 production adoption 與可衡量的 workflow impact。這是一個很重要的分界：FDE 交付的不是建議書，而是進入工作流程的系統。
同時，FDE 必須把客戶現場發現回饋給產品團隊。當三個客戶都需要類似功能時，好的 FDE 不會永遠維護三份客製分支，而會辨認能產品化的共同能力。
FDSE：把 Software 寫在職稱裡
Palantir 常用 FDSE（Forward Deployed Software Engineer）。官方說明強調找出真正問題、理解從 CIO 到第一線使用者的需求，並建立 AI 與軟體解決方案。另一篇招聘文章明確描述：工作可能發生在客戶或自家 codebase、基礎設施與第三方整合中。
因此 FDSE 往往更容易從職稱看出工程責任，但不要反推 FDE 就比較不技術。OpenAI、Twilio 的 FDE 一樣要求 production-grade coding。兩者差異更多是公司命名傳統。
Solutions Engineer：先問是售前還是交付
Solutions Engineer 最容易誤判。某些團隊主要做 demo、RFP、架構說明與 POC，目標是降低技術疑慮、協助成交；某些團隊則會一路做到 production integration。
面試前直接問：
- 成交後由誰擁有程式碼與上線？
- 一位工程師同時服務多少客戶？
- 績效看營收支援，還是看採用與 production 成果？
- 客製需求如何回到產品 roadmap？
答案比職稱更能判斷它接近售前 SE、Implementation，還是 FDE。
AI 顧問：強在問題與變革，但工程責任未必相同
AI 顧問通常從商業流程、資料可行性、風險與組織採用切入。這些也是 FDE 需要的能力，但顧問專案可能在 roadmap、POC 或交接時結束；FDE 更常被期待親自把方案建好、部署、觀測，再持續迭代。
這不代表顧問比較「不技術」。真正差別是誰擁有 production 風險。若職缺要求你負責 API、權限、測試、部署與 on-call 式的問題排除，它已經很接近工程交付。
台灣職稱更容易混合。2026 年 7 月更新的 Tricuss 職缺把 B2B SaaS、技術顧問、FDE 與 Solutions Architect 經驗並列，技能橫跨 LLM API、Agent、RAG、REST／GraphQL、雲端及容器。這是一個有效樣本，但不是台灣市場的統一模板。
用責任矩陣讀任何新職稱
遇到陌生名稱時，替職缺各打 0–2 分：
- Build：是否親自寫 production code？
- Deploy：是否負責資料、權限、環境、rollout 與監控？
- Discover：是否直接探索客戶流程與限制？
- Adopt：是否為使用者採用與商業結果負責？
- Productize：是否把重複需求帶回核心產品？
Build、Deploy、Discover、Adopt 都高，通常接近 FDE／FDSE；Discover 高但 Build 低，可能偏顧問；前期技術驗證高、交付責任低，可能偏售前 Solutions Engineer。這不是為職稱排高低，而是確認工作是否符合你的偏好。
如果你確認想走交付型角色，下一篇可用 FDE 能力地圖做自評；若仍被高薪敘事吸引，先回看 FDE 是下一個工程師紅利嗎的樣本限制。
常見問題
FDSE 和 FDE 是不同職業嗎？
不一定。FDSE 明確保留 Software，通常更強調軟體工程；FDE 在不同公司可能同樣需要深度 coding，也可能偏解決方案交付。實際責任比縮寫更可靠。
Solutions Engineer 都是售前、不寫程式嗎？
不是。有些角色以 demo、技術驗證與協助成交為主，也有些會做 production integration。要看是否擁有上線後責任、程式碼與客戶成效，而不是只看職稱。
AI 顧問可以轉 FDE 嗎？
可以，但要補足可驗證的工程交付：版本控制、測試、API、權限、部署、監控與故障處理。只有策略簡報或 no-code prototype 通常不足以證明 production ownership。