文章总结： OpenAI工程师RyanLopopolo提出HarnessEngineering方法，核心是通过管理Agent的上下文和工具实现代码自动化生成。团队禁止手写代码后人均PR从每周3.5个提升至70个，工程师角色转向系统设计、规则制定和业务决策。关键发现包括代码变为一次性产物、SPEC成为核心资产，以及信任建立需通过自动化反馈机制。可操作建议是将开发重点从代码实现转向需求明确化和验收标准细化。 综合评分： 87 文章分类： 安全开发,AI安全,安全工具,安全建设,其他

OpenAI工程师：一天烧不完10亿Token就是失职，禁止手写代码后，我们的人均PR从3.5个涨到了70个。

原创

算法哥 算法哥

算法与数据结构

2026年6月16日 23:46 福建

在小说阅读器读本章

去阅读

当代码生成几乎没有成本时，软件工程师真正的工作正在发生变化。

前几年，大家讨论最多的问题是：AI会不会替代程序员？ 后来变成了：Cursor、Claude Code、Codex能把开发效率提高多少？ 而OpenAI内部已经开始讨论另一个问题：如果一个团队彻底不写代码，会发生什么？

Ryan Lopopolo: OpenAI’s Framework for Shipping Code at 70 PRs/Week

OpenAI工程师Ryan Lopopolo给出的答案是：几个月没手写代码；很少看Agent生成的代码；每周的人均PR数量从3.5个增长到70个；新人加入两周就能进入正常开发节奏。为了描述这种新的工作方式，他和团队创造了一个新词：Harness Engineering。

最近，Ryan在《AI Native Dev》播客中首次详细介绍了这套方法。看完整场访谈后，我最大的感受是：他们讨论的重点已经不是如何写代码，而是如何管理Agent。

1、什么是Harness Engineering？

主持人Simon Maple先问了一个最基础的问题：什么是Harness Engineering？Ryan的回答并不复杂。他说，现在的大模型已经能够生成大量代码，但真正的问题不是让Agent写代码，而是如何保证这些代码可信、可维护，并且能够进入生产环境。

因为在软件开发过程中，存在大量默认约定：项目架构怎么设计、接口如何定义、哪些写法是团队认可的、哪些模式应该避免、什么才算高质量代码。过去这些知识存在于资深工程师的大脑里，新人需要通过代码评审、文档和日常交流慢慢学习。但Agent不会主动理解这些东西，你必须把它们写下来，然后在合适的时候交给Agent。

Ryan认为，与Agent打交道，本质上只有两个杠杆：Context（上下文）和Tools（工具）。Harness Engineering做的事情，就是管理这两个杠杆，让Agent在正确的时间获得正确的信息。

2. 他们做了一个决定：禁止手写代码

Ryan提到，2025年中，他给自己定了一条规则：不再亲自写代码。当时GPT-5还没发布，Codex远没有今天这么强，Agent经常卡住。于是最早期的系统里甚至有一个专门的工具叫”Ask Ryan”——Agent遇到不会处理的问题时，可以直接把任务交给Ryan，比如安装依赖、修改环境配置、处理权限问题。

但Ryan很快发现一个规律：每当自己重复做某件事情时，说明Agent缺少能力。 于是他开始不断把这些动作工具化。今天让自己帮一次，明天就把这个步骤变成工具，后天Agent就能自己完成。慢慢地，需要人工介入的情况越来越少。

3，新人反而上手更快了

很多人担心：如果所有代码都由Agent编写，新人是不是更难理解系统？Ryan的观察正好相反。他们团队后来陆续加入了新成员，结果发现新人加入后的前两周，团队整体吞吐量反而在持续提升。

原因很简单。过去一个新人入职需要花几个月了解团队习惯，而现在团队积累下来的经验已经沉淀进了Harness。新人使用同样的Codex，拿到的是同样的上下文，调用的是同样的工具。某种程度上说，新人不是向同事学习，而是在向整个团队过去积累的经验学习。 Ryan甚至开玩笑说：”我们实际上是在训练Agent，而不是训练新人。”

4、他们越来越少看代码了

访谈里最有争议的部分，大概是代码审查。Simon问：你们真的不看PR吗？Ryan说并不是完全不看，但审查重点已经发生了变化。

过去的流程是：写代码 → 提交PR → 代码评审 → 合并。现在变成了：写SPEC → 审SPEC → Agent实现 → 自动验证。在Ryan看来，如果需求描述本身就是模糊的，那么无论是人还是Agent，最终写出来的东西都不会好。 因此最值得投入时间的地方，不是逐行阅读代码，而是在任务开始前把需求讲清楚、把边界讲清楚、把验收标准讲清楚。因为这些内容最终都会变成Agent的输入，输入错了，输出自然也会错。

