Codex 发布时,团队里有人问我：“当 Codex 能够一次性完成我们花了几个月构建的用例时,我们该做什么?”
这个问题触及了 FDE 在 OpenAI 的意义的核心。我们与客户并肩工作,理解他们最棘手的问题,并构建他们可以信赖的解决方案。我们所学到的内容有助于塑造我们的产品,并为研究团队提供具体的问题去解决。
这就是进步。如果我们每隔几个月就让自己过时一次,那我们的 FDE 团队就是在履行职责。
我在 2025 年初创立了这个团队,以弥合我们所说的 “部署鸿沟”: 即模型表面上的能力与人们能够可靠地用于实际工作之间的距离。
模型能力的进步速度超过了将其投入使用所需的系统和流程。有时缺失的是一款产品。有时模型在基准测试中表现出色,但在现实世界的变量和约束条件下却无法胜任工作。
我们专注于客户最棘手的问题。当我们的模型今天能够胜任工作时,我们与产品团队和客户合作,使解决方案可重复;当模型力有不逮时,我们与客户和研究团队合作,定义差距并加以改进。我们的目标是让每一次合作都为下一位客户留下更好的起点——如果我们将底线提升到客户下一次不再需要 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，从未从事过半导体工作。他们嵌入客户的验证团队，利用业余时间学习芯片设计，并与工程师一起构建评测集（evals），以测试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与客户合作搭建平台并明确模型需要完成的任务。研究团队致力于弥合能力差距，通过 successive 模型快照让我们能够针对客户的需求测试进展。
在六个月里，关键评测的表现从约60%提升到80%，再到90%以上，达到了生产环境所需的水平。
由此产生的语音模型现在支持该客户的部署、其他定制客服部署，以及通过 Presence 提供的托管部署。在一家客户业务中遇到的问题帮助找出了可以让许多其他客户受益的改进。
每一部分都很重要。客户承诺投入解决一个模型当时还无法解决的问题。FDE保持了足够的贴近度来界定该问题、搭建平台并从头到尾推动整个合作。研究团队改进了底层模型能力。
这是让自己变得可有可无的另一种方式：帮助把今天的模型无法解决的问题转化为未来的模型能够交付的能力。我们工作的回报超越了与任何单一客户共度的那些时间。
去寻找更难的问题
我加入 OpenAI 是为了让 AI 在人们的日常工作中发挥作用。这仍然指引着团队。我常对团队说，在大多数 LLM 开发案例中，奥卡姆剃刀都适用——最简单的方案就是最好的方案。在一家以尖端研究定义的公司里，在一个被夸大宣传所玷污的行业中，我们想打造那些运行可靠、现场人员可以信赖的东西。
目标是让每一次合作都能改进后续的工作：一个更容易部署的产品、一个能处理更难任务的模型，或者让下一位客户所需的定制工作更少。
如果你有一个想要解决的难题，我们很乐意与你合作。如果你想帮助解决这些问题，我们很乐意你加入我们。
那么，当 Codex 能够处理我们花了几个月构建的工作时，我们该怎么做？
去寻找更难的问题。