本文来自微信公众号： InfoQ ，编译：宇琪，作者：冬梅，原文标题：《严禁手写代码、一天烧不完 10 亿 Token 就是失职：OpenAI 工程师揭秘“零人类编码”的激进实践》

Harness Engineering，这个词最近在开发者圈子里引发了激烈讨论，因为它触及了一个核心问题：当AI Agent能写出大量代码时，我们如何确保这些代码是可信任、可维护、可投入生产的？

对于OpenAI工程师Ryan Lopopolo来说，他的团队已经连续数月没有手写过一行代码，也没有对Agent生成的代码进行过人工审查，而是通过Harness Engineering让Agent自主完成从需求到PR的全流程。更惊人的是，随着GPT-5系列模型迭代，团队人均PR吞吐量从每周3.5个飙升至70个。这一切的起点，都来自他在2025年6月做出的一个激进决定：禁止任何人手写代码。

日前，Ryan Lopopolo在《AI Native Dev》播客中，与主持人Simon Maple一起，讲清了团队零人类编码与审查的工作模式，通过“Harness Engineering”让AI Agent自主完成复杂软件工程任务的方法。本文基于该播客视频整理，经InfoQ编辑。

核心观点如下：

• Harness Engineering的核心思想是：要生产出可接受的、我们信任的、能够围绕其构建业务信心的代码，过程中有大量微小的决策需要做出。为了让Agent理解和掌握这些，我们必须把它们写下来。

  
  

• 随着我们在代码库中积累越来越多的上下文和能力，每个通过Codex作为唯一入口进入代码库的人，默认就能获得所有人的最佳实践，而不是像传统团队那样，新人需要花一到三个月去吸收团队的最佳实践，这些最佳实践已经“铺”在代码库里了。

  
  

• 就像我希望正在成长的工程师从自己的错误中学习一样，我也希望看到Agent犯的错误，这样我们作为监督者就能想办法让它们也学会。

  
  

• 软件工程师不再需要把“编写代码”作为核心技能来培养，我更希望工程师培养的是系统思维：如何为团队的成功创造条件，如何尽可能远地预见未来、解决问题、提升代码生产和交付给客户的速度。

  
  

零人类手写代码

Simon：什么是Harness Engineering？

Ryan：我们拥有这些神奇的Coding Agent和极其智能的模型，它们能产生大量代码。但Harness Engineering的核心思想是：要生产出可接受的、我们信任的、能够围绕其构建业务信心的代码，过程中有大量微小的决策需要做出。为了让Agent理解和掌握这些，我们必须把它们写下来。让所有那些构成好代码的非功能性需求，能在正确的时间被Agent看到，并确保我们生成的所有代码都遵循我们生产高质量软件的那条“金线”。评审Agent、测试、lint、大型重构循环，各种方式让Agent形成闭环，确保它向我以及团队其他成员证明，它生成的代码是可接受的，可以合并。

Simon：Prompt Enginnering、Context Engineering和Harness Engineering的主要区别是什么？有多大重叠？

Ryan：当你与Agent交互时，你手里只有两个杠杆：你提供什么上下文，以及你提供什么工具，Harness Engineering本质上是这两者的组合，目标是确保我们提供给Agent的上下文是正确的，这样它就能发挥其推理魔力，生成好的代码。但真正独特的地方在于：我们实际上是在利用工具调用对Agent进行“提示注入”，从而管理它的上下文窗口。我们在代码库中组织测试和lint的方式，与为人类组织这些信息的方式截然不同。如果是对人，我会给出一份详尽的失败清单；但Agent不一样，由于Agent调用工具的方式，我们传递给它的消息需要既压缩又语义丰富。我不会给Agent一条机械的eslint报错，而是用一段自然语言描述：“你在文件X里搞砸了，请打开它，按照文件Y里的操作手册去修复——因为我们之前见过你犯同样的错误，而且我们知道你能处理好。”

Simon：你组建了Stripe的效率工程团队，在Brex领导过350名工程师的开发者生产力，这些经验对做Harness Engineering是帮助还是阻碍？

