Boris Cherny 与 Jarred Sumner 的现场编码

• 开发者大会上的现场编程 demo。主持词把两位嘉宾请上台：Anthropic 的 Claude Code 负责人 Boris Cherny，以及 JavaScript 运行时 Bun 的作者、现就职于 Anthropic 的 Jarred Sumner（Bun 对标 Node.js，用底层语言写成、需要编译）。Boris 开场定调：「这是一场开发者大会，我们会稍微聊几句，但大部分时间就是直接写代码。」Jarred 预告要讲「Bun 是怎么用 Claude Code 来构建和维护 Bun 自身的」，并提醒「我们这套配置比现在大多数人用的要稍微进阶一些（slightly more advanced）」——定下全场基调：看的不是入门，而是一套打磨过很多轮的高级工作流。话音刚落他就先跑了几个 agent 去修真实 issue，Boris 当场调侃：「这就是典型的 Jarred——演讲的同时还在干活（classic Jared doing work during a talk）。」 → 详细

• 在 Bun 仓库里，每当有人提交一个 issue，一个叫 RoboBun 的 Claude 机器人就会自动运行，去尝试复现这个问题。Jarred 现场点开一个最新 issue（用户遇到某种「副作用」问题），指给观众看：RoboBun 已经成功复现了它、并自动提交了一个 PR。他特意强调这条流程是无差别覆盖的：「在 Bun 的 issue tracker 里，每一个上报的 issue，都会先由 RoboBun 自动尝试复现，然后才轮到人去看。」也就是说人看到 issue 之前，机器已经先把「能不能复现、要怎么修」跑过一遍了。 → 详细
• 所有 RoboBun 的 PR 都强制带测试——Jarred 的原话是「所有这些 PR 都一定带测试，这是它提交 PR 之前的一个硬性要求（one of the actual hard requirements）」。他把这里的真正难点点破了：代码自动生成出来之后，问题不再是「能不能写」，而是「这段代码看起来对不对（does this code look correct）」——也就是说，当「写」变得几乎免费，瓶颈立刻挪到了「判断对不对」。 → 详细
• 而验证机制写得非常具体、可证伪：同一个测试必须在 Bun 的旧版本里失败、在这个调试分支里通过。这等于用一个「红→绿」的对照实验证明「这个测试确实抓到了这个 bug，而这次改动确实把它修好了」——光「测试通过」不够，必须是「在没修的版本里它会挂、在修了的版本里它才过」，才说明测试真的咬住了 bug。Jarred 强调这是一道闸门：「如果不满足这个条件，机器人根本没法提交 PR（the bot actually can't submit a PR without that being the case）。」 → 详细

• 因为 Bun 有非常多未关闭的 issue，这套自动化省下大量时间，并把工程难点整体搬了家：「它实际上把难点从『修复和调试 issue』转移到了『这个东西该不该合并（is this the right thing to merge）』。」Jarred 把这个新难点拆成一串具体的判断题：「这是正确的修复吗？质量怎么样？它完成了你 100% 的工作，还是只有 10%？」——注意这三问全是「价值/品味」层面的判断，而不再是「代码写没写出来」的执行层问题，这正是难点搬家后的新形态。 → 详细
• 然后他现场拿出了那个最有冲击力的数据。操作路径很具体：打开 GitHub 的 Insights → Contributors，把范围选成最近三个月、并专门看 main 分支——结果是「RoboBun 现在对 Bun 的贡献量已经超过我了（Robbun is now a bigger contributor to Bun than I am）」，全场大笑。他立刻补了一句把这个数字坐实而非吹大的限定：「而且这还是在它的 PR 并没有全部被合并的情况下（that's with merging not all of its PRs for sure）」——也就是说，即便砍掉那些没被采纳的 PR，机器人的净产出仍然压过了 Bun 的作者本人。这条数据是全场「机器产量碾压人」最硬的一个证据。 → 详细

