高手进阶（三）：Claude Code代码审查2026完全指南：从/review到/ultrareview三档选型与实战

代码审查 2026——从 `/review` 到 `/ultrareview` 的完整体系

Windows 10/11 · Claude Code v2.1.x (2026-05) · DeepSeek V4 Pro / Anthropic API · 🟡 中度时效 · 最后更新 2026-05-08

一、这篇教程解决什么问题

一句话定位：代码审查是日常最高频的开发场景之一。Claude Code 在 2026 年 3-4 月密集发布了多代理审查体系，从本地单次扫描的 /review 一路升级到云端多代理并行的 /ultrareview。这篇把三档审查能力讲透，给你一张表选型、一套流程落地、五个 Debug 兜底。

跳读指南：如果你已经在用 /review，直接跳到第四节 ECC 审查代理了解专业代理的增量价值。如果你只关心 /ultrareview，跳到第五节。对三档体系没概念的，务必先看第二节全景对比，这是整篇的导航图。

阅读前提（硬条件，可逐条验证）：

Claude Code CLI 已安装并能正常启动（参考《新手上路（二）》）
了解 Git 基础操作（commit / branch / diff）
已配置 GitHub CLI（gh）并完成认证（运行 gh auth status 验证）
使用 Windows 10 或 Windows 11

DeepSeek 用户注意：/ultrareview 和 GitHub PR Code Review 运行在 Anthropic 云端基础设施上，仅限 Anthropic API 用户。/review（本地）、/security-review（本地）、ECC 的 code-reviewer / security-reviewer agent 均可在 DeepSeek 上使用。本文完整覆盖两条路径，每节标注兼容性。

读完能得到什么：

一张三档审查体系全景对比表，一眼看清 /review / ECC agent / /ultrareview 各自什么时候用
掌握 /review 和 /security-review 的本地用法与输出格式
理解 ECC code-reviewer 和 security-reviewer 的专业审查维度和严重性分级
深入理解 /ultrareview 的多代理并行架构——为什么它能做到 <1% 误报
掌握 GitHub PR Code Review 的触发方式和 REVIEW.md 自定义规则
一套可落地的审查意见分级标准（必须改 / 建议改 / 可选）
5 个真实 Debug 场景的五段式排查

二、全景速览：Claude Code 代码审查三档体系

在分别深入每个工具之前，先建立全局视图。Claude Code 在 2026 年 5 月有三档代码审查能力：

维度	轻量档：`/review` + `/security-review`	标准档：ECC code-reviewer / security-reviewer	深度档：`/ultrareview`
运行位置	本地终端会话内	本地子代理（独立上下文窗口）	Anthropic 云端沙箱
审查深度	单次扫描	专项子代理（一次一个维度）	多代理舰队并行 + 独立验证
审查维度	正确性 / 安全 / 风格 / 测试	安全（OWASP）/ 代码质量 / 语言特定模式	逻辑 / 安全 / 边界 / 性能 / 回归，各由独立代理负责
耗时	数秒到 2 分钟	1-3 分钟	5-20 分钟
成本	计入正常 Token 用量	计入正常 Token 用量	$5-20/次（额外用量）
DeepSeek 兼容	✅ 完全可用	✅ 完全可用（子代理选 Flash 省钱）	❌ 仅 Anthropic API
最佳场景	提交前快速检查、小改动	中等 PR、需要语言专项审查	大 PR（>500 行）、auth/支付/迁移等高风险变更
误报率	中等（无验证环节）	中等（依赖代理质量）	<1%（独立复现验证）

一句话选型

小改动 / 快速迭代      → /review（免费，秒级）
中 PR / 需要专项深度   → ECC code-reviewer + security-reviewer（免费，分钟级）
大 PR / 高风险变更     → /ultrareview（$5-20/次，5-20 分钟，<1% 误报）
团队级 / 自动审查      → GitHub PR Code Review（$15-25/次，Team/Enterprise）

