摘要：本文详细复盘OpenAI的五个月极限实验——从一个空的Git仓库开始，3人团队如何在“零手工代码”的约束下，构建出百万行代码的Beta产品。文章呈现了实验的核心数据（1500个PR、人均日3.5个PR、10倍效率提升），剖析了从“Ralph Wiggum Loop”到完全自主的进化路径，并揭示了代码吞吐量激增后合并哲学的深刻变革：当修正成本远低于等待成本时，传统的阻塞式门禁必须让位于新的权衡。这是一场对“软件工程”定义的彻底颠覆。

---

一场“自虐式”的极端实验

2025年8月下旬，OpenAI的一个小型工程师团队开启了一项看似疯狂的计划：从一个完全空的Git仓库开始，在“人类不许手写任何代码”的铁律约束下，构建一个真实的软件产品。

这不是演示项目，不是玩具原型。五个月后，这个仓库包含了超过100万行代码，覆盖应用逻辑、基础设施、工具链、文档和内部开发者工具。产品被数百名内部用户使用，出现了稳定的日活用户，会发布、会出故障、会被修复。

唯一的区别是：代码库中的每一行——包括AGENTS.md这个指导AI如何工作的说明书——都是由Codex AI生成的。

OpenAI将这套方法论命名为**“驾驭工程”（Harness Engineering），并估计其交付速度大约是传统手写模式的10倍**。

本文将以时间线和数据为线索，全景式还原这场“零手工代码”实验的全过程，并深入探讨实验揭示的核心启示：当AI吞吐量远超人类注意力时，软件工程的底层逻辑正在被重写。

一、起点：一个由AI书写的空白画布

1.1 第一行代码，来自AI

2025年8月下旬，当第一个commit落入空的Git仓库时，它就不是人类写的。

最初的脚手架——仓库结构、CI配置、格式化规则、包管理器设置、应用框架——由Codex CLI配合GPT-5，在少量模板的引导下自动生成。当时没有任何既有人类代码可以充当“锚点”，整个系统从第一天起就是由智能体塑造的。

更魔幻的是：连那份用来指导AI如何工作的说明书——AGENTS.md，第一版也是Codex自己写的。

从第一天起，“人类不许写代码”就成了这个项目的一条不可逾越的铁律。这不是为了偷懒，而是一种近乎自虐的“刻意练习”。只有切断了人类“亲自上手”的退路，才能倒逼团队去破解那个终极难题：在完全由智能体主导的世界里，如何构建可靠的软件？

1.2 团队构成：从3人到7人

实验初期，团队仅有3名工程师。随着项目推进，团队逐渐扩展到7人。

这个规模在传统软件公司中，通常只够维持一个小型模块的开发。但在Harness Engineering模式下，7个人驱动着一群不知疲倦的Codex智能体，在代码草原上狂奔。

二、数据：惊人的产出效率

五个月后，这份“零手工代码”的成绩单令人震撼：

指标	数据	说明
代码规模	超过100万行	涵盖应用逻辑、基础设施、工具、文档、内部开发者工具
Pull Request数量	约1500个	从打开到合并，全程由智能体主导
团队规模	3人 → 7人	初期3人，后期扩展到7人
人均PR/天	约3.5个	随着流程成熟，效率持续提升
效率提升	约10倍	OpenAI估计，比传统手写代码节省约10倍时间

这些PR的执行环节——实现、测试、文档、CI配置——全程由智能体代劳。人类工程师的角色已经彻底改变：他们不再是代码的生产者，而是系统的设计者、环境的构建者、意图的定义者。

更重要的是，这些产出不是“刷产量”。产品已被数百位内部用户使用，并出现了稳定高频用户。这意味着，由AI生成的代码不仅规模惊人，而且质量足以支撑真实业务。

三、进化：从“Ralph Wiggum Loop”到完全自主

实验过程并非一蹴而就。OpenAI团队描述了智能体自主性的进化路径，可以分为几个关键阶段：

3.1 早期阶段：Ralph Wiggum Loop

在实验初期，智能体的工作模式被称为**“Ralph Wiggum Loop”**（源自《辛普森一家》中一个头脑简单的角色）。这个阶段的特点是：

• 工程师描述任务，运行智能体
• 智能体发起PR
• 人类工程师需要频繁介入，提供反馈和指导
• 智能体的自主性有限，依赖人类的持续监督

这个阶段的进展比预期慢，不是因为Codex能力不足，而是因为环境定义得不够清晰：智能体缺少实现高层目标所需的工具、抽象和内部结构。

3.2 中期阶段：自我验证能力的建立

随着环境逐步完善，OpenAI团队开始让Codex获得更多能力：

• 自我验证：让Codex能够在本地自审改动，运行测试验证修复
• 多智能体评审：请求额外的本地和云端智能体进行评审
• 反馈处理：回应人类或智能体的反馈，在循环中迭代直到所有评审者满意

为了提升智能体的自我验证能力，OpenAI做了两件关键的事：

第一，让应用对AI可读。 他们将Chrome DevTools Protocol接入智能体运行时，开发了处理DOM快照、截图和导航的技能。这样Codex可以直接复现bug、验证修复、推理UI行为，而不是只靠静态阅读代码。