• Bun 还配了自动跑的代码审查机器人。Jarred 现场展示这个画面时自己都乐了：「CodeRabbit 留一条评论、RoboBun 回一条，它们就这样来回拉锯……我太喜欢这个了（I love this）。」处理完之后机器人还会把评论标记为「已解决」（marks the comments as resolved）——不是留完言就不管了，而是真的把每一条意见跟进到关闭。一个 PR 里这种来回评论能有 30 条（30 comments or something）——本质上是两个 AI 在同一个 PR 上互相挑刺、互相回应，直到把彼此的意见全部消化干净，整个过程几乎不需要人插手。 → 详细
• 两类审查的分工是错开的，各有所长：CodeRabbit 擅长「风格类问题，以及确保代码遵守 CLAUDE.md」（守规范、守约定）；Claude 的代码审查擅长另一类——Jarred 描述得很具体：「它特别擅长发现那种非常微妙的边界情况（really subtle edge case），那种我得花 30 分钟读完所有代码、掌握全部上下文才能搞明白的问题（would have taken me like 30 minutes of reading all the code and having all the context to figure out）。所以它特别擅长把那些需要完整上下文才能真正理解的 bug 挖出来。」一句话：CodeRabbit 管「表面合不合规」，Claude 管「深层逻辑对不对」。 → 详细
• 两人觉得这种「两个 AI 互相审、互相驳」的模式值得有个名字。Boris 当场提议：「我们应该给这种模式起个名字，比如『对抗式代码审查（adversarial code review）』之类的。」（adversarial——让两个 agent 站在对立面互相挑错，而不是一个 agent 自说自话。） → 详细

• 关键在于 Claude 真正参与到回路里（in the loop）：它不是「装样子地回复」，而是真的在动手修。Jarred 把这点说得很重：「如果没有 Claude 参与到回路里的代码审查，这整套自动化其实很难真正跑起来——它不只是『装样子地回复』（very performative），而是真的在修（at fixing）。」过去 PR 耗时的元凶是上下文切换成本（switching cost）：「以前 PR 之所以要花那么久才能合并，是因为你得在本地 checkout 那个分支、修一个 lint 错误、再在本地跑一遍 linter，然后再推回去」，「这中间一直有大量的上下文切换成本（all this switching cost that's constantly there）」——把这一串来回切换自动化掉，正是省时间的大头。 → 详细

• 为什么 Bun 特别适合这套打法？因为它是系统级代码（systems code，贴近 OS 底层、不依赖图形界面）、又是命令行工具（CLI），「我们测试东西不需要跑浏览器」，复现和验证都很轻——每个 issue「本质上就是某个特定架构上的一个测试用例，你基本上能复现或验证任何东西」（前端类的可以「配置一些东西去截图、录视频」来验，「但在 Bun 的场景里我们暂时还不需要」）。更可推广的一点，Jarred 主动替「不开源、没 GitHub issue」的公司想了出路：「因为大多数产品并不是开源的，所以起点也许不是 issue，而是一张客户支持工单（customer support ticket）」——「把客户支持工单自动转交给一个 Claude 机器人，让它去复现问题、提交 PR，然后让代码审查来回拉锯」，他认为「对很多公司来说，这就是它影响力大得多的地方（a lot more impactful）」。 → 详细

• Jarred 明确泼冷水：照搬表面流程跑不通。「如果你只是简单地这么做，其实不太行（if you just do this then it doesn't quite work）。你需要的第一步，是确保开发环境配置好了。」紧接着点名 CLAUDE.md（放仓库里、给 Claude 读的项目说明）：「CLAUDE.md 真的非常重要，否则它就会提交一些你看了根本不想合并的 PR。」 → 详细
• Bun 的 CLAUDE.md 里有一条关键约定：用一个专门命令做构建。这个命令「既会构建、也会运行——它会把参数透传过去」，这么做是为了堵一个特别容易踩的坑：「因为 Bun 是需要编译的，你得确保它跑的是真正改动后的版本，而不是某个已经过期的 debug 构建。」大白话：改了源码却忘重新编译，跑的还是旧二进制，测试结果全是假的——这条命令就是防这个的。文件里还「非常详细地写了怎么跑测试、怎么写测试、测试该放哪里，以及大量『我们之前踩过的所有坑』」。 → 详细
• 核心模式（全场最可操作的一条）：「每当你发现自己在重复某件事，它大概率就应该写进 CLAUDE.md（every time that you find yourself repeating something it should probably go in cloud MD）。」Jarred 给了具体闭环：「你让 Claude 写一个测试，测试写得不好、或者有什么地方不对，你看到这种情况重复出现一两次之后，就直接告诉 Claude『把这条加进 CLAUDE.md』，这样以后每次写测试，它第一次就能写对。」还有个很微观但实用的技巧：「为了确保 Claude 能看到错误信息，我们让它把错误信息打印在那些信息量较少的内容之前（print the error message before the less informative conditions）」——因为模型读日志也有「注意力」，把关键报错往前放，能保证它一定看得到。 → 详细

