OpenAI 前置部署工程（Forward Deployed Engineering，FDE）負責人 Colin Jarvis 在 2026 年 10 月的官方文章中，說明了這個團隊存在的理由。所謂「前置部署」在企業軟體領域並非新詞，指的是工程師進駐客戶端、貼著實際使用者把系統建起來的角色。OpenAI 用這個角色處理一個特定問題：部署落差（deployment gap）。Jarvis 的定義很直接，就是模型在展示與評測上看起來做得到的事，與人們在真實工作裡能穩定依賴的事之間的距離。模型能力推進得比配套的系統與流程快，落差於是反覆出現。缺的東西有時是一個產品功能，有時是模型在充滿變數與現實限制的場景中根本做不好。
這個團隊從一開始就把「讓自己過時」寫進目標。Jarvis 回憶，Codex 問世時有同事問他：如果 Codex 能一鍵完成團隊花幾個月打造的用例，那 FDE 還要做什麼？他的回答是，那叫進步；如果每隔幾個月就被自己的成果取代，團隊才算稱職。實際做法是盡量把每次專案的成果沉澱成下一個客戶的起點，把同類問題的處理門檻壓低，直到客戶不需要 FDE 也能自行解決。
從結果出發，而不是從演示出發
每次團隊會議開場，Jarvis 放的那張簡報只有一句話：從結果出發，不惜代價把事情做成，然後再談規模化。這句話針對的是一個常見陷阱：演示很容易看起來很厲害，卻沒有人追問它在生產環境能否站得住。FDE 的職責是把客戶的問題解到足以在生產環境負責的標準，而不是停在令人驚豔的展示。這也是團隊反覆強調的順序問題：先有價值，再談複製。
農業、晶片與電信：把模型放進真實限制
John Deere 的案例說明了落差長什麼樣子。這家成立兩百年的農業企業開發了 See & Spray 精準除草技術，用攝影機與機器學習辨識雜草，只噴雜草而非整片田，最高可減少 70% 的化學藥劑用量。但效益能不能實現，取決於農民是否知道怎麼設定設備、怎麼安排耕作季節、怎麼在天氣與作物狀況變化時調整做法。John Deere 採用 OpenAI 的 API，讓 AI 以自然語言回答農民問題、提供設定建議與個人化推薦、判斷設備是否沒有發揮應有水準，並協助農民理解這套技術帶來的實際價值。重點不只在單次問答，而是沿著整段客戶旅程提供相關指引。
半導體客戶的案例則顯示 FDE 如何處理陌生領域。2025 年中，約 15 名 FDE 與一家大型半導體公司合作 10 多個用例，目標是把驗證流程改造成 AI 原生。驗證工作包含定向測試生成、根因分析與除錯，以及架構輔助；在這個產業，驗證可能佔掉一個專案約 70% 的工作量。部分 FDE 才加入 OpenAI 幾天，完全沒有半導體背景，他們進駐客戶的驗證團隊，利用空閒時間學晶片設計，與工程師一起建立評測，確認 AI 能否產生有用的測試並正確診斷晶片故障。三到六個月內，這些用例全部進入生產並獲得早期使用者採用：AI 定向測試生成節省約 48% 時間，內核優化帶來 22% 的中位效能提升，原本要花數週的除錯被壓縮到數小時。客戶的硬體長官後來問，你們以前做過晶片設計嗎？Jarvis 的答案是：FDE 不必第一天就懂產業，但必須負責把它學會。團隊刻意混合通才與領域專家，像生命科學專案裡，FDE 的科學背景有助於與做標靶驗證、基因表現分析與化學合成路線重建的研究人員建立信任，也讓他們能對工作流程該怎麼改提出有根據的判斷。
讓成功可重複
單點成功還不夠。這些流程雖然證明有價值，但每個用例都需要大量客製整合，很難搬到另一個團隊。當 Codex 的能力成長後，一位 FDE 試著圍繞 Codex 重建應用，再與團隊把用例搬到以 Codex 為核心的共同測試框架上。原本的客製應用變成建在 Codex 基礎元件上的外掛與技能，Codex 本身也成為介面，先前為各用例分別撰寫的終端介面與命令列工具於是可以退場。每個專案約 90% 的客製程式碼被移除，好處不只是少寫程式：Codex 的集中改良能直接回饋到所有用例，常用功能被打包成可共享的技能與外掛，由 AI 能力中心統一管理；要擴展到新團隊，可能只需要換上新的連接器或 MCP 伺服器（Model Context Protocol，模型上下文協定，用於把模型接上外部工具與資料來源）、建立新的評測，就能上線。2026 年 8 月的一個例子是，初次部署花了兩個月，擴到第二個團隊只花一天。這正是讓自己過時的另一種版本：底層產品變強後，原本的客製實作可以大量替換，價值卻留下來。
同樣的邏輯也出現在產品化。OpenAI Presence 是企業語音與聊天代理產品，來自真實客戶部署的累積，早期從 Swarm 開始，經由 Agents API 演進，目前有一個客戶已把超過一半的來電交給 AI 處理。部署過程讓團隊分辨哪些問題需要客製、哪些積木可以讓其他開發者直接使用，這些積木最後被收進 Presence，讓受監管流程的自動化不必重複打造底層基礎設施。另一個案例是 Thrive Holdings：OpenAI 的 FDE 與研究人員和工程師、會計師並肩，為克里特島的會計師事務所打造 Tax AI。試點期間處理了 7,000 份報稅資料，吞吐量提升約 50%。最難的是租賃房產申報的自動化，花了六週的工程與實務審查才達到 90% 的精確率與召回率；過程中累積的可重用模式，讓後續擴展到其他複雜稅表容易許多。團隊現在把同樣方法用到記帳、審計與 IT 支援。
能力缺口與自我淘汰
不是所有問題都能靠更好的產品解決。Jarvis 強調，如果只做今天模型已經做得到的事，就永遠不會發現研究團隊下一步該補的能力缺口。因此許多重要專案是從模型的極限開始，由客戶、FDE 與研究團隊共同承擔。一個大型電信客戶已有客服平台，想擴展到語音，而語音佔其客服量大約 90%，處理成本比文字更高，口音、語氣、延遲與準確度都要達到生產級。專案評估時，模型在關鍵評測上只拿到約 60%，已達能力上限，函式呼叫與指令遵循在客服情境都需要改善。FDE 與客戶一起建平台、定義模型該做到什麼，研究團隊負責補能力，後續的模型快照則用來對照客戶需求驗證進展。六個月內，關鍵評測從約 60% 升到 80%，再到 90% 以上，達到生產所需水準。這個語音模型後來支撐該客戶的部署、其他客製客服專案，以及透過 Presence 提供的代管服務。
限制也在這裡。FDE 的價值高度依賴客戶願意投入一個模型當下還解不了的問題，以及研究團隊能否在合理時間內補上缺口；若缺少其中一環，專案就可能停在演示階段。Jarvis 也提醒，在最前沿研究驅動的公司與充斥誇大宣傳的產業裡，團隊刻意選擇奧坎剃刀（Occam's Razor）式的做法：能穩定運作、現場人員敢依賴的簡單方案，勝過漂亮但脆弱的複雜系統。衡量一次合作是否成功，不只看花了多少工時，而是看它留下什麼：更容易部署的產品、能處理更難任務的模型，或是下一個客戶更少的客製工作。當 Codex 能接手團隊幾個月前打造的東西時，答案不是守住既有成果，而是再去找更難的問題。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。