本文永久链接 – https://tonybai.com/2026/10/27/openai-forward-deployed-engineering-ai-production

大家好，我是Tony Bai。

【导读】

当 Codex 已经可以一次性完成过去需要数月开发的工作，OpenAI 的前沿部署工程师（FDE）该怎么办？

OpenAI 给出的答案颇为反直觉：不要守着旧方案，而要主动让自己变得不再必要。深入客户业务、把 AI 系统真正部署到生产环境、将一次性的定制方案沉淀为可复用能力，并把模型解决不了的问题交给研究团队——这才是 FDE 的核心价值。

【文章要点】

  • FDE 是什么？为什么传统软件开发与售前工程都不足以概括这一角色？
  • AI Demo 与生产级系统之间，究竟隔着什么？
  • OpenAI 如何将半导体验证项目中的定制代码减少约 90%，并把第二个团队的部署时间从两个月缩短到一天？
  • 当模型能力遇到瓶颈，FDE 如何与客户、研究团队协作，推动模型进步？
  • AI 编程时代，企业应该如何理解 FDE，以及它对工程师职业发展的启示？

当 Codex 已经可以一次性完成过去需要数月开发的工作，OpenAI 的前沿部署工程师（FDE）该怎么办？

继续写代码？维护那些曾经引以为傲的定制系统？还是担心自己的岗位终有一天会被 AI 取代？

OpenAI 前沿部署工程负责人 Colin Jarvis 在 2026 年 10 月发表的一篇文章中，给出了一个颇为反直觉的答案：

如果每隔几个月，你们就能让自己变得不再必要，那么 FDE 团队就做对了。

这句话值得每一个正在拥抱 AI 编程的工程师仔细琢磨。

过去，我们衡量工程师的价值，往往看他能写多少代码、能设计多复杂的架构、能否解决别人解决不了的技术问题。

但当 AI 开始大幅降低软件开发成本时，新的问题出现了：代码可以很快生成，为什么企业仍然难以真正用好 AI？

OpenAI 的 FDE 实践，恰好提供了一个观察这个问题的窗口。

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

FDE 的全称是 Forward Deployed Engineering，通常译为“前沿部署工程”或“前向部署工程”。

理解这个角色，关键在于两个词：Forward Deployed。

传统的软件工程师通常围绕产品和技术开展工作：理解需求、设计系统、编写代码、测试和交付。

售前工程师则更多负责产品演示、方案设计与技术沟通。

FDE 不完全属于其中任何一种。

他们深入客户的真实业务场景，与客户的业务专家、工程师并肩工作，识别最棘手的问题，再利用 AI 模型、软件工程和领域知识，构建真正能够投入生产的系统。

这意味着，FDE 面对的往往不是一份清晰的需求文档，而是一个尚未被充分定义的问题。

例如：

  • 芯片设计团队希望利用 AI 生成有效的验证测试，并快速定位芯片故障。
  • 企业希望让 AI 处理大量真实客户的语音服务请求，而不是只在聊天窗口中回答几个问题。
  • 会计师事务所希望自动处理复杂税表，同时保证准确率达到业务要求。

这些问题都不是简单调用一个模型 API 就能解决的。

它们涉及业务流程、历史数据、外部系统、质量评估、异常处理以及生产环境的各种约束。

OpenAI 将这类挑战称为“部署鸿沟”（Deployment Gap）：模型在演示或基准测试中展现的能力，与人们在真实工作中能够可靠使用的能力之间，仍然存在距离。

图：能力到业务价值的部署鸿沟

模型回答得很好，不等于它能完成工作。

一次演示成功，不等于系统可以稳定运行。

而 FDE 的任务，就是跨越这些障碍，把模型的潜在能力转化为可衡量的业务成果。

先解决问题，再考虑规模化：Demo 不是终点

OpenAI 在文章中提出了一条非常明确的工作原则：从结果出发，尽一切努力实现成功，然后再考虑规模化。

这句话看起来简单，却与许多 AI 项目的实际推进方式形成了鲜明对比。

不少团队在接触大模型后，首先想到的是做一个聊天机器人、搭建一个 Agent，或者把某个工作流程包装成一个漂亮的 Demo。

但真正进入生产环境后，问题才开始暴露。

模型生成的测试是否真的能发现芯片设计缺陷？AI 对客户的回答是否符合业务规范？系统能否处理口音、延迟和复杂的上下文？当模型犯错时，系统能否识别并正确处理？

这些问题无法靠演示视频回答。

一个真实案例：AI 如何进入芯片验证流程？