• 「把每次踩坑的经验沉淀进 CLAUDE.md、让系统越用越顺」这套做法有个名字叫 compound engineering（复利式工程——像复利一样，每一次积累都让下一次更省力）。Jarred 补充，光有规则不够，给 agent 一份地图也很重要：「给它一份『所有文件夹在哪、代码整体怎么组织』的概览（an overview of where all the folders are, how the code is laid out）也很有帮助」，以及「关于依赖关系」的说明——让 agent 一上手就知道东西都在哪、谁依赖谁，而不是每次都现摸。 → 详细
• 更关键的是让 agent 能读 CI 错误和构建日志（CI = 持续集成，每次提交后自动跑构建和测试），从而跑完一整圈闭环。Jarred 把这一圈列得很完整：「你希望把 agent 配置成能读代码、能跑完整个回路——写代码、测试代码能不能跑通、检查 CI、监控 CI、读完所有错误（writing the code, testing the code works, checking CI, monitoring CI, reading all the errors）。」目的是把人从苦力里解放出来、只留判断：「这样等它交到人手上时，一切都已经就位。理想状态是：你读一遍代码，就有非常清楚的信号让你高度确信可以合并它（very clear indications that you can be high confidence to merge it）。」最后他点出唯一前提：「而要做到这一点，唯一的办法就是把它配置成『为成功而设』（set up for success）。」 → 详细

• Boris 回忆很早提过一个愿景、当时 Jarred 没听懂：「我记得我们第一次见面时，你就在讲你的愿景——每个人都能并行跑上百个 agent（everyone being able to run hundreds of agents in parallel）……我感觉我当时其实没真正理解。」而现在这成了 Jarred 的日常：「但现在我每天晚上真的会跑上百个 agent，我感觉自己终于到那个状态了。」他点出能扩到这个规模的技术前提：「你需要自我验证机制（self-verification），agent 才能自主运行（run autonomously）」——没有自动验证，人就得盯着每个 agent，规模上不去。他还回顾演化起点有多简陋：「这套东西在 Bun 的代码库里经历了很多次迭代。我们以前只是有一个 Discord 机器人，我 @ 一下它，它就会拉起一个容器（spin up a container）。那时候它还没有 CI 那一块，也没有代码审查那一块。」 → 详细

• 从「只会拉容器」的 Discord 机器人到今天，最大的变量是模型。Jarred 说「现在好太多了，尤其是有了 Opus 4.7」，Boris 给出更强判断：「4.7 是第一个真正让人感觉『它能做到这件事』的模型。」并对比之前的窘境：过去也许能靠脚手架（scaffolding，为让弱模型勉强工作额外搭的辅助代码和提示）做到——「往里塞一大堆 token，它勉强能跑」，但「现在它已经足够高效了，你真的可以每天都这么干」。Jarred 反复强调时间线近得惊人：「这在 6 个月前绝对做不到。3 个月前也不行。」他也坦承这对工程师是种新痛苦：「最难的是模型变得很频繁，我得不断重新调整、重新校准对『它能做什么』的认知……它是一种非常奇怪的技术，是我用过的第一种这样的技术。」 → 详细

• demo 中途 Boris 现场举手统计观众的开发方式：第一问「你的流程是不是开一堆终端窗口/桌面标签页、手动把 issue 粘进去」——「大概一半的人」举手；第二问「有没有人更像 RoboBun 那样把回路闭合得更多」，举手寥寥，Boris 定位为「下一层抽象（the next level of abstraction）」。说明闭环自动化在当时（哪怕在 Anthropic 大会观众里）仍是少数派前沿玩法。被问「看到一个 PR 你怎么审」，Jarred 给的是按复杂度分流：「通常取决于它有多复杂。」对眼前这个他判断「这个其实挺简单的，我相当有信心，只要测试通过我大概率就会合并」，但仍补一道保险：「我还是会等代码审查——至少会等 Claude 那个跑完，以防万一」，因为 Claude 能找到「不在 diff 里、要靠追踪控制流（tracing the control flow）才能发现的问题」。可信度上他给了量化信噪比：「大概只有 10% 的时候它是错的」，而别家审查产品「基本上你得无视它说的大部分内容」——别家 90% 是噪音，Claude 审查 90% 命中，这正是值得每次等一等的原因。 → 详细

