AI 时代的代码审查：Claude Code 团队实践解读（PPT）
📥 主动分享/收藏：Jack 于 2026-10-21 要求收藏（经 TARS chat）。
二手总结：本 PPT 由 TARS（另一个助手）制作，是对 Anthropic claude.dev 博客文章的中文解读，并非 Anthropic 原件。下文要点均标注为"据 PPT" 本地导入，不等同于 Anthropic 已核实的原话；与原文的核对结果见文末。
- 原件：〔本地存档〕（meta：〔本地存档〕；TARS 原工程目录 〔本地存档〕）
- 主要来源：Anthropic claude.dev 博客《How the Claude Code team does code review》，2026-10-15 — https://claude.dev/blog/solving-code-review-at-anthropic/
- 附带来源：Anthropic Engineering《Redesigning source control at Anthropic》— https://www.anthropic.com/engineering/redesigning-source-control（PPT 备注另引 The New Stack、The Register 的报道）
- 相关页：AI 代码审查、Claude Code、Claude、Agent 工程与编程 Agent
要点（据 PPT）
- 背景：Claude Code 约 90% 的代码由 Claude 编写；Anthropic monorepo 每日落地改动从 5 月约 2,500 增至 30,000+ 本地导入。
- 基础设施：git 扛不住（主分支历史近 100 GB、每天约 2,500 万次 CI checkout、曾需数百个 git 镜像），5 个月内迁移到自研版本控制系统 Scion，CPU/内存占用约为原 git 镜像方案的 1/200；同期自研代码审查界面 Antique 本地导入。
- 成果：6–9 月 Claude Code 合并 PR 数翻倍以上，需回滚的 PR 占比下降 40% 以上；"没有取消审查，而是把大部分阅读交给机器，并让撤回变得快速简单" 本地导入。
- 重新定义审查：两项职能——发现并修复问题、在团队内共享上下文；关键问题不是"有人读过代码吗"，而是"这个改动可能出什么错、由哪道检查来抓最合适"；审查从终点关卡变成像拼写检查一样持续进行，多数改动在人看之前已被 Claude 审查并修复至少一次 本地导入。
- 目标与指标：多数 PR 至多一人参与（可以是作者本人），且回滚与事故不增加；指标为每 PR 人工批准数（中位数/P95）、人工评论数、PR 等待人的时长；回滚率与事故率是护栏 本地导入。
- 分层检查 + 回滚兜底：开 PR 前自证（测试、构建、截图、新上下文子代理复审）→ 每个 PR 先过 AI 审查 → 有未处理发现不能合并的安全审查 → lint/类型/全平台测试/构建 → 按风险分级的人工审批 → 渐进上线（合并队列、功能开关、内部先用、分批发布）→ 快速回滚 本地导入。
- 按风险分级审批：低风险（文档、文案、仅内部功能、开关后的新增改动）无需人工批准；普通产品改动及缓存、自动更新器、系统提示等敏感区域需 1 人；最高风险代码需 2 人。风险等级由改动决定而非作者（分类器判定）；仅受信任作者可走轻量路径；机器人批准不能替代人；批准只对应特定 commit；指挥 agent 的人算作必需审查者之一 本地导入。
- AI 审查机制：多个代理并行找 bug，另一组逐条投票，足够多认定才发布；纯风格/诊断/清理类发现直接丢弃（经 A/B 测试）；标注 Important / Nit / Pre-existing，每条必须修复或附理由关闭，常由 agent 夜间自动修复 本地导入。
- 审查必须收敛：一个 CLI PR 一夜经历 50+ 轮审查与修复；反复标记的问题 59% 来自首轮就已存在的旧代码。措施：3 轮上限、后续只审新 diff、标记 bug 类别让作者一次修全、不重复已发布的发现 本地导入。
- 人留在哪里：方向与取舍、高风险代码（计费、自动更新器、CI 工作流）、会被复制的架构模式、读证据、为结果负责 本地导入。
- "谁合并，谁负责"（You land it, you own it）与共享上下文：要了解哪块代码就让 Claude 写讲解；在公开 Slack 频道工作；改动小、一切可撤回、按影响面定标准、不追责只看系统 本地导入。
- 落地清单：PR 前（CLAUDE.md 列可运行检查、hooks、本地 /code-review 与 /security-review、REVIEW.md）；每个 PR（必需 CI、PR 模板含测试/风险/如何回滚、AI 审查先试一个仓库、安全审查、轮次上限）；审批（成文风险分级、CODEOWNERS + 分支保护、新提交使批准失效）；合并后（合并队列、功能开关、一键回滚、事故转为评测集）本地导入。
关键结论/数据（据 PPT）
| 数据 | 值 | 来源 |
|---|---|---|
| Claude Code 由 Claude 编写的代码占比 | 约 90% | 本地导入 |
| monorepo 每日落地改动 | 5 月约 2,500 → 30,000+ | 本地导入 |
| 合并 PR 数（6–9 月） | 翻倍以上 | 本地导入 |
| 需回滚 PR 占比 | 下降 40% 以上 | 本地导入 |
| 有实质性审查评论的内部 PR 占比 | 16% → 54% | 本地导入 |
| 单个 PR 一夜审查/修复轮次 | 50+ | 本地导入 |
| 反复标记问题中属于旧代码的比例 | 59% | 本地导入 |
| Scion 相对 git 镜像方案的 CPU/内存占用 | 约小 200 倍 | 本地导入 |
结论：把"人读代码"换成"按风险选择合适的检查"，用多层自动审查 + 快速回滚换取更少的人工时间，同时以回滚率/事故率作护栏 本地导入。
与原文核对（2026-10-21 WebFetch）
-
两篇原文均可公开访问。博客作者为 Addy Osmani、Morgan Westlee Lunt、Qing Wang，2026-10-15 发布（https://claude.dev/blog/solving-code-review-at-anthropic/）；source control 文章发布于 2026-10-13（https://www.anthropic.com/engineering/redesigning-source-control）。
-
基本一致：90%、每日改动 2,500→30,000+、合并 PR 翻倍且回滚占比降 40%+、16%→54%、50+ 轮、59%、四项收敛措施、风险分级表、"人留在哪里"五项、落地清单，均与博客原文对应（https://claude.dev/blog/solving-code-review-at-anthropic/）；近 100 GB 主分支历史、约 2,500 万次 CI checkout、数百个 git 镜像、5 个月迁移、Antique、基础设施占用小 200 倍，均见 source control 原文（https://www.anthropic.com/engineering/redesigning-source-control）。
-
需注意：PPT 写"Scion 不对外开源"；source control 原文只说 Scion 不适合作为通用 git 替代、难以以对其他组织有用的形式提供，未见"不开源"的直接表述（PPT 备注称该说法来自 The Register 报道，未核对）。PPT 标题写"六层检查"但列了 7 项，原文表述为"六层检查，回滚在其下"（https://claude.dev/blog/solving-code-review-at-anthropic/）。
-
原文有、PPT 未提：Code Review for Claude Code 已在 Team/Enterprise 计划 GA，仓库可设 Quick/Standard/Deep 三档；把过去引发事故的 PR 做成评测集、每天跑；尚无在回滚/事故指标变化时自动收紧审批的"熔断"机制（https://claude.dev/blog/solving-code-review-at-anthropic/）。
-
Grok Bot 点赞：Jack 在 TARS 聊天里给这份 PPT 的附件消息点了 👍 Grok Bot 对话