严禁手写代码、一天烧不完 10 亿 Token 就是失职：OpenAI 工程师揭秘“零人类编码”的激进实践

核心结论

这篇文章的关键不在于“AI 会写代码”这个老话题，而在于 OpenAI 工程师 Ryan Lopopolo 把软件工程流程改造成了一个围绕 Agent 运转的生产系统：团队数月不手写代码，也基本不做传统逐行人工代码审查，而是通过 Harness Engineering 让 Codex / Coding Agent 从需求、实现、测试、修复到 PR 形成闭环。

所谓 Harness Engineering，可以理解为把工程团队过去隐性的判断、规范、上下文、测试、工具链、审查标准和反馈机制，显式编排成 Agent 能读取、调用和学习的“工程马具”。它不是单纯写一个好 Prompt，也不是只堆上下文，而是同时管理两类杠杆：

• Context：需求、原则、接口、设计文档、历史反馈、运行日志、代码库约定。
• Tools：测试、lint、CI、审查 Agent、浏览器 / 计算机使用能力、脚本、skills、企业数据连接器等。

Ryan 的判断是：当代码生成成本趋近于很低，工程师的核心价值会从“亲手写代码”转向“设计系统、定义接口、组织反馈、决定什么不该构建、让 Agent 团队高质量地产出”。

背景与案例

文章来自 InfoQ 对 Ryan Lopopolo 在《AI Native Dev》播客访谈的整理。Ryan 曾组建 Stripe 的效率工程团队，也在 Brex 负责过 350 名工程师规模的开发者生产力，这种“通过系统影响他人工作”的经验，成为他后来设计 Agent 工程流程的基础。

他在 2025 年 6 月就给团队设下激进约束：项目中没有人可以手写代码。当时还没有后续更强的 GPT-5 系列模型，只是 O3、Codex Mini、早期 Codex CLI 阶段，因此过程很痛苦。Agent 经常卡住，甚至会反复要求 Ryan 人工帮忙做诸如用 Cargo 安装依赖这样的琐事。Ryan 的第一步不是回到手写代码，而是把这些反复消耗他时间的动作工具化，让 Agent 可以自行调用。

这个过程让团队看清了 Agent 的真实能力边界：

• Codex 擅长遵循清晰指令。
• Codex 擅长写测试、跑测试，并基于反馈修复。
• Codex 会犯错，但错误可以被记录、归类、蒸馏，并变成下一轮上下文或护栏。
• 新成员通过 Codex 进入代码库时，可以直接继承代码库中沉淀的最佳实践，而不是像传统团队一样花 1 到 3 个月吸收隐性知识。

Ryan 提到，随着团队扩张到第 5、第 6、第 7 名新成员，新人加入前两周团队 PR 吞吐量反而提升了 5%、10%、15%。这背后的原因不是新人立刻理解了全部系统，而是“最佳实践已经铺在代码库和 Agent 工作流里”。

最吸引眼球的数据是 PR 吞吐量变化：在 GPT-5.2 时代早期，团队每名工程师每周大约产出 3.5 个 PR；到 GPT-5.5，这一数字变成 70。Ryan 认为这既来自模型能力进步，也来自 Harness Engineering 让团队能真正利用这些能力。

关键实践 / 方法

1. 以 Codex 作为代码库的唯一入口

团队的基本假设是：人不直接改代码，而是通过 Codex 进入代码库。这样做的好处是，所有人对代码库的贡献都会经过同一套上下文、工具和反馈系统，最佳实践不再只存在于资深工程师脑中，而是被编码进仓库、Issue、Markdown 文档、CI、脚本和 Agent 工具调用中。

这也改变了新人 onboarding：新人不需要先完整建立系统心智模型，只要能通过 Agent 表达判断、补充上下文、定义目标，就能快速进入生产状态。

2. 把非功能性要求写下来，变成 Agent 可见的“金线”

Ryan 强调，高质量软件包含大量微小决策：可维护性、接口边界、测试策略、风格约定、性能、安全、发布习惯、业务约束等。对人类团队来说，这些往往靠 Code Review、口头传承和资深工程师直觉维持；对 Agent 来说，必须把它们写下来，并在正确时间放入上下文。

