技术作家 Gergely Orosz 再次走进 OpenAI 总部时，距离上一次探访只有一年，内部的工作方式却已经换了底座。Codex 从一个“有也不错”的编程工具，变成了工程、研究、财务、招聘、法律和市场团队共同使用的工作入口；面向通用工作的 ChatGPT Work，也建立在 Codex harness 这套执行框架之上。员工不一定以代码作为最终产物，但智能体会在幕后编写代码、调用工具、生成文档和表格，把目标变成可交付的结果。

这份观察来自七位受访者：应用基础设施工程副总裁 Venkat Venkataramani、ChatGPT 工程负责人 Sulman Choudhry、桌面端负责人 Andrew Ambrosino、核心智能体团队负责人 Joe Gershenson、生产力团队工程负责人 Akshay Nathan、Codex 工程师 Ahmed Ibrahim，以及 Responses API 工程师 Steve Coffey。不同岗位的证词拼出了一条完整链路：智能体先改变个人如何工作，随后放大代码产量，最后迫使测试、审查、发布和线上运维一起重构。

这里也存在一个必须说清的材料边界。原报告元数据标记全文为 7,686 个英文词且属于付费内容；当前公开页面只提供引言、第 1～3 节全文和第 4 节的开头一段，实际约 3,536 词，相当于全文约 46%。后续关于内部工具和调试、十亿用户基础设施、API 可靠性与性能，以及工程岗位变化的正文并未公开。下面只解读能够逐项核对的公开内容，不根据目录预告补写后半篇的论据。

从编程工具到全公司的工作入口

转折发生得很快。Codex 桌面应用在 2 月推出 Mac 版，3 月推出 Windows 版，随后在 7 月推出由 Codex harness 驱动的 ChatGPT Work。几个月内，财务、招聘、法律等非工程团队从几乎不用 Codex，转向大多数人每周都会使用。这个扩散并非来自管理层强制推行。

图：各部门平均用户的月度输出 Token 中，Codex 所占的份额。来源：OpenAI / The Pragmatic Engineer。

更值得注意的是，产品当时并不好用。2 月至 4 月的 Codex 应用仍会把代码直接显示在屏幕上，对非技术用户相当不友好，但非工程团队的采用率依然接近 40%。原因很现实：即使界面像开发工具，它已经能完成调研、制作演示文稿、生成文档、处理电子表格等复杂工作，产出的价值足以抵消使用门槛。

随后，长周期任务能力把使用率从大约 60% 推到 90%。用户可以通过 /goal 交代一个目标，让智能体持续工作，线程甚至延续数天。Andrew Ambrosino 观察到一个反直觉变化：智能体工作得越久，人反而越少同时管理多个任务，因为一个长线程会自行派生其他智能体并行处理子问题。人负责的对象从许多零散对话，收束为少数几个目标及其验收。

另一个动力是 Akshay Nathan 所说的“认知差距”（awareness gap）。模型能力早已存在，但许多人不知道能力可以落到哪些工作上。有人先用 Codex 完成一个任务，后来从同事那里发现它还可以监控 Slack、更新 Airtable、制作入职材料。用途通过口口相传扩散，各团队再把成熟流程封装成角色或团队插件。通用智能体由此不再只是一个空白输入框，而是带着业务上下文和惯用工具进入具体岗位。

这种适配也暴露了工程团队的知识边界。开发者知道怎样构建 harness，却未必知道一份优秀的演示文稿、电子表格或商业报告应达到什么标准。因此，OpenAI 将领域专家嵌入 ChatGPT Work 的工程团队，让专业人员直接定义“好结果”的品味和要求。这里的关键并不是模型在所有领域都胜过专家，而是开发者无法凭自己的经验替每个专业领域设定质量标准。

OpenAI 内部的 Codex 还比公开产品接入了更多公司系统，这一点限制了外部类比。它已经深到足以形成运营依赖：即使只是一次轻微故障，同事发给 Codex 和 Work 团队的消息，也可能与自动监控告警同时甚至更早抵达。外部团队不能只安装同名产品，就假定会自然获得相同效果。

OpenAI 后来公布的数据能补充这次访谈，但必须保留统计口径：

• 对平均一名 OpenAI 员工而言，Codex 已占其 AI 工具输出 Token 的 85% 以上；全公司每周生成的输出 Token 中，Codex 占 99.8%。这是 Token 份额，不是使用人数或工作时间占比。
• 在 OpenAI 日活用户中，位于第 99 百分位的重度用户每天经由多个并行智能体产生超过 60 小时的 agent-turn 运行时间。并行运行时间可以超过一天的 24 小时，不能等同于人类一天工作了 60 小时。
• 在 2026 年 5 月的抽样个人用户中，80.6% 至少提交过一次模型估算相当于人类工作超过 30 分钟的请求，70.2% 至少有一次超过 1 小时，25.6% 至少有一次超过 8 小时。这些数字是模型对“等效人类任务耗时”的方向性估算，不是请求实际运行的挂钟时间，更不是独立测得的生产率。