这三档不是互斥的——典型工作流是 /review 日常用，合并前跑一次 /ultrareview。

三、轻量档：`/review` 和 `/security-review` 本地审查

3.1 `/review`——内置的快速审查

/review 是 Claude Code 出厂自带的内置命令。不需要安装任何插件。

基本用法：

# 审查当前分支的未提交改动（最常用）
/review

# 审查指定 GitHub PR
/review 42

工作机制：

/review 在本地会话内执行，分两步：

运行 git diff 收集改动
用当前会话的模型对 diff 做单次审查

输出覆盖以下维度：

功能概述：这个 PR/改动做了什么
代码质量与风格：是否符合项目惯例
具体改进建议：有文件行号的建议
潜在问题与风险：边界情况、逻辑错误
测试覆盖与安全考量：缺失的测试、明显的安全风险

实际输出示例：

## Review Summary

This PR adds rate limiting to the `/api/auth` endpoint.

### Issues Found

1. **BLOCKER** — `src/middleware/rateLimit.ts:23`
   Token bucket refill is not thread-safe. If two requests arrive within
   the same millisecond, both could be counted as under-limit.

2. **WARNING** — `src/middleware/rateLimit.ts:45`
   Hardcoded limit of 100 req/min. Should be configurable via env var.

3. **SUGGESTION** — `tests/rateLimit.test.ts` is missing a test for
   the edge case where the Redis connection drops mid-count.

### Verdict: REQUEST CHANGES (1 blocker)

适用场景与限制：

✅ 每次 git commit 前跑一次，拦住低级错误
✅ PR 小于 200 行时，单次扫描基本够用
⚠️ 单次扫描，没有验证环节——可能产生误报
⚠️ 模型能力决定审查质量——用 DeepSeek V4-Flash 跑 /review 会比 Opus 浅

3.2 `/security-review`——专注安全的内置命令

/security-review 是 /review 的安全特化版，内置命令，同样不需要安装。

# 审查当前分支的安全问题
/security-review

检测范围：

类别	检测内容
SQL 注入	字符串拼接 SQL、未参数化查询
XSS	未转义的用户输入渲染到 HTML/JSX
认证缺陷	缺失的 auth 检查、弱 token 处理
不安全的数据处理	未验证的用户输入、路径遍历
依赖漏洞	已知的第三方包 CVE
密钥泄露	硬编码的 API Key、密码、token

注意：/security-review 必须在 Git 仓库内运行，它依赖 git diff 来确定审查范围。如果在非 Git 目录运行，会收到 Git 错误。

3.3 两个本地命令的使用节奏

写代码 → git add → /review（查正确性）→ 改
       → /security-review（查安全）→ 改
       → git commit

每个改动在提交前走一遍这个循环，成本几乎为零（只消耗正常 Token），但能拦住大量低级问题。

四、标准档：ECC code-reviewer 与 security-reviewer 代理

ECC（Everything Claude Code）插件系统提供了两个专业审查子代理，比内置的 /review 更结构化。两者均可在 DeepSeek 上运行。

4.1 code-reviewer——质量与安全并重

code-reviewer 用 Sonnet 模型运行，按检查清单逐项审查：

优先级	类别	检查项示例
CRITICAL	安全	硬编码密钥、SQL 注入、XSS、路径遍历、CSRF、认证绕过、不安全依赖
HIGH	代码质量	大函数（>50 行）、深层嵌套（>4 层）、缺失错误处理、console.log 残留、缺失测试、死代码
HIGH	语言特定	Node: 未验证输入、缺失限流、N+1 查询；React: 不必要重渲染、缺失 key

/code-review    # Claude 自动路由到 code-reviewer 子代理

输出为结构化格式，每条发现标注 文件:行号 + 严重性。

4.2 security-reviewer——OWASP Top 10 专项

