把客户定制 Harness 收成统一 Codex：OpenAI 如何定义 FDE

OpenAI 的 FDE 要填的坑是「部署差距」：模型看起来能做的事，和客户在真实约束下能稳定用起来的事之间的空档。打法是先把结果做进生产，再把定制方案收成可复用产品；若模型本身不够，就用评测把缺口交给 Research。目标是每隔几个月让自己在这类问题上变得不那么必要。
https://openai.com/index/forward-deployed-engineering-means/

OpenAI 的 FDE 是干什么的
· 团队成立于 2025 年初。部署差距有时是产品缺失，有时是模型在基准上好看、在真实变量和约束下做不到。
· Codex 发布后有人问：用例我们花了几个月做，Codex 能一键搞定时 FDE 还干什么？作者的回答是：那就是进步；若每隔几个月把自己做「过时」，说明 FDE 在尽职。

从结果出发
· 核心原则：「先从结果出发，做成功所需的一切，再谈规模。」演示不够，要能在生产里站得住。
· 半导体客户案例（约 2025 年中，约 15 名 FDE、10+ 用例）：把验证流程做成 AI 原生，覆盖定向测试生成、根因分析与调试、架构助手。行业里验证可占项目约 70% 工作量。部分 FDE 入职仅几天、从未做过半导体，仍嵌入客户验证团队、自学芯片设计，并和工程师一起建评测。3–6 个月内用例陆续上线，自报效果包括：定向测试生成约省时 48%；内核优化中位性能提升约 22%；数周调试压缩到数小时。
· 作者强调：不要求入职即懂行业，但有责任学会；团队要混搭通才与领域专家。生命科学里，有科研背景的 FDE 更容易在靶点验证、基因表达分析等工作流上获得信任。

让成功可复用（核心！）
· 早期每个用例都要大量定制集成，难复制到下一支团队。Codex 变强后，有人先试着把应用重建在 Codex 上，再推动用例迁到以 Codex 为核心的统一 harness。
· 定制应用变成基于 Codex 原语的 plugins / skills；Codex 本身成为界面，原先为各用例写的终端 UI 和 CLI 被退役。
自报结果：每个项目约 90% 的定制代码被去掉。收益包括：吃到 Codex 的集中改进、少写 glue；能力以 skills / plugins 打包，便于共享并由 AI CoE 集中管控；扩展到下一支团队时，往往只需换 connectors / MCP、补新评测（评测也有 skill）。
· 规模化例子：2026 年 8 月某用例，首支团队部署约 2 个月；第二支团队约 1 天。后续团队继续变快。

出现智能缺口就闭环
· 有时产品升级就能简化定制；有时模型本身还做不到。若只做今天模型已会的事，就挖不出 Research 该攻的下一题。
· 电信客服语音案例：语音约占客服量 90%。立项时模型在关键评测上约 60%。FDE 与客户共建平台并定义需求，Research 用连续模型快照对照客户要求补能力。约六个月后关键评测从约 60% 到 80%、再到 90%+，达到可上线水平。成果反哺该客户部署、其他客服定制，以及 Presence 托管部署。

其他产品化例子
· Presence（企业语音与聊天 agent）从真实部署长出来：从 Swarm 到 Agents API；一文称某客户超一半通话已由 AI 处理。
· Thrive Holdings / Crete 税务 AI：试点处理约 7000 份报税，吞吐约提升 50%。租赁房产报税自动化约花六周工程与实务复核，才达到约 90% 的 precision / recall；模式再复用到簿记、审计、IT 支持。