2025 年年中，OpenAI 派出约 15 名 FDE，与一家大型半导体企业合作，探索如何让芯片验证流程原生支持 AI。

项目覆盖了定向测试生成、根因分析与调试、架构辅助等十余个用例。

值得注意的是，部分 FDE 加入团队时，对半导体行业并不熟悉。他们需要深入客户的验证团队，学习芯片设计知识，并与领域工程师共同构建评估机制，判断 AI 生成的测试是否有用、故障诊断是否准确。

最终，这些用例在最初的三至六个月内陆续进入生产环境，并取得了实际成效：

  • AI 辅助定向测试生成，节省约 48% 的时间。
  • 内核优化带来约 22% 的中位性能提升。
  • 部分原本需要数周的调试工作，被压缩到数小时。

这些数字来自 OpenAI 对该客户项目的公开介绍，并不意味着其他企业可以直接获得同样的收益。

但它们说明了一件事：FDE 的工作成果，不是生成了多少代码，而是客户的工作是否真正变好了。

这里还有一个重要细节。

FDE 不一定要在第一天就成为某个领域的专家，但必须主动学习领域知识。随着 AI 编程工具不断降低实现成本，理解业务、判断结果是否正确，以及知道什么才算真正解决问题，反而变得更加重要。

最值得关注的转变：把一次性交付变成可复用能力

如果 FDE 只是在客户现场完成一个项目，那么这种工作方式很容易沦为高成本的定制开发。

OpenAI 的实践还有第二个阶段：把已经验证有效的解决方案，变成下一位客户可以复用的能力。

这也是整篇文章中最值得软件工程团队关注的部分。

在芯片验证项目中，OpenAI 最初为不同用例构建了定制应用和集成代码。方案虽然有效，但扩展到其他团队时，仍然需要大量重复工作。

后来，随着 Codex 能力增强，团队开始重新审视原有架构。

他们将不同应用迁移到以 Codex 为核心的公共执行框架中，把特定功能转化为可复用的 Skills 和 Plugins，并用统一的交互方式取代针对不同用例分别构建的终端界面和命令行工具。

结果是：每个项目中的定制代码减少了约 90%。

更令人印象深刻的是部署周期的变化：按照 OpenAI 公布的一个案例，第一个团队的初始部署花了两个月，而将方案扩展到第二个团队，只花了一天。

图：从客户定制到通用能力

这背后有一个值得注意的工程思想：

第一次解决问题，可以允许一定程度的定制；但第二次、第三次遇到类似问题时，就应该认真考虑哪些部分值得抽象和复用。

当然，这不意味着所有代码都应该被抽象成平台。过早设计通用框架，同样可能制造复杂性。

真正重要的是，先通过真实业务验证什么有价值，再逐步沉淀稳定的通用能力。

OpenAI 的企业语音产品 Presence，也体现了类似的路径：从真实客户部署中识别共性需求，再把验证过的能力纳入产品，让后续客户不必重复建设底层基础设施。

这也是 FDE 与传统项目交付思路之间的重要区别。

交付一个项目，只解决了一个客户的问题；沉淀一种能力，则可能改变一类问题的解决方式。

如果模型本身不够强，FDE 又该怎么办？

前面的案例有一个前提：模型最终能够完成任务，只是需要工程团队将它接入真实业务。

但还有另一类问题：无论如何优化应用层代码，模型本身都达不到生产要求。

这时，FDE 的职责就不仅是系统集成，而是帮助发现和缩小模型的能力缺口。

OpenAI 文章介绍了一个大型电信企业的语音客服项目。

该企业希望将原有客服平台扩展到语音场景。语音业务约占其客服业务量的 90%，但相较于文本聊天，它对延迟、口音识别、语气处理和指令执行提出了更高要求。

在项目评估阶段，模型在关键评测中的表现约为 60%，尚不足以满足生产要求。

团队没有通过增加更多应用层代码来掩盖问题，而是明确了模型的短板，并将研究团队引入项目。

FDE 与客户共同构建平台、定义真实业务需要模型完成的任务；研究团队则针对函数调用和指令遵循等能力进行改进。每次模型更新后，双方都会使用相同的业务评测检验进展。

经过约六个月，关键评测成绩从约 60% 提升至 80%，最终超过 90%，达到该项目所需的生产标准。

这个案例揭示了 FDE 的另一项重要价值：把客户现场的问题，转化为模型研究团队可以解决、可以衡量的问题。

这里的评测尤其关键。

通用基准测试可以帮助团队了解模型的大致水平，但无法替代针对具体业务的评估。对语音客服而言，回答是否正确、函数调用是否符合预期、延迟是否可接受，都可能直接决定系统能否上线。