security-reviewer 专注安全漏洞，覆盖 OWASP Top 10：注入攻击、认证失效、敏感数据暴露、XXE、访问控制失效、安全配置错误、XSS、不安全反序列化、已知漏洞组件、日志监控不足。

/security-scan   # 或 Claude 在敏感代码改动后自动建议运行

# 或在涉及敏感代码改动时，Claude 会自动建议运行

4.3 ECC 代理 vs 内置 `/review` 的区别

维度	内置 `/review`	ECC code-reviewer
审查粒度	通用，覆盖所有方面	按检查清单逐项对照
严重性分级	无统一标准	BLOCKER / CRITICAL / WARNING / SUGGESTION
语言针对性	通用	针对语言适配（TypeScript 审查者 vs Go 审查者不同）
输出格式	自由文本	结构化（文件:行号 + 严重性 + 类别）
可靠性	依赖当前会话模型	固定用 Sonnet（质量稳定）
可定制性	有限	可修改代理定义文件

建议：日常用 /review 快速扫，提交前用 ECC code-reviewer 做正式审查。

五、深度档：`/ultrareview` 云端多代理审查

5.1 为什么需要 `/ultrareview`

传统的代码审查工具有一个根本矛盾：发现 bug 和确认 bug 是两个不同的任务。/review 把它们合在一起——同一个模型既找问题又判断问题是否真实。结果是：要么漏掉真 bug（因为模型不够自信不敢报），要么报告一堆假问题（因为模型在幻觉）。

/ultrareview 通过多代理架构把这两个任务分开了。这就是它能把误报率压到 <1% 的核心原因。

DeepSeek 兼容性：❌ 不可用。/ultrareview 运行在 Anthropic 云端，需要 Claude.ai 账号认证。DeepSeek 用户的等效替代方案见第五节末尾。

5.2 架构：多代理舰队 + 独立验证

你的分支/PR → 云端沙箱克隆仓库
  ├─→ 代理 1：逻辑错误（边界/null/类型不匹配）
  ├─→ 代理 2：安全漏洞（注入/权限/密钥泄露）
  ├─→ 代理 3：边界情况（竞态条件/并发）
  ├─→ 代理 4：性能风险（O(n²)/内存分配/同步阻塞）
  └─→ 代理 5：回归检测（破坏性变更/API 兼容性）
       ↓
  独立验证层（每个候选 bug 由另一代理复现确认 → 复现不了的丢弃）
       ↓
  去重 + 严重性排序 → CLI/Desktop 通知（文件:行号 + 解释）

关键设计：

代理并行：5 个审查代理同时工作（大 PR 可扩展到 20 个），每个拥有独立上下文窗口
独立验证：发现代理与验证代理分离——候选 bug 必须被独立复现才会进入最终报告，这是 <1% 误报率的核心保障
不占本地资源：全部在云端运行，终端可继续工作甚至关闭 Claude Code
仅人工启动：/ultrareview 只在你主动调用时运行，不会自动触发

5.3 前置条件

# 1. 确保版本 ≥ 2.1.86
claude --version

# 2. 登录 Claude.ai 账号（不能用 API Key）
/login

# 3. 确保在 Git 仓库内
git status

# 4. 如果需要付费运行，开通额外用量
/extra-usage

不支持的运行环境：

Amazon Bedrock
Google Cloud Vertex AI
Microsoft Foundry
启用了 Zero Data Retention（ZDR）的组织

5.4 基本用法

# 审查当前分支 vs 默认分支（含未提交和已暂存改动）
/ultrareview

# 审查 GitHub PR #1234
/ultrareview 1234

# 审查当前分支 vs 指定基准分支
/ultrareview main

运行后会弹出确认对话框，显示：

审查范围（文件数、行数）
剩余免费运行次数
预估费用

确认后审查在后台运行，你可以继续使用 Claude Code。随时用 /tasks 查看进度。

5.5 Headless 模式（CI/CD 集成）