Ryan：绝对是帮助，它让我习惯了“通过他人工作”的思维方式。当我试图提高一个拥有350名工程师的工程组织的生产力时，我无法亲力亲为地深入到每一个正在生成的PR的细节中，也无法直接处理底层系统。我必须在幕后进行引导，确保正确的事情正在发生。默认情况下，正确的系统已经就位，以便对组织能够做好工作有高度的信任。而这正是与这些Agent高效协作、超越将Coding Agent作为结对编程助手、进入大规模并行模式（比如我同时开着15个团队窗口）所需要的，我需要在某种程度上放手。所以这种运作方式，这种系统思维的心态，对我来说很自然，因为这是我整个职业生涯中必须建立起来的专长。

Simon：你给自己和团队设了一个非常激进的约束：零人类编写代码。当你决定“这个项目里没人能写任何代码”的时候，你害怕吗？有多确信这是正确的方向？

Ryan：这绝对是个激进的想法。我刚开始这么干的时候，甚至还没有像样的推理模型。GPT-5是2025年8月发布的，而我在6月就已经开始这种“放手”模式了。那还是O3时代，Codex Mini刚刚出来，Codex CLI的第一个版本。说实话，那时候模型的能力差远了，以这种方式运作非常痛苦。出于无奈，我不得不把自己变成一个很“笨重”的工具，当Agent卡住时，它可以委托给我，一开始它能做的唯一一件事就是“让Ryan帮它做点什么”，很快我就厌倦了反复被要求做同样的事情。比如最初它总是让我用Cargo安装依赖，这是Codex当时无法可靠完成的事情。自动化这件事是我的第一步，它让我进入了一种状态：密切关注自己的时间花在哪里，想办法构建一个工具调用来消除这种时间消耗。

从零开始这样做，你会切身经历Agent的每一个失败。在编写代码的过程中，亲眼看到它犯什么错，你也能看到它真正擅长什么。Codex非常擅长遵循指令，也非常擅长编写测试并执行测试。所以把大量工程流程压缩成这些“铺好的路”，让我对Agent的信心逐渐建立起来。

Simon：你说它擅长遵循指令、擅长写测试——这不就是大多数开发者的反面吗？你的团队里其他人对这种零手写代码的决策接受度如何？

Ryan：我很幸运，我们团队扩张时招的全是公司的新人。这些新成员直接掉进了这个疯狂的环境，心想“哦，原来这就是我们做事的方式”，然后一头扎进去。早期最痛苦的是如何指导大家不产出“垃圾代码”，但一旦我们找到了方法，到我们招到第五、第六、第七个新成员时，在头两周内，我们实际上看到PR吞吐量提升了5%、10%、15%。这可不是团队快速扩张时的常见路径。原因在于：随着我们在代码库中积累越来越多的上下文和能力，每个通过Codex作为唯一入口进入代码库的人，默认就能获得所有人的最佳实践，而不是像传统团队那样，新人需要花一到三个月去吸收团队的最佳实践，这些最佳实践已经“铺”在代码库里了。这意味着新加入团队的成员能够非常快速地贡献他们自己的最佳判断和上下文，每个人都能非常快地变得更高效。

Simon：所以你们实际上是在通过Agent来让新人“入职”？

Ryan：没错。

零人类代码审查

Simon：有一个非常好的说法：“你只有有了刹车才能开得快”。现在，“开得快”就是使用Codex以比我们手动编写更快的速度生成代码，“刹车”就是测试、评审，它们验证代码并指出我们需要在实际投入生产之前花时间修复和调整的地方。另一个有趣的事情是“零人类代码评审”，这几乎是把AI当作刹车了，工程师们对于Agent来做评审有多适应？

Ryan：其实，合并后代码审查这个概念本身并不新鲜。我在2010年代初刚入行时，这就是写软件的常态，团队内部有高度信任环境，偏向行动和吞吐量，只抽查部分代码样本。除此之外，还要在团队中进行大量的同步沟通，以确保每个人对系统都有相同的心智模型。现在，Agent让这种做法重新流行起来，这很酷。因为如果代码库的入口始终是Agent，团队里的每个工程师其实不需要对系统有完整的心智模型，只要他们信任团队里的其他人都在让Codex拥有那种专业水平就行。