因此，Harness Engineering 的目标是让 Agent 在生成代码时能看到这些非功能性要求，并通过测试、lint、评审 Agent、大型重构循环和 CI 外循环来证明代码“可接受、可合并”。

3. 用工具调用做上下文管理，而不是只靠长 Prompt

Ryan 区分 Prompt Engineering、Context Engineering 和 Harness Engineering：当人与 Agent 交互时，真正可控的杠杆只有上下文和工具。Harness Engineering 的特殊之处，是通过工具调用对 Agent 做动态上下文塑形。

例如，团队不会简单把一条 eslint 报错原样丢给 Agent，而是把失败信息压缩成语义丰富的自然语言：告诉 Agent 哪个文件出错、应参考哪个操作手册、为什么这是一个已知模式、应该如何修复。这种反馈更适合 Agent 的推理方式，也更节省上下文窗口。

4. 人类审查前置到计划、里程碑和 SPEC，而不是逐行审查代码

文章中所谓“零人类代码审查”并不等于完全没有人类判断，而是审查重心迁移：

• 对普通实现，依靠 Agent、测试、lint、CI 和后置审计闭环。
• 对复杂计划、跨周里程碑、执行文档，仍要求传统双人预合并审查。
• 原因是这些文档本质上就是给 Agent 的提示词；如果需求写得模糊，生成结果就会偏离。

这意味着工程师的审查对象从“这一行代码命名好不好”变成“任务描述是否精确、接口是否合理、系统边界是否清楚、这件事是否应该做”。

5. 建立“垃圾回收”与反垃圾外循环

团队早期在 PR 吞吐量暴涨后遇到质量压力，于是每周五进行“垃圾回收”：清理低质量代码，开长时间同步会，把团队对好代码的心智模型社会化。

随后他们把这种人工反馈系统化：

• 建立包含 100 到 150 条评论的 GitHub issue，记录底层软件开发原则。
• 让 Agent 基于这些原则扫描代码库，识别偏差并排序。
• 让 Agent 自动提出修复 PR。
• 设置 on-call 值班人员对 Agent 产出做“点赞 / 点踩”：合并、不合并、留下反馈。
• 下一轮 Agent 读取自己过去的 PR、人工反馈和会话日志，分析犯错原因，生成 Markdown 经验文档，作为后续上下文。

这套机制的核心是：不要给同样的反馈两次。一旦某类错误重复出现，就把它沉淀为文档、审查 Agent、测试或更早阶段的 pipeline 规则。

6. 允许低风险错误进入系统，再从错误中学习

Ryan 并不主张所有场景都无脑自动发布。文章明确提到，他们的项目没有做持续部署，而是手动切发布分支并做冒烟测试；发布流程仍保留一定人工监督。

但在低风险区域，他倾向于让 Agent 犯错，因为错误只有真实进入系统，才能被观察、修复、蒸馏成模式，再前移到提示词、文档、审查 Agent 或确定性测试中。这是一种“先用最低成本修 prompt，必要时再左移”的策略。

7. SPEC 与代码的关系被反转

文章提出一个重要趋势：当代码生成成本足够低，代码可能从长期资产变成可丢弃的高决策密度工件，真正持久的资产变成 SPEC、上下文和接口定义。

Ryan 以 Symphony 为例描述三阶段 pipeline：

1. 把原始实现交给 Codex，让它生成能复现系统的 SPEC Markdown。
2. 把 SPEC 交给一个从未见过原始代码的新 Agent，让它重新实现系统。
3. 再让第三个 Agent 比较新系统、SPEC 与原始实现，找出不一致，并提出 SPEC 修改建议。

这会消耗大量 Token，但结果是一份更精炼、更可靠、又保留适配空间的 SPEC。换句话说，代码既可以是原型，也可以是提炼 SPEC 的“稻草人”。

8. Token 消耗成为组织级智能提取能力的指标

