How OpenAI defines FDE: consolidating customer-customized Harness into a unified Codex
English text is being prepared.
OpenAI's FDE team was established in early 2025, with the goal of filling the deployment gap between model capabilities and customers' real-world constraints; the approach is to first get results into production, then consolidate customized solutions into reusable products. In the early days, every use case required extensive customized integration; after Codex became stronger, the team rebuilt the application on Codex, turning customized applications into plugins and skills based on Codex primitives, and self-reports that about 90% of the customized code for each project was removed. In a semiconductor customer case, about 15 FDEs covered 10+ use cases, self-reporting about 48% time savings in targeted test generation and about 22% median performance improvement in kernel optimization; in a telecom customer service voice case, the key evaluation rose from about 60% to 90%+ in about six months.
Why read this
AI score 62
The original article breaks down the path of OpenAI's FDE team from customized delivery to a unified Codex harness, which can serve as a reference for teams doing enterprise delivery.
Topics
Body
把客户定制 Harness 收成统一 Codex：OpenAI 如何定义 FDE
OpenAI 的 FDE 要填的坑是「部署差距」：模型看起来能做的事，和客户在真实约束下能稳定用起来的事之间的空档。打法是先把结果做进生产，再把定制方案收成可复用产品；若模型本身不够，就用评测把缺口交给 Research。目标是每隔几个月让自己在这类问题上变得不那么必要。 https://t.co/X1E2WtaMbe
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 支持。