OpenAI FDE Lead Discusses How the Team Brings AI into Enterprise Production Environments

入职没几天，就被“逼着”去学怎么设计芯片？辛辛苦苦干了几个月写出来的代码，AI一升级，直接给你删掉了90%？最奇葩的是，在这个岗位上，你干得越好，你可能就越快“失业”？

这是目前全球最顶尖的AI公司——OpenAI里，做一名FDE工程师的真实经历。

如果说OpenAI的研究员是在实验室里造核武器的人，那FDE团队就是把这些武器带到前线，手把手教企业怎么打赢战争的“特种兵”。他们的任务只有一个：解决客户最棘手的业务问题，把AI真正落地到生产环境里。

在最新发布的一篇博客中，负责人Colin Jarvis 分享了 OpenAI FDE 团队的工作方式，还附上了一张团队全员大合照。

这份工作远没有听上去那么高大上，甚至充满了“受虐”的色彩。总结了一下，他们主要得闯过这么几道难关。

第一关：你得是个“速成”的行业专家

在2025年年中，大概有15名OpenAI FDE工程师被派去和一家大型半导体客户合作。目标是用AI来帮芯片做验证。芯片验证有多麻烦？它能占整个造芯工程近70%的工作量。

但这帮工程师刚入职没几天，别说造芯片了，可能连半导体行业的门都还没摸清楚。怎么办？硬着头皮上。他们直接扎进客户的团队里，跟着学芯片设计，用业余时间恶补知识。

为什么要这么拼？打个比方，如果你不懂怎么修车，你怎么能判断AI给出的修车方案是对是错？AI写了一段测试代码，或者报了一个故障，你得知道它在真实业务里到底有没有用。

结果三到六个月后，他们帮客户省了大概48%的定向测试时间，性能中位数提升了22%，原本要几周的调试工作，压缩到了几个小时。客户的硬件老大甚至震惊地问：“你们以前是做芯片设计的吗？”

第二关：拒绝“面子工程”，死磕真实效果

在普通的软件开发里，搞个Demo，跑通了，能演示了，基本就算交差了。但在FDE团队，这连及格线都够不上。

如果是为了对付差事，工程师大可以搞个“阉割版”交差。但FDE的做法是：不行，咱们得从根儿上解决。他们把客户的需求拆解开，跑回去找OpenAI的研发团队，要求他们给模型“升级大脑”，改进指令遵循和函数调用的能力。

磨了半年，硬是把分数从60分拉到了90分以上，达到了真正能上线的标准。这说明什么？FDE不仅是AI的使用者，他们更是逼着AI进化的“监工”。

前面那个半导体项目，团队花了好几个月，给不同的场景写了大量定制化的代码和工具。

结果过了一段时间，OpenAI自家的写代码模型Codex升级了！更聪明了！这时候，一位FDE工程师做了一个疯狂的决定：他用升级后的Codex重新搭了框架，把原来那些复杂的定制应用，全变成了通用的插件。

结局是：每个项目里的定制代码，被删掉了大约90%！

心疼吗？可能有一点。但换来的是什么？以前部署一套方案要两个月，现在推广给下一个团队，只要一天。

这就是在OpenAI当工程师最核心的价值观：你的价值，绝对不是你写了多少行代码，而是你解决了什么问题，以及你能否让下一个人，不用再从头受一遍你受过的苦。

这也体现在他们和税务公司合作的AI项目里。一开始处理复杂的出租物业税表极其痛苦，团队花了6周时间才把准确率拉到90%。但一旦这个方法沉淀下来，以后再处理类似的复杂表单，AI就能轻车熟路了。

在Codex发布后，FDE团队里确实有人这么问过负责人Colin Jarvis。

Colin的回答非常霸气，他说：“那就去找一个更难的问题。”

以下是博客全文翻译：

FDE在 OpenAI 意味着什么

我们做什么、如何工作，以及如何解决企业最棘手的问题、交付真实的影响。

Codex 发布时，团队里有人问我：“如果 Codex一次就能搞定我们过去几个月辛苦搭起来的那些用例，那我们该去做什么？”

这个问题恰好触及 FDE 在 OpenAI 的核心含义。我们和客户并肩工作，弄清他们最难的问题，搭出他们可以依赖的方案。我们从中获得的认识，既影响产品的走向，也为研究团队提供一个个具体可以去攻的问题。

这就是进步。如果我们每隔几个月就让自己变得多余，说明 FDE 团队把活干对了。

我在 2025 年初组建这支团队，为的是弥合我们所说的“部署鸿沟”——模型看起来能做到的事，与人们能可靠拿来完成工作的事，两者之间的距离。

图 1｜“部署鸿沟”：模型能力所能创造的价值，与当前业务价值轨迹之间的落差

模型能力的演进速度，快过把它真正用起来所需要的系统和流程。有时候缺的是一个产品；有时候模型在基准测试上表现很好，放到真实变量和约束下却干不了这活。

