3个人5个月100万行代码，人类一行没写

上周，OpenAI 发了一篇工程博客，看完我愣了半天。

3 个工程师，从空仓库开始，5 个月时间，产出了 100 万行代码，1500 个 PR。

人类写的代码行数：零。

这是 OpenAI 工程师 Ryan Lopopolo 记录的真实经历。他们用 Codex（OpenAI 的编程智能体）从零构建了一个内部产品，全过程只有一个铁律——程序员不许写代码。

不是"AI 帮你写，你来改"。而是彻底倒过来：人类负责定义规则，AI 负责全部执行。

这件事让我重新思考了一个问题：AI 编程这件事，我们大部分人理解错了。

大部分人对 AI 编程的理解，还停留在 Copilot 阶段：

• • 你写一行注释，AI 补全一行代码
• • 你写一个函数框架，AI 填充逻辑
• • 你发现 bug，AI 帮你修

本质是：人类当司机，AI 当副驾。

但 OpenAI 这个实验做的是完全不同的事：

• • 人类描述目标，AI 自己拆解任务
• • AI 自己写代码、自己测试、自己提交 PR
• • AI 评审 AI 的代码，另一个 AI 做二次审查
• • 大多数 PR 自动合并，人类几乎不介入

他们管这套方法叫 Harness Engineering——驾驭式工程。

不是 AI 辅助你写代码，是你驾驭 AI 写代码。

就像从手写书信变成了口述让秘书代写。重点不是"谁动笔"，而是"你怎么让秘书理解你的意思"。

他们到底做了什么？

时间回到 2025 年 8 月。

空仓库里落下了第一个 commit——这个 commit 不是人写的，连那个指导 AI 怎么干活的 AGENTS.md 文件，第一版也是 AI 自己写的。

从第一天起，这个仓库就是由智能体塑造的。

然后呢？进展比预想的慢很多。

不是 Codex 不够强，是环境太烂了。

工具缺失、文档混乱、结构不清晰——这些"人类勉强能接受"的环境，对 AI 是致命的。AI 没法靠直觉补全信息，没法靠经验猜测意图，它只能用它能"看到"的东西。

于是 OpenAI 工程团队的主要工作变成了：让 AI 有能力完成有价值的工作。

1. 给 AI 一张地图，不是一本 1000 页的说明书

他们最初试过把所有规则塞进一个大 AGENTS.md，结果是一场灾难。规则越多，AI 越容易迷失在细节里，漏掉关键约束。

后来他们把 AGENTS.md 变成了一张"寻宝地图"——只有大约 100 行，不包含具体知识，只是一个目录，指向仓库深处的真实文档。

真正的知识库在结构化的 docs/ 目录里。这就是"渐进式披露"：AI 从一个小而稳定的入口开始，被教会下一步去哪找，而不是一开始就被信息淹没。

他们甚至专门安排了一个"文档园丁"智能体，定期扫描文档，发现和代码不一致的陈旧描述，自动发起修复 PR。

2. AI 看不见的东西，等于不存在

所有存在于 Google Docs、Slack、或者某人脑子里的知识，对 AI 来说完全不可见。

一个在群里讨论过的架构决策，如果没有沉淀进仓库，AI 就会绕着它转，做出各种"合理但错误"的决策。

所以他们把所有知识——设计文档、架构决策、产品规格、质量标准——全部显式化、结构化、写进仓库。

对 AI 来说，这不是奢侈品，是基础设施。

3. 用"围栏"代替"指挥"

AI 毕竟是概率模型，会产生幻觉，会偷懒，会写出"看似能跑实则一团糟"的代码。

OpenAI 的解法不是微观管理每一行代码，而是建围栏：

• • 每个业务领域有固定的依赖方向（Types → Config → Repo → Service → Runtime → UI）
• • 横切关注点只能通过显式接口
• • 依赖方向通过自定义 lint 规则强制执行（这些 lint 规则本身也是 AI 写的）

还有一组"品味不变量"：强制结构化日志、命名规范、文件大小上限、可靠性要求。

边界集中管控，内部高度自治。

人类的品味不会消失，而是被"编码"进系统——评审意见、重构建议、用户 bug 反馈全部转化为文档更新或工具规则，持续在每一行代码上执行。

做完了这些之后，他们经常看到 Codex 一次运行连续工作六个小时以上——通常还是在人类睡觉的时候。

这对普通人意味着什么？

你可能说：这是 OpenAI，他们有最好的模型和最牛的工程师，跟我有什么关系？

关系大了。因为这个实验揭示的不是"AI 有多强"，而是一个更朴素的道理：

翻译成人话：

以前程序员的核心能力是"写代码"，以后是"设计让 AI 能写好代码的环境"。

这两个技能的差别在于——写代码是手艺活，环境设计是架构能力。

手艺活容易被替代，架构能力不容易。

再具体一点，如果你现在就开始做 AI 编程，你需要练的是这三件事：

1. 把需求说清楚的能力 —— 不是写代码，是写文档、写规格、写验收标准。你描述得越精确，AI 执行得越好。

2. 建规则的能力 —— 代码规范、架构约束、质量标准。不是你亲自守着每一行代码，而是把规则写进系统，让系统自动执行。

3. 拆任务的能力 —— 把大目标拆成 AI 能独立完成的小块。AI 能吃掉多少，取决于你切得有多细。

这三件事，跟你会不会写 Python、会不会写 TypeScript 没有半毛钱关系。

我自己的经验也能印证这一点。我做 AI 编程出海这几个月，真正花时间最多的不是写代码，而是：定义项目边界、写 AGENTS.md、设计目录结构、写质量规则。

代码？AI 写的。

配图脚本？AI 写的。

公众号发布脚本？AI 写的。

我做的是那个"设计环境"的工作。这个实验只是把这个道理推到了极致——3 个人，不写一行代码，5 个月造出百万行产品。

软件工程的"蒸汽机时刻"

1784 年，英国工厂里出现了一个有趣的现象。

工人们发现，那些习惯了手动操作的纺纱工，在面对蒸汽机时反而最不适应。不是因为他们不聪明，而是因为他们的所有经验——手感的轻重、节奏的快慢、力度的大小——在蒸汽机面前全部失效了。

能快速适应的，不是最强的手艺人，而是那些理解机器原理、能设计生产流程的人。

2026 年的程序员，就站在类似的十字路口。

OpenAI 这篇博客的标题叫 "Harness Engineering"——驾驭工程。harness 这个词，最早就是用来指套在马身上的缰绳和马鞍。

你不再是那个骑着马跑的人，你是那个设计缰绳的人。

马跑得有多快，取决于你的缰绳设计得有多好。

我自己的 AI 编程实践也在不断验证这个道理。如果你也想开始用 AI 编程，不需要先学编程语言——先学怎么把一件事说清楚，怎么建规则，怎么拆任务。

这三件事，才是 2026 年程序员最重要的核心竞争力。

参考资料：

• • Harness Engineering: Leveraging Codex in an Agent-First World — Ryan Lopopolo, OpenAI, Feb 11, 2026
• • https://openai.com/index/harness-engineering/