本文系统讲解Claude Code在代码审查领域的五种实战模式:从最简单的终端一键Review,到多Agent并行自动化审查流水线。适合有一定Claude Code使用基础、希望将AI代码审查融入团队工作流的开发者。读完本文,你将掌握从零搭建一套覆盖本地自查、PR审查、CI自动化的完整AI Review体系。
适用人群:使用Claude Code 2.x的开发者、技术负责人、DevOps工程师 预计学习时长:2-3小时(含动手实践)
claude --version ≥ 2.1.147)最快上手的方式,30秒完成一次自查。在提交代码之前,直接把diff管道给Claude:
# 查看当前工作区的变更
git diff | claude "Review this diff for bugs, security issues, and improvements"
# 只审查已暂存的变更
git diff --cached | claude "Review staged changes for correctness bugs only"
# 审查某个分支相对于main的所有差异
git diff main...HEAD | claude "Review all changes vs main. Focus on logic errors and security."
预期输出(结构化审查结果):
## Code Review Findings
### 🔴 Critical: SQL Injection (src/auth/login.ts:42)
用户输入 `username` 直接拼接进SQL查询字符串,存在注入风险。
当前代码: db.query(`SELECT * FROM users WHERE name = '${username}'`)
建议修复: db.query('SELECT * FROM users WHERE name = $1', [username])
### 🟡 Warning: Missing Error Handling (src/api/handler.ts:88)
fetch() 调用没有 try/catch,网络超时会导致未捕获异常。
### ✅ Good: Proper Null Check (src/utils/parse.ts:15)
新增的 null guard 正确处理了边缘情况。
常见问题:
| 问题 | 原因 | 解决方案 |
|---|---|---|
| 输出太笼统 | prompt不够具体 | 在引号中指定关注领域,如"只关注安全漏洞和竞态条件" |
| diff为空 | 没有未提交的变更 | 确认 git status 有输出,或使用 --cached |
| 审查遗漏大文件 | diff超过上下文窗口 | 按目录分批审查:git diff main -- src/auth/ \| claude ... |
实操建议:将以下别名加入 .bashrc 或 .zshrc,养成提交前自查习惯:
# 快速审查别名
alias cr='git diff | claude "Review for bugs, security issues. Be concise."'
alias crc='git diff --cached | claude "Review staged changes for critical bugs only."'
alias crm='git diff main...HEAD | claude "Review all branch changes vs main."'
Claude Code从v2.1.147起内置了 /code-review 命令(此前版本叫 /simplify),提供比管道方式更深入的审查体验。
# 启动Claude Code交互会话
claude
# 在会话中执行代码审查
> /code-review
# 指定审查力度(低/中/高)
> /code-review --effort high
# 审查后将结果作为内联评论发到PR(需要GitHub认证)
> /code-review --comment
/code-review 与管道方式的区别:
flowchart LR
subgraph 管道方式
A[git diff] -->|stdin| B[单次推理]
B --> C[文本输出]
end
subgraph code-review命令
D[读取diff] --> E[分析周围代码]
E --> F[多轮验证]
F --> G{发现问题?}
G -->|是| H[打开相关文件确认]
H --> I[结构化报告]
G -->|否| J[确认无问题]
I --> K[可选: --comment 发到PR]
J --> K
end
style 管道方式 fill:#e8f4f8
style code-review命令 fill:#fff3e0
/code-review 的核心优势在于它能主动打开仓库中的相关文件进行交叉验证。管道方式只看diff文本,/code-review 会读取调用链上的其他文件,发现跨文件的逻辑问题。
实战:审查一个认证模块
# 切换到feature分支
git checkout feature/new-auth-flow
# 启动Claude Code
claude
# 执行深度审查
> /code-review --effort high
预期行为:
1. Claude读取当前分支相对于main的所有diff
2. 识别出变更涉及认证逻辑
3. 主动打开 src/middleware/auth.ts、src/models/user.ts 等相关文件
4. 发现Token刷新逻辑存在竞态条件
5. 输出带严重等级的结构化报告
--effort 参数说明:
| 等级 | 深度 | 耗时 | 适用场景 |
|---|---|---|---|
low |
单文件扫描 | 10-30秒 | 小改动、hotfix |
medium |
跨文件关联 | 1-3分钟 | 常规PR |
high |
全链路追踪 | 3-8分钟 | 核心模块变更、安全敏感代码 |
2026年3月9日,Anthropic正式发布了托管版Code Review。这是五个专职Agent并行分析你的PR,经置信度过滤后只发布高质量发现。
flowchart TB
PR[Pull Request 创建/更新] --> Trigger[触发审查]
Trigger --> Fleet[Agent集群]
Fleet --> A1[Agent 1: Bug Detector]
Fleet --> A2[Agent 2: Security Scanner]
Fleet --> A3[Agent 3: Regression Analyzer]
Fleet --> A4[Agent 4: Convention Checker]
Fleet --> A5[Agent 5: Edge Case Hunter]
A1 --> Merge[发现合并与去重]
A2 --> Merge
A3 --> Merge
A4 --> Merge
A5 --> Merge
Merge --> Verify[验证步骤: 对照代码行为确认]
Verify --> Score[置信度评分 0-100]
Score --> Filter{≥ 80分?}
Filter -->|是| Post[发布为内联评论]
Filter -->|否| Log[仅记录在日志]
Post --> Comment[GitHub PR评论 + 严重等级标记]
style Fleet fill:#ffcdd2
style Verify fill:#c8e6c9
style Post fill:#bbdefb
每个发现带有三级严重性标记:
| 标记 | 严重等级 | 含义 |
|---|---|---|
| 🔴 | Important | 合并前应修复的bug |
| 🟡 | Nit | 值得改进但不阻塞 |
| 🟣 | Pre-existing | 已有代码中的问题(非本PR引入) |
Step 1:安装GitHub App
# 在Claude Code中运行安装向导
claude
> /install-github-app
按提示完成:选择仓库 → 授权 → 自动存储API Key为repo secret。
Step 2:启用Code Review
管理员在 claude.ai/admin-settings 中:
1. 选择目标仓库
2. 设置触发模式:opened(仅新建PR)或 every push(每次推送)或 manual(仅手动触发)
3. 保存
Step 3:自定义审查标准 — REVIEW.md
在仓库根目录创建 REVIEW.md:
# Review Criteria
## 重点关注
- 授权回归:管理员和普通用户的权限检查是否一致
- 幂等性:Webhook处理器是否保证重复调用安全
- 事务边界:涉及支付的写操作是否有事务保护
- 异步任务:是否存在重复发送邮件/退款/通知的风险
- 输入验证:所有外部输入是否经过校验和清洗
## 不关注(已有工具覆盖)
- 代码格式和import顺序
- 命名风格(已由ESLint处理)
- TypeScript类型声明的完整性
Step 4:提供项目上下文 — CLAUDE.md
CLAUDE.md 告诉Agent你的系统架构:
# CLAUDE.md
## 架构说明
- packages/auth 负责所有角色和权限检查
- apps/api 是唯一允许修改计费状态的服务
- apps/worker 重放Webhook事件,必须保持幂等
- 不要在 BillingService 之外直接写 Subscription 表
## 关键约束
- 所有数据库写操作必须通过 Repository 层
- 禁止在 controller 中直接操作 ORM
- 环境变量通过 config 模块统一读取
Step 5:触发与查看
# 方式1:自动触发(配置为opened/every push时)
git push origin feature/new-auth
# 方式2:手动触发
# 在PR页面评论:
@claude review
# 方式3:一次性审查(不改变仓库设置)
# 在PR页面评论:
@claude review once
| 指标 | 数据 |
|---|---|
| 单次审查费用 | $15-$25(随PR大小和复杂度浮动) |
| 平均完成时间 | ~20分钟 |
| 有价值评论率 | 54%(对比传统方法的16%) |
| 误报率 | <1% |
费用控制技巧:
- 大型重构分批提交多个PR,降低单次成本
- 使用 REVIEW.md 收窄关注范围,减少Agent探索开销
- 对不重要的PR用 @claude review once 按需触发
如果你的团队使用Bedrock/Vertex(数据合规要求)、或者不在Team/Enterprise计划上,anthropics/claude-code-action@v1 是完全自主控制的替代方案。
# .github/workflows/claude-review.yml
name: Claude Code Review
on:
pull_request:
types: [opened, synchronize, reopened, ready_for_review]
jobs:
review:
runs-on: ubuntu-latest
permissions:
contents: read
pull-requests: write
id-token: write
steps:
# 必须checkout,Agent需要读取完整文件来验证发现
- uses: actions/checkout@v6
with:
fetch-depth: 1
- uses: anthropics/claude-code-action@v1
with:
anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
prompt: |
REPO: ${{ github.repository }}
PR NUMBER: ${{ github.event.pull_request.number }}
Review the diff for correctness, security, and obvious bugs.
Focus on logic errors, unhandled error paths, missing input
validation, and tests that do not actually exercise the new
behavior. Skip style nits.
Post inline comments on the lines you have something concrete
to say about, then a one-paragraph summary as a top-level
PR comment.
claude_args: |
--model claude-sonnet-4-6
--max-turns 8
--allowedTools "mcp__github_inline_comment__create_inline_comment,Bash(gh pr comment:*),Bash(gh pr diff:*),Bash(gh pr view:*)"
flowchart TB
subgraph YAML配置
A[prompt] --> B[审查指令文本]
C[claude_args] --> D[--model 模型选择]
C --> E[--max-turns 对话轮数]
C --> F[--allowedTools 工具白名单]
end
subgraph 工具白名单
F --> G[create_inline_comment<br/>在diff行上发评论]
F --> H[gh pr comment<br/>发PR总结评论]
F --> I[gh pr diff<br/>读取diff内容]
F --> J[gh pr view<br/>查看PR元数据]
end
subgraph 执行流程
K[PR事件触发] --> L[checkout代码]
L --> M[读取diff]
M --> N[Agent分析]
N --> O[打开文件验证]
O --> P[发布内联评论]
P --> Q[发布总结评论]
end
style 工具白名单 fill:#e1f5fe
各参数调优指南:
| 参数 | 推荐值 | 说明 |
|---|---|---|
--model |
claude-sonnet-4-6 |
平衡速度与质量;安全敏感路径可升级 claude-opus-4-7 |
--max-turns |
8 |
读diff + 打开3-4个文件 + 发评论足够;超时不要加轮数,缩窄path filter |
fetch-depth |
1 |
Agent通过 gh 读diff,但需要checkout才能打开文件验证 |
permissions |
read + write |
最小权限:读代码 + 写评论 + OIDC令牌 |
jobs:
review:
runs-on: ubuntu-latest
if: |
github.event_name == 'pull_request' &&
!github.event.pull_request.draft
steps:
- uses: actions/checkout@v6
- name: Check if important paths changed
id: filter
run: |
CHANGED=$(gh pr diff ${{ github.event.pull_request.number }} \
--name-only | grep -E '^(src/|lib/|pkg/)' | head -1)
if [ -n "$CHANGED" ]; then
echo "should_review=true" >> $GITHUB_OUTPUT
else
echo "should_review=false" >> $GITHUB_OUTPUT
fi
env:
GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
- uses: anthropics/claude-code-action@v1
if: steps.filter.outputs.should_review == 'true'
with:
anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
prompt: |
Only review files under src/, lib/, and pkg/.
Skip documentation, config, and generated files.
claude_args: |
--model claude-sonnet-4-6
--max-turns 8
--allowedTools "mcp__github_inline_comment__create_inline_comment,Bash(gh pr comment:*),Bash(gh pr diff:*),Bash(gh pr view:*)"
如果你从 @beta 版本迁移,以下是关键变更映射:
| Beta参数 | v1等效 |
|---|---|
mode: agent |
已移除,自动检测 |
direct_prompt |
prompt |
override_prompt |
prompt(配合GitHub变量) |
max_turns: "10" |
claude_args: --max-turns 10 |
model: sonnet |
claude_args: --model claude-sonnet-4-6 |
allowed_tools |
claude_args: --allowedTools ... |
前四式解决的是"发现问题",第五式解决"发现问题后怎么办"——将审查结果转化为可操作的CI门禁。
flowchart LR
PR[PR提交] --> Review[Code Review<br/>四种模式任选]
Review --> Check[Check Run输出]
Check --> Parse[解析severity JSON]
Parse --> Gate{有Important发现?}
Gate -->|是| Block[⚠️ 标记需要关注]
Gate -->|否| Pass[✅ 审查通过]
Block --> Fix[开发者修复]
Fix --> Push[推送修复]
Push --> Review
Pass --> Merge[人工Review后合并]
style Gate fill:#fff9c4
style Block fill:#ffcdd2
style Pass fill:#c8e6c9
style Merge fill:#bbdefb
托管Code Review在Check Run的最后一行输出机器可读的severity JSON:
# 提取severity数据
gh api repos/OWNER/REPO/check-runs/CHECK_RUN_ID \
--jq '.output.text | split("bughunter-severity: ")[1] | split(" -->")[0] | fromjson'
# 输出示例:
# {"normal": 2, "nit": 1, "pre_existing": 0}
# .github/workflows/review-gate.yml
name: Review Quality Gate
on:
check_run:
types: [completed]
jobs:
gate:
runs-on: ubuntu-latest
if: github.event.check_run.name == 'Claude Code Review'
steps:
- name: Parse review severity
id: severity
run: |
SEVERITY=$(gh api repos/${{ github.repository }}/check-runs/${{ github.event.check_run.id }} \
--jq '.output.text | split("bughunter-severity: ")[1] | split(" -->")[0] | fromjson')
echo "data=$SEVERITY" >> $GITHUB_OUTPUT
env:
GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
- name: Check for critical findings
run: |
IMPORTANT=$(echo '${{ steps.severity.outputs.data }}' | jq '.normal')
if [ "$IMPORTANT" -gt 0 ]; then
echo "::warning::⚠️ Found $IMPORTANT important issue(s). Review before merging."
echo "has_critical=true" >> $GITHUB_ENV
else
echo "✅ No critical findings. Safe to merge."
echo "has_critical=false" >> $GITHUB_ENV
fi
- name: Post gate status comment
if: always()
run: |
if [ "$has_critical" = "true" ]; then
gh pr comment $PR_NUMBER --body "## ⚠️ Code Review Gate
Found important issues that should be addressed before merging.
Review the inline comments above and push fixes."
else
gh pr comment $PR_NUMBER --body "## ✅ Code Review Gate Passed
No critical issues found. Ready for human review."
fi
env:
GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
PR_NUMBER: ${{ github.event.check_run.pull_requests[0].number }}
重要:Code Review的Check Run始终以
neutral结论完成,永远不会通过分支保护规则阻塞合并。如果你需要真正的合并门禁,必须像上面那样在自己的workflow中解析severity并设置结论。
每个审查评论自带 👍👎 按钮,这是Anthropic校准审查质量的关键信号:
团队最佳实践:
1. 前2周:对所有发现都点👍或👎,积累校准数据
2. 定期检查Check Run详情,看哪些类型的发现被👍多
3. 根据反馈调整 REVIEW.md 的重点范围
假设你维护一个Node.js支付微服务,需要从零搭建AI代码审查体系。
payment-service/
├── src/
│ ├── handlers/
│ │ ├── charge.ts # 扣款处理
│ │ └── refund.ts # 退款处理
│ ├── services/
│ │ ├── payment.ts # 支付核心逻辑
│ │ └── webhook.ts # Webhook处理
│ └── middleware/
│ └── auth.ts # 认证中间件
├── CLAUDE.md # 项目上下文
├── REVIEW.md # 审查标准
└── .github/workflows/
├── claude-review.yml # AI审查workflow
└── review-gate.yml # 质量门禁workflow
# CLAUDE.md
## 架构
- 这是一个Express.js支付微服务,处理信用卡和Webhook
- payment.ts 是核心,所有金额变更必须通过 PaymentService
- webhook.ts 处理Stripe回调,必须保证幂等性
- auth.ts 校验Bearer Token + API Key双重认证
## 关键约束
- 金额使用整数(分),禁止浮点运算
- 所有外部API调用必须有超时和重试
- 退款必须校验原交易存在且未退款
- 禁止在handler层直接访问数据库
# REVIEW.md
## 必须审查
- 金额计算的精度(是否使用了浮点数)
- 并发退款是否可能导致重复退款
- Webhook处理的幂等性
- API Key和Secret是否硬编码
- 错误响应是否泄露内部信息
## 忽略
- TypeScript类型声明的完整性
- import语句排序
- 注释风格
# 提交前快速自查
git diff | claude "Review for payment-specific bugs: float math, idempotency, race conditions."
# 深度审查整个支付模块
claude
> /code-review --effort high --focus security
# .github/workflows/claude-review.yml
name: Payment Service Review
on:
pull_request:
types: [opened, synchronize]
paths:
- 'src/**'
- 'package.json'
jobs:
review:
runs-on: ubuntu-latest
permissions:
contents: read
pull-requests: write
id-token: write
steps:
- uses: actions/checkout@v6
with:
fetch-depth: 1
- uses: anthropics/claude-code-action@v1
with:
anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
prompt: |
This is a payment microservice. Critical review areas:
1. Float math in monetary calculations (MUST use integer cents)
2. Idempotency of webhook handlers
3. Race conditions in concurrent refunds
4. Hardcoded secrets or API keys
5. Error responses leaking internal info
Post inline comments ONLY for real bugs and security issues.
Skip style nits entirely.
claude_args: |
--model claude-sonnet-4-6
--max-turns 10
--allowedTools "mcp__github_inline_comment__create_inline_comment,Bash(gh pr comment:*),Bash(gh pr diff:*),Bash(gh pr view:*)"
复用前面"第五式"的 review-gate.yml,但增加支付特有的检查逻辑:
- name: Payment-specific checks
run: |
# 检查是否有金额相关的发现
FINDINGS=$(gh api repos/${{ github.repository }}/check-runs/${{ github.event.check_run.id }} \
--jq '.output.text')
if echo "$FINDINGS" | grep -qi "float\|decimal\|0.01\|precision"; then
echo "::error::⚠️ Float arithmetic detected in payment code!"
exit 1
fi
flowchart TB
subgraph 开发阶段
Dev[编写代码] --> Local[git diff管道<br/>闪电自查]
Local --> Fix1[修复明显问题]
Fix1 --> Commit[提交代码]
end
subgraph PR阶段
Commit --> PR[创建Pull Request]
PR --> Action[GitHub Actions触发]
Action --> Agent[5个Agent并行审查]
Agent --> Inline[内联评论]
Agent --> Summary[PR总结评论]
end
subgraph 门禁阶段
Inline --> Parse[解析severity JSON]
Summary --> Parse
Parse --> Gate{有Important?}
Gate -->|是| Review1[人工Review<br/>重点看AI发现]
Gate -->|否| Review2[人工Review<br/>关注架构设计]
end
subgraph 反馈闭环
Review1 --> Feedback[👍👎反馈]
Review2 --> Feedback
Feedback --> Calibrate[校准审查质量]
Calibrate -.->|优化| REVIEW[REVIEW.md调整]
end
style 开发阶段 fill:#e3f2fd
style PR阶段 fill:#fff3e0
style 门禁阶段 fill:#fce4ec
style 反馈闭环 fill:#e8f5e9
根因:REVIEW.md 缺乏业务特定规则,Agent回退到通用审查行为。
修复:
# ❌ 泛泛的REVIEW.md
Review for bugs and security issues.
# ✅ 精准的REVIEW.md
## 必须发现
- 缺少事务包裹的数据库写操作
- Redis缓存未设置TTL
- JWT token未校验过期时间
- HTTP响应包含stack trace
## 不要报告
- 变量命名(已有lint规则覆盖)
- import顺序(已有prettier覆盖)
- 函数缺少JSDoc
策略:
1. 调高置信度阈值:/code-review --threshold 90
2. 在 REVIEW.md 中明确排除已知的安全模式
3. 利用👍👎持续校准
检查清单:
- --max-turns 是否过高?降到8
- PR是否包含大量自动生成代码?加path filter排除
- 是否是首次审查(Agent需要构建整个仓库的心智模型)?后续会更快
| 场景 | 推荐模式 | 预估成本 |
|---|---|---|
| 个人开发者日常 | 管道方式(免费) | $0 |
| 小团队核心PR | /code-review --comment |
API token费用 |
| 企业级全量PR | 托管Code Review | $15-25/PR |
| 数据合规要求 | GitHub Actions自托管 | API token + Actions分钟 |
| 维度 | 第一式管道 | 第二式/code-review | 第三式托管Review | 第四式Actions | 第五式门禁 |
|---|---|---|---|---|---|
| 速度 | 30秒 | 1-8分钟 | ~20分钟 | 2-10分钟 | 实时 |
| 深度 | 单文件 | 跨文件关联 | 5Agent并行 | 可定制 | 结果驱动 |
| 成本 | 几乎免费 | API token | $15-25/PR | API token | 无额外 |
| 适用 | 个人自查 | 深度审查 | 团队标准 | 企业定制 | CI集成 |
| 误报率 | 中等 | 低 | 很低(<1%) | 取决于prompt | N/A |
| 需要GitHub | 否 | 否 | 是 | 是 | 是 |
| 维度 | 评估 |
|---|---|
| 适合训练营类型 | 企业DevOps训练营、AI工程实践营、代码质量提升营 |
| 预计教学时长 | 4小时(含动手搭建完整Review流水线) |
| 分组建议 | 2-3人一组,每组一个真实仓库 |
| 产出物 | 完整的CLAUDE.md + REVIEW.md + GitHub Actions workflow |
| 考核方式 | 提交包含已知bug的PR,验证AI Review能否捕获 |
[!tip] 51学通信知识星球 星主:爱卫生(微信:gprshome201101)——公众号「51学通信」创办者,19 年通信行业运维与讲师经验,著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书(各大电商平台有售)。 星球定位:深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域,主打运维岗位与信令分析。 当前规模:5200 篇主题 / 990 个回答,198 元/年。 加入福利:加入星球后请加爱卫生微信,拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题,另有群内分享。 AI 加持:51学通信知识星球已作为 skill 接入 WorkBuddy,使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例,做总结、找文档和 PPT 等场景全覆盖。