我们盯住客户最难的问题。模型今天就能胜任的部分，我们和产品团队、客户一起把方案做成可复用的；模型还力所不及的部分，我们和客户、研究团队一起界定差距、推动改进。我们希望每一次项目都能让下一个客户站在更好的起点上——如果地板被抬到这样的高度：下次再遇到这一类问题，客户已经不需要 FDE 出面，那我们的活就算干好了。

拥有两百年历史的农业企业约翰迪尔（John Deere），面对的挑战是如何把面向农户的个性化建议规模化。

其中一个例子是精准除草技术 See & Spray：用摄像头和机器学习识别杂草、只对杂草施药，而不是整片农田撒药，可把化学品用量降低最多 70%。

但要拿到这些好处，前提是农户知道怎么配置设备、怎么安排整个种植季、在条件变化时怎么调整做法。

约翰迪尔调用 OpenAI 的 API，让这类支持既个性化又能规模化。

机会不止于单次交互：把有用的指导贯穿客户旅程的每一步，让农户把设备用得更充分，同时提升效率与可持续性。

这正是 OpenAI 的 FDE 要去解决的问题：帮组织从“拥有 AI 能力”，走到“拥有能在复杂真实环境里产生实际价值的系统”。

但这类问题往往没有边界，可能没有现成的标准答案，也没有操作手册。人人都想造出从未有过的东西，愿意为此付出代价的人就少得多。

既要找到有天赋的 FDE，又要不断抬高“够用”的标准，这意味着持续试错，也持续投入。

从结果出发

每次 FDE 团队开会，我都会先放一页幻灯片，上面只有一条核心价值观：“从结果出发，为成功不惜代价，然后再谈规模化。”

图 2｜作者在团队会议上展示的核心价值观：从结果出发、为成功不惜代价、然后规模化

在有人问出“它在真实世界里能用吗”之前，一个惊艳的演示能顶很久。

我们的职责，是把客户的问题解决到这样的标准：敢在生产环境里为它背书。

2025 年年中，我们派出约 15 名 FDE，和一家大型半导体客户一起做十多个用例。目标是把他们的验证（verification）流程做成 AI 原生的，范围包括：

在这个行业，验证环节可能占到一个项目七成的工作量。空间巨大，可以下手的地方也很多。

有些 FDE 几天前才入职 OpenAI，从没做过半导体。他们直接扎进客户的验证团队，业余时间补芯片设计，和客户工程师一起搭评测（evals），检验 AI 能否生成有用的测试、能否正确诊断芯片失效。

边学边做，我们为各个用例搭了定制的harness（执行框架）。头 3 到 6 个月里，这些用例全部进入生产环境，并被早期用户用起来。回报落在数字上：

复盘时，客户的首席硬件官问：“你们来这儿之前是做芯片设计的吗？”

我们的 FDE 不需要第一天就懂这个行业，但把它学会，是他们自己的责任。

当编码助手让软件开发越来越快，理解客户的业务反而更重要了。我们的团队是通才与领域专家的混合编队。

知识要够，才能做出靠谱的判断；好奇心也要够，才会去质疑关于现状的那些默认假设。

以生命科学为例，我们 FDE 的科研背景，让他们能赢得研究人员的信任——这些人做的是靶点验证与优先级排序、基因表达分析、化学合成路线重构这类临床前药物发现工作。这份专业积累，让他们能就“这些流程该怎么改”给出有依据的判断。

让成功可复制

我们已经证明这些流程能产生价值，但每一个都还需要太多定制集成，才能复制到另一个团队。下一个挑战是：在保住这些成果的同时，让软件更容易部署、更容易维护。

图 3｜FDE 把一个硬问题转化为可复制的能力：硬问题 →从零到一的方案 →可复用的封装

那时 Codex 的能力已经长起来了。一位 FDE 试着围绕它重建自己的应用，然后和团队一起把这些用例迁到以 Codex 为核心的统一 harness 上。

定制应用变成了基于 Codex 通用原语构建的插件和技能。Codex 同时成了统一入口，我们为各个用例单独写的终端界面和 CLI 就此退役。

每个项目里大约 90% 的定制代码被去掉了，我们构建、维护和推广这些流程的方式也随之改变：

l Codex 的集中式改进能直接受益，每个用例需要的胶水代码随之减少。

l 关键功能被打包成技能和插件，团队之间更容易共享，也便于 AI CoE（AI 卓越中心）集中管控。这意味着从一个团队扩展到下一个团队，可能只需换上新的连接器／MCP 服务器、重建一套评测（这一步我们同样做了对应的技能），就能跑起来。

l 2026 年 8 月的一个例子里，首次部署花了两个月，把方案扩展到第二个团队只用了一天。随着规模扩大，后续团队的接入越来越快——这个趋势延续了下来：同样是 2026 年 8 月的用例，首次部署两个月，第二个团队一天。

