: 首页; 看点啥; 插画图片

首页热点时事严禁手写代码:一天烧不完 10 亿 Token 就是失职：OpenAI 工程师揭秘“零人类编码”的激进实践 | B...

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

2026-06-14 0

原创冬梅 2026-06-13 13:30 北京

Harness Engineering，这个词最近在开发者圈子里引发了激烈讨论

编译｜宇琪

策划｜冬梅

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

声明：本文为 InfoQ 编译，不代表平台观点，未经许可禁止转载。