主题
11.5 Code Review 与安全审计
用多代理评审和 /security-review 把审查变成流程，而不是靠人肉扫。
读完你能做什么：为不同深度的审查需求选对命令，并配置团队的自动审查门禁。
一、审查命令的层次
Claude Code 有一组由浅入深的审查命令（详见 05.4）：
| 命令 | 深度 | 对象 | 何时用 |
|---|---|---|---|
/code-review | 找正确性 bug | 本地 diff | 提交前自查 |
/code-review --fix | 找 + 修 | 本地 diff | 想直接应用修复 |
/review | 快速单次 | GitHub PR | 快速过一遍 PR |
/code-review <level> <pr#> | 多代理深度 | 指定 PR | 重要 PR 深审 |
/security-review | 安全专项 | 当前分支 diff | 安全敏感改动 |
/code-review ultra | 云端多代理 | 最深度（消耗额度） |
二、提交前自查
养成习惯：提交前先自查。
text
> /code-review它检查当前 diff 的正确性 bug 和可清理项。想直接修：
text
> /code-review --fix这是最高性价比的习惯 —— 在代码离开你手之前先过一遍，比 review 时被打回来省事得多。
三、安全审计
text
> /security-review分析当前分支待提交改动的安全漏洞：注入、鉴权问题、数据泄露等。
3.1 什么改动必须跑安全审计
text
- 涉及用户输入的处理
- 认证、授权逻辑
- 数据库查询（尤其动态拼接）
- 文件操作、路径处理
- 处理密钥、token、支付
- 反序列化、模板渲染3.2 补充自定义安全检查
内置审计之外，针对你项目的特定风险：
text
<task>
安全审查这次改动，重点检查：
1. 所有 SQL 是否参数化（我们绝对禁止字符串拼接 SQL）
2. 用户输入是否都做了校验和转义
3. 有没有把敏感信息写进日志
4. 权限检查是否可能被绕过
5. 有没有硬编码的密钥
</task>
<output_format>
每个发现：[严重度] 位置(文件:行) - 问题 - 攻击路径 - 修复建议
没发现的类别也明确说"未发现"。
</output_format>四、多代理深度审查
对重要 PR，用多代理审查获得更全面的视角：
text
> /code-review medium 456不同 level 对应不同的审查深度和 effort。多个代理从不同角度审查同一份改动，覆盖面比单次审查更广。
五、让审查更有效的提示词技巧
5.1 抑制"凑数"倾向
Claude 有"倾向于给更多内容显得有帮助"的默认倾向（见 04.1）。审查时这会导致它报告一堆无关痛痒的风格问题。
text
<constraints>
- 只报告会导致实际问题的缺陷（bug、安全、性能），不报告纯风格偏好
- 每个发现必须给出：触发条件 + 后果 + 修复
- 没有严重问题就直说"无严重问题"，不要为凑数列举
- 按严重度排序，Critical 在前
</constraints>5.2 给出项目特定的审查标准
text
按我们团队的标准审查：
- 金额必须用 decimal（发现 float 是 Critical）
- 所有外部调用必须有超时和重试
- 公开 API 必须有输入校验
- 不允许 catch 后吞掉异常六、响应 review 意见
让 Claude 处理 reviewer 的评论：
text
> PR #456 上 reviewer 留了几条评论。读一下，然后：
- 对合理的意见，做出对应修改
- 对你不认同的意见，回复说明你的理由，不要盲从
- 改完 push，并在 PR 上逐条回应评论七、团队审查门禁
把审查做成团队的自动门禁。
7.1 CI 中的自动审查
在 CI 里跑 headless 审查（见 06.6）：
bash
claude -p --max-turns 15 --output-format json \
--append-system-prompt "只报告会导致生产问题的缺陷" \
"$(git diff origin/main...HEAD)
审查这个 diff，输出 JSON：
{\"blocking\": bool, \"issues\": [{\"severity\":\"\",\"file\":\"\",\"note\":\"\"}]}" \
> review.json
# 有 blocking 问题就让 CI 失败
[ "$(jq -r '.blocking' review.json)" = "true" ] && exit 17.2 审查技能
把团队审查标准固化成技能（见 08.6）：
markdown
---
name: team-review
description: 按团队标准审查代码。当用户要审查代码、检查 PR、或提交前检查时使用。
---
# 团队代码审查
## 检查项
- 金额用 decimal（float 是 Critical）
- SQL 参数化（拼接是 Critical）
- 外部调用有超时重试
- 异常不被吞掉
- 无硬编码密钥
## 输出
只报实际缺陷，按严重度排序，每条给触发条件+后果+修复。
无严重问题就直说。八、审查的心态
| 原则 | 说明 |
|---|---|
| 审查是流程，不是灵感 | 用命令和标准，别指望它随机发现 |
| 抑制凑数 | 明确"只报实际问题" |
| 安全单独审 | /security-review 针对性强 |
| 结论要证据 | 每个发现给具体位置和攻击路径 |
| 人仍是最终把关 | Claude 审查是增强，不是替代人工 |