Anthropic 的 Addy Osmani：一天合并三万次代码变更，人看的是 AI 交上来的证据

Anthropic 今年 5 月每天往代码库里合并大约 2500 次代码变更，到 9 月已经超过 3 万次，涨了十几倍。这么多改动，显然不可能每一行都有人看过。那他们凭什么敢合并？

负责 Claude Code 开发者体验的 Addy Osmani 在这场对谈里讲了他们的做法：每个改动先由 Claude 像真实用户一样实际用一遍、审一遍，发现问题自动修；人不再逐行读代码，而是去看 AI 交上来的证据，比如它在浏览器里点来点去的录屏、在手机和电脑上的截图。

在他看来，写代码已经不是难点，接下来能不能再快一截，取决于能不能把“验证”做扎实。给 AI 一个检查自己做得对不对的办法，产出的质量能好两到三倍。如果你也在用 AI 写代码，又拿不准哪些改动敢直接合并，这期给了一份大公司内部的参考答案。

这是 AI Engineer 大会上一场 18 分钟的台上对谈。Addy Osmani 在 Google 工作了大约 14 年，长期负责 Chrome 的开发者体验，写过大量面向开发者的文章，今年 9 月加入 Anthropic。提问的 Manish Kapur 在 Sonar 负责产品和开发者关系，Sonar 是做代码质量和安全检查工具的公司，旗下的 SonarQube 用来自动扫描代码里的漏洞和问题。

【Anthropic 的做法：Claude 先审一遍，人看证据】

Manish 提到，他前一晚刚读了 Anthropic 发的一篇文章，里面说 Anthropic 现在每天合并约 3 万次代码变更。Addy 补充了两个数字：5 月的时候每天大约 2500 次；最近 https://t.co/aTfkxmbzQe 网页版重做，性能提到了原来的三倍左右，这次重做在很短时间里合并了大约 3000 个 PR（代码合并请求），参与的不只有工程师，还有产品设计师和其他岗位的人。

他说他们的审查流程分几步。第一步是让 Claude 先审一遍，关键在于要让它能像真实用户一样把功能实际用一遍：跑端到端测试（从头到尾模拟用户操作的自动化测试），在浏览器里打开页面检查，运行各种工具和代码规范检查，凡是能建立信心的检查都做。

发现 bug 或者功能缺口怎么办？他们设置了 Hook（一种在特定时机自动触发的脚本），每次代码有改动就自动运行，检查这次改了什么，这样 PR 里的问题能尽快被改掉。Anthropic 还有一个代码审查产品，他们自己也在用。整体思路是尽可能把代码审查自动化。

第二步是把团队的“品味”写下来。Addy 说现在大家常讲品味和判断力，团队应该把自己认为的最佳实践和品味写进共享的 CLAUDE.md、AGENTS.md 这类文件（放在项目里、专门写给 AI 看的说明文档），AI 审代码时会去参考。

第三步才轮到人，人负责检查 AI 给出的证据。他举的例子是：做一个用户在浏览器里用的界面，就要确认它在浏览器里测过，最好让 AI 生成一段它点来点去的录屏，看完你就有信心说“这个能用”；在意手机或桌面端的体验，就让它给出这些设备上的截图或录屏。他说目标是让 AI 尽可能多地提供验证证据。

【瓶颈从写代码转到了验证】

Manish 给了几组数字说明问题。持续集成服务 CircleCI（代码提交后自动构建、测试的云服务）今年分析了 2800 万次自动化流程，发现代码产出量涨了 59%，但每 10 次往生产环境合并的尝试里有 3 次失败。Sonar 即将发布的一份调查里，76% 用 AI 生成代码的开发者说，代码产出的速度快到他们根本来不及验证。

Addy 说，现在技术负责人最关心的是怎么在保证有信心的前提下更快上线。过去我们说一段代码质量高，依据是好的测试、性能基准、需求规格，这些能给人信心的东西现在都可以让 AI 便宜又快地生成出来，人再去修改完善。他认为工程师现在最该花时间的就是这些检查。

至于下一步的提升从哪来，他说模型质量已经相当不错了，他举了 Opus 5.5 为例。更大的空间在验证，而且要讲具体。你跟人说“验证一下”，对方下一个问题就是“验证到底指什么”。所以讨论应该落到哪些测试真正有用上。Anthropic 用得最多的是三类：端到端测试；属性测试，也就是不写一个个具体例子，而是写一条规则（比如“排序后列表长度不变”），让程序自动生成大量随机输入去验证；还有视觉验证测试，通过截图对比检查界面有没有变样。目标是有足够的信心让这些改动自动合并。

