入职没几天，就被“逼着”去学怎么设计芯片？辛辛苦苦干了几个月写出来的代码，AI一升级，直接给你删掉了90%？最奇葩的是，在这个岗位上，你干得越好，你可能就越快“失业”？ 这是目前全球最顶尖的AI公司——OpenAI里，做一名FDE工程师的真实经历。 如果说OpenAI的研究员是在实验室里造核武器的人，那FDE团队就是把这些武器带到前线，手把手教企业怎么打赢战争的“特种兵”。他们的任务只有一个：解决客户最棘手的业务问题，把AI真正落地到生产环境里。 在最新发布的一篇博客中，负责人Colin Jarvis 分享了 OpenAI FDE 团队的工作方式，还附上了一张团队全员大合照。 这份工作远没有听上去那么高大上，甚至充满了“受虐”的色彩。总结了一下，他们主要得闯过这么几道难关。 第一关：你得是个“速成”的行业专家 AI工程师懂代码很正常，但懂造芯片吗？ 在2025年年中，大概有15名OpenAI FDE工程师被派去和一家大型半导体客户合作。目标是用AI来帮芯片做验证。芯片验证有多麻烦？它能占整个造芯工程近70%的工作量。 但这帮工程师刚入职没几天，别说造芯片了，可能连半导体行业的门都还没摸清楚。怎么办？硬着头皮上。他们直接扎进客户的团队里，跟着学芯片设计，用业余时间恶补知识。 为什么要这么拼？打个比方，如果你不懂怎么修车，你怎么能判断AI给出的修车方案是对是错？AI写了一段测试代码，或者报了一个故障，你得知道它在真实业务里到底有没有用。 结果三到六个月后，他们帮客户省了大概48%的定向测试时间，性能中位数提升了22%，原本要几周的调试工作，压缩到了几个小时。客户的硬件老大甚至震惊地问：“你们以前是做芯片设计的吗？” 你看，在AI写代码越来越快的今天，懂技术已经不稀奇了，能迅速听懂客户到底要什么，反而成了最稀缺的能力。 第二关：拒绝“面子工程”，死磕真实效果 在普通的软件开发里，搞个Demo，跑通了，能演示了，基本就算交差了。但在FDE团队，这连及格线都够不上。 比如，一家大型电信公司想搞语音AI客服。语音客服可比文字聊天难多了，你要懂用户的口音、情绪，还得反应快。刚开始，AI模型在关键测试里只能拿60分，根本没法用。 如果是为了对付差事，工程师大可以搞个“阉割版”交差。但FDE的做法是：不行，咱们得从根儿上解决。他们把客户的需求拆解开，跑回去找OpenAI的研发团队，要求他们给模型“升级大脑”，改进指令遵循和函数调用的能力。 磨了半年，硬是把分数从60分拉到了90分以上，达到了真正能上线的标准。这说明什么？FDE不仅是AI的使用者，他们更是逼着AI进化的“监工”。 第三关，眼睁睁看着自己的心血被AI干掉 前面那个半导体项目，团队花了好几个月，给不同的场景写了大量定制化的代码和工具。 结果过了一段时间，OpenAI自家的写代码模型Codex升级了！更聪明了！这时候，一位FDE工程师做了一个疯狂的决定：他用升级后的Codex重新搭了框架，把原来那些复杂的定制应用，全变成了通用的插件。 结局是：每个项目里的定制代码，被删掉了大约90%！ 心疼吗？可能有一点。但换来的是什么？以前部署一套方案要两个月，现在推广给下一个团队，只要一天。 这就是在OpenAI当工程师最核心的价值观：你的价值，绝对不是你写了多少行代码，而是你解决了什么问题，以及你能否让下一个人，不用再从头受一遍你受过的苦。 这也体现在他们和税务公司合作的AI项目里。一开始处理复杂的出租物业税表极其痛苦，团队花了6周时间才把准确率拉到90%。但一旦这个方法沉淀下来，以后再处理类似的复杂表单，AI就能轻车熟路了。 说到这，大家可能会有个疑问：如果AI进化得这么快，把工程师过去几个月干的活儿，一秒钟就干完了，那这些顶级工程师岂不是要失业了？ 在Codex发布后，FDE团队里确实有人这么问过负责人Colin Jarvis。 Colin的回答非常霸气，他说：“那就去找一个更难的问题。” 以下是博客全文翻译： FDE在 OpenAI 意味着什么 我们做什么、如何工作，以及如何解决企业最棘手的问题、交付真实的影响。 Codex 发布时，团队里有人问我：“如果 Codex一次就能搞定我们过去几个月辛苦搭起来的那些用例，那我们该去做什么？” 这个问题恰好触及 FDE 在 OpenAI 的核心含义。我们和客户并肩工作，弄清他们最难的问题，搭出他们可以依赖的方案。我们从中获得的认识，既影响产品的走向，也为研究团队提供一个个具体可以去攻的问题。 这就是进步。如果我们每隔几个月就让自己变得多余，说明 FDE 团队把活干对了。 我在 2025 年初组建这支团队，为的是弥合我们所说的“部署鸿沟”——模型看起来能做到的事，与人们能可靠拿来完成工作的事，两者之间的距离。 图 1 ｜“部署鸿沟”：模型能力所能创造的价值，与当前业务价值轨迹之间的落差 模型能力的演进速度，快过把它真正用起来所需要的系统和流程。有时候缺的是一个产品；有时候模型在基准测试上表现很好，放到真实变量和约束下却干不了这活。 我们盯住客户最难的问题。模型今天就能胜任的部分，我们和产品团队、客户一起把方案做成可复用的；模型还力所不及的部分，我们和客户、研究团队一起界定差距、推动改进。我们希望每一次项目都能让下一个客户站在更好的起点上——如果地板被抬到这样的高度：下次再遇到这一类问题，客户已经不需要 FDE 出面，那我们的活就算干好了。 拥有两百年历史的农业企业约翰迪尔（John Deere），面对的挑战是如何把面向农户的个性化建议规模化。 其中一个例子是精准除草技术 See & Spray：用摄像头和机器学习识别杂草、只对杂草施药，而不是整片农田撒药，可把化学品用量降低最多 70%。 但要拿到这些好处，前提是农户知道怎么配置设备、怎么安排整个种植季、在条件变化时怎么调整做法。 约翰迪尔调用 OpenAI 的 API，让这类支持既个性化又能规模化。 AI 可以用自然语言回答农户的提问，给出针对性的设置指引和建议，判断设备是否没有发挥出全部性能，也帮农户看清自己从这项技术里到底得到了什么。 机会不止于单次交互：把有用的指导贯穿客户旅程的每一步，让农户把设备用得更充分，同时提升效率与可持续性。 这正是 OpenAI 的 FDE 要去解决的问题：帮组织从“拥有 AI 能力”，走到“拥有能在复杂真实环境里产生实际价值的系统”。 但这类问题往往没有边界，可能没有现成的标准答案，也没有操作手册。人人都想造出从未有过的东西，愿意为此付出代价的人就少得多。 既要找到有天赋的 FDE，又要不断抬高“够用”的标准，这意味着持续试错，也持续投入。 从结果出发 每次 FDE 团队开会，我都会先放一页幻灯片，上面只有一条核心价值观：“从结果出发，为成功不惜代价，然后再谈规模化。” 图 2 ｜作者在团队会议上展示的核心价值观：从结果出发、为成功不惜代价、然后规模化 在有人问出“它在真实世界里能用吗”之前，一个惊艳的演示能顶很久。 我们的职责，是把客户的问题解决到这样的标准：敢在生产环境里为它背书。 2025 年年中，我们派出约 15 名 FDE，和一家大型半导体客户一起做十多个用例。目标是把他们的验证（verification）流程做成 AI 原生的，范围包括： l 定向测试生成 l 根因分析与调试 l 一个架构助手 在这个行业，验证环节可能占到一个项目七成的工作量。空间巨大，可以下手的地方也很多。 有些 FDE 几天前才入职 OpenAI，从没做过半导体。他们直接扎进客户的验证团队，业余时间补芯片设计，和客户工程师一起搭评测（evals），检验 AI 能否生成有用的测试、能否正确诊断芯片失效。 边学边做，我们为各个用例搭了定制的harness（执行框架）。头 3 到 6 个月里，这些用例全部进入生产环境，并被早期用户用起来。回报落在数字上： l 基于 AI 的定向测试生成，节省约 48% 的时间 l 内核优化带来中位数 22% 的性能提升 l 原本数周的调试，压缩到数小时 复盘时，客户的首席硬件官问：“你们来这儿之前是做芯片设计的吗？” 我们的 FDE 不需要第一天就懂这个行业，但把它学会，是他们自己的责任。 当编码助手让软件开发越来越快，理解客户的业务反而更重要了。我们的团队是通才与领域专家的混合编队。 知识要够，才能做出靠谱的判断；好奇心也要够，才会去质疑关于现状的那些默认假设。 以生命科学为例，我们 FDE 的科研背景，让他们能赢得研究人员的信任——这些人做的是靶点验证与优先级排序、基因表达分析、化学合成路线重构这类临床前药物发现工作。这份专业积累，让他们能就“这些流程该怎么改”给出有依据的判断。 让成功可复制 我们已经证明这些流程能产生价值，但每一个都还需要太多定制集成，才能复制到另一个团队。下一个挑战是：在保住这些成果的同时，让软件更容易部署、更容易维护。 图 3 ｜FDE 把一个硬问题转化为可复制的能力：硬问题 → 从零到一的方案 → 可复用的封装 那时 Codex 的能力已经长起来了。一位 FDE 试着围绕它重建自己的应用，然后和团队一起把这些用例迁到以 Codex 为核心的统一 harness 上。 定制应用变成了基于 Codex 通用原语构建的插件和技能。Codex 同时成了统一入口，我们为各个用例单独写的终端界面和 CLI 就此退役。 每个项目里大约 90% 的定制代码被去掉了，我们构建、维护和推广这些流程的方式也随之改变： l Codex 的集中式改进能直接受益，每个用例需要的胶水代码随之减少。 l 关键功能被打包成技能和插件，团队之间更容易共享，也便于 AI CoE（AI