需要澄清的是，系统里并不是完全没有审查。我们确实有一些场景要求传统的双人预合并审查，主要集中在高度复杂的计划、跨周阶段里程碑这类事情上。原因很简单：这些计划、里程碑、执行文档，本质上就是你要给Agent的提示词。如果你依赖一个文本文档来驱动实现，那文档里的措辞是否精确、是否充分描述了任务，就变得至关重要，因为如果你在前期把任务描述得不够具体，你得到的就是垃圾。所以，我们把人类审查的重点放在了这上面，而不是放在逐行代码上。

Simon：所以这里的审查和通常理解的代码审查完全不同，它是前置的。传统的代码审查经常争论细节、命名、风格指南之类的东西。而现在，我们看的是更高层次的设计，可能的原因是审查高层设计本身就更有趣，因为我们可以提供更有意义的输入，思考我能在这里提供的最大价值是什么。但同样，我们可能也更远离代码本身了，所以在某种程度上必须信任。或者实际上，深入实现细节几乎是在浪费我们的时间，因为我们需要将这些抽象化，需要有机制让测试自动进行，以确保成功。

Ryan：没错，这又回到了那个“团队技术主管”的心态。我当年在Brex负责开发者生产力时，我不会去操心每个团队写的每一行Terraform代码。但我确实关心高层指导原则，我希望基础设施是可复现的，我希望它能快速部署，我希望我们有模块来解决常见的开发者工作流。但你的底层模块怎么组织，只要代码在局部是连贯的、并且实际解决了业务问题，我其实不太在意。

Simon：你和团队是在哪个阶段真正觉得：“我完全信任这套机制了”？

Ryan：我觉得有两个阶段。第一个是：我是否信任Agent能够产出代码？那个神奇的时刻发生在我和队友一起开发Codex应用的早期版本时。当时我心想，“天啊，我要是能语音输入就好了”然后我给了机器一个提示词，半小时后，这个想法就在真实的应用里跑起来了。那种感觉太棒了，你突然获得了一种信心：只要我安排提示词的节奏足够好，这个“魔法机器”就能把我的想法变成现实。所以这是第一阶段，进入这种心态：我们作为工程师的角色应该是想办法喂养机器，安排工作，让我们的愿景得以实现。

第二阶段是：这段代码值得信任吗？质量够高吗？当我们把第三名工程师招进团队时，PR吞吐量猛增，但我们根本来不及做审查，也没法保证“垃圾代码”不会混进代码库。所以我们开始踩刹车，每周五做“垃圾回收”，开很多长时间的同步站会，把这种心智模型社会化。我们倾向于吞吐量，倾向于合并，但同时要保持质量底线。所以每个周五都在努力消除垃圾代码，同时找到系统性的方法来消灭它，我们绝不想给出同样的反馈两次。所以这逐渐累积成了这些程序化的护栏，以及一个非常长的外循环，由自动化的CI任务组成，专门用来查找垃圾代码、识别垃圾代码、编译一份“好代码”的金色原则清单，然后找出代码库中与这些原则的偏差，自动提出PR。到那时我们才看到：哦，Agent确实能按我们期望的方式写代码，我们只需要设置正确的循环和系统，让它自己关闭这个反馈回路。

Simon：是通过上下文或Skill之类的东西提供给它的吗？

Ryan：是在skills出现之前，大概八个月前吧。我们用的是非常廉价的手段，建了一个GitHub issue，工程师和Agent可以在里面留言，记录底层软件开发原则。这个issue越积越大，最后变成了一个拥有100到150条评论的大帖子。这个帖子就是种子，Agent会用它来爬遍整个代码库，对违规行为进行优先级排序，然后提出PR。

一开始我们完全不信任它。我们设置了一个on-call值班机制，专门负责监督所有Agent产出的内容。这个人做的是人工的“点赞/点踩”：合并或不合并，留下评审反馈。这样一来，下一次反垃圾循环启动时，它就会查看自己之前产出的所有PR，吸收这些人类反馈，和上次运行的会话日志做对比。它会问自己：我犯了哪些错误？我遗漏了哪些优先级？我产出了不对齐的代码吗？为什么？然后它自己找出如何不再犯同样错误的方法，生成一些Markdown文档，保存到GitHub运行记录中。于是下一次运行时，它就拥有了从系统里真实人类反馈中学到的额外上下文。

