Codex 发布后，有人问 OpenAI 前向部署工程负责人 Colin Jarvis：「我们过去几个月辛苦搭的用例，Codex 一下就能做了，我们怎么办？」他的回答点出了 FDE 这个角色的本质：「这正是我们的工作——如果每几个月就把自己淘汰一次，说明团队干得对。」

FDE 是什么

判断写进第一句：FDE 是陪客户啃最硬的骨头、把模型能力变成生产可依赖系统的角色，而不是卖模型的售前。

Jarvis 2025 年初成立这支团队，目标是弥合「部署差距」——模型看起来能做的事，和人们能可靠用它完成工作之间的距离。模型能力跑得比落地所需的系统和流程快，有时候缺的是产品，有时候模型在基准上分很高、一碰到真实变量和约束就干不了。FDE 就在这个缝里工作：模型今天能做的，和产品、客户一起把方案做成可复制；模型做不到的，和客户、Research 一起把差距定义清楚、推动底层改进。

有个细节很关键：FDE 不需要第一天就懂客户行业，但学懂它是职责。团队由通才和领域专家混编。判断力要够，还要有质疑现状的好奇心。

四大原则

文章主体就是四条方法论。一是「从结果出发，做成，再规模化」——顺序很重要，LLM 让你建得快，就先用这个速度把有价值的东西交到用户手上，再看什么扛得住实践，再放大。二是「让成功可复制」——每个案子都为下一个客户留下更好的起点。三是「随时弥合智能差距」——只做现有模型已经能做的，就挖不出 Research 下一步要补的差距，所以重要案子常从能力的极限处开始。四是「去找更难的问题」——目标永远是把下一个任务变得更容易：更好部署的产品、能扛更难题的模型、或更少的下一次定制。

这四条不是并列的口号，是一条链：先落地、再复制、补差距、再去解更难的题，环环相扣。

几个真实案例

事实清单，逐个核对原文：

  • 半导体客户：约 15 名 FDE 覆盖 10+ 用例做芯片验证 AI 化。定向测试生成省约 48% 时间，kernel 优化带来 22% 中位性能提升，调试从几周压到几小时。客户首席硬件官问他们「你们以前是不是做过芯片设计」。
  • John Deere：把 OpenAI API 接进支持服务，用自然语言回答农民问题、给定制化设备配置建议、识别设备没发挥全力的情形。
  • Codex 重构：半导体用例迁移到以 Codex 为核心的通用 harness 后，每个项目移除了约 90% 的定制代码，部署从初始 2 个月缩到第二个团队 1 天。
  • Tax AI：试点处理 7000 份报税、吞吐提升约 50%；最难的是租赁房产报税，用了六周工程和从业者评审才做到 90% 精确率与召回率。
  • 电信语音：模型在关键 evals 上从约 60% 起步，六个月内靠 successive snapshots 提到 80% 再到 90%+，达到生产门槛；Audio Big Bench 准确率从 65.6% 升到 92.29%。

和售前/解决方案工程师的差别

原文没有直接点这两个词，但差别能从职责里读出来。售前和解决方案工程师的终点常是「演示成功」；FDE 的终点是「生产标准」——Jarvis 原话是「把客户的问题解决到我们能站得住、能上生产的标准」。另一个本质差异是闭环方向：FDE 把现场学到的东西反哺回产品和 Research，是「能力反哺」的角色，而不是单向交付。也就是说，FDE 的价值不在于签单，而在于每一次交付都让下一个客户少做一点定制。

对职业路径的启示

对个人，这个角色传递的信号是：AI 时代最稀缺的不是会调 API，而是能把「模型能力」翻译成「客户真实工作」的人——既要技术判断，又要行业理解，还得有把定制方案做成可复制产品的能力。

那句「每个人都想造从没有过的东西，少有人愿意付出把它做出来的代价」，说的就是这件事。当 Codex 能接手你几个月搭的东西时，答案是去找更难的问题——这也是 FDE 这个角色给整个行业提的醒。