Ryan 的一句“每天不用掉十亿 Token 几乎就是失职”不是鼓励浪费，而是在强调：如果从模型中提取的智能量近似与 Token 消耗量相关，那么团队就应该设计能安全、对齐、并行地消耗大量 Token 的工作流。

这不可能靠个人和模型聊天实现，必须依赖：

• 并行 Agent 工作流。
• 异步反馈循环。
• 面向团队和组织的自动化，而非单机助手模式。
• 可审计、可回滚、可学习的工程护栏。

他把当前阶段类比为 CI/CD 早期：大家还没有标准答案，但必须通过激进实践找到未来会沉淀为默认基础设施的模式。

对工程团队的启示

第一，AI Coding 的瓶颈正在从“模型能不能写”转向“组织能不能承接”。如果团队没有清晰的测试、接口、文档、运行反馈和质量护栏，Agent 只会更快地产出混乱。真正的竞争力不是谁会写 Prompt，而是谁能把工程知识转化为 Agent 可执行的系统。

第二，代码审查的价值会继续上移。传统逐行审查在高吞吐 Agent 生产模式下很难扩展，工程师更应该审查需求、计划、SPEC、接口边界、失败模式和发布风险。也就是说，人类要把精力放在高杠杆决策上，而不是沉迷检查机器生成的每个局部实现。

第三，团队知识管理会变得更重要。过去没有写下来的“约定俗成”，在 Agent 时代会直接变成质量缺口。优秀团队需要把经验沉淀到仓库、Issue、Markdown、CI、测试、脚本、skills 和评审 Agent 中，让每次反馈都能复用。

第四，工程师能力模型会变化。Ryan 认为“编写代码”不再是唯一核心技能，更重要的是系统思维：预见未来几个月的问题、定义好接口、理解客户需求、决定优先级、识别不该构建的功能、为 Agent 扫清障碍。这并不意味着工程师不懂代码，而是代码能力从手工产出转为判断、抽象和治理能力。

第五，低成本编码会带来产品风险。因为“什么都能建”之后，更关键的问题变成“该不该建”。团队如果缺少产品判断和用户节奏意识，很容易用 Agent 快速堆出复杂但无价值的功能。

风险与我的判断

我认为这篇文章最有价值的地方，是它把“AI 编程”从个人效率工具讨论推进到了工程组织设计讨论。但它的实践也有明显边界，不能简单照搬。

主要风险包括：

• 质量幻觉：PR 数量暴涨不等于业务价值和系统质量同步增长。没有强测试和可观测性，吞吐量会掩盖技术债。
• 上下文污染：如果沉淀下来的原则、Issue、Markdown 或历史反馈本身质量不高，Agent 会把错误规范放大。
• 责任边界模糊：零手写、零逐行审查容易让团队误以为责任转移给了模型，但生产事故、隐私、安全和合规责任仍在人类组织。
• 过度后置审计：允许低风险错误进入主分支可以学习，但高风险系统不能以此为借口牺牲发布纪律。
• 供应商与工具链依赖：以 Codex 为唯一入口会极大绑定特定平台能力，迁移成本和治理风险都需要提前评估。
• 指标误导：十亿 Token 是一个刺激组织思考并行化和自动化的挑衅性目标，但如果缺少价值度量，Token 消耗会变成新的虚荣指标。

我的判断是：OpenAI 团队的“零人类编码”更像是前沿团队在高信任、高工具成熟度、高测试意识环境中的压力测试，而不是所有公司明天都该执行的制度。对大多数工程团队，更现实的路线是分阶段引入：

1. 先把重复反馈写成文档和测试。
2. 让 Agent 处理低风险、边界清晰的任务。
3. 建立 AI 生成代码的审计、回滚和质量指标。
4. 把人类审查逐步前移到需求、SPEC 和接口。
5. 等自动化闭环成熟后，再扩大 Agent 自主合并和后置审查范围。

这篇文章真正提示我们的是：未来的软件工程不是“人类 vs AI 谁写代码”，而是“谁能设计出更好的 AI 原生工程系统”。代码仍重要，但它会越来越像系统运行中的中间产物；更持久、更稀缺的资产，是需求判断、上下文组织、接口设计、反馈闭环和工程治理能力。