10 个主要问题 Q&A
Q1：FDE 在 OpenAI 是什么缩写，中文是什么？ A1：Forward Deployed Engineering，前沿部署工程。
Q2：什么是 FDE 要解决的 “部署鸿沟”？ A2：模型在基准测试里展现的能力，和企业在真实约束下稳定使用、产生业务价值之间的差距。
Q3：FDE 最核心的理念 “让自己变得过时” 是什么意思？ A3：当一类场景跑通、能力产品化标准化后，客户后续处理同类问题不再需要 FDE 专项介入。
Q4：FDE 四大工作准则是什么？ A4：以结果为起点；让成功可复制；及时补齐智能缺口；去寻找更难的问题。
Q5：FDE 工程师是否必须提前懂客户所在行业？ A5：不需要入职就精通行业，但必须快速学习业务，理解业务约束。
Q6：FDE 和产品团队、研究团队是什么关系？ A6：FDE 对接客户，把业务问题整理清楚；成果沉淀到产品；模型短板交给研究团队优化。
Q7：Codex 在 FDE 规模化落地中起到什么作用？ A7：作为底层核心，把零散定制应用转为插件、技能，削减约 90% 定制代码，大幅降低复制成本。
Q8：OpenAI Presence 这个产品从哪里孵化而来？ A8：从 FDE 多个企业语音、对话智能体真实落地项目中沉淀演化出来。
Q9：当现有模型能力不足以完成客户需求时 FDE 怎么做？ A9：和客户一起定义评测标准，引入研究团队迭代模型，持续验证直到达到生产指标。
Q10：FDE 项目的价值仅仅服务单个客户吗？ A10：不是。单个客户场景验证出的能力、模型改进，后续可以普惠大量其他企业客户。
附录 OpenAI 的 FDE 到底意味着什么
我们的工作内容、协作方式，以及如何攻克企业最棘手的难题，创造真实业务价值
作者：科林・贾维斯（Colin Jarvis），OpenAI 前沿部署工程负责人
原文链接： https://openai.com/business/forward-deployed-engineering/https://forum.openai.com/public/events/work-at-the-frontier-forward-deployed-engineering-at-openai-vmimj73oz5
文章导航： https://openai.com/index/forward-deployed-engineering-means/#start-with-the-outcome —— 以结果为起点https://openai.com/index/forward-deployed-engineering-means/#make-success-repeatable —— 让成功可复制https://openai.com/index/forward-deployed-engineering-means/#close-the-intelligence-gaps-as-they-appear —— 及时补齐智能能力缺口 https://openai.com/index/forward-deployed-engineering-means/#go-find-the-harder-problem —— 去寻找更难的问题
Codex 刚推出的时候，团队里有人问我：“如果 Codex 仅凭一次提示，就能搞定我们花好几个月搭建的场景，那我们该做什么？”
这个问题，直指 OpenAI FDE（前沿部署工程，Forward Deployed Engineering）的核心。我们和客户并肩协作，理解他们最难的业务难题，打造稳定可靠的解决方案。从项目中沉淀的认知，会反哺产品迭代，也为研究团队提供需要攻克的真实问题。
这就是进步。如果每隔几个月，我们自己搭建的方案就不再必要、被能力更强的模型替代，恰恰说明 FDE 团队做到位了。
我在 2025 年初组建了这支团队，目的是弥合我们所说的“部署鸿沟”：也就是模型纸面展现出来的能力，和人们在实际工作中能够稳定落地使用之间的差距。 （配图说明：部署鸿沟示意图，展示 AI 现有能力和业务价值之间的断层）
模型能力迭代的速度，远超配套落地所需的系统与流程建设速度。有时候缺的是一款成型产品；有时候模型在基准测试里表现亮眼，但放到充满现实变量、业务约束的真实场景里，就无法胜任工作。
我们聚焦客户最棘手的难题。如果现有模型已经可以胜任这项工作，我们就联合产品团队与客户，把方案打磨成可复用的标准化方案；如果模型能力尚有不足，我们就和客户、研究团队一起定义能力缺口，推动模型优化。我们的目标是：每一次项目落地，都能为下一个客户打下更好的基础。当我们把能力基线抬升到一定程度，客户以后再遇到同类问题，不再需要 FDE 介入，就代表我们的工作圆满完成。
有着两百年历史的农业企业约翰迪尔（John Deere），面临的难题是如何规模化给农户提供个性化农技建议。 其中一个典型项目是 See & Spray 精准除草技术：这套设备搭载摄像头与机器学习模型，识别杂草并定点喷施农药，而非整块农田统一喷洒，最多可以减少 70% 的农药用量。
但想要兑现这份价值，农户需要懂得调试设备、规划农时、根据环境变化调整作业方案。 约翰迪尔接入 OpenAI API，让这套农技支持服务变得个性化、可规模化。
AI 可以用自然语言回答农户的问题，提供定制化的设备配置指导与农事建议，识别设备是否没有发挥全部性能，还能帮农户看懂这套技术带来的实际收益。 它的价值不止单次问答：在农户使用设备的全流程中持续提供适配建议，帮助农户用好设备，同时提升生产效率、实现绿色可持续。
这正是 OpenAI FDE 要解决的一类挑战：帮助企业从拥有 AI 能力，升级到搭建能在复杂真实环境中持续产出实际价值的业务系统。
但这类问题往往没有标准答案、没有既定参照、也没有现成手册。人人都想打造前所未有的新事物，愿意踏踏实实地走完落地全流程的人却很少。
一边寻找优秀的 FDE 人才，一边持续拉高 “可用标准”，意味着我们要不断试错、持续实践。
以结果为起点
每一次 FDE 团队启动项目会，我都会放一页幻灯片，上面写着核心准则：以结果为起点，全力以赴达成目标，之后再规模化复制。
酷炫的演示 demo 很容易让人兴奋，但很少有人第一时间关心它能不能在生产环境稳定运行。 我们的工作，是解决客户真实问题，交付一套我们自己也愿意背书、可以上线投产的方案。
2025 年年中，约 15 名 FDE 工程师服务一家大型半导体客户，落地十多个 AI 场景。核心目标是把芯片验证流程全面 AI 原生改造，覆盖：
-
定向测试用例生成 -
根因分析与故障调试 -
架构辅助助手
在半导体行业，验证工作通常占到项目总工作量的 70%，落地空间巨大，可选切入点很多。
有些 FDE 工程师刚加入 OpenAI 没几天，完全没有半导体行业背景。他们驻场嵌入客户的验证团队，利用业余时间学习芯片设计知识，和客户工程师一起搭建评测集，验证 AI 能不能生成有效测试用例、精准定位芯片故障。同步为每个场景搭建专属执行框架。在前 3–6 个月里，所有场景全部上线投产，拿到了亮眼指标：
-
AI 定向测试生成，节省约 48% 工时 -
内核优化带来 22% 的性能中位数提升 -
原本需要数周的调试工作，压缩至数小时
项目复盘时，客户首席硬件官问我们：“你们之前都是芯片设计师吗？”
FDE 工程师不需要入职第一天就精通行业，但主动吃透业务，是我们的责任。
代码助手降低软件开发门槛之后，读懂客户业务这件事变得更加关键。我们的团队兼顾通才与行业专家。 你要有足够专业判断能力，也要保有好奇心，敢于质疑行业里习以为常的固有思路。
举个生命科学领域的例子：我们 FDE 成员本身具备科研背景，在靶点验证与优先级排序、基因表达分析、合成路线重构等临床前新药研发场景中，更容易获得科研人员信任。依托专业积累，他们可以给出靠谱判断，思考如何优化现有工作流。
让成功可复制
我们已经证明这套流程可以创造价值，但每个场景定制化集成成本太高，很难快速推广到其他团队。下一个难题就是：保留已经验证的价值，同时降低软件部署与维护成本。
彼时 Codex 的能力持续提升。一位 FDE 工程师尝试基于 Codex 重构应用，随后团队把所有场景迁移到一套以 Codex 为核心的通用执行框架上。
原先一个个独立定制应用，变成基于 Codex 基础能力封装的插件与技能集。Codex 同时充当交互入口，我们不再需要为每个场景单独开发终端界面与命令行工具。
每个项目的定制代码量削减了大约 90%，彻底改变了我们搭建、维护、规模化落地工作流的方式：
-
所有场景共享 Codex 的集中升级红利，单个场景需要手写的粘合代码大幅减少 -
核心能力打包成技能与插件，方便团队内部共享，也可以由企业 AI 能力中心统一管控。从一个团队复制到另一个团队，往往只需要接入新连接器 / MCP 服务、新建评测集（我们也配套了自动构建评测集的技能），就能快速启用。
2026 年 8 月有个项目：首次落地耗时两个月；把方案复制到第二个团队，只花了一天。后续扩容速度持续加快。
这就是 “让我们自己变得不再必要” 的一种方式。投产落地的过程帮我们摸清了什么才是业务核心价值；随着底层模型产品持续变强，大量定制开发代码可以被替换，价值却保留下来。
这也是为什么顺序很重要：大模型让快速开发成为可能。先用这个速度把有价值的系统交到用户手上，摸清真实环境里哪些方案站得住脚，再规模化推广有效的方案。
这套思路适用于所有项目。 OpenAI Presence（面向企业语音与对话智能体的产品），正是从真实客户落地项目里孵化出来的。最早基于开源项目 Swarm 起步，之后迭代到智能体 API，如今已有客户依靠这套产品承接超过半数的客服来电。
这些落地实践帮我们分清：哪些问题需要定制开发，哪些能力可以沉淀成通用组件。我们把组件封装进 Presence，开发者不用重复搭建底层基础设施，就能快速搭建受合规监管的对话业务流程。每一次落地，都反过来塑造产品，给下一个客户更好的起点。
在克里特岛会计事务所税务 AI 项目中，OpenAI FDE 与研究人员，联合工程师、会计师，基于 Codex 搭建税务智能体。试点期间，这套税务 AI 处理了 7000 份报税单，处理吞吐量提升约 50%。
其中最难的场景之一是租赁房产报税自动化：前后花费六周开发 + 从业者评审，才做到 90% 的精确率与召回率。这次沉淀出可复用范式，后续拓展到其他复杂税务表单就轻松很多。
现在团队用同样思路搭建记账、审计、IT 支持智能体，依靠一线从业者反馈和真实使用数据持续迭代优化。
及时补齐智能能力缺口
有时候产品迭代简化了我们原先的方案；但也有些时候，当下的模型本身还做不到业务要求。
如果我们只做现有模型刚好能搞定的事，就无法发现研究团队下一步需要攻克的智能短板。所以很多高价值项目，恰恰起步于模型能力边界：客户、FDE、研究团队一起合力攻坚。
我们曾为一家大型电信客户搭建客服平台，客户希望拓展语音客服能力。 语音进线占这家客服总量约 90%，语音工单的服务成本远高于文字对话，同时带来一系列新挑战：口音适配、语气识别、时延与准确率，都要达到生产级标准。做好这件事，会给客户业务带来巨大收益。
项目前期评估，在投产标准评测集上，模型得分只有大约 60%，已经摸到能力天花板。客服场景下的工具调用、指令遵循能力都有待提升。
我们如实告知客户现状，并把研究团队纳入项目。FDE 对接客户搭建平台、清晰定义模型需要完成的任务；研究团队针对性补齐能力短板，持续输出新版本模型，对照客户业务指标验证效果。
历时六个月，关键评测指标从 60% 提升至 80%，最终突破 90%，满足上线标准。
迭代后的语音模型，不仅支撑这家客户落地，也服务其他定制客服项目，以及基于 Presence 的托管式部署。来自单一客户业务里发现的难题，最终转化成惠及大量客户的模型能力升级。
每一环都不可或缺：客户愿意投入资源，攻克当下模型还解决不了的问题；FDE 深度跟进，把业务问题标准化、搭建平台、全程推进项目；研究团队夯实底层模型能力。
这是 “让我们自己变得不再必要” 的另一层含义：把今天模型解决不了的难题，变成未来模型原生具备的能力。我们投入的价值，远远不止服务单个客户的工时。
去寻找更难的问题
我加入 OpenAI，初衷是让 AI 真正融入人们的日常工作，这也是团队一直以来的方向。我常跟团队说：在大模型开发里，奥卡姆剃刀原则依然适用 —— 最简单可行的方案往往最好。身处一个以前沿研究为底色、充斥夸大宣传的行业，我们想要打造稳定可靠、一线从业者可以信赖的系统。
每一个项目的目标，都是为后续铺路：推出更容易部署的产品、让模型胜任更难的任务、降低下一个客户的定制工作量。
如果你有棘手难题想要解决，欢迎和我们合作。如果你愿意一起攻克这些难题，欢迎加入我们。
回到最开始那个问题：如果 Codex 轻松搞定我们花数月搭建的工作，我们该做什么？
去寻找更难的问题。
术语小注
FDE = Forward Deployed Engineering，本文译作前沿部署工程，业内也常直译：前置部署工程 Deployment gap：部署鸿沟 Evals：评测集（AI 行业术语，用于检验模型效果的测试用例集合） MCP：Model Context Protocol，模型上下文协议 Occam’s Razor：奥卡姆剃刀原则
附图
