Claude Code /review：让 AI 帮你做 Code Review

什么是 /review

Code Review 是开发流程中最重要的环节之一，但也是最容易被跳过的。

原因很现实：reviewer 忙、排期紧、PR 堆积。有些团队甚至形成了”互相点 Approve”的默契——review 变成了走过场。

/review 让 Claude Code 充当你的 Code Reviewer。 它会拉取 PR 的详情和 diff，然后像一个资深开发者一样，从代码质量、项目规范、性能、测试覆盖、安全性五个维度给出审查意见。

不是替代人类 reviewer，而是在人类 review 之前多一道 AI 把关。

怎么用 /review

审查指定 PR

/review 123

Claude Code 会执行以下流程：

运行 gh pr view 123 获取 PR 详情（标题、描述、作者等）
运行 gh pr diff 123 获取完整 diff
分析变更，输出结构化的审查意见

查看待审 PR 列表

/review

不带参数时，Claude Code 会运行 gh pr list 列出当前仓库的所有 open PR，你再选择要审查哪一个。

前提条件

/review 依赖 GitHub CLI（gh），使用前确保：

已安装 gh：brew install gh（macOS）
已登录：gh auth login
当前目录在一个 Git 仓库中

/review 审查什么

/review 的审查涵盖五个维度：

维度	关注点
代码正确性	逻辑是否正确，边界条件是否处理，是否有潜在 bug
项目规范	是否遵循项目的代码风格和约定
性能影响	是否引入性能问题，如 N+1 查询、不必要的循环
测试覆盖	改动是否有对应的测试，测试是否充分
安全考量	是否有注入、XSS、敏感数据泄露等安全风险

审查结果以清晰的分节和要点列表呈现，包括：

PR 概览——这个 PR 做了什么
具体建议——哪些地方可以改进，怎么改
潜在风险——需要注意的问题

实际效果

以一个真实场景为例——你的同事提了一个 PR，添加了用户搜索功能：

/review 42

Claude Code 可能输出类似这样的审查：

## PR 概览

PR #42 为用户管理页添加了搜索功能，包括前端搜索组件和后端 API 接口。

## 代码质量

- searchUsers 函数的 SQL 查询使用了字符串拼接，建议改用参数化查询防止 SQL 注入
- 搜索结果没有分页，大数据量下可能有性能问题

## 项目规范

- 新增的 API 路由命名风格与现有路由不一致（用了 camelCase 而非 kebab-case）

## 测试覆盖

- 缺少搜索边界条件的测试（空字符串、特殊字符、超长输入）

## 安全

- 搜索输入没有做长度限制和内容校验

/review 的工作原理

从源码来看，/review 是一个 prompt 类型的命令——它本质上是向 Claude 注入了一段精心设计的 Code Review 提示词。

你是一个代码审查专家。按以下步骤操作：

1. 如果没有提供 PR 编号，运行 gh pr list 列出所有 open PR
2. 如果提供了 PR 编号，运行 gh pr view <number> 获取 PR 详情
3. 运行 gh pr diff <number> 获取 diff
4. 分析变更，提供全面的审查意见

这意味着 /review 本身并不依赖什么特殊的内部机制——Claude 会用它常规的工具（Bash、Read、Grep 等）来完成审查。这也意味着你可以在审查过程中追问、让它解释某个建议、或者要求它关注特定方面。

三个审查命令对比

Claude Code 其实有三个审查相关的命令，适用于不同场景：

/review —— 通用 PR 审查

特性	说明
审查对象	GitHub PR
运行环境	本地
审查维度	代码质量、规范、性能、测试、安全
耗时	几分钟
费用	正常 Token 消耗
适用场景	日常 PR 审查

/ultrareview —— 深度 Bug 猎手

/ultrareview 123    # 审查指定 PR
/ultrareview        # 审查当前分支

特性	说明
审查对象	PR 或当前分支（vs 主分支的 fork point）
运行环境	云端（远程 Claude Code 会话）
审查维度	专注于发现和验证 Bug
耗时	10-20 分钟
费用	独立配额，Free/Pro 有免费次数，超出后按 Extra Usage 计费
适用场景	重要功能上线前的深度审查

/ultrareview 和 /review 完全不同——它会在云端启动一个”猎虫舰队”（bughunter fleet），由多个 AI Agent 并行分析你的代码，每个 Agent 专注于不同的角度。找到潜在 Bug 后还会进行验证，最终汇总结果返回给你。

这个命令由功能开关控制，可能不是所有用户都能看到。

/security-review —— 安全专项审查

/security-review

特性	说明
审查对象	当前分支（vs origin/HEAD）
运行环境	本地
审查维度	纯安全视角
耗时	几分钟
费用	正常 Token 消耗
适用场景	上线前的安全检查

/security-review 的审查维度非常聚焦，只看安全问题：

输入验证：SQL 注入、命令注入、XXE、模板注入、路径遍历
认证授权：认证绕过、权限提升、会话管理
密钥管理：硬编码密钥、弱加密、密钥泄露
代码执行：RCE、反序列化、eval 注入、XSS
数据泄露：敏感数据暴露、日志泄露

它有严格的误报过滤机制——只有置信度达到 8/10 以上的漏洞才会报告。每个漏洞都带有严重程度（HIGH/MEDIUM/LOW）、漏洞描述、利用场景和修复建议。

/security-review 不需要 gh CLI，它直接用 git diff 获取变更内容。

三个命令怎么选

日常 PR 审查        →  /review 123
重要功能深度检查    →  /ultrareview 123
上线前安全扫描      →  /security-review

它们不冲突，可以组合使用。比如一个重要功能上线前：

先用 /review 做一轮通用审查
再用 /security-review 专门扫安全
如果是核心功能，用 /ultrareview 做深度 Bug 猎杀

实用技巧

技巧一：审查后追问

/review 的审查结果不是终点。你可以继续对话：

"第二点 SQL 注入的问题能展开说一下吗？给个修复示例"
"除了你提到的问题，这个 PR 的整体架构设计合理吗？"
"帮我把审查意见整理成 PR Comment 的格式"

技巧二：聚焦审查

如果你只关心某个方面，可以在参数里说明：

/review 123 focus on performance
/review 123 只看安全相关的问题

/review 会把你的额外说明附加到审查提示中。

技巧三：结合 /diff 使用

如果你还没提 PR，可以先用 /diff 看看当前会话的改动，然后手动让 Claude 审查：

帮我审查一下刚才这些改动，特别是安全方面

技巧四：自动化审查流程

结合 /hooks，你可以在特定时机自动触发审查。比如在会话结束前提醒审查：

{
  "hooks": {
    "Stop": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "echo '{\"systemMessage\": \"提醒：如果本次会话有代码改动，建议运行 /review 或 /security-review 做一次审查\"}'"
          }
        ]
      }
    ]
  }
}

写在最后

Code Review 的价值毋庸置疑，但让人做 Review 的最大障碍是时间成本。

/review 把这个成本降到了接近零——几分钟就能得到一份覆盖五个维度的审查报告。它不完美，不能替代有领域经验的人类 reviewer 的判断，但它可以：

在人类 review 之前先过滤掉明显的问题
提醒你可能忽略的测试和安全隐患
在没人有空 review 时给你一个快速的反馈

把 AI 当作第一轮 reviewer，让人类 reviewer 专注于更高层次的架构和业务逻辑判断。这才是人机协作的正确姿势。