内容来源：Claude Code Blog (claud cod)。https://claudcod.com/blog/claude-code-review-command/
原题：Claude Code /code-review: Catch Bugs Before You Push
原发布时间：2026-05-24
Claude Code 的
/code-review命令会扫描 Diff 中的正确性 Bug，支持不同推理强度，还能通过--comment将行内评论发布到 GitHub PR。
归档校注
• 这是 Mohamed EL BATHA 的独立教程，不是 Anthropic 官方文章；原文发布于 2026-05-24，并于 2026-05-27 更新。
• 当前语法为 /code-review [low|medium|high|xhigh|max|ultra] [--fix] [--comment] [target]。原文采用 2026 年 5 月时的语法，缺少 ultra 与 --fix。
• 原文多次声称 /simplify 仍是别名。从 v2.1.154 开始，这一说法已不再准确：/simplify 现在是独立的纯清理审查，会直接应用修复，但不会寻找正确性 Bug。
• 默认本地范围比原文所称的“未提交 Diff”更广。当前文档说明，它包含当前分支领先上游的提交、已暂存改动，以及工作区中尚未提交的改动。
• 当前 /code-review 会检查正确性 Bug，也会寻找涉及复用、简化与效率的清理机会；原文只描述 Bug，范围比当前行为更窄。
• 目前首选的云端审查调用方式是 /code-review ultra，而 /ultrareview 仍是别名。云端功能能否使用取决于身份验证方式、提供商、套餐及数据保留设置；当 ultrareview 不可用时，会回退到本地审查。
• 原文推荐把 high 作为实用默认值。当前模型指南建议多数 Opus 4.7 编程工作使用 xhigh，但支持的级别和默认值会因模型而异；这只是一项偏好，不是通用规则。
• “Bundled Skill”身份并不能证明用户一定可以检查、Fork 或覆盖 /code-review，当前引用的文档并未支持这一说法。Bundled Skills 与用户编写的 Skills 同样由提示词驱动，但不能仅凭这一点推断源码可见性与覆盖行为。
• 当前官方 /code-review 文档没有说明 --comment 会专门通过 gh pr view 检测 PR，也没有说明它要求本地 gh CLI 已完成身份验证。请把这项实现细节视为具有版本敏感性。
• 20～60 秒的运行时间与审查者偏好均为作者的个人经验，没有提供仓库、模型、Diff 大小、对话记录、样本数量或基准测试方法。
• 本地与托管式 AI 审查都只是尽力而为的辅助检查，可能漏报，也可能误报。高影响改动仍需配合测试、安全控制和责任明确的人工审查。
• 正文没有位图、视频、音频或 iframe。页首内联 SVG、声明的社交封面和作者头像均已归档；SVG 中被源站错误转义的八个图形元素已恢复。源站返回的社交封面本身接近空白，只有顶部色条和底部浅线；这些情况均记录在媒体清单中。
详细结构化校注见 source_snapshot.json。
原文
第一次在 Claude Code 命令列表中看到 /code-review 时，我以为这是一条新命令。其实不是。它是 /simplify 的新名称，随 2026 年 5 月 21 日发布的 v2.1.147 推出，而且现在的职责更集中：扫描当前 Git Diff 中的正确性 Bug，报告发现的问题，却不会改动任何文件。旧版的清理与重构行为已经完全移除。
过去几周，我每次推送前都会运行这条命令。缩小范围是正确的决定。一条命令有时重写代码、有时查找 Bug，实在很难建立清晰预期。现在 /code-review 只有一项工作，而且做得很好。
/code-review 究竟做什么
/code-review 会读取未提交的 Diff，交给 Claude 的审查流水线处理，再列出发现的问题。在基本使用中，它不会编辑文件、打开浏览器，也不需要 GitHub 凭据。输出是一份朴素的潜在正确性 Bug 清单，包括所在文件与简短说明。
这条命令被归类为 Bundled Skill，意味着它是一套由提示词驱动的工作流，而不是硬编码的 CLI 行为。在任意会话中运行 /skills，即可查看完整的 Bundled Skills 清单。这种分类也意味着，如果项目需要在 Skill 层面定制审查行为，你可以检查、Fork 或覆盖它。
不带参数运行时，会使用当前会话设置的推理强度：
/code-review
对于小改动，这足以快速检查是否存在明显问题。面对改动数百行的功能分支时，我总会明确传入推理强度，而不是依赖会话碰巧采用的默认值。
还有一个重要细节：/simplify 仍可作为别名使用。如果你的脚本、Hooks 或习惯都围绕 /simplify 构建，不会因此失效。这次更名是为了提升清晰度，而非引入破坏性变更。请注意，v2.1.152 更新了 /simplify 别名，使其改为调用 /code-review --fix，直接把发现的问题修复到工作区。如果你依赖 /simplify 进行只读审查，以后请改用不带 --fix 的 /code-review。
推理强度：从 Low 到 Max
完整语法为：
/code-review [low|medium|high|xhigh|max] [--comment] [target]
每档推理强度都在速度、Token 成本与覆盖范围之间作出不同权衡：
low 只返回置信度高、影响显著的问题。我会把它用于配置编辑、锁文件更新或文案修改等小改动，希望快速增加一道安全网，又不想看到太多噪声。
medium 是大多数功能开发的默认甜点位。它可以发现真实 Bug，又不会产生大量不确定的问题。
high 会进行更广泛的检查。凡是要合并进主分支的改动，我都会选择它。它有时会标出最后被证实为误报的问题，但我宁愿多筛选几条结果，也不愿让逻辑错误进入生产环境。
xhigh 与 max 适合安全敏感代码、复杂算法改动或身份验证流程，因为这些场景需要 Claude 深入推理整个 Diff。它们运行时间更长，也会产生更多需要人工判断与筛选的推测性发现。
Claude Code 推理强度系统在这里的工作方式与普通任务相同。大多数 PR 的实用默认值是 high：速度足以融入推送前习惯，检查深度也足以发现真实问题。
使用 --comment 发布 GitHub PR 行内评论
这个功能对我的合并前工作流改变最大。传入 --comment 后，Claude 会把发现的问题直接作为行内评论发布到当前打开的 GitHub PR，并附着在问题所在的具体代码行上：
/code-review high --comment
Claude 会使用 gh pr view，从当前分支自动检测打开的 PR。结果会作为标准 GitHub Review 显示，在 Diff 上附带行内评论。如果 Claude 没有发现问题，它会发布一条简短确认评论，说明未检测到问题。
这个参数出现以前，我需要把终端中的审查结果复制出来，再手动粘贴到 GitHub 作为 PR 评论。现在的工作流变成：完成代码，运行 /code-review high --comment；等我在浏览器中打开 PR 页面时，审查结果已经出现在 GitHub 上。
命令也接受可选的目标参数：
# 只审查 src/auth/ 下的改动
/code-review high --comment src/auth/
# 按编号审查指定 PR
/code-review high --comment 142
使用路径形式时，审查会集中于 Diff 中某个子目录。当大型改动集涉及多个无关区域时，这很有帮助。使用 PR 编号时，命令会审查指定的 Pull Request，而不是当前工作区的 Diff。
此功能要求安装 gh CLI 并完成身份验证。如果你还没有在 Claude Code Pull Request 工作流中使用 gh，无论是否使用该功能，都值得进行配置。
/code-review、/ultrareview 与 Code Review 的区别
如果一直在使用 Claude Code 处理 PR，你很可能见过多种审查选项，并且好奇它们有何区别。下面是实用层面的划分。
/code-review 在本地运行、速度快，并以会话为基础。它在当前终端中运行，使用会话所选的模型与推理强度，成本与其他 Claude Code 任务相同。它适合在推送前审查你自己的 Diff。
/ultrareview 会在沙箱中启动一场基于云端的多智能体审查。多个专业智能体并行分析整份 PR，并结合完整代码库，而不是只查看 Diff。它更全面、成本更高、耗时也更长。我会把它用于大型功能，或涉及安全关键代码路径的任何改动。
托管式 Code Review 服务是组织级 GitHub App。管理员可以按仓库启用，并配置触发行为：PR 创建后运行一次、每次推送时运行，或只允许手动触发。它会自动运行，不需要开发者执行命令。这项服务要求 Team 或 Enterprise 套餐，并通过 Usage Credits 单独计费。
对于个人工作流与独立开发者而言，/code-review 已经足够。--comment 参数能以一次普通 Claude 会话的成本提供 GitHub 行内反馈，自然地融入每天的推送节奏。
一个真正能坚持下来的推送前习惯
我一直使用 /code-review，是因为它恰好能融入现有工作流中的一个固定节点。我完成改动、运行测试、通过 /diff 检查 Diff，然后根据自己对改动的信心，运行 /code-review medium 或 /code-review high。对大多数 Diff 而言，它只需要约 20～60 秒。
PR 准备好接受审查时，我会运行 /code-review high --comment，为审查者提供一轮可以直接回应的初步结果，而不必从零开始。审查者告诉我，他们更喜欢已经附带 Claude 审查的 PR，因为显而易见的问题已经标出，他们可以把注意力放在架构与意图上。
下面是我打开 PR 前运行的基本终端命令序列：
# 检查发生了哪些改动
/diff
# 进行全面审查，并将结果发布到 GitHub
/code-review high --comment
这就是完整工作流。无需切换上下文、无需复制粘贴，也不必为另一款审查工具单独进行身份验证。
如需了解更多内容，请浏览 Claude Code Workflows 指南中的所有文章。
要点总结
• /code-review 在 v2.1.147（2026 年 5 月 21 日）由 /simplify 更名而来；/simplify 仍可作为别名使用
• 它是一项 Bundled Skill，会扫描当前 Git Diff 中的正确性 Bug，但不会编辑任何文件
• 推理强度从 low（速度快，只报告高置信度问题）到 max（深度检查，可能包含推测性发现）
• 传入 --comment 可把发现的问题作为 GitHub PR 行内评论发布到当前打开的 PR；需要 gh CLI
• 可以通过可选参数指定某个子目录路径或 PR 编号
• /code-review 在本地运行并以会话为基础；/ultrareview 是基于云端的多智能体审查；托管式 Code Review 服务则是组织级自动化方案
• 在请求人工审查前运行 /code-review high --comment，是适用于各种 Pull Request 的可靠默认习惯
