Code review 流水线：一次改动从作者机器走到用户手里
这篇按 Claude Code 团队的文章，把一次改动从作者机器走到用户手里要过的九道关画成一张流水线图，其中只有按风险审批这一步由人决定。
这张图按 Claude Code 团队的文章《How the Claude Code team does code review》整理，主干来自原文的配图「The life of a change」。
CODE REVIEW 干两件事
- 改动上线之前，review 要找出问题并把它们修掉。
- 与此同时，review 也让整个团队对代码库形成共享的上下文和理解。
REVIEW 要问三件事
- 这次改动解决了它要解决的问题吗？
- 这次改动和现有系统合得来吗？
- 这次改动会不会弄坏别的地方？
原文里，这三个问题是每个 PR 上的 Claude review 读 diff 时要问的。
“did a human read the code?” is an imprecise proxy for “what could go wrong with this change, and which check—automated or human—is the right one to catch it?”
换句话说，「有没有人读过代码」只是一个不够精确的替代指标。真正该问的是这次改动可能出什么问题，以及哪一道检查（自动的或人工的）最适合把它拦下来。
— How the Claude Code team does code review
一次改动的一生
九个阶段里，大部分由机器自动完成；只有按风险审批这一步由人来决定。
01工作先自验
Claude 先跑测试、构建和 linter；接着由另一个 agent 在全新的上下文里把 diff 审一遍。
02必过 CI
CI 会跑 lint、类型检查、多平台测试、构建和打包。只要有一项变红，这个 PR 就不能合并。
03Claude code review
几个 agent 同时找 bug，然后一组验证 agent 对每条发现投票，留下来的发现按严重程度排序。
04安全审查
安全审查是单独跑的一轮。bug review 和安全审查里只要还有没关闭的发现，PR 就不能合并。
05按风险审批
唯一由人决定的一步
一个分类器读完改动以后定下风险档，风险档再决定需要几个人批准。风险档由改动本身决定，跟作者是谁无关；而且 agent 的批准从来不能顶替人的批准。
另外，有些路径无论落在哪一档都必须有人批，比如负责人列为敏感的代码和所有 CI workflow 文件。
06Merge queue
merge queue 把改动套到最新的 main 上，再把所有检查跑一遍，因此两个各自通过的 PR 不会合起来弄坏 main。
07藏在 feature flag 后面，内部先用
新行为先由 Anthropic 员工用起来，然后才推给所有用户。
08渐进发布
公开版本先发到 latest 渠道，stable 渠道随后才跟上。
09盯着，往前修或者回滚
作者和 on-call 一起盯着线上；出了问题时 flag 能很快关掉，坏掉的构建也会被 revert。
来源：Addy Osmani、Morgan Westlee Lunt、Qing Wang，How the Claude Code team does code review，claude.dev Blog，2026 年 10 月 15 日。
阶段顺序按原文配图「The life of a change」排列；原文正文分层介绍时，把 CI 放在了 AI review 和安全审查之后。