• 全场技术含量最高的案例。Jarred 让 Claude 在一台单独的 Linux 机器上跑性能基准（benchmark），目标是让 Bun 新加的图像处理比业界标杆 Sharp（Node 生态里最流行的图像处理库）更快。他强调投入极少：「我跟它说『让它比 Sharp 更快（make it faster than sharp）』，我基本上就做了这么点事。」只额外给了几个方向性提示：「比如『你可以去读一下 JavaScriptCore 里的这段代码，搞明白怎么在并非严格必要时避免克隆 TypedArray』。」（JavaScriptCore 是 Bun 底层用的 JS 引擎；TypedArray 是存二进制数据的数组，少复制一次就少一份开销。）结果：「它就真的去做了，并且把它搞定了……说实话挺疯狂的，因为这些东西在几个月前根本都跑不起来。」 → 详细
• Boris 给这种打法贴上 AI 实验室内部术语：「在 Anthropic 内部、在一个 AI 实验室里，我们把这种事叫做 hill climbing（爬山）。」并解释机理：「如果你给模型某个指标，再给它一个验证结果的方法，你就能让它不断迭代、一直跑一直跑，直到它达到那个指标（give the model some metric and a way to verify its result, you can just make it iterate and keep going until it hits that metric）。」（爬山——像蒙着眼往山顶走，每一步摸一下「是不是更高了」，靠这个反馈逼近最优。）他认为这是 4.7 被低估的强项：「这是 4.7 格外擅长的一件事，而且我觉得它被严重低估了（really underutilized），因为它是第一个真正很擅长这件事的模型。只要你给它一个目标、给它一个提升性能的途径、再给它一个衡量的办法，让它在 auto mode 里跑，它就会一直跑到把事情做完为止。」 → 详细
• 另一个佐证「人几乎不用盯」的例子：有一个 PR 里「大概有 100 条评论，它就一条条地去把所有问题都修掉」。而 Jarred 当时投入度低到——「这件事并不是我 100% 专注在做的，我大概只有 10% 的注意力在上面，我是同时在做五件事（maybe like 10% focused on this, doing five things at once）」。100 条审查意见自动闭环、人只分 10% 心神，这就是「闭环自动化」省力的直观画面。 → 详细

• Jarred 澄清：除了 RoboBun 修小 issue，他最近还亲自用 Claude Code（而非 RoboBun）做了一些挺大的 PR——最典型的是「给 Bun 加了一个内置的图像处理库支持——那是 Claude 做的，我们后面还做了一堆后续 PR」（即上节「比 Sharp 更快」案例的来源功能）。他一口气数了过去两周用 Claude 完成或在做的重活：HTTP/3 服务器、HTTP/2 服务器 PR、HTTP/3 和 HTTP/2 的 fetch 支持、图像处理 API，以及正在进行中的 Rust 重写（「不一定会真的发布」）。他对 Rust 重写既骄傲又克制：「那是我到目前为止做过的最有野心的一个，不过『做过』用得太重了，因为它远远还没做完。」Boris 给 Jarred 的整套打法下了很高评价：「你做这件事的方式，其实比 Claude Code 团队自己开发 Claude Code 的方式还要超前」，并形容它「几乎就像是『完全起飞』、完全闭合的回路（full liftoff, full fully closed loop）」。 → 详细