# 非交互式运行，阻塞等待结果，打印到 stdout
claude ultrareview

# 审查特定 PR
claude ultrareview 1234

# 指定基准分支
claude ultrareview origin/main

退出码：0 = 完成（有或没有发现）、1 = 启动失败/错误/超时、130 = Ctrl-C 中断。

中断 claude ultrareview 子命令不会停止远程审查——远程会话继续运行。终端会打印一个 URL，可以在浏览器中跟踪。

5.6 定价与配额

计划	免费运行次数	免费后单价	说明
Pro ($20/月)	3 次（一次性，已过期 2026-05-05）	$5-20/次	额外用量
Max 5x ($100/月)	3 次（一次性，已过期 2026-05-05）	$5-20/次	额外用量
Max 20x ($200/月)	3 次（一次性，已过期 2026-05-05）	$5-20/次	额外用量
Team ($30/座/月)	无	$5-20/次	额外用量，管理员需先开通
Enterprise	无	$5-20/次	额外用量，管理员需先开通

2026-05-05 后：所有计划的免费运行已过期。每次 /ultrareview 都是付费的，费用根据改动大小在 $5-$ 20 之间。注意额外用量和计划内用量是分开计费的——额外用量需要单独开通。

5.7 `/ultrareview` vs `/review` 的本质区别

	`/review`	`/ultrareview`
运行位置	本地会话内	云端沙箱
架构	单代理单次扫描	多代理舰队 + 独立验证
耗时	数秒到 2 分钟	5-20 分钟
成本	计入正常用量	$5-20/次（额外用量）
误报控制	无验证环节	每个发现由独立代理复现确认
适用	每次改动的快速反馈	合并前的高信心审查

一句话：/review 是日常用的快速检查，/ultrareview 是合并前的最终防线。

5.8 真实案例

来自 Anthropic 官方博客（2026-03）：一次生产服务 PR 中，Code Review 标记了一行在 diff 中看起来完全正常、但在整个代码库上下文中会破坏关键边界条件的改动。工程师事后承认"我自己永远看不出来"。TrueNAS 社区反馈 /ultrareview 发现了一个存在数月、多次人工审查遗漏的 ZFS 加密密钥缓存 bug。

5.9 DeepSeek 用户的替代方案

如果你用的是 DeepSeek API，/ultrareview 不可用。以下是等效的本地替代方案：

方案 A：ECC 代理组合（免费，推荐）

# 在 Claude Code 会话中，依次运行
/code-review        # ECC code-reviewer 质量审查
/security-scan      # ECC security-reviewer 安全审查

两个代理覆盖了 /ultrareview 的核心审查维度。缺点是缺少独立验证环节，可能产生更多误报。

方案 B：自定义多代理审查命令

在 .claude/commands/ultrareview-local.md 中创建：

---
description: DeepSeek-compatible multi-agent code review
allowed-tools: Bash(git:*), Read, Grep, Glob
---

Review the current branch against the default branch in depth.

Changes:
!`git diff origin/main...HEAD --stat`

Full diff:
!`git diff origin/main...HEAD`

Launch 3 subagents in parallel to review:
1. Security agent: injection, XSS, auth bypass, secrets, unsafe crypto
2. Logic agent: boundary conditions, null safety, race conditions, type safety
3. Performance agent: N+1 queries, O(n²), missing caching, sync blocking

Each agent returns findings with file:line + severity.
Aggregate and deduplicate. Output a consolidated report ranked by severity.

然后运行 /ultrareview-local。比 ECC 代理组合更接近 /ultrareview 的并行架构（但仍在本地运行，受限于本地模型的验证能力）。

三档 DeepSeek 等效对照：

Anthropic 用户	DeepSeek 用户	深度差距
`/review`	`/review`	无
ECC code-reviewer	ECC code-reviewer	无
`/ultrareview`	ECC code-reviewer + security-reviewer 并联	缺少独立验证、缺少 5+ 代理并行

