架构师（JiaGouX）
我们都是架构师！
架构未来，你来不来？
一条 Claude Code CLI 的 PR，夜里由 Agent 反复评审、修改，转了五十多轮。评审器提问题，修复 Agent 改代码，改完再送回去看。最后是作者把它停了下来。
评审器还能继续找，修复 Agent 还能继续改，该由谁来喊停？
2026 年 6 月到 9 月，Claude Code 代码库合并的 PR 数量翻了一倍多，需要回退的 PR 占比下降了 40% 以上。这是同期的整体变化，不能归功于某一条评审规则。
前几天写《AI 写代码越来越快，研发交付系统该怎么演进？》时说过，代码写得快了，变更审查会排队。Claude Code 团队遇到的更具体：写代码和看代码的都可以是 Agent，如果没人管评审的范围和轮次，一条 PR 就能在原地转一整夜。看看他们现在怎么让一条改动走到合并，也看看人在哪些地方还得出面。
开 PR 前先跑一遍
Claude Code 团队把第一轮检查放在 PR 之前。作者让 Claude 跑测试、构建；如果改了界面，就拿截图和设计稿对一对。Claude 要交出运行结果，不能只回一句“做完了”。
接着再开一个上下文全新的子 Agent 看 diff。它没见过前面的修改过程，只能自己读代码、找问题。团队里不少人开 PR 前还会跑几个内部 Skill：一个找 Bug，一个精简改动，一个把功能从头到尾走一遍。
编译没过、界面不对，在本地就能发现。等 CI 在 PR 里报出来，作者还要再推一次提交，再等一轮检查。验证提前到开 PR 之前，少掉的就是这一来一回。
图 1：一条 PR 从开 PR 前到发布后经过的检查；自动检查先处理可验证的问题，风险高的批准交给人。
PR 里，谁查什么
PR 打开后，CI、代码评审和安全评审都会跑。一个 CLI PR 的 CI 可能有几十项检查，包括 lint、类型、各平台测试和构建。
代码评审查的是另一回事。它带着 PR 想解决的问题，到整个仓库里读这次 diff：修 Bug 有没有找到根因？改了这里，会不会碰坏别处？几个 Agent 同时找 Bug，另一组 Agent 再对每条发现投票，认可的够多，才会发成评论。代码风格、诊断信息、顺手清理这类意见会被过滤掉。安全问题另有一套自动评审。
他们还让代码 Owner 写 REVIEW.md，告诉评审器这块代码最怕什么。好的 REVIEW.md 都很短：评文档，要看内容有没有写错；评配置，要看会不会路由错。评论必须给出文件和行号，不能凭名字猜。
举个配置路由的示意例子，下面这行不是 Claude Code 的源码：
const target = routes[tenantId] ?? routes.default;tenantId 是 acme，配置里却没有 acme，请求就会走 default。类型检查能通过，测试如果只查“有没有拿到 target”，也可能是绿的。可 acme 到底能不能走默认路由，光看这一行判断不了。评审器还得查项目的路由约定、相关测试和这次 PR 想解决的问题。确认有问题，评论写明触发条件和代码位置；默认路由本来就允许，这条评论就带着理由关闭。
CLAUDE.md 写着项目的技术栈、约定和目标，每次评审都会加载，违反约定的代码会被评审器指出来。Boris Cherny 提到，团队共用一份入库的 CLAUDE.md，看到 Claude 做错了什么，就补进去。
评审器反复指出同一类问题时，他们从源头改：调整 Skill，加 lint 规则，或者补进 CLAUDE.md、REVIEW.md。
评论要有结果，复查要能停
评审器找到问题后，会标成 Important、Nit 或 Pre-existing。最后一种表示问题原来就有，不是这条 PR 新带进来的，免得它看起来像作者的错。代码评审或安全评审留下的发现，都要有处理结果：修掉，或者说明理由后关闭。没处理完，PR 不能合并。常有 Agent 在夜里接手修复，作者回来时，PR 已经又过了一轮。
问题出在“修完再审”的循环上。开头那条 PR 就这么转了五十多轮。团队后来用 git blame 回看评审器反复指出的代码，约 59% 在它第一轮查看时就已经存在。评审器很少找到新 Bug，每轮多挖出几个旧的，修复 Agent 跟着改，下一轮又来了。对人来说，一条 Nit 几秒钟就能略过；Agent 可能按它改代码，推一次提交，再触发一轮评审。
团队自己也推了一把：他们习惯默认多跑几轮，觉得每轮总能多抓到一点。这对高风险改动可能值得，对每条 PR 就不一定了。
他们随后改了复查办法。前几轮之后，只复查新增的 diff；同一类问题一次指出，让作者把同类写法都改掉，不是只改一行；已经发过的评论不再重复。还加了一条上限：三轮之后，评审器请作者退一步，重新考虑改法。
旧代码的问题也没被放下：评审 Agent 每晚还会扫描已有代码。把这件事和 PR 复查分开，就不必指望一条 PR 顺手清完仓库里的旧账。
图 2：前几轮之后只复查新增 diff；三轮之后仍没通过，就由作者重新判断这条 PR 的改法。
调整后，团队统计的内部 PR 里，一轮评审加修复就通过的，从 65% 升到 78%；需要五轮及以上的，从 8.9% 降到 1.5%。这是整套调整前后的数字，不能拿来算某一条规则的单独效果。
《Claude官方教你用 Loop：如何让Claude Code上夜班的四个交接点》里讲过，单个 Agent 的 loop 要先写好停止条件。这条 PR 里两个 Agent 都在干活，PR 本身却可能原地打转，所以停止条件要放在整条 PR 上，不放在某一个 Agent 上。
人在什么时候看
Anthropic 给这套流程定了目标：Claude Code 各仓库里的大多数 PR，合并时至多有一个人参与，这个人可以就是作者。前提是回退和事故不能增加。他们统计每个 PR 的人工批准数、人工评论数和 PR 等人的时间，回退和事故率是护栏：这两项一涨，省下的人工时间只是挪到了别处。
要不要人批准、批几个人，由改动本身决定。一个分类器读改动，定风险等级；另一个分类器再判断，这次改动即使等级偏低，是否也该多一个人看。
文档、文案、仅内部使用的功能、藏在开关后的增量改动属于低风险，CI、代码评审和安全检查都通过后，可以不要人批准。普通产品改动，或者缓存、自动更新器、系统提示词这样的敏感区域，需要一人批准。最高风险的代码和少数指定路径需要两人。
图 3：人工批准的人数随改动风险增加；自动检查可放行低风险变更，不能替代必须由人承担的批准责任。
只有仓库信任名单里的作者能走较轻的路径，主要是这个仓库所属的团队，其他人要再找一人批准。代码 Owner 标出的敏感路径和 CI 工作流文件，始终要有人看。Agent 点“批准”不算数。Agent 写的代码，由指挥它的人算作必需的审阅人之一，和自己写代码时一样。
批准只对应一个具体提交。有新提交进来而系统无法确认，比如 Agent 又推了一次，或有人手动解决了冲突，原来的批准就要重给一次。PR 模板也要求交代怎么测试、出了问题怎么撤回，Claude 可以帮着填，最终由发起改动的人确认。
到了人工批准这一步，CI 的绿灯只说明已有的检查没报错。改动值不值得做，测试漏了什么，这种写法会不会被后来的人照着用，仍要审阅者判断。原文给审阅者的一条规矩是：说不清检查会漏掉什么，就要求一次真正的评审，不要快速批准。
原文提到一个挺实际的做法：有个团队认为评审排队的问题已经解决，来自团队外的改动却仍要有人看。看的不只是代码对不对，还要问“这件事要不要做”。有人会在公开讨论里指出以前的决定，或者提出更简单的办法；PR 可能因此被改写，甚至直接关闭。他们尽量早点在讨论里说这些话，不等 PR 写完再留一条阻塞评论。
读同事的 diff，原本也是在了解彼此的代码。现在大部分 diff 由机器读，这层了解从哪来？Anthropic 说还没有正式流程，也不要求谁在脑子里装下整个 Claude Code。有人要弄懂某一块，就让 Claude 专门讲那一块，比如“Claude Code 怎样获取托管设置？”，几分钟就能拿到一份对应当前代码的说明。
团队也习惯在公开的 Slack 频道里做事，别人正在改什么，可以边做边看到。一个是按需理解代码，一个是跟上团队的讨论；过去读 diff 时顺手获得的那部分信息，现在更多从这两个地方来。
合并了还要看
两条 PR 各自通过检查，合在一起仍可能出错。所以合并队列会把改动放到最新主干上，再跑一遍检查。新功能通常先用开关藏起来，给内部员工试；公开发布先到 latest，之后才到 stable。出了问题，开关不用重新部署就能关，也可以修复或回退。
发布之后，作者和值班人员还会看指标和事故看板。Claude Code 有每周轮换的值班，事故复盘会追问：本该由哪一层拦住它。
发生过的事故也会留下来：团队把相关 PR、后续修复或回退收进评测集，让熟悉代码的工程师确认 Bug 在哪儿，再每天拿这些案例考评审器。他们还按作者的反应给每条评论归类：改了、说它错了、说是有意为之，或者觉得无所谓。已知没有问题的 PR 也会交给评审器，专门看它会不会建议有害的修改。只要不在乎误报，评审器很容易多抓出一些问题。
坏合并目前还要靠作者、值班人员和看板发现，回退或事故增多时自动收紧审批的机制还没建成。团队里的工程师希望先有这套机制，再让更多代码不经人工批准就合并。
参考资料
Anthropic，How the Claude Code team does code review（https://claude.dev/blog/solving-code-review-at-anthropic/） Boris Cherny，关于团队共享 CLAUDE.md的 X 帖（https://x.com/bcherny/status/2007179840848597422）
如喜欢本文，请点击右上角，把文章分享到朋友圈
如有想了解学习的技术点，请留言给若飞安排分享
因公众号更改推送规则，请点“在看”并加“星标”第一时间获取精彩技术分享
·END·
相关阅读：
- AI 写代码越来越快，研发交付系统该怎么演进？
- Claude官方教你用 Loop：如何让Claude Code上夜班的四个交接点
- Agent、Harness、Loop 到底怎么分？一条运行链看清楚
- 架构排熵：Loop Engineering 的持续清理系统
- 输出结果不等于完成任务：Agent 最容易忽略的一环
- 从 LLM 到 Agent 到 Harness：真正复杂的是运转起来之后
版权申明：内容来源网络，仅供学习研究，版权归原创者所有。如有侵权烦请告知，我们会立即删除并表示歉意。谢谢!
架构师
我们都是架构师！
关注架构师(JiaGouX)，添加“星标”
获取每天技术干货，一起成为牛逼架构师
技术群请加若飞：1321113940 进架构师群
投稿、合作、版权等邮箱：[email protected]