Simon：那这是正确的方式吗？你会推荐其他人也这样搭建他们的Agent迭代流程吗？是先写代码，再事后审计、审查，还是今天你已经倾向于在代码生成时就加入这些规则？

Ryan：两者结合。我们确实认为这些异步循环是高效工作的核心组成部分。早期的Codex Security项目也是同样的工作方式：代码合并到主分支后，安全审查才会介入，发现漏洞后生成补丁，提PR，审查，合并。这种流程的好处在于，它允许错误真正进入主分支，而这些错误是可以被学习的。每当我们能够提出一个修正时，除了修复它，也通过Agent、循环、蒸馏识别重复的模式，这些是我们想要更早地拉入pipeline的东西。

Simon：当你确实把错误推送到生产环境时，现在会不会不那么害怕了？因为你知道Agent可以很快地审查和修复它们？

Ryan：这确实是一个光谱。说实话，这个项目我们并没有做持续部署。我们在构建一个原生应用，手动切发布分支，做冒烟测试。冒烟测试最初全部由人工完成，然后我们观察时间花在哪里，再尝试让Agent承担一部分。但在这个世界里，我认为对发布流程保持一定水平的人工监督仍然很重要。

不过，如果我戴上团队技术主管的帽子，有些错误是完全可以犯的，它们的后果很低。就像我希望正在成长的工程师从自己的错误中学习一样，我也希望看到Agent犯的错误，这样我们作为监督者就能想办法让它们也学会。

在代码生产成本如此低廉的新世界里，我认为你可以把DevOps的左移策略彻底翻转过来。我现在能做的最便宜的事情，就是修改我的提示词。这是修复生成代码成本最低的方式。如果发现错误更系统化，我再考虑进一步左移：我可以添加文档，或者部署一个审查Agent，让它按照这些文档评判每一个PR。或者我甚至可以做更彻底的左移，编写确定性测试来自动捕获这种行为，越早越好。但出发点永远是用最少的精力去消除不良行为，因为这些模型是神奇的推理者，大多数时候它们只需要我付出很少的努力就能做得很好。

SPEC驱动的未来

Simon：你刚才描述的方式“通过修改提示词就能改变整个实现”，让我觉得真正持久留存的东西不再是代码，而是我们的提示词、上下文和功能需求。这让我想到了Symphony，一个“幽灵库”，因为它本质上就是SPEC和上下文，而不是实现或代码。当我们这样想的时候，代码就变成了一个一次性的产物，今天的实现明天可能就变了。真正持久、我们应该投入最多时间的东西，是SPEC和提示词，这是未来的方向吗？当我们思考SPEC与代码之间的关系时，这种关系正在发生多大的变化？

Ryan：想想传统的SPEC驱动开发：你从SPEC开始，然后在代码产出过程中不断细化它。但对于Symphony这样的项目，我实际上发现，先产出代码要容易得多。让代码先摆出一个“稻草人”，一个世界可能长什么样的初始版本，然后团队围绕它进行讨论、改进，最后再从中提炼出SPEC。因为产出的工件，无论是代码、电子表格还是Google文档，它们在决策密度上非常高，这些决策是为了产出我们认可为“好”的东西而做出的。

所以对于Symphony，我们最终交付的东西本质上是一个SPEC，但我们一开始的起点，是在我们的monorepo里用TypeScript写的一个“感觉对了”的实现版本。当我们觉得它不错了，我们才开始从中产出SPEC，分享给世界。这个过程非常酷，我们有一个三阶段的pipeline：

第一阶段，我们把Symphony的原始实现交给Codex，让它生成一个SPEC Markdown文件，这个文件要能够复现这个系统。第二阶段，我们拿着这个SPEC，交给一个全新的、没有访问过原始代码的Agent，说：“这是SPEC，请实现这个系统。”第三阶段，当它说“完成”后，我们把新系统、SPEC和原始实现一起交给第三个Agent，让它当裁判，去判断：“派生工件与原始系统之间有哪些不一致？请提出对SPEC的修改，以便下一次尝试做得更好。”