六、跨平台审查：GitHub PR Code Review（Team/Enterprise）

除了 CLI 内的审查命令，Claude Code 还提供了一套 GitHub 集成的自动审查服务——在 GitHub PR 上自动运行，结果直接显示为行内评论。

DeepSeek 兼容性：❌ 不可用。这是 Anthropic 托管服务，仅限 Team/Enterprise 计划。

6.1 工作流程

PR 创建/推送 → GitHub App 检测 → 多代理并行分析 diff + 完整代码库上下文 → 验证过滤误报 → 去重排序 → 行内评论 + 摘要评论 + Check Run。

6.2 三种触发模式

模式	行为	成本
PR 创建时一次	PR 打开或标记 ready 时运行一次	最低
每次推送	每次推送到 PR 分支都运行，自动解决已修复问题的评论线程	最高（推送次数 × 单价）
手动	仅当有人评论 `@claude review` 时运行	可控

手动模式下评论 @claude review once 只运行一次且不订阅后续推送，适合长周期 PR 的按需审查。

6.3 自定义审查行为

CLAUDE.md：Code Review 会读取仓库中的 CLAUDE.md。新引入的违反 CLAUDE.md 规则的问题会被标记为 nit 级别。双向生效——如果 PR 修改了 CLAUDE.md 覆盖的代码但没有更新 CLAUDE.md 本身，也会被标记。

REVIEW.md（仓库根目录，自动发现）：注入到每个审查代理的系统提示作为最高优先级。示例：

# REVIEW.md
- Any SQL without parameterization → 🔴 Important
- Missing TypeScript type on public export → 🟡 Nit
- New /api routes MUST have integration test
- Any new env var MUST be in .env.example
- DB migrations MUST include rollback script

6.4 严重性标记

标记	含义
🔴 Important	应在合并前修复的 bug
🟡 Nit	小问题，值得修复但不阻塞
🟣 Pre-existing	代码库中已存在的问题，非本 PR 引入

6.5 内部数据参考

指标	数据
PR 反馈率（引入前→后）	16% → 54%
大 PR（>1000行）发现率	84%，平均 7.5 个问题
小 PR（<50行）发现率	31%，平均 0.5 个问题
误报率	<1%
平均耗时/费用	~20 分钟 / $15-25

数据来源：Anthropic 官方博客（2026-03），自报数据。

七、审查意见分级与工作流整合

7.1 统一的严重性分级标准

不管用哪档审查工具，建议团队统一使用以下分级标准：

级别	标签	含义	合并条件
Blocker	🔴	会导致生产事故：数据丢失、安全漏洞、服务崩溃	必须修复后才能合并
Major	🟠	可能导致异常行为：逻辑错误、边界条件遗漏、性能严重退化	必须修复或明确记录豁免理由
Minor	🟡	代码质量问题：命名不当、缺失注释、可读性差	建议修复，不阻塞合并
Nit	⚪	风格偏好：空格、引号风格、import 排序	可选修复

7.2 推荐工作流：三阶段审查

阶段 1：日常开发（每次 commit 前）
    git add → /review → 修复 → git commit
    成本：零额外费用，计入正常用量

阶段 2：PR 提交前（本地深度审查）
    /code-review + /security-scan → 修复 → git push
    成本：零额外费用，计入正常用量

阶段 3：合并前（云端最终验证）
    /ultrareview → 修复 → 合并
    成本：$5-20/次

    或者（Team/Enterprise）：
    开 PR → 等待自动审查完成 → 审查发现 → 合并
    成本：$15-25/次

7.3 Git Hook 集成

在 .claude/settings.local.json 中配置 pre-commit Hook 实现自动审查（适合质量要求高的项目，注意每次 commit 的等待时间和 Token 消耗）：