• Jarred 摊开了真实配置：「我主要是用 CLI（命令行界面），权限一直用 auto mode（自动批准模式）。」被问到 auto mode 之前用什么，他爆了个有现场效果的料：「在那之前我用的是 --dangerously-skip-permissions（直译『危险地跳过权限』）。」全场笑，他赶紧自我纠正、当场打免责声明：「不行，你们用那个是会删掉东西的（you can delete stuff if you do that）。我……我觉得我不该推荐那个。」 → 详细
• auto mode 解决的痛点很具体——人不用再当「批准按钮的人肉中继」。Jarred 描述了那个让人抓狂的旧体验：「等着给 Claude 按『批准』实在不爽，因为你一转身去做别的事，回来发现它就一直干等在那儿（it's just been sitting there）。」他点出 auto mode 的价值是「真正解决了这个问题，而不只是『全靠信任』」——它不是「闭眼信任」，是把人从「一步一确认」的人肉环节里彻底拿掉。它带来的直接结果就是超长自主运行：「在 auto mode 里，我可以让 Claude 一连跑好几个小时（for hours and hours at a time）。我几乎每天晚上都这么跑，就挂一堆 Claude 在 auto mode 里跑着（a bunch of quads running in auto mode）。」而现场这整场 demo 本身就是最好的证明：「这整件事就是一个 prompt，然后它就一口气跑了 30 分钟（this entire thing was one prompt and that just ran for 30 minutes）」，他补充「我说的就这么多（this is all I said）」。对比之下，auto mode 之前「它根本跑不通，因为它总会卡在某种权限请求上（always got stuck at some kind of permission request）」——一卡住就得人回来按一下，根本不可能挂着跑一晚上。 → 详细

• Boris 注意到 Jarred 屏幕上输入框（composer）固定贴在屏幕底部，由此引出 no flicker mode（无闪烁模式）。Jarred 用得很满意：「说实话我觉得我们干脆该把它设成默认，因为它好太多了」，并现场演示体验差异：「你能看到我可以飞快地滚动——以前你也能滚得快，但有时会有闪烁，现在没有了」。Boris 自曝它差点被当成玩笑：「我们是在愚人节那天上线它的（we launched it on April Fools），现在回头看，它当时确实有点像个玩笑」，但正色给了实操建议：「如果你真的去用 Claude Code，把 no flicker 设成 1 就对了——你只要设一下那个环境变量就行。」这个功能背后是一次彻底重写：「我们彻底重写了 CLI 里跑的渲染器，所以它现在用的是虚拟化滚动、虚拟化选择」（虚拟化——只渲染屏幕上看得见的那部分，无论历史多长开销都一样），带来两个硬好处「内存占用恒定、CPU 占用恒定」，还有个意外彩蛋——鼠标在终端里能用了：「Jarred 打字时真的可以在 composer 里点来点去……这对一个终端来说挺疯狂的」。 → 详细

• Jarred 直接给出「当下瓶颈在哪」、且强调它是新出现的：「现在真正的瓶颈是：我对合并这个东西放心吗？我有信心它的改动是对的吗？（do I feel good about merging this?）这是个新情况，因为以前是代码本身还不够好。」对大多数简单 issue，他认为应更激进合并：「对于大多数简单的 issue，我们其实应该更多地去按下『合并』。」眼下卡住的是工程基建那层：「现在的瓶颈其实是 CI——是确保代码完整跑起来、确保所有测试都正常。」破法他给了两个方向：「我们怎么确保能传达出『足够的证据』来证明改动是正确的；或者让回滚变得更容易」（前者降「合并前」判断成本，后者降「合并错了」纠错成本）。他把整套思维提炼成本主题的题眼：「Claude Code 促使你思考的方式是：每当出现一个新瓶颈，你就得把那个瓶颈自动化掉，然后总会冒出另一个瓶颈，你再去攻它（every time there's a new bottleneck, you automate that bottleneck, and there's always some other bottleneck after）。」并把迁移链一节节数出来：「一开始『写代码』是瓶颈，现在不再是；然后『验证、跑测试』是瓶颈，现在也不再是；现在大概是更深一层的验证」——再往后他预判下一个瓶颈是「规划（planning）——该做什么、不该做什么，以及修复这件事的正确方式是什么」。 → 详细

