Anthropic公开Claude Code的AI代码审查实践 · 话题榜 · TwKit

@dotey

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

@vikingmute

昨天还在说 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 已经提过的意见不再重复。

@Xudong07452910

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/

@yupi996

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% 是第一轮审查时就在的老问题。。。