{
  "hooks": {
    "pre-commit": [{
      "matcher": "*.{ts,tsx,js,jsx,py,go}",
      "command": "claude --print \"/review staged changes. Exit 1 if BLOCKER found.\"",
      "blocking": true
    }]
  }
}

八、Debug #1 — `/review` 不识别 diff，返回"No changes to review"

报错日志

> /review
No changes to review.

根因

/review 依赖 git diff 收集改动。三种情况会导致"认为没有改动"：(1) 刚提交完，所有改动已进入 HEAD；(2) 在子目录运行，仓库在上级目录；(3) 文件被 .gitignore 忽略。

代码修复

git status                      # 检查状态
git diff HEAD~1 | claude --print "Review this diff"  # 若已提交
cd $(git rev-parse --show-toplevel)  # 回到仓库根目录
git check-ignore -v src/generated/config.ts  # 检查是否被忽略

验证

git diff --stat    # 应列出改动文件
/review            # 应正常输出审查结果

九、Debug #2 — `/ultrareview` 拒绝运行，提示"Authentication required"

报错日志

> /ultrareview

Error: Ultrareview requires authentication with a Claude.ai account.
You are currently signed in with an API key only.
Run /login to authenticate with Claude.ai first.

根因

/ultrareview 在 Anthropic 云端基础设施上运行，需要 Claude.ai 账号认证。API Key 只授权模型调用，不授权云端计算资源——多代理沙箱编排在 Anthropic 托管服务上，架构上就与 API Key 的"纯模型调用"模式不同。

代码修复

/login              # 浏览器 OAuth 授权
/extra-usage        # Team/Enterprise 需先开通额外用量
/ultrareview        # 重新运行

验证

# 确认认证状态
/login
# 应显示："Logged in as <你的账号> (Pro/Max/Team/Enterprise)"

# 运行确认
/ultrareview
# 应显示确认对话框，包含审查范围和剩余运行次数

十、Debug #3 — `/ultrareview` 对小于 50 行的 PR 不触发或耗时过长

报错日志

> /ultrareview

Starting ultrareview...
Review completed in 22 minutes. 0 findings.

或者：

> /ultrareview 42

Error: This PR has fewer than 10 lines changed.
Consider using /review instead.

根因

/ultrareview 为大改动设计。改动 <50 行时性价比急剧下降——5 个代理的成本不变（$5-20），但发现概率从 84%（大 PR）降到 31%（小 PR）。

代码修复

# <50行 → /review
# 50-500行 → /code-review + /security-scan
# >500行或涉及 auth/支付/迁移 → /ultrareview

在 CLAUDE.md 中加入自动建议规则（参考第七节的工作流建议）。

十一、Debug #4 — `/security-review` 报错"fatal: ambiguous argument"

报错日志

> /security-review

fatal: ambiguous argument 'origin/HEAD...': unknown revision or path
not in the working tree.

根因

/security-review 内部运行 git diff origin/HEAD... 确定审查范围。origin/HEAD 悬空的两大原因：(1) clone 后未 fetch；(2) 远程默认分支改名（如 master → main）。

代码修复

git fetch origin
git remote set-head origin --auto
git branch -r | grep HEAD   # 应输出：origin/HEAD -> origin/main

验证

git remote show origin | grep "HEAD branch"  # 应输出：HEAD branch: main
/security-review                              # 应正常开始审查

十二、Debug #5 — ECC code-reviewer 审查结果过于冗长，淹没关键问题

报错日志

不是真正的"报错"，而是输出质量问题：

> /code-review
# 输出了 47 条发现，其中 4 条是真正的 bug，
# 28 条是"建议把 const 改成 let"级别的 nit，
# 15 条是"函数名可以考虑更语义化"的建议
# 真正的 blocker 被淹没在噪声中

根因

ECC code-reviewer 默认全面审查，不区分严重性，风格建议（nit）与真正的 bug（blocker）混在同一输出流。缺少验证环节，误报率高时会导致"狼来了"效应。