这些数据能证明工作正在从短问答迁移到长期委托，却不能单独证明代码质量更好、人员需求下降，或任何公司照做都能获得相同生产率。

IDE 没有消失，工作的基本单位先变了

Codex 桌面应用差点没有发布。2025 年 12 月，团队已经有 Codex CLI，市场上也有功能完整的 IDE，于是一个介于终端和 IDE 之间的工具是否有独立价值，并不明显。Andrew Ambrosino 把这种担忧比作 iPad：用户可能宁可选择更便携的手机，或者功能更强的笔记本电脑，中间设备反而无处安放。

与此同时，Antigravity 在 11 月以 VS Code 分支的形态出现，更加诱使团队沿用成熟编辑器。但 OpenAI 最终没有 fork VS Code。他们押注的是：随着智能体能力提高，开发者会减少直接操作 IDE，把工作重心移到目标定义、任务委托和结果判断。内部 IDE 使用量从 1 月起下降，说明这一变化正在发生；不过 Codex 应用也在 6 月加入了文件编辑功能。这组事实更适合解释为“IDE 不再垄断开发入口”，而不是宣布 IDE 已经死亡。

真正改变的是工作的基本单位。过去，开发者在编辑器里完成一组行级修改；现在，人可以交代一个结果，让智能体查找上下文、修改多个文件、运行验证并处理后续反馈。当产出单位从“改一段代码”扩大为“完成一个目标”，代码生成速度就会远超原有研发基础设施的设计容量。

Venkat Venkataramani 看到，每名工程师产生的 PR 数量呈“曲棍球棒”式上升，部分构建、测试和部署系统在大约六个月内承受了近十倍负载。其他公司可能用两三年才经历同等增长，OpenAI 却几乎每个月都会遇到一组新的扩容问题：版本控制要接住更多代码，CI/CD 要执行更多任务，发布系统还要吸收更高频的变更。模型能力每前进一步，瓶颈就向下游移动一次。

这也是传统 PR 和代码审查开始显得不合时宜的原因。如果每次变更仍完全依赖人工逐行检查，人的接受速度会成为固定上限。但取消审查并不能解决问题，只会把风险直接推到生产环境。OpenAI 的做法是把审查拆成专业化智能体、风险分流和明确的人工关卡，让审查能力随变更量一起扩展。

原生移动端则展示了另一类无法靠内部自动化直接消除的瓶颈。iOS 和 Android 更新仍须经过 Apple 与 Google 的应用商店审核，往往需要数小时或数天。Sulman Choudhry 回忆，Facebook 在 2010 年代把移动发布从每月一次逐步提升到双周一次、每周一次，同时依靠实验系统和 Feature Flag 让代码先随版本进入客户端，再远程决定何时开放功能。这曾显著提高移动团队的速度，但面对今天几分钟即可生成的软件变更仍显得迟缓。OpenAI 的 Codex 使用高度偏向移动端，而原生应用发布距离网页部署的速度还很远。

这个案例揭示了软件工厂的真实约束：智能体可以压缩内部生产时间，却不能凭空消除商店审核、合规要求和生产风险。生成变快以后，原先不显眼的外部等待会成为主导交付周期的新瓶颈。

九步闭环：代码生成只是中间一环

“软件工厂”借用了制造业的比喻：人和机器人共同生产汽车，在软件里则是人和智能体共同生产、发布并维护系统。制造业甚至存在不需要照明的“黑灯工厂”，但 OpenAI 当前的流程还不是无人系统。人类定义目标、批准生产发布；故障智能体目前也只能建议缓解措施，除非工程师明确授权，否则不会执行。

图：人类定义目标后，Codex 与上下文、CI、审查、发布、生产观测、Perf Factory 和 Sevbot 构成反馈回路。来源：The Pragmatic Engineer。

完整流程由九个相互反馈的环节组成：