第二，让可观测性对AI开放。 日志、指标、追踪通过本地可观测性栈暴露给Codex，并按worktree隔离。每个任务都在独立环境里运行，结束后自动销毁。智能体可以直接执行LogQL、PromQL查询，于是“确保服务启动在800ms内完成”这样的提示变得真正可执行。

3.3 后期阶段：完全自主的临界点

随着更多开发循环被直接编码到系统中——测试、验证、评审、反馈处理、恢复——仓库在实验后期跨过了一个有意义的阈值：Codex可以端到端地驱动新功能。

给定单个提示，智能体现可以：

1. 验证仓库的当前状态
2. 重现报告的错误
3. 录制展示失败的视频
4. 实现修复
5. 通过驱动应用程序验证修复
6. 录制第二个展示解决方案的视频
7. 打开Pull Request
8. 回应智能体和人类的反馈
9. 检测和修复构建失败
10. 仅在需要判断时升级给人类
11. 合并更改

OpenAI团队经常看到单个Codex运行在单个任务上连续工作六个小时以上，很多时候发生在人类睡觉期间。

四、转折：当吞吐量改变合并哲学

随着Codex的吞吐量增加，一个深刻的变革发生了：许多传统的工程规范变得适得其反。

4.1 核心矛盾的转移

在手工代码时代，核心矛盾是“如何更快地写出正确代码”。代码评审、门禁检查、测试覆盖——所有这些流程都围绕一个假设：代码是稀缺资源，人类注意力是充裕资源。

但在Agent-First时代，情况完全颠倒：

• 代码变得充裕：AI可以在你睡觉时产出3.5个PR
• 人类注意力变成真正的稀缺资源：7个人无法逐行评审1500个PR

于是，OpenAI团队不得不重新思考合并哲学。

4.2 新原则：修正成本低，等待成本高

他们得出的结论是：在代理吞吐量远超人类注意力的系统中，修正成本低，等待成本高。

这意味着：

• 最小化阻塞式合并门禁：不再让不稳定测试无限期阻塞进度
• 缩短PR生命周期：通过后续运行处理问题，而非预先阻塞
• 将评审工作移交给智能体对智能体：随着时间推移，几乎所有评审工作都移交给了“智能体对智能体”处理

OpenAI团队坦诚：“这在低吞吐量环境中是不负责任的。在这里，这通常是正确的权衡。”

这种权衡的转变，触及了软件工程的底层逻辑。它意味着在AI时代，我们需要重新设计流程，以适应新的成本结构。

五、启示：10倍效率背后的代价与条件

10倍的效率提升令人振奋，但OpenAI的经验也揭示了这种模式背后的前提条件。

5.1 成功的代价：大量的前置投入

实验早期进展比预期慢，团队花了大量时间做一件事：让智能体有能力完成有价值的工作。

他们必须：

• 设计清晰的架构边界和依赖方向（Types→Config→Repo→Service→Runtime→UI）
• 建立结构化的知识库（docs/目录作为唯一事实来源）
• 开发自定义linter和结构测试（这些lint本身也是Codex生成的）
• 构建反馈循环和反熵机制

正如Thoughtworks专家Birgitta Böckeler所言：“这个团队花了5个月时间完善他们的‘马具’，这说明这不是一个可以一蹴而就的事情。”

5.2 适用性的边界

OpenAI团队也明确指出，这种行为严重依赖于该仓库的特定结构和工具，不应假设在没有类似投资的情况下能够泛化。

至少，目前还不行。

对于遗留系统、跨团队协作、大规模工程治理等问题，Harness Engineering模式还需要更多实践验证。

5.3 工程师价值的重塑

这场实验最深刻的启示，或许在于对工程师价值的重新定义。

当AI可以在你睡觉时产出3.5个PR，当100万行代码可以在五个月内由7名工程师“监督”完成，传统软件工程师的价值主张必须重新定义。

但这不意味着工程师被淘汰。相反，它意味着工程师必须向价值链上游移动：

• 从代码执行者 → 到系统设计者
• 从手工调试 → 到环境构建
• 从微观管理 → 到宏观约束

正如OpenAI团队反复强调的那句话：“Humans steer, agents execute.”（人类掌舵，智能体执行）

结语：设计环境，而非编写代码

回顾这场五个月的极端实验，最令人震撼的不是1500个PR、不是100万行代码、不是10倍效率，而是它向我们展示的一个未来图景：

当AI能够胜任代码的“执行”工作时，人类将彻底解放双手，向价值链上游移动。我们的工作不再是逐行敲击键盘，而是为智能体设计一个它可以自由驰骋、又不会脱缰的“角斗场”。

这需要全新的思维方式、全新的技能组合、全新的工程实践。但它也打开了前所未有的可能性：当代码不再稀缺，人类的创造力和判断力将成为唯一真正的瓶颈。

那些拒绝AI、坚持手搓代码的人，终将被浪潮吞没；而那些懂得**“驾驭”AI的人，将成为AI时代的真正骑手。

---

下一篇预告：《角色的重构：当工程师不再写代码，他们的一天在做什么？》
我们将深入拆解OpenAI工程师在实验中的日常工作流，看他们如何通过“深度优先”的方式，将大目标分解、把能力编码进仓库，以及“文档园丁”智能体是如何诞生的。敬请期待。

---

欢迎在评论区分享你的看法：10倍效率的背后，你认为最大的代价是什么？