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