Codex 发布时，团队里有人问我：“如果 Codex 能一次性搞定我们过去几个月构建的那些用例，我们该怎么办？”
这个问题直指 FDE 在 OpenAI 的意义所在。我们与客户并肩工作，理解他们最难的问题，并构建他们可以依赖的解决方案。我们学到的东西有助于塑造我们的产品，并为 Research 提供具体的问题去解决。
这就是进步。如果我们每隔几个月就让自己变得过时，那说明我们的 FDE 团队在尽职尽责。
我在 2025 年初创立了这个团队，目的是弥合我们所说的“部署鸿沟”：即模型看似具备的能力与人们能够可靠地用来完成工作之间的差距。
模型能力的演进速度，快于将其投入使用所需的系统和流程。有时缺失的是一环产品。有时模型在基准测试上表现良好，却无法在现实变量和约束下完成工作。
我们聚焦于客户最难的问题。在我们的模型今天就能胜任的地方，我们与 Product 和客户合作，让解决方案可复用；在模型力有不逮的地方，我们与客户和 Research 合作，界定差距并推动改进。我们的目标是让每一次合作都能为下一位客户留下更好的起点——如果我们把下限提升到客户下次不再需要 FDE 来解决这一类问题的程度，那我们就做得很好了。
挑战在于John Deere，一家拥有 200 年历史的农业企业，如何为农民规模化地提供个性化建议。
一个例子是 See & Spray，这是其精准除草技术，利用摄像头和机器学习识别并喷洒杂草，而不是对整片田地施药，从而将化学品用量减少多达 70%。
但要实现这些收益，取决于农民是否知道如何配置这项技术、规划他们的种植季，并在条件变化时调整他们的做法。
John Deere 部署了 OpenAI 的 API，帮助让这种支持变得个性化且可规模化。
AI 可以用自然语言回答农民的问题，提供量身定制的设置指导和推荐，识别设备何时可能未发挥全部潜力，并帮助农民理解他们从这项技术中获得的价值。
这一机会超越了任何单次交互：在整个客户旅程中提供相关指导，帮助农民更好地利用他们的设备，同时提升效率和可持续性。
这正是 OpenAI FDE 致力于解决的挑战：帮助组织从 AI 能力迈向能在复杂、真实环境中交付实际价值的系统。
但问题往往没有明确边界，可能不存在既定的标准答案，也没有现成的操作手册。每个人都想打造前所未有的事物。但愿意付出必要努力去实现它的人却更少。
在寻找优秀 FDE 人才的同时不断提高“足够好”的标准，意味着持续不断的实验与实践。
从结果出发
在每次 FDE 团队会议开始时，我都会放一张幻灯片，上面写着一条核心价值：“从结果出发，不惜一切代价取得成功，然后再考虑规模化”。
一个令人印象深刻的演示可以走得很远，直到有人问它在真实世界中是否有效。
我们的职责是把客户的问题解决到我们能在生产环境中为之负责的标准。
2025 年中期，我们约有 15 名 FDE 与一家大型半导体客户合作，覆盖 10 多个用例。目标是让他们的验证流程实现 AI 原生，涵盖：
定向测试生成
根因分析与调试
架构助手
在这个行业中，验证可能占项目工作量的约 70%。机会巨大，而且有许多可能的切入点。
有些 FDE 几天前才加入 OpenAI，从未从事过半导体工作。他们嵌入客户的验证团队，利用业余时间学习芯片设计，并与工程师一起构建评估，以测试 AI 能否生成有用的测试并正确诊断芯片故障。
在学习的同时，我们为各个用例构建了定制化的 harness。在最初的 3-6 个月里，它们全部进入了生产环境并获得了早期用户采用。回报体现在这些指标上：
通过基于 AI 的定向测试生成，节省了约 48% 的时间。
通过内核优化，性能中位数提升了 22%。
数周的调试被压缩到数小时
当我们把这一切复盘汇报时，首席硬件官问道：“你们来这儿之前是不是做过芯片设计师？”
我们的 FDE 并不需要在第一天就了解这个行业，但学习它是他们的责任。
随着编码助手让软件开发变得更快，理解客户的业务变得更加重要。我们组建的团队由通才和领域专家混合构成。
你需要足够的知识来做出合理的判断，并且要有足够的好奇心去质疑关于现状的假设。
例如，在生命科学领域，我们 FDE 的科学背景帮助他们赢得研究人员的信任，这些研究人员从事临床前药物发现任务，如靶点验证与优先级排序、基因表达分析以及化学合成路线重建。这种专业知识让他们能够就这些工作流如何改进提供有依据的判断。
让成功可复制
我们已经证明这些工作流能够交付价值，但每一个仍然需要过多的定制集成才能扩展到另一个团队。下一个挑战是在保留这些成果的同时，让软件更易于部署和维护。
到那时，Codex 的能力已经增强。一位 FDE 尝试围绕它重建自己的应用，随后与团队合作，将这些用例迁移到一个以 Codex 为核心的通用 harness 上。
定制应用变成了基于通用 Codex 原语构建的插件和技能。Codex 还成为了接口，让我们得以淘汰为各个用例单独编写的终端 UI 和 CLI。
我们能够从每个项目中移除大约 90% 的定制代码，这改变了我们构建、维护和扩展这些工作流的方式：
我们可以受益于对 Codex 的集中式改进，减少每个用例所需的胶水代码量
关键功能被捆绑为技能和插件，使它们更容易彼此共享，并由 AI CoE 集中控制。这意味着从一个团队扩展到下一个团队可以像换入新的连接器/MCP 服务器、构建新的评估（我们也有相应的技能）并启动运行一样简单。
在 2026 年 8 月的一个例子中，初始部署耗时两个月。将该解决方案扩展到第二个团队只花了一天。随着我们扩大规模，后续团队的上手速度更快——这一趋势持续至今，2026 年 8 月的一个用例在初始部署耗时 2 个月后，第二个团队仅用 1 天。
这是让自己变得过时的一种方式。我们为投入生产所做的工作确立了真正重要的东西。随着底层产品的改进，我们可以替换掉大部分自定义实现，同时保留它所交付的价值。
这就是顺序重要的原因。LLM 让我们能够快速构建。利用这种速度将有价值的东西交到用户手中，了解哪些在实践中站得住脚，然后扩展行之有效的部分。
同样的原则适用于所有合作项目。
OpenAI Presence，我们用于企业语音和聊天智能体的产品，源自真实的客户部署。这项工作始于Swarm（在新窗口中打开）并通过Agents API演进，如今一位客户已用 AI 处理其超过一半的通话。
将这些部署投入生产让我们了解到哪些问题需要自定义解决方案，哪些构建模块可供其他团队使用。我们将这些构建模块引入 Presence，使开发者更容易自动化受监管的工作流，而无需重建底层基础设施。每次部署都帮助塑造了产品，并为下一位客户提供了更好的起点。
借助Thrive Holdings，OpenAI 的 FDE 和研究人员与工程师和会计师并肩合作，为克里特岛的会计师事务所构建了 Tax AI。在试点期间，Tax AI 处理了 7,000 份纳税申报表，吞吐量提高了约 50%。
最难的挑战之一是自动化租赁房产报税，这需要六周的工程和从业者评审才能达到 90% 的精确率和召回率。这项工作创造了可复用的模式，使 Tax AI 更容易扩展到其他复杂的税务表格。
团队现在正将同样的方法应用于记账、审计和 IT 支持——构建能通过从业者反馈和真实使用不断改进的系统。
在智能缺口出现时将其弥合
有时更好的产品能让我们简化已构建的东西，但有时模型本身还无法胜任这项工作。
如果我们只构建当今模型已经能实现的东西，就无法发现 Research 接下来需要弥合的智能缺口。因此，我们的许多重要合作都从这些极限处开始，由客户、FDE 和 Research 共同承诺一起攻克它们。
我们已与一家大型电信客户开发了一个客服平台，他们希望将其扩展到语音。
语音约占他们客服量的 90%。这些案例的遏制成本高于聊天，并带来了一系列新的技术挑战，需要将口音、语气和延迟/准确率提升到生产级水平。把它做好将对他们的业务产生重大影响。
在范围界定期间，我们的模型在我们用于评估其能否在生产中胜任工作的关键评测上得分约为 60%。我们已经达到了其能力的极限。客服场景中的函数调用和指令遵循需要改进。
我们向客户解释了这一点，并将 Research 引入这项工作。FDE 与客户合作构建平台并定义模型需要做什么。Research 致力于弥合能力缺口，连续的模型快照让我们能够根据客户的要求测试进展。
在六个月里，关键评测上的表现从约 60% 提升到 80%，然后达到 90% 以上，达到了生产所需水平。
由此产生的语音模型现在支持该客户的部署、其他定制客服部署，以及通过 Presence 提供的托管部署。在一个客户的业务中遇到的问题，帮助识别出了可服务于许多其他客户的改进。
每个部分都很重要。客户承诺解决一个模型尚无法解决的问题。FDE 保持足够紧密的参与，以界定该问题、构建平台，并从头到尾推动整个合作。研究改进了底层模型能力。
这是让我们自己变得过时的另一种方式：帮助把当今模型无法解决的问题，转化为未来模型可以交付的能力。我们工作的回报，超越了我们在任何单个客户身上投入的时间。
去寻找更难的问题
我加入 OpenAI，是为了帮助让 AI 在人们的日常工作中变得有用。这仍然指引着团队。我经常对团队说，在 LLM 开发的大多数情况下，奥卡姆剃刀原则适用——最简单的解决方案就是最好的。在一家以尖端研究定义自身的公司里，在一个被夸大宣传所污染的行业中，我们想要构建的是可靠运行、让一线从业者可以依赖的东西。
目标是让每一次合作都能改进接下来的事情：一个更容易部署的产品、一个能处理更难任务的模型，或者为下一个客户减少定制工作。
如果你有一个想解决的难题，我们很乐意与你合作。如果你想帮助解决这些问题，我们很乐意你加入我们。
那么，当 Codex 能处理我们花了数月构建的工作时，我们该怎么办？
去寻找更难的问题。