这是一个非常消耗Token的过程。但最终你得到的是一个高度精炼的SPEC，它能够可靠地复现原始系统，同时仍然为这个“幽灵库”的消费者留出空间和歧义性，让他们可以根据自己的实际业务上下文来适配。我认为这非常酷，因为它意味着我们能在业务逻辑、关键部分上做到极其紧凑、高精度的SPEC，同时仍然保留灵活性。

Simon：我喜欢你描述的这个过程，一个非常纯粹的原型：快速开发应用程序，从中获得经验。但区别在于，因为开发成本很低，现在可以说：“我可以直接扔掉它。”我不会被诱惑去保留那个半成品，而是把我学到的一切和功能需求都提炼到那份SPEC里。

Ryan：其实这个过程并不新鲜。回想我职业生涯中其他领域，比如与数据科学团队合作时，他们会在Jupyter Notebook里拼凑出一个模型来先验证想法。一旦他们对结果有了信心，就会交给工程团队去生产化。如果我们考虑在Figma中快速设计原型，然后交给团队进行生产化，也是同样的背景。但现在，因为代码的生产成本变得极其低廉，我们可以在生产系统中直接做这件事。

我们在构建的应用中有一个很酷的实践——在Dev Electron应用里，我们设了一个窗口，Agent可以启动它，这个窗口提供了我们正在交付的原生渲染画布，以及完整的设计系统和组件库。这意味着Agent能直接在即将部署的界面上快速制作新屏幕的原型，生成截图，交给我们的设计师，这样就形成了一个超级紧凑的反馈循环：我们的愿景是否与现实匹配？我们能否在我们将要发布的界面中实现这种体验？

Codex的演进

Simon：最近在社交媒体和社区讨论中，大家对Codex的行业认知发生了很大变化。我听到很多人都在称赞Codex，从其他知名的Agent迁移到Codex上。这到底是某个特定功能让Codex实现了能力跃升，还是团队持续积累的成果？

Ryan：Codex的产品迭代速度非常快。我们刚刚庆祝了一个里程碑：周活跃用户突破500万。Codex的开发和研究团队之间存在着一个非常紧密的良性循环，这是一个奇妙的飞轮效应。GPT-5系列的每一个小版本迭代，Codex的能力都在实现飞跃式提升。从5.2到5.3，最大的提升来自后台工具调用和并行工具调用。这意味着Codex能够同时做更多工作，在更复杂的需求上更快推进。到了5.4版本，普通GPT-5模型和Codex模型的统一带来了质的改变：你不仅得到了一个超级强大的代码生成Agent，它还同时拥有极其强大的通用智能和文本能力，这意味着我可以用Codex来处理软件开发流程中除写代码之外的所有环节。比如我今天晚些时候要演示的幻灯片，100%由Codex使用Google Sheets的应用连接器生成，这在去年我根本想象不到。而在5.5版本中，计算机使用和内置浏览器功能的出现，进一步闭环了整个流程。回想5.1、5.2时代，我们需要做大量笨拙的变通操作，现在这些都不再需要了，因为我们正在给Agent提供越来越强大、越来越完整的工具。

因为我们部署的框架和应用、我们的研究环境以及让模型有效使用这些东西之间存在着良性循环，这是一个能力持续提升的过程。我喜欢Codex的一点是，它会完整地完成工作，它不会给我太多废话。我可以像对待团队中的其他成员一样对待它，我不会盯着我所有七个队友的肩膀，在他们做错事时敲他们的头。我给他们一个任务，我可能偶尔在站会上检查一下，我相信他们会生成一个或多个能完成工作的PR，我对Codex及其自主完成任务的能力也有同样的信任。

Simon：在你看来，到底是Agent的更新拉动效果更大，还是模型本身的更新更关键？

Ryan：两者都有贡献，但我必须说，新模型的发布才是最让我兴奋的部分。在提升能力方面，我们拥有的最强杠杆就是持续训练模型。我认为5.2就是这些Coding Agent的奇点时代，从5.2系列开始的每一个版本迭代，都在反复提升PR吞吐量。在5.2时代初期，我团队里每个工程师每周大概能产出3.5个PR。到了5.5，这个数字变成了70。这已经不只是线性增长了，简直不可思议。

Simon：那这变化是因为人变了，还是能力本身变好了？

