OpenAI 的软件工厂不是未来,是一面镜子:你看到的取决于你站的位置

◆ 导语

9 月 15 日，Pragmatic Engineer 的 Gergely Orosz 发了一篇他在 OpenAI 旧金山总部的深度探访。标题叫「Inside OpenAI's agentic software factory」，副标题更直接——Codex has "taken over" OpenAI。

4 个月，非工程师部门使用率从接近零飙到 90%。Codex 占了公司每周产出 token 的 99.8%。法务 88%、招聘 89%、财务 91% 的产出都走 Codex。工程副总裁 Venkat Venkataramani 说，OpenAI 现在的工程师「越来越像产品经理而非传统系统工程师」。

同一周，OpenAI 工程博客发了另一篇文章——Ryan Lopopolo 的团队用 0 行手工代码构建了一个内部产品，3 名工程师 5 个月推了大约 1500 个 PR，人均每天 3.5 个。他们管这叫「harness engineering」。

两篇文章拼在一起，描述了一家正在用 AI agent 重写软件开发全流程的公司。但仔细看这些数字和案例，它们到底说明了什么？是所有公司的未来，还是 OpenAI 这家特殊公司的特例？

我的判断：OpenAI 的软件工厂是真的，但能被复制的部分比大多数人以为的少得多。真正的信号不是「AI 取代工程师」，而是「验证（而非生成）正在成为瓶颈」。

◆ 发生了什么

从聊天工具到公司基础设施

时间线很清楚。2025 年秋，OpenAI 把构建自主软件工程师（aSWE）定为公司级目标。2026 年 1 月，内部 Codex 使用率开始飙升——不是因为强制命令，而是因为 Mac 桌面应用在 2 月上线、Windows 版在 3 月、ChatGPT Work 在 7 月，工具到位了人就自然迁移。

最惊人的数字来自非工程部门。Gergely 引用桌面端负责人 Andrew Ambrosino 的话：「四个月内，财务、招聘、法务从大约 0% 的 Codex 使用率涨到了 90%。」现在几乎所有 OpenAI 员工每周都用 Codex 和 ChatGPT Work。

OpenAI 的内部 Codex 版本远比外部强。它接入了 Slack、GitHub、Notion、Databricks、Datadog、内部日志，以及由 Codex 自己维护的内部 Skills。新员工入职被告知：「直接问 Codex。」Gergely 说这个做法让人惊讶——你可以问它谁在做什么、为什么做了某个决定，它居然都能回答。

9 步软件工厂流水线

Venkat 描述的流程是这样的：

1. 人类定义目标。 工程师或产品经理说明问题和期望结果。判断力、优先级、品味在这一步起作用。

2. Codex 收集上下文。 OpenAI 把所有文档搬进了源码仓库里——让 agent 更容易理解。Codex 还能访问 Git、Slack、Notion、内部日志、自定义 Skills。

3. Codex 写代码。 迭代修改直到达成目标并自行验证。

4. 构建测试 + CI。 Agent 构建代码、跑测试、修失败、开 PR，然后盯着 PR 直到绿灯。新增了「perf harness」——把可疑 PR 送去 A/B 框架评估性能影响。

5. Agentic 代码审查。 不用一个通用 AI 审查，而是启动多个「领域专家」agent——一个查云基础设施，一个查安全，一个查性能。每个 agent 有全量代码和文档上下文。按风险分级：高风险走更严流程（更多 AI 评审或强制人工复审），低风险可由 agent 自动批准。

Gergely 自己对这一步持保留意见。他说他本来不信「让 agent 装成云基础设施专家就能给出不同审查」，但后来理解了——这些 agent 确实有 OpenAI 全部代码和文档的上下文，所以它们能提供针对性的反馈。关键在于怎么给它们设上下文和边界。

6. Agentic 部署。 人工批准后，分配一个专属 agent「护送变更上线」。Agent 会：读代码找 feature flag 位置→理解变更→决定成功/失败信号→自建监控 dashboard→盯生产信号。OpenAI 的长期目标：每次变更一个自主 SRE。

7. 观察生产。 上一环节 agent 自建的 dashboard + 内部可观测性栈。

8. Perf Factory 反馈回开发。 Agent 筛选告警、去重信号、识别延迟回归、定位根因、提出修复。把性能问题自动反馈进开发循环。

9. Sevbot 事故响应。 基于 Codex 的事件响应 agent。收集上下文、提出缓解方案（但从不当自己执行）、在 Slack 回答开发者问题。OpenAI 的目标是让它自主处理「常规」故障，实现非工作时段无人被叫醒。但 Gergely 写道，on-call 在 OpenAI 仍然是现实。

