摘要： Deloitte 2026 年報告指出，只有 25% 的企業已把四成以上 AI 專案推進正式上線。Cohere 於 8 月 27 日刊文主張 FDE 應與客戶工程團隊共同建置、培訓內部 champion，並留下可重用實務與測試套件；衡量標準是客戶能否獨立營運、驗證與擴充系統。
企業 AI 落地真正卡住的地方，已經不在實驗室裡的模型表現，而在 pilot 究竟能不能推進到 production。Deloitte 2026 年的報告指出，僅 25% 的企業已把四成以上的 AI 專案送進正式上線階段。多數團隊就困在「證明可行」與「實際營運」中間的那道鴻溝裡，而這道鴻溝怎麼填，往往決定了企業未來是握有自身能力，還是被廠商牽著走。
Cohere 於 2026 年 8 月 27 日刊出的文章立場鮮明：forward-deployed engineers（FDE）的可貴之處不在「幫你做完」，而在「教你做到會」。凡是正在評估 AI 落地策略的產品 builder，都值得把這個說法放在心上。
為什麼 FDE 不只是換個名字的外包廠商
產業知識與跨廠商視野，向來是第三方顧問或系統整合商的強項；然而一旦產品本身有侷限、模型行為不符預期，或整合出了狀況，他們通常只能繞道處理，或把問題丟回原廠。Cohere 的 FDE 不同：他們一面待在客戶的環境裡，一面仍屬於產品團隊內部，因此可以直接翻看底層程式碼，必要時為單一客戶改動產品，再把解法一般化。
文中舉了一個例子：某個客戶的 agent 會在會議前自動生成簡報，卻因為工具引用錯誤、context 過長而屢屢失敗。負責的 FDE 索性重建 agent，並調整 Slack 整合，讓它能吃下更大的資料量。這種從源頭下手解決問題的本事，第三方很難複製。
不過這裡也浮出一個關鍵疑問：萬一關鍵知識全都留在廠商工程師的腦中，企業最後會不會變成「擁有部署，卻不擁有營運能力」？
依賴分成兩層：技術綁定與營運綁定
Cohere 的文章把依賴拆成兩類。一類落在技術或商業架構上，例如採用某家廠商的模型或 API，日後要遷移時可能得付出額外成本，但只要做了這個選擇，不管由誰來部署，這層依賴都存在。另一類則是營運依賴——真正的風險在於內部團隊沒有能力自行診斷問題、修改系統或驗證效能。
也就是說，FDE 該做的不是「幫你解決問題」，而是「讓你自己能解決問題」。這和我們在細模型的大優勢裡談過的思路相同：企業挑選工具時，短期成效只是其中一面，長期能不能自主才是關鍵。
能力建構：從 co-building 到內部 champion
Cohere 的解法，是把知識轉移直接嵌進交付流程，而不是等專案收尾才做 handover。FDE 會和客戶的工程團隊一路走過架構、整合、部署、測試與故障排除，tacit knowledge 就在這個過程裡自然流動。他們同時也在客戶內部培育「champion」，讓這批種子成員日後能再去教其他團隊。
做法再具體一些：針對 MCP 等技術主題開設工作坊，協助客戶累積可重用的工程實務（涵蓋部署、負載測試、connector 開發），甚至教客戶用 AI 自己查文件、自己診斷問題，不必每次都得找 FDE。Cohere 也協助客戶建立測試套件，讓日後模型版本或設定變更時，系統行為依然能被驗證。
這正好呼應我們在2026 年 AI Agent 結構化資料擷取工具指南中提到的「可驗證性」——團隊若沒有能力自行驗證系統，就只能永遠接受廠商的判斷。
評估 FDE 廠商時，你該問的問題
Cohere 的觀點其實給出了一套實用的評估框架：關鍵不是問「他們能不能幫我上線」，而是問「他們離開後，我能不能自己營運」。可以逐項檢視：
- FDE 是從第一天就和你的工程團隊 co-building，還是直到最後才交出一份文件？
- 他們有沒有協助建立測試與監控機制，讓你能獨立驗證系統效能？
- 他們願不願意教你的團隊使用底層工具與協定（如 MCP），而不是只丟一個黑箱解法？
要是廠商從頭到尾只強調「我們會幫你搞定」，卻看不到能力建構的環節，那你買到的恐怕不是解決方案，而是一紙長期的服務合約。
結語：走到最後，依賴該讓位給自主
Cohere 的立場說得很直白：一次好的 FDE 參與，應該讓客戶的營運自主權隨時間增加，而非減少。對企業而言，這是重要的心態轉變——AI 落地不是一次性的專案，而是內部能力一層層累積的過程。當你評估 FDE 或任何外部夥伴時，不妨把「他們能否讓我變得更獨立」當成核心指標。畢竟，真正的成功不在系統上線那天，而在你不再需要他們的那天。