1. 人类定义结果。 软件工程师或产品经理先说明问题和期望结果。Venkat 观察到，工程师正在变得更像产品经理：编码被大量委托之后，判断、优先级和品味变得更重要。智能体可以扩大执行力，却不能替组织决定什么值得做、什么结果可以接受。
2. Codex 汇集上下文。 OpenAI 把文档移进源代码仓库，让代码和说明更容易同步演进。Codex 还可以访问 Git 仓库与 GitHub、Slack 与 Notion、Databricks、Datadog、内部日志以及团队技能；有些内部技能甚至由 Codex 自己维护。由于接入足够深，新工程师入职时会被建议直接向 Codex 询问系统问题。
3. 智能体实现并验证变更。 Codex 根据目标持续修改代码，直到达到要求，并验证软件行为。公开材料没有说明这里必然使用某种特定沙箱，也没有限定验证只能在本地完成，因此不能把未披露的执行环境当成既定事实。
4. 构建、测试并等待 CI 通过。 智能体构建代码、运行测试、根据失败结果修正实现，然后创建 PR，触发更完整的 linter 和测试套件。它会持续看护 PR，处理 CI 失败并更新变更。额外的性能 harness 只把被判定为可能有问题的 PR 送入 Synthetics A/B 框架，评估性能影响；并非所有 PR 都接受同一套昂贵性能测试。
5. 专业审查、风险分流与合规路由。 系统不是只调用一个通用代码审查器，而是派生多个拥有领域配置的审查智能体。Gergely 最初对此持怀疑态度：仅在提示词里要求模型“扮演云基础设施专家”，并不会自动带来专业判断。这套方式可能有效，依赖的是智能体能访问相关代码和文档，并把有限上下文集中到一个狭窄领域。低风险 PR 只有在相应代码区域主动 opt-in 后，才可能由智能体自动批准；高风险变更可以增加更多 AI 审查，或强制加入人工审查。系统还可根据风险自动决定何时需要额外的自动合规检查或人工合规意见。编码智能体会继续跟踪审查评论并修复问题。
6. 智能体护送发布。 人类批准某项变更进入生产后，系统才为它分配发布智能体。智能体会找到 Feature Flag，理解变更，判断哪些信号代表成功或失败，并为这次变更生成自己的监控看板，再持续观察发布状态。OpenAI 的长期目标，是形成接近“每次变更一个自主 SRE”的能力；这是方向，不是当前已经完全自主发布的事实。
7. 按变更粒度观察生产。 观测来源包括前一步生成的看板，以及 OpenAI 内部产生日志、指标、追踪和 wide events 的可观测系统。过去由工程师为服务搭建看板，现在智能体能够针对单次变更生成观测视图，使“这次改动是否健康”成为可以独立追踪的问题。
8. 生产信号回流开发。 Perf Factory 从告警和看板中筛选信号、去重、识别真正的延迟回退、定位根因并提出修复方案。报告导言还概括说，它可以启动 Codex 智能体处理性能问题；但公开的流程描述只证明它会提出修复，不能据此推断补丁会绕过审查自动合入或上线。
9. Sevbot 协助事故响应。 事故发生时，Sevbot 收集上下文、判断可能的缓解措施，并在 Slack 频道回答开发者的问题。它当前不会自行执行缓解操作；工程师可以指定某项措施，再让它实施。OpenAI 希望未来让 Sevbot 自主处理一部分常规事故，使人不必在非工作时间被叫醒，事后再审查它的行动，但现阶段 on-call 仍然存在。

把九步连起来看，工厂的核心并不是“一个模型写完所有代码”，而是三种能力彼此制约：机器负责高频执行和持续观察，自动化系统提供可验证反馈，人类在目标、风险与生产动作上承担责任。任何一层缺失，代码吞吐提高都可能只是更快地制造等待、噪声或事故。

现在的人工关卡，与未来的自动化方向

从当前事实看，人类仍把守三个关键节点：开头决定问题与期望结果；代码进入生产前给予批准；Sevbot 要执行具体缓解措施时提供明确指令。风险较高的代码还可能被强制送交人工审查。把 OpenAI 现状描述成完全无人参与的“黑灯软件工厂”并不准确。

但这不意味着边界会永久停在这里。OpenAI 正在探索让发布智能体承担更完整的变更级 SRE 职责，也希望 Sevbot 最终可以自主处置部分常规事故。真正的演进路线是：先建立足够可靠的上下文、风险分类、测试和生产信号，再逐步扩大可自主执行的范围。当前状态与长期目标必须同时保留，既不能把愿景当成已实现能力，也不能把今天的人工关卡说成永远不会移动。

其他团队真正可以借鉴什么

OpenAI 的实践建立在少见的条件上：文档与代码同仓；智能体能读取 GitHub、Slack、Notion、Databricks、Datadog、日志和内部技能；构建、测试、CI 与生产观测能快速反馈；代码变更有风险分级和合规路由；公司还能提供高额 Token 与计算预算。公开材料展示的是 OpenAI 内部的访谈观察和官方统计，并不能证明这套方式已经被普遍验证为安全，也不能证明它适合所有公司原样照搬。

更可迁移的顺序，是先让系统变得可被机器理解、可被测试验证、可被生产信号约束，再提高代码生成量：

• 把真正影响实现的文档放到代码附近，并建立随代码更新的责任机制；
• 让智能体获得完成任务所需的上下文，同时把读写权限、审计和生产动作的边界说清；
• 用测试、CI、性能评估和生产观测建立短反馈回路，让错误尽早暴露；
• 按变更风险决定需要多少智能体审查、合规输入和人工批准，而不是对所有代码采用同一种流程；
• 先测量下游构建、审查、发布和运维能承受多少吞吐，再决定是否进一步放大生成速度。

这套软件工厂最重要的启示，是代码不再是唯一稀缺资源。当智能体显著降低实现成本，稀缺性会转移到高质量上下文、可执行的判断、验证能力和风险承担上。工程组织要改造的不是一个编辑器入口，而是从目标到生产反馈的整条链路。