太长不看版
- 代码审查是内置能力——/code-review（别名 /review）默认审查分支领先 upstream 的提交加上未提交的改动，后台跑，不用装任何东西。
- 发现是分了级的：Important、Nit、Pre-existing，每条都带实锤证据、影响面和修复建议，--fix 一键落到工作区。
- 审查深度是个旋钮：low 到 max 会跨会话记住你上次的档位，ultra 走云端 ultrareview，--max-findings（v2.1.288+）管条数上限。
- GitHub 侧由 Claude App 按你设的触发器审查 PR、发行内评论；check run 永远是 neutral 结论，永远不会卡住合并。
Introducing Code Review
频道：Anthropic · Claude0:45
Anthropic's NEW Claude Code Review Agent
频道：Patrick Ellis29:56
Claude Code release notes — v2.1.288
更新日志：github.com/anthropics/claude-code
Review pull requests with Claude Code — official docs
官方文档：code.claude.com/docs
页面事实以官方 code review 文档和 v2.1.288 更新日志为准；截图取自上面两支视频，逐一核对过。所述行为对应 Claude Code v2.1.288（2026 年 10 月）。
截图为 Anthropic《Introducing Code Review》与 Patrick Ellis《Anthropic's NEW Claude Code Review Agent》的视频帧，均标注出处，且每一步都链回原视频对应时间点。
一步步跑一次代码审查
把审查跑起来
- 1
升级 Claude Code，敲下命令
审查是内置的，不用装插件。先升到 v2.1.288 以上拿到新旗标，输入 /code-review（老写法 /review 现在是它的别名），回车。审查在后台跑，你手上活儿不用停。
Anthropic 给这个内置审查专门做了张标题卡。看视频 0:07 处 - 2
让它审对的那份 diff
不带参数时，/code-review 审分支领先 upstream 的提交加未提交改动。想指定范围就传文件路径、PR 号、分支名，或者 main...my-feature 这种区间。
审查会话启动前，先选好仓库、把任务说清楚。看视频 0:08 处 - 3
放它在后台跑
审查是独立 agent，读代码期间你的输入框一直是空闲的。再敲一次 /code-review 能把进行中的审查拉回前台；想强制前台，用 print 模式或设 CLAUDE_CODE_DISABLE_BACKGROUND_TASKS=1。
出现 Starting Claude Code 状态，说明审查已经跑起来了。看视频 0:12 处 - 4
看带证据、带影响的分级发现
每条发现都标 Important、Nit 或 Pre-existing，附实锤证据、影响面和修复建议——官方演示里就在真实 PR 上抓到一个 CVSS 9.1 Critical 的 IDOR 漏洞。
单条发现的证据、影响与修复，和 bot 发出来的一模一样。看视频 0:23 处
从发现到修完
- 5
把发现发到 PR 上
加 --comment，每条发现会以行内评论发到 GitHub PR 上（GitLab MR 从 v2.1.257 起走 glab）。在 github.com 上由 Claude GitHub App 跑的审查，也是同样的落法。
Claude bot 在 diff 下面逐条评论，每条线程带 resolve 按钮。看视频 0:18 处 - 6
用 --fix 或一次粘贴修掉
跑 /code-review --fix，采纳的发现直接落进工作区。或者把建议粘回会话里——演示里的会话自己改文件、勾掉 todo，全程不用你盯。
会话照着修复清单一条条勾，你只管看。看视频 0:14 处 - 7
复审到 diff 收敛
修完再跑一次 /code-review，它只复查改动过的部分，所以二审很便宜——复审的指令就是收敛，不是翻旧账。等 todo 全勾完，同一个会话里直接推分支、开 PR。
全部任务完成，会话已经准备好创建 PR。看视频 0:24 处 - 8
用 --max-findings 管条数
v2.1.288 新增：/code-review --max-findings 5 或 --max-findings all 覆盖默认条数上限，而且这个选择会在后续审查里一直沿用，直到你传 --max-findings default 恢复默认。
一条 Critical 发现，带等级、证据和修复建议发在 PR 线程里。看视频 0:20 处
调深度、上自动化、立规矩
- 9
effort 拉满，或者上 ultra
审查接受 low、medium、high、max 四档 effort，而且跨会话记住你上次的档位，设一次就行。/code-review ultra 升级成云端 ultrareview；还能组合：/code-review ultra --fix，或者在 CI 里跑 claude ultrareview。
审查深度就是个旋钮，就挨着模型选择器。看视频 0:04 处 - 10
装 Claude GitHub App，覆盖每个 PR
Owner 在 admin settings 里打开 Code Review，装上 Claude GitHub App。每个仓库选一个触发器——PR 创建后一次、每次 push 后、或手动——之后在任何开着的 PR 下评论 @claude review 就能触发。
点一下 Setup，授权 Claude GitHub App 读取代码。看视频 0:02 处 - 11
把你的规矩教给它
路径上每一层 CLAUDE.md 都会被遵守，新违反的条目会标成 nit。云端审查还会读仓库根目录的 REVIEW.md——重定义严重级别、限 nit 条数、跳过路径或分支、设验证门槛；skillOverrides 还能把审查 skill 限制成只能手动触发。
一份 markdown 写的安全审查评分规则，出自 Anthropic 的开源仓库。看视频 18:30 处
/code-review、/review、/security-review、/simplify、ultra 怎么选
Claude Code 自带一小族审查命令，很容易混。什么时候用哪个，一条条说清。
- 1/code-review——默认的抓 bug 审查。审分支领先 upstream 的提交加未提交改动，按严重程度排序，后台跑，不挡你干活。
- 2/review——同一个命令。从 v2.1.223 起 /review 就是 /code-review 的别名；再往前它是个独立的只读 PR 单轮审查，所以老教程里的说法跟现在对不上。
- 3/security-review——照 Anthropic 开源方法论做的安全专项。只抓安全漏洞——Patrick Ellis 的演示里它抓出了故意埋的假 API key——而且同样随 Claude Code 自带。
- 4/simplify——做清理，不抓 bug。只做直白的重构和格式整理，不判断对错。如果你旧脚本里用 /simplify 找 bug，把那段脚本换成 /code-review --fix。
- 5ultra——云端升级档。/code-review ultra 把整个分支相对默认分支的 diff 交给更深的云端审查；接 --fix 把结果落回本地，或者 CI 里跑 claude ultrareview。
实操分工：写代码时用 /code-review 当默认内循环；鉴权、支付、一切碰 token 的地方交给 /security-review；ultra 留给那种你本来想找同事再审一遍的高风险迁移。纯风格清理是 /simplify 的活儿——那根本不算审查。
审查没动静、话痨、GitHub 上不跑？急救手册
代码审查的问题大多一行就能解。先顺着这张单子过一遍，再动配置。
- 1提示「Unknown command」或行为跟老教程对不上——先升级。--max-findings 要 v2.1.288+，/review 别名是 v2.1.223 来的，GitLab MR 的 --comment 要 v2.1.257+。
- 2审查跑完了却「啥都没发现」——默认有条数上限，报告本来就短。用 --max-findings all 放开再看一遍，别只等 Critical，Nit 和 Pre-existing 标记也值得扫一眼。
- 3它钻进后台「消失」了——这是设计如此。再敲一次 /code-review 就能接上进行中的审查；想一直在前台，设 CLAUDE_CODE_DISABLE_BACKGROUND_TASKS=1。
- 4觉得你的规矩没被当回事——本地 /code-review 只认 CLAUDE.md，从来不读 REVIEW.md，后者是云端 GitHub 审查的规则文件。仓库级检查清单放 REVIEW.md，个人和项目风格放 CLAUDE.md。
- 5GitHub 上 PR 没人审——查仓库触发器（创建后一次、每次 push、手动），确认评论的人有 write 及以上权限；fork 来的 PR 只有在明确评论 @claude review 后才会被审。
再补一个坑：check run 永远叫 Claude Code Review，结论永远是 neutral，所以分支保护规则永远不会因为它卡合并。想卡？在自己 CI 的 job 里解析 check run 输出里的 bughunter-severity 汇总行，发现 Important 就让构建失败。