Claude Code 斜杠命令（四）：代码审查三剑客

Claude CodeAI工具教程斜杠命令

系列目录

  1. （一）快速入门——最常用的基础命令
  2. （二）对话管理——让你的会话有条不紊
  3. （三）上下文管理——不让 Token 成为瓶颈
  4. （四）代码审查三剑客
  5. （五）模型与推理控制
  6. （六）并行工作与后台 Agent
  7. （七）项目配置与权限管理
  8. （八）研究、规划与 CI/CD 集成
# 代码审查体系 ## 查看改动 - /diff 交互式 diff 查看 - 可追问改动原因 ## 全面审查 - /code-review 正确性/效率/可复用 - effort: low/medium/high/max/ultra - --fix 自动应用修复 - --comment 发布为 PR 评论 ## 清理重构 - /simplify 可读性和简洁度 - 不找 bug，只做清理 ## 安全扫描 - /security-review OWASP Top 10 - 注入/认证/越权/敏感数据 ## PR 审查 - /review PR URL - 配合 --comment 发布意见

AI 代码审查能做什么、不能做什么

AI 代码审查不是人工 review 的替代品，而是一道在提 PR 前的自动过滤网。它擅长发现逻辑漏洞、冗余代码、常见安全模式缺失，但对业务规则的正确性、团队约定的风格细节，以及"这段逻辑是否符合产品需求"这类问题，仍需人工判断。把 AI 审查定位成"让人工 review 更聚焦"的工具，而不是"省掉人工 review"，你才能从这套工具链里获得最大价值。

命令速查表

命令 关键参数 用途 适用场景
/diff 无 交互式查看当前 diff 提交前确认改动范围
/code-review --fix、--comment、effort 级别 全面代码质量审查 功能开发完成后
/simplify 无 专项简化与重构建议 代码可读性差、逻辑绕弯时
/security-review 无 安全漏洞扫描 涉及认证、输入处理、数据存储时
/review PR URL 审查 GitHub PR 需要对他人 PR 给出意见时

/diff：在提交前看清自己改了什么

/diff 本质上是一个上下文感知的交互式 diff 查看器。它不只是把 git diff 的输出抛给你，而是允许你在 Claude Code 的对话界面里追问："这里改动的原因是什么？""这个函数签名变化会影响哪些调用方？"

典型用法：完成一个 feature 后，在运行任何审查命令之前先执行 /diff，快速确认改动范围符合预期，没有意外引入不相关文件的修改。

/diff

如果你发现某个文件不应该被改动，可以直接在对话里说"帮我还原 config/settings.py 的修改"，Claude 会处理 revert 而不需要你切换到终端。

/code-review 深度讲解

这是审查工具链的核心。/code-review 会分析当前分支相对于主分支的所有变更，从正确性 bug、可复用性、效率三个维度给出发现。

effort 参数：花多少力气做审查

effort 参数控制审查的深度和覆盖面，直接影响耗时和 token 消耗：

  • low / medium：高置信度发现，数量较少，适合日常小改动的快速过滤
  • high / max：更广的覆盖面，会包含一些置信度稍低的发现，适合功能主干代码
  • ultra：云端多 Agent 深度审查，耗时最长，适合核心模块上线前的最后一关

选择策略：改了三行配置用 low；改了一个完整模块用 high；要重构核心认证逻辑再考虑 ultra。不要把 ultra 当默认选项，它的价值在于稀缺性。

flowchart LR A[改动范围?] --> B{核心/跨模块?} B -- 否 --> C[low / medium] B -- 是 --> D{上线前最终审查?} D -- 否 --> E[high / max] D -- 是 --> F[ultra] 
/code-review          # 默认 medium effort
/code-review high     # 指定 effort 级别

--fix：让 Claude 直接修

加上 --fix 后，Claude 不只是列出问题，还会把发现的问题直接应用到文件里。这对于格式问题、明显的空指针风险、重复代码等情况非常省事。

flowchart LR A[git commit] --> B[/code-review --fix] B --> C{修复结果满意?} C -- 是 --> D[继续流程] C -- 否 --> E[git checkout 还原] 
/code-review --fix
/code-review high --fix

注意：--fix 前建议先确保工作区是干净状态（或者已经 commit），这样如果自动修复结果不满意，你可以用 git checkout 还原。

--comment：发布为 PR inline 评论

如果你想让审查结果直接出现在 GitHub PR 的 review 界面里，用 --comment。Claude 会把每条发现定位到对应的文件和行号，以 inline comment 的形式发出去。

/code-review --comment
/code-review max --comment

这个参数特别适合团队协作场景：你作为 PR 作者先用 Claude 做一轮审查，把明显问题用 --comment 标注出来，再请队友 review，让人工 review 聚焦在真正需要讨论的设计决策上。