图 4｜架构改造前后对比：改造前（左）为多智能体架构，改造后（右）为以 Codex 为中枢的架构

这是“让自己变得多余”的一种方式。为走到生产环境所做的那些工作，确立了什么才是真正重要的。随着底层产品变强，我们可以替换掉大部分定制实现，同时留住它创造的价值。

这就是顺序重要的原因。LLM 让我们建得快。用这份速度，先把有价值的东西交到用户手上，看清什么在实践中站得住，再去规模化真正有效的部分。

这条原则适用于所有项目。

面向企业语音与聊天智能体的产品OpenAI Presence，就是从真实的客户部署里长出来的。这条线始于 Swarm，经由 Agents API 演进，今天已有一个客户超过一半的来电由 AI 处理。

把这些部署推进到生产，让我们看清哪些问题需要定制方案、哪些积木别的团队可以直接用。我们把这些积木收进 Presence，让开发者不必重建底层基础设施，就能把受监管的流程自动化。每一次部署既塑造了产品，也让下一个客户站在更好的起点。

与 Thrive Holdings 合作时，OpenAI 的 FDE 和研究员同工程师、会计师一起，为克里特岛（Crete）的会计师事务所打造了 Tax AI。试点期间，Tax AI 处理了 7,000 份纳税申报，吞吐量提升约 50%。

最难的挑战之一是租赁房产申报的自动化：为了把精确率和召回率做到 90%，花了六周工程开发和从业者评审。这项工作沉淀出可复用的模式，让 Tax AI 更容易扩展到其他复杂的税表。

现在团队正把这套方法用到记账、审计和 IT支持上——构建那些能通过从业者反馈和真实使用不断变好的系统。

图 5｜在同样的人力下处理更多税表：Tax AI 的吞吐量指数约为改造前的 1.5 倍

智能缺口一出现就补上

有时更好的产品让我们能简化自己搭的东西，但有时模型本身还干不了这活。

如果只做今天模型已经能做到的事，我们就发现不了研究团队接下来要补的那些智能缺口。

所以我们很多重要的项目，恰恰从这些极限处开始：客户、FDE 和研究团队一起承诺，把它们啃下来。

我们此前已和一家大型电信客户搭好了客服平台，他们想把它扩展到语音。

语音占他们客服量的九成左右。这类通话比文字客服更难在自助环节解决，处理成本也更高，而且在口音、语气、延迟与准确率要达到生产级水准上，带来一连串新技术挑战。做好了，对他们的业务影响很大。

项目评估阶段，在用来判断模型能否胜任生产环境的关键评测上，我们的模型得分约 60%。这已经触到它能力的天花板：客服场景下的函数调用和指令遵循都需要提升。

我们向客户讲清了这一点，并把研究团队拉进来。FDE 和客户一起搭平台、界定模型需要做到什么；研究团队负责补齐能力缺口，一个个新的模型快照让我们能对照客户的要求检验进展。

六个月里，关键评测的成绩从约 60% 升到 80%，再到 90% 以上，达到了生产环境要求的水准。

图 6｜语音推理的实时进展：Audio Big Bench 准确率从 2024 年 12 月的 65.6% 升至 2026 年 5 月的 92.29%

最终得到的语音模型，如今支撑着这位客户的部署、其他定制的客服部署，以及通过 Presence 提供的托管部署。在一个客户业务里遇到的问题，帮我们找到了能服务许多其他客户的改进。

每一环都不可少。客户愿意投入一个模型当时还解决不了的问题；FDE 贴着现场，把问题界定清楚、把平台搭起来，并从始至终推动项目；研究团队提升了底层的模型能力。

这是“让自己变得多余”的另一种方式：帮一个当下模型解不了的问题，变成未来模型能交付的能力。我们工作的回报，远超出在单个客户身上投入的那些小时。

去找更难的问题

我加入 OpenAI，是想让 AI 在人们的日常工作里真正有用。

这一点至今仍在指引团队。我常对团队说，LLM开发里大多数情况都适用奥卡姆剃刀——最简单的方案就是最好的。在一家以最前沿研究定义自己的公司里，在一个被夸张话术沾染的行业里，我们想做的是可靠运转、让一线的人敢依赖的东西。

目标就是让每一次项目都改善下一次：更好部署的产品、能处理更难任务的模型，或者下一个客户更少的定制工作。

如果你有一个想解决的难题，我们愿意和你一起做；如果你想参与解决这些问题，我们欢迎你加入。

那么，当 Codex 能接下我们花了几个月搭建的工作，我们该做什么？

去找更难的问题。

市场有风险，投资需谨慎。本文不构成个人投资建议，也未考虑到个别用户特殊的投资目标、财务状况或需要。用户应考虑本文中的任何意见、观点或结论是否符合其特定状况。据此投资，责任自负。