Manish 从 Sonar 的角度补充了一个“多层验证”的框架，主张零信任，在每个环节都验证。第一层是规则固定的自动扫描，查 SQL 注入这类安全漏洞和常见 bug；第二层是 AI 审查，查规则扫不出来的逻辑问题，以及代码是否符合本来的意图；第三层是软件供应链检查，看项目依赖的第三方代码包里有没有已知漏洞或恶意代码。每一层专门抓一类问题。

【从“亮灯工厂”到“熄灯工厂”，自主权要一步步挣】

对谈的标题里有个说法叫“软件工厂”，来自 Addy 今年写的一篇文章，他的定义是“把循环规模化”：让 AI 一遍又一遍地规划、编写、检查、上线代码。他把软件工厂分成两种。亮灯工厂里，AI 承担这些步骤，但人还在里面，用自己的判断和品味把关。熄灯工厂更像全自动的汽车厂，机器人一直在干活，人退到更上游，只负责定方向，只有遇到最特殊的例外情况才被叫进来。

他说大多数团队处在两者之间，都在摸索怎么在信得过的前提下一步步提高自动化程度。AI 能给出的验证越多、越让人有信心，就越能往熄灯的方向走。Sonar 的调查显示，目前只有 5% 的公司在用软件工厂，预计会涨到 34%，金融行业是 39%。被问到 2027 年底大多数团队会是哪种工厂，Addy 的判断是：亮灯工厂为主，带着一些熄灯的角落。

自动化程度高了，管控就成了企业的难题。Addy 说，几个月前他接触过的很多公司都在担心同一件事：放手让工程团队用 AI 智能体，结果冒出了几百甚至几千个智能体，谁也不知道它们在干什么，它们访问各种系统和数据，可能还在往生产环境部署。他总结企业最关心三件事：怎么控制、怎么分配权限、怎么用沙箱（隔离的运行环境）保证智能体不越界。

AI 写的代码要不要在 PR 里标出来？Addy 认为应该。过去工程师对自己写的代码有很强的归属感，在 Anthropic 大家没那么在意 Claude 被署名为作者，更看重给用户交付的东西对不对。标出来还有一个用处：知道是 AI 写的，就能决定要加哪些额外的约束和检查。Manish 也同意，他认为至少未来半年到九个月里应该标注，对金融客户来说还关系到审计。两人都强调责任归属不变。Addy 说，就算这次是我让 Claude 去干的活，出了问题还是我负责，还得我去修。

那 AI 开的 PR 什么时候能放心合并？Addy 的回答是：你有充分的信心不会出问题，或者已经尽可能把风险降下来的时候。

快问快答里，Addy 还给了两条建议。对技术负责人，要推着团队想清楚“验证”具体指什么，现在的测试做到了哪一步，离“AI 自己判断代码可以合并、你也放心”还差什么。对刚入行的开发者，多积累各种测试的经验，端到端测试、属性测试都要会。

【不逐行看代码，和不验证是两回事】

Anthropic 一天三万次合并，人显然也没有逐行看，但按 Addy 的说法，每次合并之前 AI 都得先把功能实际跑一遍，再把证据交给人看。省掉的是读代码的时间，验证一步都没少。

他们能这样做是有前提的。

一是模型，Addy 自己提到 Opus 5.5 这一代已经够好，我也是用上 Fable 和 Opus 5.5 之后才放心不怎么 Review。

二是验证的基础设施：端到端测试、自动录屏、每次改动都触发的检查，这些都得先搭好。

为了扛住这个量，据 Anthropic 10 月发的工程博客，他们连 Git 都换成了自己开发的版本管理系统。这样的投入，大多数团队一时做不到。

所以我的建议是，想少看代码，别先急着把 Review 关掉，先补上 Addy 说的那一步：让 AI 交活的时候附上证据。如果不知道从哪里下手的话，可以从最容易出问题的界面开始，要求它在浏览器里实际操作一遍，给你截图或录屏。证据还是要你自己看，只是看录屏比读几百行代码快得多。

另外，Manish 讲的三层验证框架可以参考，不过 Sonar 本身就是卖代码检查工具的，听这部分时心里有个数就行。

视频来源：https://t.co/NAnM2wC9wj