因此，FDE 不只是把模型交给客户使用的人，也是连接真实需求、业务评测与模型研发的重要桥梁。

当模型遇到瓶颈时，他们帮助研究团队弄清楚：究竟缺少什么能力，以及怎样才能证明这一能力已经得到改善。

为什么说 FDE 的成功，是让自己逐渐变得不再必要？

回到最初的问题：如果 Codex 可以完成过去需要数月开发的工作，FDE 应该怎么办？

OpenAI 的答案是：去寻找更难的问题。

这不是一句简单的口号，而是前面几个案例共同指向的工作方法。

当模型已经能够完成某项任务时，FDE 应该与产品团队合作，把解决方案变得更标准化、更容易部署，而不是坚持维护原有的定制实现。

当模型无法完成任务时，FDE 应该与研究团队合作，明确能力缺口，并通过真实业务评测推动改进。

当某个客户的问题被成功解决后，FDE 还应该思考：哪些经验可以沉淀为公共产品、工具、评测方法或通用工作流？

这构成了一个持续循环：

图：FDE 的价值飞轮

每一次客户交付，都应该让下一次交付更容易。

这也是衡量 FDE 价值的一种新视角：不是团队做了多少定制开发，而是随着时间推移，同类问题是否越来越容易解决。

当然，“让自己变得不再必要”并不意味着 FDE 这个岗位会很快消失。新的模型能力会带来新的业务机会，而新的业务机会也会暴露此前无法发现的问题。

真正需要消失的，是那些随着产品和模型进步，已经没有必要继续存在的重复性工作。

AI 时代，工程师应该从 FDE 身上学到什么？

OpenAI 的 FDE 实践，对普通软件工程师和企业技术团队同样有启发。

第一，不要把写代码当作解决问题的终点。

AI 编程工具已经能够显著降低代码实现的成本，但它不会自动替你决定应该解决什么问题，也不会天然保证生成的系统符合真实业务要求。

第二，尽早进入真实场景，用结果检验方案。

与其花几个月打造一个看起来无所不能的 Agent，不如尽快找到真实用户，明确成功标准，构建可靠的评测机制，再通过持续迭代解决问题。

第三，把定制经验变成可以复用的工程资产。

公共框架、Skills、Plugins、连接器、评测集和部署流程，都可能成为下一次交付的起点。每次项目结束后，都值得问一句：哪些工作下次不应该再从头做？

第四，学会区分应用工程问题与模型能力问题。

有些问题可以通过更好的数据、工具调用、工作流和系统设计解决；另一些问题则需要模型本身取得进步。准确识别两者的边界，能避免团队在错误的方向上不断堆积代码。

最后，还有一点容易被忽略：领域知识不会因为 AI 更会写代码而失去价值。

恰恰相反，当实现变得更便宜，判断什么值得实现、如何验证结果、如何在复杂约束下做出正确决策，就变得更加重要。

FDE 并不是所有工程师都必须转向的职业方向，但它所代表的工作理念，正在变得越来越值得借鉴。

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

OpenAI 的这篇文章，表面上是在解释 FDE 的职责，实际上也提出了一个关于 AI 时代工程价值的问题。

如果 AI 能够快速生成代码，那么工程师的价值究竟在哪里？

答案或许不在于谁能写出更多代码，而在于谁能理解真实问题，设计可靠的解决方案，并将一次成功变成可重复的能力。

FDE 把这一过程推到了客户现场：既要理解业务，又要动手构建系统；既要对生产结果负责，又要将发现的问题反馈给产品和研究团队。

这是一种连接业务、工程与 AI 研发的工作方式。

文章最后，Colin Jarvis 再次回应了开头的问题：当 Codex 已经能够完成过去花费数月构建的工作时，FDE 应该做什么？

他的回答只有一句话：去寻找更难的问题。

这或许也是 AI 编程时代，值得每一位工程师记住的一句话。

参考资料：

还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：

  • 抛弃臃肿框架，回归“驾驭工程 (Harness Engineering)”的第一性原理
  • 用 Go 语言手写 ReAct 循环、并发拦截与上下文压缩引擎等，复刻极简OpenClaw
  • 构建坚不可摧的 Safety Middleware 与飞书人工审批防线
  • 在底层实现 Token 成本审计、链路追踪与自动化跑分评估
  • 从“调包侠”进化为掌控大模型边界的“AI 操作系统架构师”

扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。

还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：

  • 告别低效，重塑开发范式
  • 驾驭AI Agent(Claude Code)，实现工作流自动化
  • 从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码，开启你的AI原生开发之旅。

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。