5, 信任不是天生的

Ryan承认，最开始他们也不信任Agent。团队甚至安排了专门的值班人员负责检查Agent的工作结果。但后来发生了一件事：团队发现很多反馈都在重复，同样的问题不断出现。于是他们开始思考：为什么要让人类重复说同一句话？

如果Agent总犯同一个错误，那就应该让它学会这个教训。 于是他们建立了一套自动反馈机制：Agent会定期回顾自己过去提交的内容，分析哪些地方被人类指出问题，总结原因，生成新的经验文档，然后在后续任务中继续使用。Ryan说：”如果我希望年轻工程师从错误中成长，那么Agent也应该如此。”

6. 代码开始变成一次性产物

访谈里还有一个特别有意思的观点。Ryan认为，未来真正重要的资产可能不是代码，而是SPEC。

过去大家习惯先写SPEC再写代码，但现在很多时候变成了先生成代码再从代码提炼SPEC。因为代码已经便宜到几乎没有成本，你可以快速生成一个版本，讨论，推翻，再生成，反复迭代。 最后沉淀下来的，反而是系统设计本身，而不是某一次具体实现。

Ryan的团队甚至做过实验：让一个Agent从现有代码中生成SPEC，再让另一个完全没见过代码的Agent根据SPEC重写系统，最后再由第三个Agent对比两者差异，不断修正SPEC，最终得到一份高度准确的系统说明。

7、人均PR从3.5个到70个

Ryan给出了一个非常夸张的数据。Codex早期阶段，他们团队的人均产出大约是每周3.5个PR。而到了新版Codex，这个数字增长到了每周70个PR——20倍提升。

Ryan认为原因有两个。第一是模型能力提升，第二是工程摩擦消失了。以前为了让Agent操作Electron应用，团队搭过非常复杂的环境：图形界面Ubuntu、虚拟显示驱动、XQuartz、FFmpeg录屏，一堆基础设施。后来这些东西全部被内置能力取代。以前要折腾半天的事情，现在打开开关就能用。

8、”一天不用十亿Token，就是失职”

Ryan曾说过一句很有争议的话：”如果一天不用掉十亿Token，那几乎是在失职。”很多人觉得这句话太夸张，但他的解释其实很直接。他认为模型能够释放多少能力，与投入多少Token有很强关系。 如果只是自己和Agent结对编程，根本不可能达到这个规模。

想消耗十亿Token，就必须让Agent参与整个团队的工作、参与整个组织的工作，让大量任务并行运行，构建自动化循环，建立持续反馈机制。这和当年CI/CD刚出现时很像，大家都知道方向是对的，但没人知道最佳实践是什么，整个行业都还在摸索。

9、软件工程师最重要的能力正在变化

访谈最后，Simon问：未来的软件工程师最重要的能力是什么？Ryan的回答很明确：不是写代码，而是系统思维。

他说自己现在的时间大概这样分配：30%做复杂重构，30%做新产品探索，30%与客户沟通、确定优先级。真正写代码的时间已经很少，因为代码有人写——准确地说，是有Agent写。工程师更重要的职责变成：定义目标、设计系统、建立规则、管理上下文、清除障碍。

以及最重要的一件事：决定什么不该做。Ryan说了一句很值得思考的话：”现在的问题不是我们能不能做，而是我们应不应该做。”因为代码已经变得太便宜了，任何功能都可以快速实现，但最终使用产品的还是人。软件开发的节奏，仍然要由人的需求决定。

写在最后

看完整场访谈，我觉得Ryan并没有证明程序员不重要。相反，他证明了另一件事：代码正在变得越来越不重要。

过去十几年，程序员的主要工作是写代码、看代码、改代码。而Ryan描述的未来里，Agent写代码，Agent看代码，Agent改代码。工程师负责的是定义问题、设计系统、建立规则、管理上下文、决定方向。

如果这个趋势继续下去，未来最有价值的人，未必是写代码最快的人，而是最懂业务、最懂系统、最懂如何组织Agent的人。 或许，这才是Harness Engineering真正想表达的东西。

来自访谈视频原链接：

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：算法与数据结构 算法哥 算法哥《OpenAI工程师：一天烧不完10亿Token就是失职，禁止手写代码后，我们的人均PR从3.5个涨到了70个。》