Ryan：两者都有。随着模型能力以这种跨越式的方式提升，我们在“赋能”环节上需要投入的精力确实变少了，所谓的Harness Engineering变得更简单。我们使用的技术本身没有变，但为了把Agent连接到外部世界而需要构建的笨重工具，正在变得越来越少。举个例子，在计算机使用功能出现之前，为了让Codex驱动我们的Electron应用，我们需要启动一个运行在Docker容器中的图形化Ubuntu系统，里面要装虚拟显示驱动和X Server，然后让工程师在他们的Mac上安装XQuartz，通过Agent连到那个无头主机，再连上FFmpeg去录制应用屏幕上的变化，整个过程极其笨重。而这一切，现在只需要在应用里打开一个计算机使用的开关就搞定了。

Frontier项目中的Harness实践

Simon：具体看看Frontier项目这个典型案例，请你带我走一遍这个项目的harness到底长什么样，包括哪些部分会更新、谁拥有它、谁负责修改它。

Ryan：OpenAI Frontier是我们的企业级Agent平台，覆盖了从如何用API构建Agent、Agent SDK、Codex harness，到如何观察和治理在企业中运行的Agent，一整套体系。最酷的是，所有harness都统一对齐到了Codex上，这意味着我们在产品和研究之间有了一个单一的、高度杠杆化的接口。模型上做的所有后训练改进，都能自动为每个产品带来杠杆效应。

目前，我们通过插件向Codex注入新能力的方式非常清晰。这些插件就是skills和scripts，本质上还是context和tools。有趣的是，我们最终形成了一种类似IOCTL的可扩展机制，作为Agent构建者和产品构建者，我们能给模型、给Codex的最大杠杆，就是给它越来越粗粒度的工具，这些工具直接连接到我们试图解决的实际业务问题，同时帮它做好上下文塑形和管理。

我和团队还在Frontier上做了另一个令人兴奋的事——企业级上下文管理。我们要搞清楚企业里到底在做哪些工作，数据仓库的数据本体是什么，以及这些数据如何被用来回答指标问题。我们做了很多有趣的实验，比如给企业里的每个Agent配一个“边车”，让它持续管理上下文。这个想法背后是：所有Agent都是Coding Agent，所以我们应该给它们那些对git仓库来说原生的事物——它们可以grep、可以搜索。我们写代码所用的技术，会非常自然地迁移到在企业中构建Agent这件事上，而这一切都来自于使用那个基础的Codex Harness来构建这些agent。

代码可读性：面向人类还是面向Agent

Simon：我们刚才聊到字节码和机器码，那些代码是给机器读的，不是给人读的。后来我们进入了下一代的编程语言，开始更多地为人来写代码。现在，我们是不是又站在了一个新的分水岭上？代码的可读性，到底应该面向人类，还是面向AI Agent？

Ryan：如果非要我只选一样东西对人类可读，我会选系统的参考文档、接口定义，以及用Mermaid绘制的实体关系图、系统图和时序图，这是今天就能做到的。当然，我仍然会往下看机器生成的代码，会看Agent产生的diff。但随着我对Agent的信任逐渐建立，我越来越少地去看那些代码了。对于越来越复杂的任务，我能做到忽略Agent生成的代码细节，不是所有任务，但越来越多。

我发现我和团队能提供最大价值的地方，恰恰在于定义接口、定义系统的组件是什么、每个组件应该如何结构化、以及代码之间如何相互关联。至于这些组件的具体实现，老实说，我可能甚至不知道它们是用什么语言写的。

有个很好笑的故事，我们在开发本地开发流程时，希望Codex能通过Chrome DevTools协议连接到我们的Electron应用，我们一开始用的是MCP。后来我偶然瞥了一眼代码，发现已经彻底变了，Codex仍然通过Chrome DevTools协议连接Electron应用，但实际上是启动了一个本地的TypeScript守护进程，提供一个小型CLI接口，而不是MCP。因为我们发现实际上只需要2到3个工具调用，这样做更节省上下文、速度更快。这一切都在我不知情的情况下发生了，我的工作流完全没有被打断。

Simon：你觉得这很酷还是令人担忧？

