OpenAI 团队 FDE 的官方方法论

国内 FDE（前线部署工程）已经热了大半年，但最值得参照的方法论来自 OpenAI 内部。

此前 8 月 18 日日课讲过 FDE 的本质：它不是一个全新的岗位，而是深入业务现场，同时交付结果与可复用资产。今天再看 OpenAI FDE 团队的公开打法，最值得学的不是「驻场」两个字，而是怎样不把驻场做成外包。

他们的 FDE 团队从 2025 年初的 2 人扩到现在约 90 人，负责人 Colin Jarvis 在一次公开访谈里，完整讲述了 FDE 的全套打法。

一、只碰核心业务

这个团队的项目筛选极其苛刻，只瞄准能为客户创造千万到数亿美元价值的核心业务问题，个别项目甚至到百亿级。

为什么只做核心业务？只有在核心业务场景上，客户才愿意调动最好的资源、开放最核心的数据、承担试错的风险。边缘场景看起来好做，但做不出深度，也沉淀不出可复用的东西。

二、评测驱动开发

大模型是概率性的，某次对不代表一直对。怎么保证它在生产环境里稳定可靠？

Colin Jarvis 给出的方法叫评测驱动开发（Eval-Driven Development，EDD）。核心规则只有一条：任何一段由大模型驱动的业务逻辑，在没有一套能验证其有效性的评测集之前，都不算完成。

标准流程分三步：

1. 项目启动前，和客户的领域专家一起定义评测集，包含真实的业务输入和期望输出，定义什么算好、什么算坏。

2. 开发过程中，每一次模型或代码的改动都必须跑通评测集，确保性能不回退。

3. 项目交付时，评测框架本身就是交付物的一部分，交给客户的内部团队持续维护和迭代。

评测集让概率性大模型的行为变得可度量、可回归、可交接。这是整套方法论的基石。

三、划清概率性与确定性的边界

EDD 解决质量控制，架构层面还有另一个核心问题：大模型擅长处理复杂性和做推理，但企业应用里很多环节要求 100% 准确。

Colin Jarvis 的设计原则是：让大模型做它擅长的事，用确定性业务规则做约束。

举个例子，一家亚太汽车制造商的供应链项目，场景是中国出口到韩国的商品加征 25% 关税，需要快速调整供应链方案。

大模型负责理解自然语言指令，分析影响哪些零部件，调用内部模拟器生成多个调整方案，比如更换供应商、调整工厂产能。