人工智能阅读时长 19 分钟

OpenAI 的 FDE 实战手册：通过将 AI 演示转化为生产系统，让自己变得不再必要

OpenAI 的前沿部署工程师（FDE）通过深入客户现场，弥合 AI 演示与生产环境之间的鸿沟：将定制解决方案转化为可复用的能力，并把真实世界中的模型缺陷反馈给研究团队——目标是随着模型的进步，让自己变得不再必要。

什么是 FDE？不是售前，也不只是程序员

FDE 指的是前沿部署工程。与传统的依据需求文档工作的软件工程师不同，也与专注于演示的售前工程师不同，FDE 直接嵌入客户的真实业务环境中。他们与领域专家和工程师并肩工作，找出最棘手、往往定义不清的问题，然后结合 AI 模型、软件工程和领域知识，构建真正能在生产环境中运行的系统。

OpenAI 将模型基准测试与可靠业务价值之间的鸿沟称为部署鸿沟。一个在聊天窗口中回答良好的模型，并不等于一个能在实时语音客服热线中应对口音、延迟、复杂上下文和错误恢复的系统。

从结果出发，再考虑规模化

OpenAI 的指导原则是：从期望的结果出发反向推导，不惜一切代价取得成功，然后再考虑规模化。许多团队一开始就构建聊天机器人或炫目的演示；而 FDE 则会先问清楚在客户的工作流程中成功是什么样子，并首先构建评测框架。

案例研究：AI 在半导体验证中的应用

2025 年年中，约 15 名 FDE 与一家大型半导体公司合作，将 AI 引入芯片验证。该项目涵盖定向测试生成、根因分析、调试和架构辅助——超过十个用例。一些 FDE 此前并无半导体背景；他们在工作中学习，与客户的验证工程师共同设计评测指标，并判断 AI 生成的测试是否真正发现了缺陷。

在生产环境中运行 3–6 个月后的成果：

AI 辅助的定向测试生成节省了约 48% 的工程时间。

内核优化带来了约 22% 的中位数性能提升。

过去需要数周的调试任务被压缩到数小时。

这些数字来自 OpenAI 的公开案例研究，并不保证适用于每一次合作，但它们体现了 FDE 的衡量标准：成功与否取决于客户的工作是否真正得到改善，而不是写了多少行代码。

将一次性交付转化为可复用的能力

如果 FDE 只交付定制项目，这种模式就会变成昂贵的定制开发。第二阶段是将经过验证的解决方案提炼为可复用的资产。在半导体项目中，团队最初为每个用例分别构建定制应用和集成代码。随着 Codex 能力的提升，他们将所有内容迁移到一个以 Codex 为核心的共享执行框架上，把功能转化为可复用的 Skills 和 Plugins，并用统一界面取代了针对每个用例的 UI。

成果：每个项目的定制代码减少了约 90%。第二个团队的部署时间从两个月缩短到一天。

工程上的经验是：先用任何必要的定制手段解决问题；只有当同一模式反复出现时，才将其抽象为平台。过早的泛化会带来复杂性。OpenAI 的企业语音产品 Presence 也遵循了同样的路径——在真实部署中发现的共性需求被回馈到产品中，让后来的客户无需重建基础设施。

当模型不够好时：把差距反馈给研究团队

有时，无论应用层工程做多少努力都无法弥合差距——模型本身存在不足。在一个大型电信语音客服项目中，语音承担了约 90% 的联系量，但对延迟、口音鲁棒性、语气处理和可靠的函数调用有更高要求。最初的模型评测得分约为 60%，低于生产门槛。

FDE 没有用更多的应用代码来掩盖缺陷，而是精确定义了能力差距，并让研究团队参与进来。FDE 与客户共同搭建平台并定义真实任务；研究人员则针对函数调用和指令遵循进行改进。每次模型更新都用同一套业务专属评测集来衡量。

在约 6 个月内，关键评测得分从约 60% 提升到 80%，随后超过 90%，达到了生产标准。这揭示了 FDE 的第二个核心价值：把客户现场的问题转化为具体、可衡量的研究任务。

业务专属的评测至关重要。通用基准只能反映模型的大致质量，但无法替代那些检验以下问题的评测：答案是否正确？函数调用是否符合预期？延迟是否可接受？FDE 成为连接真实需求、业务评测与模型研究的桥梁。

为什么 FDE 的成功意味着让自己变得不再必要

OpenAI 前沿部署工程负责人 Colin Jarvis 直言不讳地说：如果每隔几个月你就能让自己变得不再必要，那 FDE 团队就是在正确地做事。这不是一句口号，而是这些案例中反复出现的循环：

当模型能够完成任务时，与产品团队合作将部署标准化、简化，而不是维护定制代码。

当模型无法完成任务时，与研究团队合作定义差距，并通过真实世界的评测推动改进。

客户成功之后，要追问：哪些部分可以沉淀为公开的产品、工具、评测套件或工作流，供下一次项目使用？

每次交付都应让下一次更容易。衡量标准从“我们写了多少定制代码？”转变为“类似的问题是否随着时间推移变得越来越容易解决？”这个角色不会消失——新的模型能力会解锁新的商业机会，进而暴露出新的问题——但已被产品和模型吸收的重复性工作应当消失。

给 AI 时代每位工程师的启示

不要把代码生成当作终点。AI 工具大幅削减了实现成本，但它们不会决定要解决什么问题，也无法保证系统满足真实的业务约束。

尽早进入真实场景，用结果来验证。与其花几个月构建一个“什么都能做”的 AI Agent，不如找到一个真实用户，定义成功标准，构建可靠的评测，然后持续迭代。

把定制化经验转化为可复用的工程资产。框架、Skills、插件、连接器、评测集、部署流水线——每个项目都应留下能成为下一个项目起点的产物。

区分应用工程问题与模型能力问题。有些差距可以通过更好的数据、工具、工作流或系统设计来弥合；另一些则需要更好的模型。误判这个边界，只会把精力浪费在错误的层面上堆砌代码。

随着实现成本越来越低，领域知识的价值不断上升。判断什么值得构建、验证正确性、驾驭复杂约束，才是高杠杆的活动。

总结：去解决下一个更难的问题

OpenAI 的这篇文章表面上是在解释 FDE 角色，实质上是在追问：当 AI 能快速写代码时，工程价值究竟在哪里？答案是：不在于谁写的代码最多，而在于谁真正理解问题、设计出可靠的解决方案，并把一次成功转化为可复制的能力。前沿部署工程师在客户现场将这一点落地——掌握业务上下文、构建系统、对生产结果负责，并把洞察反馈给产品和研究团队。这是一种连接业务、工程和 AI 研究的工作模式。

Jarvis 的结束语值得每位工程师铭记：去找下一个更难的问题。