代码修复

在 CLAUDE.md 中添加审查指令，过滤低信号输出：

## Code Review Configuration

When running code review via ECC code-reviewer or /review:

### Priority — only flag HIGH SIGNAL issues
- The code will fail to compile (syntax errors, type errors, missing imports)
- The code will produce wrong results regardless of inputs (clear logic errors)
- Security vulnerabilities (injection, auth bypass, exposed secrets)

### Do NOT flag
- Code style or formatting preferences
- Variable naming suggestions unless misleading
- "Consider refactoring" without a concrete bug
- Issues that depend on specific runtime state to verify
- Subjective improvements

### Output format
- Group by severity: BLOCKER → MAJOR → MINOR
- File:line citation for every finding
- Skip the "looks good overall" pleasantries
- If no BLOCKER or MAJOR findings: output "PASS — no blocking issues"

验证

# 修改配置后重新运行
/code-review

# 应输出：
# - 5-10 条发现
# - 按严重性分组
# - 每条有文件:行号
# - 没有风格建议和"可以考虑"的模糊建议

十三、速查卡

13.1 审查工具选型矩阵

场景	工具	命令	耗时	成本	DeepSeek
提交前快速扫	`/review`	`/review`	秒级	正常用量	✅
安全专项扫	`/security-review`	`/security-review`	秒级	正常用量	✅
中等 PR 质量审查	ECC code-reviewer	`/code-review`	1-3 分钟	正常用量	✅
安全漏洞审计	ECC security-reviewer	`/security-scan`	1-3 分钟	正常用量	✅
大 PR 深度审查	`/ultrareview`	`/ultrareview [PR]`	5-20 分钟	$5-20	❌
团队自动审查	GitHub PR Code Review	自动/`@claude review`	~20 分钟	$15-25	❌
CI 非交互审查	`claude ultrareview`	`claude ultrareview`	5-20 分钟	$5-20	❌

13.2 关键配置路径

配置	路径	用途
自定义 `/review` 行为	`.claude/commands/review.md`	覆盖内置 `/review` 的审查维度
ECC code-reviewer 配置	`.claude/agents/code-reviewer.md`	自定义审查清单和严重性标准
GitHub PR 审查规则	仓库根目录 `REVIEW.md`	定义 PR Code Review 的审查规则
项目级审查指令	仓库根目录 `CLAUDE.md`	所有审查工具共享的项目规范
Git Hook 审查	`.claude/settings.local.json`	pre-commit 自动审查

13.3 常见报错 → 解决方案

报错特征	解决	详情
"No changes to review"	确认有未提交改动，在仓库根目录运行	Debug #1
"Authentication required"	`/login` 登录 Claude.ai 账号	Debug #2
`/ultrareview` 对小 PR 返回 0 findings	改用 `/review` 或 `/code-review`	Debug #3
"fatal: ambiguous argument"	`git remote set-head origin --auto`	Debug #4
审查输出太长淹没关键问题	配置 CLAUDE.md 中的审查指令过滤 nit	Debug #5
`/ultrareview` 提示"extra usage not enabled"	`/extra-usage` 开通或联系管理员	Debug #2
GitHub PR 审查不触发	确认安装了 GitHub App + 仓库已选择	检查 claude.com/settings

十四、扩展阅读

本系列相关文章：

高手进阶（一）：Claude Code 五端完整指南 — IDE 中的审查工作流和权限配置
高手进阶（二）：Routines 云端自动化 — 可以配置 Routine 定时运行代码审查
高手进阶（四）：自定义 Skill 与插件市场 — 制作自己的代码审查 Skill（即将发布）
高手进阶（五）：子代理与并行开发 — 子代理机制是审查代理的底层基础
新手上路（四）：MCP 协议实战 — GitHub MCP Server 是 PR 审查的基础设施

参考文献