Ryan Lopopolo 的「零手写代码」实验

同期发布的 OpenAI 官方博文更极端。Ryan Lopopolo 的团队在 2025 年 8 月底从一个空仓库开始，5 个月后推了大约 100 万行代码，1500 个 PR——全部由 3 名工程师驱动 Codex 完成，没有一行是人类手写的。

他们的哲学是「人类掌舵，agent 执行」。工程师的工作不是写代码，而是设计环境、指定意图、构建反馈循环。当 agent 失败时，问题几乎从不是「agent 不够努力」，而是「环境欠规格」——缺了什么工具、什么抽象、什么文档让 agent 能做有用的事。

他们发明了一套做法：AGENTS.md 只做目录（约 100 行），深层知识放结构化 docs/ 目录。自定义 linter 机械强制架构约束（linter 当然也是 Codex 写的）。代码审查从「守门人」变成「观测站」——PR 短命、squash merge、flaky 测试用补跑而非无限阻塞。

◆ 背景分析：为什么是 OpenAI

这里需要说清楚一件事：OpenAI 不是一家普通公司。

首先是模型权限。OpenAI 的内部 Codex 版本比外部版强得多——它几乎接入了所有内部系统。外部开发者用 Codex，不可能得到同样的上下文密度。Gergely 明确写了：「OpenAI 的内部 Codex 版本比外部对手先进得多，因为它接入了几乎所有 OpenAI 系统。」

然后是 token 预算。OpenAI 员工有无限的 token 预算。Simon Willison 算过一笔账：StrongDM（另一家声称零人工代码的公司）每个工程师每天烧至少 1000 美元的 token，大约 2 万美元/人/月。光成本这一条就排除了绝大多数公司的可能性。

第三是修改模型的权力。Ryan Lopopolo 的团队不只是用模型，他们能直接影响 Codex 模型的训练方向。当 agent 在某个场景失败，他们可以直接反馈给模型团队，下一版模型可能就修了。这种反馈循环没有任何外部公司拥有。

第四是绿地项目。那个 100 万行零手写代码的实验，是一个从第一天起就为 agent 可读性设计的新代码库。现有系统、历史债务、组织政治——这些全都不存在。SourceFeed 的分析文章说得直接：「这不是反驳，而是边界条件。」就像 FANUC 从 2001 年起就用机器人造机器人，但前提是产线末端有能测量真正重要东西的质量门。

◆ 各方怎么看

质疑方：数据可信度与可复制性

TNW 的报道提出了最直接的问题：98% 员工使用 Codex 的数据，「每一个数字都来自 OpenAI 自己」。卖 Codex 的公司在测量自身成功——这不算独立验证。

Gary Marcus 说得更尖刻：「能编译并通过给定测试的模型，不等于能产出正确、安全、可维护、架构良好的软件。」他援引 Gergely 的观察——越是接近写代码的人，越不信软件工程会被 AI 完全解决。

最有力的一手反例来自 Dex Horthy（HumanLayer CEO）。他的公司 2025 年 7 月起真正运行了「熄灯工厂」——无人读代码。4 个月后系统崩溃，联创花两周手工重写。他的诊断精准：问题不在 harness，在模型。RL 训练只奖励「测试通过」，没有对「侵蚀可维护性」的惩罚。架构债以周/月为单位爆发时，奖励信号早已消失。他把这叫「Goodhart 定律以 token 速度运行」。

Dex Horthy 有一句话值得刻在墙上：「如果模型能可靠区分好代码与坏代码，它一开始就该写出好代码。」

VentureBeat 的分析用了一个更讽刺的标题：大多数公司以为自己在建软件工厂，其实只是「更快地生产缺陷」。Faros AI 的数据：单人吞吐 +33.7%、PR 合并 +16.2%，但每 PR 事故 +242.7%、人均 bug +54%。

支持方：角色迁移而非岗位消失

OpenAI 自己的说法由 Venkat 代表：「轻松有 1000 倍工程师，且可能不是上限。」工程师角色从手写代码转向对产出质量有良好判断。

WIRED 报道了一个有趣的对齐：Notion 联创 Simon Last 从可靠性角度倒向 Codex（「Claude Code 对我撒谎」）。开发者 George Pickett 的态度是承认岗位颠覆但视为必然：「社会层面鬼知道这意味着什么——会很颠覆，但我对正在发生的事相当乐观。」