• RoboBun 目前只修 issue、不做功能需求（doesn't do feature requests yet）——但这条线不是死的，功能开发可走「人工 @ 触发」的旁路：「我们也可以在 Discord 或 Slack 里 @ 它，它就会尝试去实现那个功能。」真实场景：「有时候别人说『嘿，Bun 少了这个东西』，我就直接 @ 那个机器人，大概一个小时后就有一个 PR 了。有很多次有人在 Twitter 上 @ 我说『能修一下这个 bug 吗』，我基本上就是这么干的，然后回复一个 PR 的链接。」两人还冒出个玩笑：「我们要不要给 RoboBun 开个 Twitter 账号？」但 Jarred 对「照单全收所有功能请求」有明确顾虑，理由落在「工程品味」：他「对『让它把任何人在 GitHub issue 里要求的所有东西都照单实现』这件事有顾虑，因为那有点太多了」。他用「把图像处理库塞进 Bun」这个自己刚做过的决定反思：「某种程度上，把图像处理库这种东西塞进 Bun 里，本身就有点疯狂——但我们一直在谈『工程品味（engineering taste）』，这里面是有品味成分的。」核心疑问：决定「一个运行时该不该内置某个能力」是个有品味的取舍，而「我们还不确定 Claude 是否已经到了『会和你一样认为这是个好主意』的程度」——不过他乐观补一句：「未来某个时刻它会到那一步，也许已经开始接近了。」 → 详细

• 两人共同得出一个对团队协作很有冲击力的判断：「PR 正在变成『建议』（PRs become suggestions）。」Jarred 解释背后的心理学差异：「以前不合并一个同事的 PR，你会有负罪感，因为他们投入了工作；但当它是 Claude 的时候，你就不必有负罪感。所以如果一个 PR 是错的，或出于任何别的原因，你直接不合并就行。」反直觉的二阶效应是门槛不降反升：跟人合作时「你不希望别人因为白费的工作而难受」，这份体谅会让你倾向放行同事的 PR；可一旦 PR 来自 Claude、不再需要这份体谅，「某种程度上，这其实反而抬高了你决定合并什么的门槛（raising the bar for what you decide to merge）」。Boris 把它上升到团队信任结构的变迁：「随着瓶颈的转移，这里面的动态也跟着变了一点。这有点像从『彼此信任、信任团队里的人』，变成『我们有没有正确的自动化？以及我们作为一个团队，信不信任这套自动化？（do we have the right automation, and do we trust automation as a group?）』」 → 详细

• 现场这套 agent 带「巡检」逻辑：它会自动监控 PR，「跑了一些命令，然后它会睡 20 分钟再醒来（go to sleep for 20 minutes and wake back up）」，靠某种循环（a loop）持续盯着。Jarred 顺口吐槽间隔：「20 分钟可能有点太长了，不过没关系。」时间到点时两人盘了战果：「过了 25 分钟，我们一共拿到了三个 PR」，Boris 评「不错」，期间还「顺手多修了一个 bug」，而 RoboBun 仍在后台「还在生成更多的 PR」。收尾时第 4 个 PR 也压线完成，Jarred 实况解说它最后那段「自我纠错」：它「正在攻最后那第四个 PR，来来回回地：发现一个 bug，然后修掉一个 bug……看起来它现在就要提交 PR 了」，他顺势判断「这个修复听起来也对」。最后他点开对应 issue 看热度：「这是一个开了很久的 issue」，赞数 20 个——Jarred 说「挺多的」，给这场 demo 收了个有分量的尾。 → 详细

本视频没有正式的闪电问答环节，收尾部分是 Boris 对工程未来的展望，以及两人对「现状」的坦诚交代：

• Boris 的收尾陈词把这场 demo 抬到了「行业先行者」的高度：「对我来说，这真的是一幅很酷的图景——工程未来的走向（such a cool vision of where engineering is going），我觉得对在座每个人都是。而且你知道，我们会最先看到这一切，我们得先把它摸索明白，然后其他所有人也都得把它摸索明白（we're going to see this first, we're going to have to figure it out first, and then everyone else is going to have to figure this out）。」 → 详细
• 两人没有把话说满，反而强调「还在路上」：「你也能看到，我们还没把所有事情都搞明白（we haven't figured everything out yet）。但我觉得我们现在所处的状态，就是不断地实验、不断地去找下一个瓶颈是什么，好把它解决掉（constantly experimenting, constantly trying to see what the next bottleneck is so we can solve it）。」demo 在「这太酷了」的感叹和掌声中收尾。 → 详细