FDE、售前、方案架構師、實施與客戶成功，到底差在哪裡？
這些角色都會面對客戶，但責任邊界完全不同。關鍵不在是否駐場，而在是否能寫、能整合、能驗證，並把現場學習推回產品。
七種面向客戶的角色，責任邊界一次看懂
FDE 的特徵不是『會見客戶』，而是現場、開發、價值與產品閉環同時存在。
| 角色 | 現場深度 | 編碼 | 主要產出 | 是否回饋產品 |
|---|---|---|---|---|
| FDE | 高頻／駐場 | 中高 | POC、整合、生產價值 | 核心責任 |
| 實施工程師 | 常駐 | 低 | 配置、聯調、驗收 | 通常不是 |
| 方案架構師 | 短期 | 低 | 架構、方案、報價 | 間接 |
| 售前工程師 | 短期 | 極低 | Demo、應答、投標 | 間接 |
| 後端研發 | 極低 | 高 | 產品功能、版本、Bug | 直接做產品 |
| 客戶成功 | 定期拜訪 | 無 | 採用、滿意、續約 | 回報需求 |
| 技術支持 | 駐場／遠端 | 低 | 排障、恢復、定位 | 回報故障 |
依研報第 10 頁重製並精簡為手機可讀欄位。
FDE 走紅之後，最容易發生的事就是名片先改、工作不變。售前工程師改叫 FDE、實施團隊改叫部署工程、顧問公司也說自己一直都在做。要判斷是不是同一件事，不能看職稱，要看責任。
售前與方案架構師：把可能性說清楚
售前工程師負責產品展示、技術答疑和投標材料，核心任務是降低客戶在購買前的不確定性。方案架構師更進一步，會設計系統架構、技術選型與整合方案。但這兩個角色通常不長期留在現場，也不對生產環境的最後結果負責。
FDE 會參與前期診斷，卻不能停在方案。當簡報裡的箭頭接不上真實 API、資料欄位缺漏、模型在例外情境出錯，FDE 要親自把問題解到能運作。
實施與技術支持：把系統上線、保持可用
實施工程師按照既定產品與文件完成配置、聯調和驗收，對標準化軟體非常重要。技術支持則處理故障、排查與恢復。兩者主要面對已知需求；FDE 面對的往往是需求本身還不清楚、產品能力也需要被重新組合的情境。
差異不在誰比較高級，而在問題型態不同。穩定 ERP 上線需要紀律嚴謹的實施；高不確定 AI 專案需要能一邊定義問題、一邊寫程式驗證的 FDE。把兩者混用，只會讓成本變高。
研發與客戶成功：一個離現場遠，一個離程式遠
後端研發負責標準產品的核心能力，通常不適合被每個客戶的特殊需求拉著走。客戶成功經理負責採用、滿意度與續約，但不一定理解底層技術。FDE 正好站在兩者之間：既能進現場，也能把需求抽象成研發可採用的產品問題。
招募時，用四個問題比看履歷更有效
- 他能否把模糊需求拆成可驗證假設？
- 他能否親手完成資料、API、Prompt、評估與工作流整合？
- 他是否願意用業務 KPI，而不是功能數量定義成功？
- 他能否把一次性的解法，整理成產品團隊可重用的元件？
如果四題只答得出一題，那是相鄰角色，不一定是 FDE。公司也不必人人都變成 FDE；更實際的做法，是讓 FDE 擔任跨角色的閉環負責人，並讓售前、研發、實施與 CSM 保持各自專長。
FDE 不是取代所有人，而是確保沒有人把最關鍵的接縫當成別人的工作。
資料來源與閱讀邊界
本文以 華西證券《FDE：AI 商業模式黏合劑》（2026-08-11）第 10 頁為導讀。本站未公開或直接重製原始研報頁面；文中圖表依可辨識資料重製，約數、指數與預測均明確標示。
研報是資料起點，不是本站結論。本文為產業研究與個人觀點，不構成投資、交易、招募或法律建議。
這是「FDE × 企業 AI 落地」第 4 篇。整套策展只追一個問題：AI 如何從模型能力，變成企業每天可驗證的營運能力？