Find bugs with ultrareview — Claude Code Docs — /ultrareview 官方文档，定价、用法、与 /review 的对比
Code Review — Claude Code Docs — GitHub PR Code Review 设置指南，触发模式、REVIEW.md 自定义
Bringing Code Review to Claude Code — Anthropic 官方博客，内部使用数据（54% PR 反馈率、<1% 误报率）
Set up Code Review for Claude Code — 管理员配置指南，计费与配额说明
Automated Security Reviews in Claude Code — /security-review 官方文档
Claude Code /ultrareview: Cloud Bug-Hunting Fleet — 第三方深入分析，多代理架构和定价对比
Everything Claude Code (ECC) — ECC 插件系统，code-reviewer 和 security-reviewer 代理定义
Claude Code Slash Commands: Complete Guide (2026) — Claude Code 内置命令全指南

高手进阶（三）：Claude Code代码审查2026完全指南：从/review到/ultrareview三档选型与实战

代码审查 2026——从 /review 到 /ultrareview 的完整体系

一、这篇教程解决什么问题

二、全景速览：Claude Code 代码审查三档体系

一句话选型

三、轻量档：/review 和 /security-review 本地审查

3.1 /review——内置的快速审查

3.2 /security-review——专注安全的内置命令

3.3 两个本地命令的使用节奏

四、标准档：ECC code-reviewer 与 security-reviewer 代理

4.1 code-reviewer——质量与安全并重

4.2 security-reviewer——OWASP Top 10 专项

4.3 ECC 代理 vs 内置 /review 的区别

五、深度档：/ultrareview 云端多代理审查

5.1 为什么需要 /ultrareview

5.2 架构：多代理舰队 + 独立验证

5.3 前置条件

5.4 基本用法

5.5 Headless 模式（CI/CD 集成）

5.6 定价与配额

5.7 /ultrareview vs /review 的本质区别

5.8 真实案例

5.9 DeepSeek 用户的替代方案

六、跨平台审查：GitHub PR Code Review（Team/Enterprise）

6.1 工作流程

6.2 三种触发模式

6.3 自定义审查行为

6.4 严重性标记

6.5 内部数据参考

七、审查意见分级与工作流整合

7.1 统一的严重性分级标准

7.2 推荐工作流：三阶段审查

7.3 Git Hook 集成

八、Debug #1 — /review 不识别 diff，返回"No changes to review"

报错日志

根因

代码修复

验证

九、Debug #2 — /ultrareview 拒绝运行，提示"Authentication required"

报错日志

根因

代码修复

验证

十、Debug #3 — /ultrareview 对小于 50 行的 PR 不触发或耗时过长

报错日志

根因

代码修复

十一、Debug #4 — /security-review 报错"fatal: ambiguous argument"

报错日志

根因

代码修复

验证

十二、Debug #5 — ECC code-reviewer 审查结果过于冗长，淹没关键问题

报错日志

根因

代码修复

验证

十三、速查卡

13.1 审查工具选型矩阵

13.2 关键配置路径

13.3 常见报错 → 解决方案

十四、扩展阅读

参考文献

代码审查 2026——从 `/review` 到 `/ultrareview` 的完整体系

三、轻量档：`/review` 和 `/security-review` 本地审查

3.1 `/review`——内置的快速审查

3.2 `/security-review`——专注安全的内置命令

4.3 ECC 代理 vs 内置 `/review` 的区别

五、深度档：`/ultrareview` 云端多代理审查

5.1 为什么需要 `/ultrareview`

5.7 `/ultrareview` vs `/review` 的本质区别

八、Debug #1 — `/review` 不识别 diff，返回"No changes to review"

九、Debug #2 — `/ultrareview` 拒绝运行，提示"Authentication required"

十、Debug #3 — `/ultrareview` 对小于 50 行的 PR 不触发或耗时过长

十一、Debug #4 — `/security-review` 报错"fatal: ambiguous argument"