Anthropic公开Claude代码审查实践

Claude Code 团队公开了他们审代码的做法：代码大约九成由 Claude 写，六月到九月合并的修改翻了一倍多，需要撤回的比例反而降了四成多。 这期用一摞带洞的奶酪片讲这套做法：每道检查都会漏，叠起来就很难漏，底下还有一张网兜底。 片中回答五个问题：哪些修改还要人看，AI 审 AI 会不会没完，审查的 AI 漏了怎么办，人不读代码怎么懂代码，出了事算谁的。人不再逐行读代码，时间花在机器做不好的判断上。 视频1: 英文版 视频2: 中文版

曝光 36260 · 评论 94 · 点赞 325 · 书签 409

推荐阅读，Anthropic 如何做 Code Review！ 1. 保留 code review，但大部分审核交给机器，人的时间只花在高风险判断上，同时让出错后能快速回滚。 2. 提 PR 前：Claude 自己跑测试和构建，再由一个新开的 agent 审一遍 diff。 3. 每个 PR：AI 多 agent 找 bug，投票过滤掉误报，再加一轮安全审查和 CI。每条发现都必须处理，否则不能合并。 4. 人工审批按风险分级：低风险 0 人，中风险 1 人，高风险 2 人，由分类器判定。bot 的批准不能替代人，驱动 agent 的人对改动负责。 5. 上线：合并队列、feature flag、先内部使用再灰度发布，出问题一键回滚。 6. 持续改进：历史事故整理成每日 eval，用来评估 reviewer。审查轮数设上限，避免 agent 之间无限互审。

曝光 15576 · 评论 14 · 点赞 173 · 书签 179

Claude Code 团队称，现在大约 90% 的代码已经由 Claude 写。那这么多代码到底谁来 Review？ Anthropic 最新这篇文章给了一个很这得参考的答案。 他们已经把 Code Review 从 PR 最后的人工关卡，拆成了一条持续验证链。 代码提交前，Agent 自己跑测试，再开一个干净 Context 的 Subagent 看 diff；PR 创建后自动跑 Claude Review 和 Security Review；人主要盯风险、架构和改动意图；合并后还有 Feature Flag、灰度和快速回滚。 按 Anthropic 的内部数据，6 月到 9 月合并的 PR 数量翻了一倍多，回滚率反而下降超过 40%。研究版 AI Review 上线后，有实质性 Review 意见的 PR 也从 16% 提到了 54%。 这里真正值得看的，是 AI Coding 把代码生产速度拉高以后，Code Review 也开始被重新设计。 人以后肯定越少逐行看 diff，把注意力留给意图、系统影响和那些机器很难替你承担的判断。 甚至每次漏掉一个 Bug，都可以继续写回 CLAUDE.md、REVIEW.md 或新的自动检查里，让下一次 Review 更强。 代码可以越写越快，真正要跟着一起扩容的是验证系统。 文章 https://claude.dev/blog/solving-code-review-at-anthropic/

曝光 14812 · 评论 16 · 点赞 149 · 书签 139

AI 编程党有福了，Claude Code 团队刚公开了自己怎么审 AI 写的代码，1 张图带你抄作业！🫡 这个团队约 90% 的代码都是 Claude 写的，从 6 月到 9 月，合并的 PR 翻了一倍多，被回滚的比例反而降了四成多！ 重点就这 5 条： 1）让 Claude 跑完测试，把输出贴给你看 2）提 PR 前先跑一遍自带的 /code-review 3）同类问题反复出现，就写进 CLAUDE.md 4）AI 审查来回超过 3 轮，就退一步重新想方案 5）改文档这类低风险的，机器审完就能合，改计费、CI 流程的必须有人批 第 4 条是踩坑换来的，有个 PR 一晚上被 AI 来回审了 50 多轮！而且统计下来，AI 反复揪出的问题里，约 59% 是第一轮审查时就在的老问题。。。

曝光 12559 · 评论 12 · 点赞 183 · 书签 193

Anthropic 这篇聊 Claude Code 团队怎么做 Review 的文章有点干货，推荐收藏！ 他们 90% 的代码都是 Claude 写的，每天合并几万次提交，肉眼逐行去看早就不可能了。 结果：PR 翻倍了，revert 率反而降了 40%。 他们的几点很实操的做法⤵️ 1. 别让人当第一道靶子 改完不能直接丢给同事。Claude 必须自己跑完测试、比对完截图，再叫另一个没上下文的 subagent 独立扫一遍 diff。 2. 多 Agent 投票，治好了 AI 废话多的毛病 平时大家不用 AI review，主要是烦它总挑一些缩进、命名的刺。他们是多个 agent 并行找 bug，再拉另一组 agent 投票，纯样式的吐槽直接被刷掉，最后报出来的基本都是硬伤。 3. 分级放权，谁 prompt 谁背锅 改个文档或者加个带 flag 的增量代码，自动化检查全绿就可以直接合了；动到核心模块或 CI 配置才拉工程师看。责任界定也很简单：谁指挥 AI 写的，谁就算 reviewer，出了 bug 自己来兜底。 4. 敢合的前提是回滚够快 只要出了事能在秒级关 flag 甚至直接撤回，这样就不用为了防错而把全流程卡死。

曝光 12376 · 评论 10 · 点赞 79 · 书签 91

昨天还在说 Code Review 的实践，今天Anthropic就写了一篇文章详细描述它们 Code Review 的工程实践： https://claude.dev/blog/solving-code-review-at-anthropic/ 非常受用，可以好好读一下，核心观点是：代码多到人读不过来之后，人已经不 review 代码了，而是追求花最少的时间 并且回滚和事故又不增加 一个改动要过七层检查，几点也很有趣： 1 让 Agent 提 PR 之前先自证 证明做完了 测试 截图 等等 2 每个 PR 都有 AI review diff，对照整个仓库和 PR 的意图来审 多个 agent 同时找 bug 再由另一组投票，多数认定是真问题才发出来 纯风格类的意见直接丢掉 这个和我的 review-forge 的思路非常类似 3 按风险决定要几个人批 低风险不用人批准自动合并，普通功能一人批 最高风险的路径要两个人（我怀疑这步骤真的那么有用吗？人能看过来吗） 4 merge queue / feature flag / 灰度发布 先给内部员工用， 快速发现 快速回 feature flag 不用部署就能关掉 里面还有一个非常实用的思路 正好解答昨天多 agent review 的问题： review 要能收敛，agent 写 agent 审，有可能可以互相折腾个没完，文中说有个 PR 一夜之间来回改了五十多轮 git blame 一看，59% 被反复标记的都是第一轮时就已经存在的老代码 所以他们加了几条规则：最多三轮，超过就让作者退一步重新想方案 几轮之后只审新增的 diff 已经提过的意见不再重复。

曝光 9902 · 评论 10 · 点赞 133 · 书签 180