FDE 的真正工作：把“看起来会做”变成生产环境里的可靠系统
OpenAI 前向部署工程负责人 Colin Jarvis 复盘部署鸿沟：半导体验证、Tax AI 与电信语音如何从客户现场问题走向产品原语和模型能力。
前向部署工程不是一支做漂亮 Demo 的团队。它的职责，是缩短“模型看起来能做到”与“组织可以放心投产”之间的距离。
Codex 出现后，Colin Jarvis 团队里有人问了一个直指应用型 AI 经济性的问题：如果 Codex 能一次完成团队过去几个月做的用例，我们接下来做什么？Jarvis 是 OpenAI 前向部署工程负责人，他的答案不是守住旧工作，而是把“让自己过时”视为团队履行职责的证据。
这个问题正是《What FDE means at OpenAI》的核心。文章发布于 2026 年 10 月 22 日。OpenAI 的前向部署工程师与客户并肩工作，在客户真实流程里找出最难的问题，再做出足够可靠、能经受生产环境考验的系统。现场工作还会反过来影响 Product 与 Research：反复出现的失败会变成产品需求，当前模型解决不了的问题会变成具体的研究目标。
这与传统解决方案咨询有本质区别。交付物不是战略 PPT，也不是概念验证，而是一套真正运行的系统、一套可复制的部署模式，必要时还包括更强的模型。团队定义成功的方式也很特别：每一次合作都应该让下一位客户拥有更高的起点。如果某类工作最终变得足够简单，下一位客户不再需要前向部署工程师，那么上一次合作就是成功的。
部署鸿沟首先是执行问题，不只是模型问题
Jarvis 于 2025 年初创建这支团队，目标是填补 OpenAI 所说的“部署鸿沟”：模型展现出的能力，与人能够可靠用它完成工作之间的距离。模型能力可能比周边产品、评估体系、集成方式和组织流程进步得更快。一个模型可以在基准测试里表现很好，却在真实变量、异常情况、组织约束和业务后果面前失效。
这条鸿沟至少有两种形态。有时模型已经具备所需能力，缺的是产品与系统；有时模型确实还做不到。把两者当成同一个问题，会产生两种坏结果：团队可能不断给一个已经碰到能力上限的模型堆提示词，也可能为一个很快会被产品原语吸收的能力过度建设基础设施。
因此，OpenAI 的工作原则是从客户最难的问题出发，而不是从自己偏好的技术出发。如果今天的模型能完成工作，前向部署工程师、Product 团队和客户一起把方案做成可复制的系统；如果模型做不到，工程师与客户则和 Research 一起定义缺失的能力。无论走哪条路，合作都必须为下一次部署留下可复用的知识。
先看结果，不要先看 Demo
每次团队工作开始时，Jarvis 都会放出一页很简单的幻灯片：从结果出发，不惜代价把事做成，然后再扩展。这个顺序借用了约翰·哈里森制造航海钟的经验。1735 年的 H1 证明问题可以被解决；1759 年的 H4 则让方案好到足以投入实际使用。让一件事存在，与让它可靠，是两个不同成就。Demo 可以庆祝前者，却很容易绕过后者。
文章给出的客户案例是 John Deere。其 See & Spray 系统用摄像头与机器学习识别杂草，再有针对性地喷洒，而不是处理整片农田。OpenAI 称，这种精准方式最多可减少 70% 的化学品使用。但只有硬件并不会自动产生收益。农户仍需要正确配置设备、规划种植季，并在田间条件变化时调整操作。
John Deere 使用 OpenAI 的 API，让支持服务更个性化、更可扩展。农户可以用自然语言提问，获得配置指导、情境化建议，并在设备没有发挥应有性能时得到提示。这里最重要的变化，不是模型能回答一个问题，而是它能在整个客户旅程中持续提供相关指导。这要求模型嵌入产品知识和作业上下文，而不是只生成一段听起来合理的文字。
前向部署的经济价值在这里变得具体：不是 AI 能聊精准农业，而是农户能在真实约束下，对一套物理系统做更好的决定。交互界面、证据、建议和升级路径都同样重要。
生产价值只能在客户现场被验证
2025 年中期，约 15 名 OpenAI 前向部署工程师与一家大型半导体客户合作，推进十多个用例。目标是让验证流程实现 AI 原生。芯片项目约 70% 的工作量可能花在验证上，因此即便缩短一点周期也很有价值。最初范围包括定向测试生成、根因分析与调试，以及架构助手。
一些工程师刚加入 OpenAI 几天，从未做过半导体。他们进入客户的验证团队，在业余时间学习芯片设计，并与客户工程师一起建立评估，判断 AI 能否生成有用的测试、是否能正确诊断芯片故障。这不是向用户收集提示词的过程。团队必须学会什么才算有效测试、故障应该如何定位、芯片设计师会信任什么结果。
在前三到六个月里，这些定制 harness 全部进入生产并获得早期用户采用。OpenAI 报告称，基于 AI 的定向测试生成节省了约 48% 的时间，kernel 优化让性能中位数提升 22%，过去需要数周的调试被压缩到数小时。文章引用客户首席硬件官的反应：“你们来之前是芯片设计师吗？”
OpenAI 的前向部署工程师不需要在第一天就懂行业，但他们有责任把行业学会。
这条区分对所有应用型 AI 团队都重要。领域知识不能被更快的代码生成替代。当编码助手让实现成本下降，理解客户业务反而会在工作中占更大比重。团队既要有足够知识做正确判断，也要有足够好奇心质疑现状，而不是不加思考地把旧流程自动化。
因此，OpenAI 会组合通才与领域专家。在生命科学中，有科研背景的工程师可以参与靶点验证与优先级排序、基因表达分析、化学合成路线重建等工作。足够深的专业能力，让他们能够判断流程应该如何改变，而不只是把现有步骤翻译成软件。
先让成功可复制，再谈规模化
半导体用例已经证明价值，但每个项目仍带有太多定制集成。这是企业 AI 常见的失败点：第一次部署很成功，最后却变成一堆只有原团队能维护的脚本、CLI、提示词和连接器。系统在标杆客户里能跑，换一个环境却越来越难复现。
随着 Codex 能力提升，一名工程师尝试围绕它重建应用。随后，团队把半导体用例迁移到以 Codex 为核心的公共 harness 上。定制应用变成建立在共享 Codex 原语之上的插件和 skill。Codex 也成为统一界面，使团队能够退役那些为单个用例编写的终端界面与命令行工具。
OpenAI 称，这一步从每个项目中移除了约 90% 的定制代码。意义不只是代码更少。Codex 的集中改进现在能抵达每个部署；共享 skill 和插件让能力更容易分发，也便于客户的 AI 能力中心统一治理。把工作流扩展到另一个团队，可能只需要更换连接器或 MCP server、为新环境建立评估，然后让用户开始使用。
文章举了一个 2026 年 8 月的例子：第一次部署用了两个月，把方案扩展到第二个团队只用了 1 天。后续团队的上手还更快。这才是“可复制部署”的实际含义：昂贵的首次合作产出知识与原语，降低下一次合作的边际成本。
顺序很重要。大语言模型让团队可以快速构建，但速度首先应该用来把一个有价值系统交到用户手里。生产会揭示哪些假设成立、哪些异常占主导、哪些部分值得变成平台能力。只有到那时，规模化才是在保留真正有效的东西。直接规模化一个 Demo，只会把 Demo 的弱点一起复制。
一次部署可以变成产品，产品又会改变下一次部署
OpenAI Presence 是企业语音与聊天智能体产品，也走过同样路径。它始于客户部署与开源项目 Swarm，随后通过 Agents API 演进。OpenAI 称，目前有一位客户超过一半的来电已由 AI 处理。
生产部署暴露出哪些问题需要定制方案，哪些模块可以复用。可复用的部分随后变成产品基础设施。Presence 让开发者更容易自动化受监管流程，而不必为每个客户重新搭建底层系统。每一次部署都在为下一位客户增加证据。
与 Thrive Holdings 合作、为 Crete 会计师事务所构建的 Tax AI 是另一个具体案例。OpenAI 前向部署工程师和研究员与工程师、会计共同工作。试点期间，Tax AI 处理了 7,000 份税表，吞吐量提升约 50%。
出租物业税表尤其困难。自动化这项工作需要六周工程与从业者审查，才达到 90% 的精确率和召回率。结果不只是一张税表被自动化，而是形成了可复用的模式，让 Tax AI 更容易扩展到其他复杂税表。团队现在正把同样方法用于记账、审计和 IT 支持，并通过从业者的真实反馈持续改进系统。
这比常见的“从试点走向生产”漏斗更成熟。部署同时也是一个发现产品的工具。它会暴露重复集成、缺失评估，以及客户真正需要的控制界面。把这些发现打包，会改变未来每一次合作的成本结构。
当瓶颈是模型本身，就把智能缺口变成研究问题
并非所有问题都能靠更好的集成解决。如果前向部署工程师只构建今天的模型已经能做到的事，就永远无法发现 Research 下一步需要补齐的能力缺口。因此，一些最有价值的合作恰恰从模型边界开始，由客户、前向部署工程师和 Research 共同承担推进责任。
一家大型电信客户已经与 OpenAI 建设了客服平台，并希望扩展到语音。语音约占其客服量的 90%。这类交互比聊天更难控制，口音、语气、延迟和准确率都提高了技术门槛。做对这件事会明显改变其业务经济性。
在需求界定阶段，OpenAI 模型在生产任务的关键评估中约为 60%。客服场景里的函数调用与指令遵循还需要改进。OpenAI 向客户说明了限制，并把 Research 引入项目。前向部署团队与客户一起建设平台、定义模型需要完成的行为；Research 负责补齐能力缺口。随后一系列模型快照，让团队可以按客户的真实要求验证进展。
六个月里，关键评估成绩从约 60% 提升到 80%，随后超过 90%，达到生产要求。OpenAI 公布的图表还展示了 Audio Big Bench 在五个模型快照上的准确率，从 2024 年 12 月的 65.6% 上升到 2026 年 5 月的 92.29%。这两个指标不能混为一谈：前者是客户特定的生产门槛，后者是范围更广的音频推理基准。
最终形成的语音模型支持该客户的部署、其他定制客服部署，以及通过 Presence 提供的托管部署。一个客户业务中遇到的问题，变成了可服务更多客户的能力。这是另一种“让自己过时”：底层模型吸收最难的部分后，客户不再需要最初那套定制工作。
把文章里的证据压缩成一张表
这些案例来自不同产业，成熟度也不同，但共享同一种模式。下表数字均来自 OpenAI 报告，口径并未跨客户统一，因此不应被当作通用 benchmark。
| 案例 | 报告的变化 | 时间尺度 | 可复用的关键 |
|---|---|---|---|
| 半导体验证 | 定向测试生成节省约 48% 时间；kernel 性能中位数提升 22%；数周调试压缩到数小时 | 3-6 个月进入生产 | 客户特定评估与公共 Codex harness |
| 第二团队扩展 | 初始用例部署两个月；2026 年 8 月案例中第二个团队只用了 1 天 | 2 个月到 1 天 | 共享 skills、plugins、连接器、MCP server 与评估模板 |
| Tax AI 试点 | 处理 7,000 份税表；吞吐量提升约 50%；出租物业税表六周达到 90% 精确率与召回率 | 试点与六周最难场景建设 | 从业者反馈与可跨复杂税表复用的模式 |
| 电信语音客服 | 关键生产评估从约 60% 提升到 80%，再超过 90% | 6 个月 | 客户定义的评估、前向部署团队建设平台、Research 改进模型 |
有两个限制需要说清。第一，这些是供应商撰写的案例，不是独立审计。文章提供了有价值的运营细节与量化结果，但没有公开底层数据集、评估规则、失败率和完整成本。第二，同一团队可以报告自己挑选案例上的高成功率，而筛选过程本身不可见。即便如此，其战略含义仍然成立，因为多个案例展示了同一种机制：生产证据会改变下一步该建什么。
机器人与物理 AI 团队应该拿走什么
以下内容是 RobotWorld 的延伸分析，不是 OpenAI 原文主张。机器人会把部署鸿沟放大。语言模型失败可能只产生一份坏文档；物理 AI 失败可能损坏设备、停线，甚至造成安全事件。环境只能被部分观测，硬件会随时间漂移，而评估策略所需的数据采集成本很高。
因此，前向部署思维对机器人更重要，而不是更不重要。一次机器人部署不能停在有视觉冲击力的遥操作 Demo，也不能停在固定仿真里的高分。团队需要定义运营结果、给部署后的系统埋点，并把现场失败连接到模型、数据、集成和工作流变更。
| 部署阶段 | 必须回答的问题 | 进入下一阶段所需的证据 |
|---|---|---|
| 零到一 | 机器人能否在目标环境里完成任务？ | 在具有代表性的感知、光照、物体与操作员条件下稳定完成任务 |
| 生产 | 系统能否以要求的节拍和质量持续运行，并具备安全恢复路径？ | 周期时间、一次通过率、人工介入率、失败分类、恢复成功率与 uptime |
| 复用 | 哪些部分只适用于当前工位、场地或机队，哪些可以成为原语？ | 共享 skills、适配器、遥测 schema、仿真场景与评估套件 |
| 研究反馈 | 哪些失败是集成问题，哪些是真实能力缺口？ | 来自现场的评估集，足以区分产品修复与模型或策略改进 |
对机器人学习团队而言，文章里最值得借鉴的概念是公共 harness。一次成功的操作策略很有价值，但真正可复用的层次在它周围：标定后的传感器、任务规范、失败捕获、可回放 episode、仿真与真机评估、部署控制，以及向整个机队分发改进的机制。没有这层系统，每个新客户现场都会变成一次新的定制集成；有了它，每次部署都能抬高下一次的地板。
第二个概念是，评估必须编码客户的真实工作。半导体场景里是有效定向测试和正确故障诊断；税务自动化里是难税表的精确率与召回率；电信语音里是生产约束下的函数调用与指令遵循。通用基准可以帮助选择模型，却不能单独判断某个工位或客户流程是否已经就绪。
去找更难的问题
Jarvis 说，他加入 OpenAI 的动机是让 AI 在人们每天的工作中真正有用。在一个容易充满夸张叙事的行业里，这支团队明确偏好“能可靠工作的最简单方案”。奥卡姆剃刀在这里不是一句关于模型规模的标语，而是一种决策纪律：哪些必须定制，哪些可以打包，哪些应该在平台进步后消失。
每一次合作都应该改善下一次：让产品更容易部署，让模型能处理更难的任务，或者让下一位客户需要更少的定制工作。这比生产了多少个漂亮 Demo 更能衡量前向部署的价值。
所以，当 Codex 能完成过去要花几个月构建的工作时，前向部署工程师不会捍卫旧实现。工作系统已经变成原语，团队应该转向下一个尚未解决的问题。同样的检验也适用于机器人：部署成功最有力的证明，不是原工程团队永远不可替代，而是下一台机器人、下一条产线或下一个现场能从更高的起点开始。
来源：OpenAI，《What FDE means at OpenAI》，作者为前向部署工程负责人 Colin Jarvis，发布于 2026 年 10 月 22 日（openai.com/index/forward-deployed-engineering-means）。本文为原文完整翻译与改编，并包含明确标注的 RobotWorld 延伸分析；所有图表均来自原文。