Ars Technica 2025 年底的早期报道有一个细节：Sora 的 Android 应用由 4 名工程师用 Codex 18 天从零构建。设计师现在可以直接用 Codex 实现代码而非向工程师提交 spec——这个变化是真实的。

中间派：工厂架构是真的，乘数不是

Addy Osmani（Google Chrome 工程负责人）提出了「理解债」概念：黑暗工厂不会偿还理解债，只会以测试全绿的速度加速欠债。他给自动化设的限是「back pressure」——自主权只能授予到你能廉价可靠验证的程度。验证，而非生成，才是工厂的真正瓶颈。

Peter Roelants 的证据审查报告结论严谨：「严格版本（完全熄灯）未被证实。最强的公开证据比其名号窄得多。」没有任何公开账目把结构质量、逃逸缺陷、维护成本与客户结果挂钩。

Gergely 本人参观完后在 LinkedIn 上写了一段很诚实的话：越是贴近生产代码的人，越不信软件工程会被 AI 解决；越是远离一线的人，越觉得已基本解决。他说这可能是偏见——但也可能不是。

◆ 这意味着什么

我想把讨论拉回一个更实际的问题：对中文开发者来说，OpenAI 的软件工厂到底意味着什么？

可复制的部分

1. AGENTS.md + 结构化 docs/ 目录。 这是 Ryan Lopopolo 团队的核心发明——给 agent 一张地图而非千页说明书。这个做法成本为零、立即可用，任何用 AI 编程工具的团队都能今天开始做。

2. 自定义 linter 机械强制架构约束。 让 linter 的错误信息直接包含修复指引，注入 agent 上下文。这不是什么高深技术，但它改变了 agent 收到错误反馈时的行为。

3. 风险分级代码审查。 低风险变更让 agent 自动批准，高风险走更严流程。这比「AI 审查一切」或「人类审查一切」都更合理。

4. 理解债概念。 Addy Osmani 的框架比「AI 能不能取代工程师」有用得多。问题是：你的验证能力能否跟上你的生成速度？

不可复制的部分

1. 无限 token 预算。 每天 1000 美元/人的 token 成本，大多数公司承担不起。

2. 直接修改模型的反馈循环。 外部用户能做的最多是提 feature request，OpenAI 内部能直接改训练。

3. 绿地代码库。 从第一天为 agent 可读性设计的代码库，跟历史债务缠身的现有系统是两回事。

4. 全系统接入。 内部 Codex 接 Slack/Notion/Git/Datadog/自定义 Skills——外部 Codex 做不到。

我的判断

OpenAI 的软件工厂揭示了一个方向，但没有证明一个乘数。

方向是真实的：agent 确实在接管编码、测试、审查、部署的机械部分，人类的杠杆正在从「写代码」转向「定义意图和验证结果」。Ryan Lopopolo 的 AGENTS.md 做法是所有人今天就能抄的作业。

但乘数被污染了。3-5 倍、1000 倍——这些数字全部来自卖工具的公司的自报。METR 的随机对照试验测出来是「AI 让资深开发者平均慢 19%，但他们自己觉得快了 20%」——43 个百分点的校准误差。DORA 2025 报告的结论是「AI 不修复团队，只放大现状」。

对中文开发者来说，最该关注的不是「OpenAI 的工程师还在不在写代码」，而是两件事：

第一，你所在团队的验证能力跟得上生成速度吗？ 如果 agent 的代码产出翻倍了，你的 code review、测试覆盖、上线灰度能力翻倍了吗？没有的话，你只是在更快地产出缺陷。

第二，你把什么知识放在了 agent 能读到的地方？ OpenAI 把所有文档搬进源码仓库，不是因为他们喜欢这样组织——是因为 agent 读不到 Google Docs 和人脑里的东西。这个约束对所有用 AI 编程工具的人都成立。

OpenAI 的软件工厂是一面镜子。你看到的取决于你站的位置。离代码近的人看到的是约束和边界，离代码远的人看到的是无限可能。两边的观察可能都对——但只有一边在操作系统。

◆ 总结

OpenAI 用 Codex 重写了软件开发全流程，从目标定义到事故响应，agent 覆盖了 9 个环节。这些实践中的 AGENTS.md、linter 注入、风险分级审查是所有人能今天就用的。但「熄灯工厂」已被 HumanLayer 四个月崩溃、LaunchDarkly 自主重写搁浅证伪。验证才是瓶颈，不是生成。你该做的不是追 1000 倍乘数，而是确保你的验证能力不被生成速度甩开。