什么时候值得用 ultra

ultra 会启动云端多 Agent 并发审查，适合这些场景：

  • 核心业务逻辑（支付、权限校验）上线前
  • 重大重构，改动跨越多个模块
  • 需要一份可以存档的正式审查报告

普通功能迭代没必要用 ultra，medium 或 high 已经够用。

/simplify vs /code-review：选哪个

很多人分不清这两个命令的边界，一张表说清楚：

维度 /code-review /simplify
关注点 bug、正确性、效率、安全 可读性、冗余、代码简洁度
会找 bug 吗 是 否，只关注质量清理
适用时机 功能完成后全面检查 代码能跑但写得绕时
输出形式 问题列表（可选 --fix） 直接应用简化修改
token 消耗 较高（可调 effort） 较低

实际项目中，两者可以串联使用：先 /simplify 把代码理顺，再 /code-review 做全面审查，最后 /security-review 过安全关。

/security-review 实战

/security-review 专注于安全漏洞扫描，它能覆盖的范围与 OWASP Top 10 高度对应：

  • 注入攻击（A03）：SQL 拼接、命令注入、模板注入
  • 认证缺陷（A07）：弱密码策略、session 管理漏洞、JWT 配置错误
  • 访问控制（A01）：权限校验遗漏、越权访问路径
  • 敏感数据暴露（A02）：明文存储密码、日志里打印 token、响应体里泄露内部字段
  • 不安全的依赖（A06）：已知漏洞的第三方包版本
  • 安全配置错误（A05）：CORS 过于宽松、调试模式未关闭、错误信息暴露堆栈

实际项目场景：你开发了一个新的 API 端点，处理用户上传文件。在提 PR 前跑 /security-review，它会检查文件类型验证、路径穿越风险、文件大小限制等问题，这些正是人工 review 容易遗漏的安全细节。

/security-review

/security-review 的发现属于"高风险，必须处理"类别，不像 /code-review 的建议可以选择性采纳，安全问题原则上要在合并前全部解决。

/review：审查他人的 GitHub PR

当你需要审查队友提交的 PR 时，使用 /review 并提供 PR URL：

/review https://github.com/your-org/your-repo/pull/123

Claude 会拉取 PR 的所有变更，结合 PR 描述和 commit message，给出审查意见。这对于需要 review 大量 PR 的 tech lead 来说非常实用——先让 Claude 做一轮初筛，再人工聚焦在架构决策和业务逻辑上。

/review 也支持配合 --comment 使用，把意见直接发布到 PR 上，让整个 review 流程留在 GitHub 界面里。

推荐的代码审查流程

flowchart LR A[完成编码] --> B[/diff 确认改动] B --> C[/simplify + /code-review] C --> D[/security-review] D --> E[提交 PR]

这条流水线覆盖从写完代码到提 PR 的完整路径：先用 /diff 确认自己改了什么，再用 /simplify 和 /code-review 做质量审查，然后 /security-review 过安全关，最后提 PR。整个过程不离开 Claude Code 界面。

常见误区

误区一：把 /code-review 当 linter 用 /code-review 做的是语义级别的审查，不是格式检查。如果你只是想统一缩进或排序 import，继续用项目已有的 linter（eslint、ruff、gofmt），不要为此浪费 token。

误区二：ultra 越多越好 ultra 模式的价值在于覆盖普通审查发现不了的深层问题，但它的成本（时间和 token）相应也高得多。对日常迭代用 ultra，会让它变成"狼来了"——真正需要深度审查时反而没有区分度。

误区三：/security-review 能覆盖所有安全风险 /security-review 是代码层面的静态分析，它发现不了运行时的配置问题（比如生产环境的 IAM 权限过宽）、基础设施层面的风险，以及依赖于特定业务逻辑才能触发的漏洞。它是安全流程的一个环节，不是全部。

这套工具链的最大价值不在于某个命令有多强，而在于它们串联起来能形成一条自动化的质量门禁，让你在提 PR 前就能把大部分低级问题过滤掉，把人工 review 的注意力留给真正需要讨论的问题。下一篇我们聊模型与推理控制——如何在不同任务里选对模型，让性能和成本都达到最优。

实操清单

  • 功能完成后执行 /diff 确认改动范围符合预期
  • 执行 /simplify 整理代码可读性
  • 执行 /code-review 进行质量审查（日常用 medium，重要模块用 high）
  • 使用 /code-review --fix 前先 git commit 保留还原点
  • 涉及认证/输入处理/数据存储时执行 /security-review
  • 核心模块上线前尝试一次 /code-review ultra 深度审查
  • 审查团队 PR 时使用 /review <PR URL> 并配合 --comment 发布意见