Code Review Prompt：让 AI 像资深 reviewer 一样审代码

用法

把 git diff（或某几个文件）贴进去，让 AI 扮演资深 reviewer 审一遍。适合 PR 提交前自审、或让编码 Agent 在落代码前做最后一道关。

Prompt

你是一位有 10 年经验的资深代码 reviewer。请基于下面的 git diff 做一次严格但务实的代码审查。

# 审查层次（按顺序）
1. 意图核对：这段改动是否真正达成了它声称要做的事？有没有遗漏的边界？
2. 正确性：逻辑错误、空值/越界、并发竞态、错误处理缺失。
3. 安全：注入、越权、敏感信息泄露、不安全反序列化。
4. 性能：不必要的重复计算、N+1、内存/连接泄漏。
5. 可维护性：命名、重复、耦合、误导性注释。

# 输出要求
- 按「阻断 / 重要 / 建议」三级严重度组织，没有问题的级别直接写「无」。
- 每条必须给出 `文件:行号` 和一句话修复建议，不要只说「这里有问题」。
- 不挑刺风格问题（格式化、纯主观命名），除非它确实影响可读性。
- 最后用 3 句话总结：该不该合、最大风险点、合入前必须改的几件事。

# 约束
- 铁律：只基于 diff 里出现的内容下结论，不要假设代码库里没有的东西。
- 如果信息不足无法判断（如缺测试、缺上下文），明确写「需补充上下文」。

<git diff 粘贴到这里>

为什么有效

• 分层 + 严重度：逼模型先抓正确性和安全，再谈风格，避免淹没在无关建议里。
• 文件:行号 硬要求：没有定位的 review 等于没说，强制可落地。
• 「不挑刺」约束：抑制模型最爱生成的格式化吹毛求疵，保留高信号建议。
• 意图核对前置：很多 bug 是「改了但没改对」，先问「达成意图了吗」能抓到这类。

进阶（自动化）

配合编码 Agent，把 review 嵌进流程：

git diff main...HEAD | cat > /tmp/pr.diff
# 把 /tmp/pr.diff 喂给 Claude Code / Cursor 的 review 会话

或在 CI 里用 Codex / Aider 跑「diff → review 评论」，作为人工 review 前的第一道关。

反例（AI 默认会写的烂 review）

「建议优化变量命名，提升可读性。」——没有行号、没有具体改法，等于废话。 「payment.go:142 的 total 在折扣分支未被重新计算，会导致超额优惠；建议在应用折扣后重算并加单测。」

列了 15 条清一色「建议用 const」「建议加空行」——全是低信号风格挑刺。 阻断级 1 条 + 重要级 2 条，每条可定位、可修复。

什么时候用 / 别用

该用：

• PR 提交前自审——把 diff 喂一遍，先挡掉自己看得见但没细想的问题
• 让编码 Agent 落代码前的最后一道关（写完 → 自己 review → 再交付）
• 接手别人 PR 且你不熟这块代码时，先让 AI 给一份「该看哪里」的清单
• 大 diff 的分诊——上千行改动先看它的分级，再决定人工审的顺序

别用：

• 安全合规 / 越权类问题的终审——AI review 只能当第一道筛子，不能当结论
• diff 之外依赖很重的改动（跨服务协议、数据库迁移）：它看不到 diff 之外的东西，会给出假阴性
• 纯重构 / 大范围格式化：噪声淹没信号，且这类改动本就该靠 CI 与测试把关
• 期待它替你决定合不合——它给风险，决策权在你

验收判据（怎么判断这份 review 值不值得信）

AI review 最大的风险不是「漏报」，而是假阴性让你放松警惕。按这四条验收：

1. 抽 3 条「阻断 / 重要」亲自打开看行号——行号都对不上或指向无关代码，整份作废，不要只修那一条。
2. 故意埋一个已知 bug 看它抓不抓得到——这是唯一能测出漏报率的办法。抓不到，说明这个 prompt 在你的代码库上不可靠，别把它放进 CI 当门禁。
3. 看「需补充上下文」的条目——一份好的 review 一定会写这句。通篇斩钉截铁、没有一句「信息不足」，往往是它在用猜测填充空白。
4. 看阻断级的数量——每次都报 5 条阻断，等于没有阻断。分级失去坡度说明它没在真判断，只是在凑数。

为什么强调这几条：这份 prompt 的价值是「高信号」，而不是「全」。把它当第一道筛子、不当终审，是它能长期有用的前提。

变体

变体 A —— 安全优先（适合对外接口 / 鉴权改动） 把审查层次第 3 项前移并加码：3. 安全（最高优先级）：注入、越权、敏感信息泄露、不安全反序列化、SSRF、路径穿越。对每一处外部输入，明确指出它在哪里被信任、在哪里被校验。

变体 B —— 只审意图达成（适合大 diff 快速分诊）

只做一件事：核对这段改动是否真正达成了 PR 描述里声称的目标。
不要列风格问题，不要列性能优化，只回答：达成 / 部分达成 / 未达成，
并给出 diff 里支持你判断的证据（文件:行号）。

变体 C —— 生成可贴到 PR 的评论（适合流水线） 在输出要求追加：每条按「文件路径:行号 + 一句话问题 + 一句话修复建议」输出，不要标题、不要总结、不要 markdown 标题语法，便于脚本直接拆成 PR 评论。

批量跑 / 接管道：

# 单 PR：diff 直接进管道
git diff main...HEAD | claude -p "按 code-review 模板审查，只输出 markdown 表格"

# CI 里做第一道筛（非零退出交给人工看）
git diff origin/main...HEAD > /tmp/pr.diff
claude -p "审查 /tmp/pr.diff，只输出阻断级问题；没有就输出 NONE" > /tmp/review.md
grep -q "NONE" /tmp/review.md || echo "有阻断级问题，需人工复核"

延伸阅读

• 重构辅助：Refactor Legacy Prompt
• 测试生成：Test Generation Prompt
• 编码范式：Agentic Coding