人工审查没取消：机器先读代码，人按风险把关，出错靠快速回滚兜底。
审查要回答的问题，从「有没有人读过代码」换成了「这次改动可能怎么坏，该由哪一道检查（自动或人工）来抓」。优化目标是人的时间和注意力。
人在审查上的成本有两份：一份是审代码的时间，一份是事后修坏代码的时间。只压低第一份，这份时间会转到第二份上。所以团队看三类数：每个 PR 的人工审批数（中位数和第 95 百分位）、人工评论数、PR 等人的时长。回滚率和事故率是护栏，这两个数一旦上升，就说明时间只是换了个地方花，并没有省下来。
“Revert and incident rates are the guardrail” ¶15
「合并 PR 增加到两倍以上，回滚比例降了 40% 以上」用的是比例口径：分母在变大，PR 也在变小，这两点本身就会拉低回滚占比。文中没给回滚绝对数，也没给事故率的变化，而事故率恰恰是它自己定的护栏指标。
大部分审查发生在 PR 创建之前，像写字时的拼写检查一样一直在跑，不再是流程末端的一道闸门。
交给 Claude 一个能实际运行的东西（测试、构建、对照设计稿的截图），要求它把输出拿出来，而不是说一句「做完了」。然后由一个新上下文的子代理审 diff，它没看过生成过程，不会被作者的思路带偏。Boris Cherny 估计，有了验证手段，最终结果能好两到三倍，不过这只是他个人的估计。
“ask it to show the output instead of saying it's done” ¶17
「验证让结果好两到三倍」是 Boris Cherny 的个人估计，没有说明怎么测的，不能当作实测效应量引用。
AI 审查的价值取决于噪声控制：几个代理同时找 bug，另一组代理对每条发现投票，足够多票认为是真问题才会发出来。
纯风格、诊断、清理类的发现直接丢掉。这几个过滤器先在自家 PR 上做过 A/B 才保留下来。留下的发现按严重度排序，标成 Important、Nit 或 Pre-existing；Pre-existing 用来防止把旧 bug 算到作者头上。每条发现都必须回应：要么修，要么写理由关掉。研究预览期间，内部 PR 拿到实质审查意见的比例从 16% 升到 54%。
“Then a separate group votes on each finding” ¶26
16% 到 54% 衡量的是「拿到实质审查意见的 PR 占比」，不是准确率或召回率。意见更多不等于真 bug 抓得更多；文中自己也说过，多报非 bug 就能轻易提高命中。
代理写、代理审的组合必须能收敛，否则两边会一直互相制造工作。
代理作者不会像人那样随手略过一条 nit，它会去修，于是多一次提交、多一轮审查。团队用 git blame 查过审查器反复标出的问题，约 59% 是第一轮审查时就已经存在的代码，也就是说每一轮只是多挖出几个旧问题。对策有四条：最多三轮，超过就让作者退一步重新考虑方案；前几轮之后只审新的 diff；按 bug 的类别标出来，让作者一次改完所有同类位置；已经报过的问题不再重复报。同时把「几轮通过」和召回率一起跟踪。
“An agent author and an agent reviewer can keep each other busy indefinitely.” ¶44
有几项可以在自己的环境里低成本复现：给代理可运行的验证、要求它出示输出；新上下文子代理审 diff；轮次上限加只审增量；用 git blame 统计审查意见里旧问题的占比（原文约 59%）。
人工审批的分量按风险定，风险档位由改动本身决定，与作者是谁无关；代理的批准永远不能顶替一个必须由人给的批准。
一个分类器读改动、定风险档位，第二个分类器再判断这次改动是否需要额外的人，即使档位说不需要。敏感路径和 CI workflow 文件一律要人审。只有信任名单上的作者能走较轻的审批路径。谁发起了改动谁就是责任人。审批只对某一个具体 commit 有效，之后出现系统无法担保的新提交（例如代理推送、手工解决的合并冲突），就要重新审批。
“The change sets the tier, not the author.” ¶32
零人工合并的安全边界还没有闭环。作者承认还没有「回滚或事故数一上升就自动收紧审批」的熔断器；知识传承靠按需让 Claude 写 explainer，也没有正式流程。
审查器本身也在一个改进循环里：历史事故被收成评测集每天回跑；审查反复指出的问题，在源头修掉。
收集造成过事故的历史 PR，连同后来的修复和回滚，由熟悉那块代码的工程师确认每个 bug 和它的位置，审查器每天跑一遍这个集合。噪声用人的反应来量：作者是改了、说审查错了、说是故意的，还是觉得无所谓；另外在已知干净的 PR 上统计会引出有害改动的误报。审查反复指出的问题，写进 CLAUDE.md、REVIEW.md、skill 或 lint 规则。REVIEW.md 写法要短：写清这个仓库里「失败」长什么样，限制 nit 数量，列出跳过的路径，要求给文件和行号作证据，总结以问题数量开头，没有可修的就直说。
“Any incidents are now an eval.” ¶41
这一点暂无对应的审视。
作者没有直接谈到这一点。
这篇文章同时在推广 Code Review for Claude Code（Team/Enterprise 已 GA）和 /code-review、/security-review。所有效果数据都来自 Anthropic 自家仓库，团队、工具和模型都是自己的，没有外部对照。
作者没有直接谈到这一点。
monorepo 每日变更从约 2,500 到超过 30,000，这组数字说的是另一个仓库，和 Claude Code 仓库的回滚数据不是同一口径，不能拼在一起推出因果。
作者没有直接谈到这一点。
文章没给成本数据：多代理找 bug、投票、Deep 模式、每夜全库扫描各要多少 token 和费用、耗时多长，都没提。风险分类器的误判率也没给。
多个代理找、另一组投票、再过滤分级，让发到人面前的意见尽量都是真问题。
审查要回答的问题，从「有没有人读过代码」换成了「这次改动可能怎么坏，该由哪一道检查（自动或人工）来抓」。优化目标是人的时间和注意力。
人在审查上的成本有两份：一份是审代码的时间，一份是事后修坏代码的时间。只压低第一份，这份时间会转到第二份上。所以团队看三类数：每个 PR 的人工审批数（中位数和第 95 百分位）、人工评论数、PR 等人的时长。回滚率和事故率是护栏，这两个数一旦上升，就说明时间只是换了个地方花，并没有省下来。
Revert and incident rates are the guardrail
¶15 ↗
大部分审查发生在 PR 创建之前，像写字时的拼写检查一样一直在跑，不再是流程末端的一道闸门。
交给 Claude 一个能实际运行的东西（测试、构建、对照设计稿的截图），要求它把输出拿出来，而不是说一句「做完了」。然后由一个新上下文的子代理审 diff，它没看过生成过程，不会被作者的思路带偏。Boris Cherny 估计，有了验证手段，最终结果能好两到三倍，不过这只是他个人的估计。
ask it to show the output instead of saying it's done
¶17 ↗
AI 审查的价值取决于噪声控制：几个代理同时找 bug，另一组代理对每条发现投票，足够多票认为是真问题才会发出来。
纯风格、诊断、清理类的发现直接丢掉。这几个过滤器先在自家 PR 上做过 A/B 才保留下来。留下的发现按严重度排序，标成 Important、Nit 或 Pre-existing；Pre-existing 用来防止把旧 bug 算到作者头上。每条发现都必须回应：要么修，要么写理由关掉。研究预览期间，内部 PR 拿到实质审查意见的比例从 16% 升到 54%。
Then a separate group votes on each finding
¶26 ↗
代理写、代理审的组合必须能收敛，否则两边会一直互相制造工作。
代理作者不会像人那样随手略过一条 nit，它会去修，于是多一次提交、多一轮审查。团队用 git blame 查过审查器反复标出的问题，约 59% 是第一轮审查时就已经存在的代码，也就是说每一轮只是多挖出几个旧问题。对策有四条：最多三轮，超过就让作者退一步重新考虑方案；前几轮之后只审新的 diff；按 bug 的类别标出来，让作者一次改完所有同类位置；已经报过的问题不再重复报。同时把「几轮通过」和召回率一起跟踪。
An agent author and an agent reviewer can keep each other busy indefinitely.
¶44 ↗
人工审批的分量按风险定，风险档位由改动本身决定，与作者是谁无关；代理的批准永远不能顶替一个必须由人给的批准。
一个分类器读改动、定风险档位，第二个分类器再判断这次改动是否需要额外的人，即使档位说不需要。敏感路径和 CI workflow 文件一律要人审。只有信任名单上的作者能走较轻的审批路径。谁发起了改动谁就是责任人。审批只对某一个具体 commit 有效，之后出现系统无法担保的新提交（例如代理推送、手工解决的合并冲突），就要重新审批。
The change sets the tier, not the author.
¶32 ↗
审查器本身也在一个改进循环里：历史事故被收成评测集每天回跑；审查反复指出的问题，在源头修掉。
收集造成过事故的历史 PR，连同后来的修复和回滚，由熟悉那块代码的工程师确认每个 bug 和它的位置，审查器每天跑一遍这个集合。噪声用人的反应来量：作者是改了、说审查错了、说是故意的，还是觉得无所谓；另外在已知干净的 PR 上统计会引出有害改动的误报。审查反复指出的问题，写进 CLAUDE.md、REVIEW.md、skill 或 lint 规则。REVIEW.md 写法要短：写清这个仓库里「失败」长什么样，限制 nit 数量，列出跳过的路径，要求给文件和行号作证据，总结以问题数量开头，没有可修的就直说。
Any incidents are now an eval.
¶41 ↗
这篇文章同时在推广 Code Review for Claude Code（Team/Enterprise 已 GA）和 /code-review、/security-review。所有效果数据都来自 Anthropic 自家仓库，团队、工具和模型都是自己的，没有外部对照。
「合并 PR 增加到两倍以上，回滚比例降了 40% 以上」用的是比例口径：分母在变大，PR 也在变小，这两点本身就会拉低回滚占比。文中没给回滚绝对数，也没给事故率的变化，而事故率恰恰是它自己定的护栏指标。
16% 到 54% 衡量的是「拿到实质审查意见的 PR 占比」，不是准确率或召回率。意见更多不等于真 bug 抓得更多；文中自己也说过，多报非 bug 就能轻易提高命中。
monorepo 每日变更从约 2,500 到超过 30,000，这组数字说的是另一个仓库，和 Claude Code 仓库的回滚数据不是同一口径，不能拼在一起推出因果。
有几项可以在自己的环境里低成本复现：给代理可运行的验证、要求它出示输出；新上下文子代理审 diff；轮次上限加只审增量；用 git blame 统计审查意见里旧问题的占比（原文约 59%）。
「验证让结果好两到三倍」是 Boris Cherny 的个人估计，没有说明怎么测的，不能当作实测效应量引用。
文章没给成本数据：多代理找 bug、投票、Deep 模式、每夜全库扫描各要多少 token 和费用、耗时多长，都没提。风险分类器的误判率也没给。
零人工合并的安全边界还没有闭环。作者承认还没有「回滚或事故数一上升就自动收紧审批」的熔断器；知识传承靠按需让 Claude 写 explainer，也没有正式流程。