Ryan：我觉得震惊，但也觉得很好。这基本上意味着我真实地体验到了那种高信任关系，团队里的某个人想象了一个更好的世界，去实现了它，而且完全没有干扰到团队中的任何人。而且因为写代码的是agent，它们对工具或其结构没有意见。只要我们给它们能用的东西，允许它们完成工作就行。

Simon：在目前的使用场景中，什么情况下你仍然想深入查看代码？

Ryan：如果画一个二维坐标图，横轴是低/高模糊度，纵轴是低/高复杂度，那么在“高模糊+高复杂度”这个象限里，主要对应两类项目。第一类是从零开始做全新的事情：接口的形状、代码放哪里、用户体验什么样，我都还不知道。第二类是最困难的重构：我需要打破或重新定义接口，甚至回退删除代码来实现目标，但我不清楚最终想要的形态是什么。这些是我最投入精力的地方，也恰恰是我最想待的地方。因为这才是预见未来六个月、为团队扫清障碍的意义所在。而且代码在这里是廉价的，我乐意写一个5万行diff的PR然后直接扔掉，只是为了搞清Agent会在哪些地方失败，然后把我喜欢的接口放进去。

每天十亿Token的暴论

Simon：我们来聊聊你之前说过的一句话：“一天不用掉十亿个Token，几乎就是失职。”你这话是想敲打谁？

Ryan：核心想法是：我们能从模型中提取的智能量，在某种程度上与Token消耗量是线性相关的。这在当时很有争议，但现在我们看到它越来越成立。这就是test time compute存在的原因。为了让模型更聪明、产生更丰富的副作用，我们需要把工作流推向高Token消耗的场景。而要达到每天十亿Token，你绝不能只是在跟模型结对编程。你必须找到并行化的方式，必须搭建异步循环，必须构建能对组织和团队产生影响的Agent，而不是只影响你自己。为此，我们发明了一系列模式，从仓库上下文中生成自动化，让团队中每个人都能用，而不是单机模式。

当然，不是说今天喊一声“我要消耗十亿Token”就魔法般地实现了，这需要做大量工作来确保安全、保证输出对齐。现阶段，我们还没有一套持久、可扩展、固化的模式。所以故意抛出“十亿Token”这个挑衅性目标，本质上是逼大家去搞清楚到底什么模式管用。感觉就像我们刚发明了CI/CD的概念，大家都在拼命理解它意味着什么。15年后它才成为标准化、默认标配的东西。现在Agent和软件生产也需要经历同样的过程，我们必须找出那些模式。

Simon：顺着这个逻辑推演下去，如果每个团队、每个开发者每天用十亿Token，那工程团队会变成什么样？

Ryan：我发现拥有一支视角、经验和专长多样化的团队非常有价值。我自己更偏向后端和基础设施，这意味着当团队只有我一个人时，我写的React代码糟糕透顶——有些组件6000行长，一堆糟糕的渲染逻辑，那些`useEffect`钩子里有四层重叠的闭包，极难推理。把能对我说“Ryan，这代码是垃圾”的人拉进团队，帮助巨大。拥有这些全栈团队，我觉得非常有用。

另外，我认为软件工程师不再需要把“编写代码”作为核心技能来培养，我更希望工程师培养的是系统思维：如何为团队的成功创造条件，如何尽可能远地预见未来、解决问题、提升代码生产和交付给客户的速度。现在我的时间分配是30%做最难的重构，30%做从零到一的产品构思，30%跟客户交流、排优先级、安排工作。而以前我大概50%到70%的时间都在写代码。所以我能后退一步，专注于这些跨职能、高优先级的工作流，从而为Agent团队扫清障碍，让它们去完成代码生产的部分。

Simon：最关键的部分是跟用户交流、理解需求，并把这些映射回应用的功能需求，而不是过度思考“应用该怎么构建、实现”，却忽略了“用户真正想要什么”。

Ryan：对，其中一部分是决定不构建什么，现在很多人容易掉进这个陷阱。

Simon：因为编码太便宜了，什么都能建。但我们必须停下来问自己：这个该建吗？因为最终消费产品的还是人类。当我们考虑人类用户实际使用时，我们必须以他们能舒适接受的节奏来开发，这是一个非常有趣的平衡。

访谈视频原链接：

https://www.youtube.com/watch?v=MFQIKbr1IEo