Code Review Prompt：让 AI 像 Staff Engineer 一样审查代码

用法

把需要 review 的代码 / PR diff 粘进来，配合下面的 prompt。

什么时候用 / 别用

用它：

• PR 已经自测过、需要第二双眼睛看正确性而不是风格。
• 改动涉及并发、鉴权、资源生命周期、异常路径——这四类是人类 reviewer 最容易漏、而 AI 分级清单最擅长的。
• 你是唯一 reviewer，需要一个不会疲倦的第一道筛。

别用：

• 只想做风格统一——那是 linter 和 formatter 的活，用 AI 做这件事会把真问题淹掉（本 prompt 明确写了「不要报」清单，等于主动放弃这块）。
• 需要判断的是产品语义正确性（这个折扣计算规则对不对）。AI 没有你的业务上下文，它会编一个听起来合理的规则。
• diff 超过约 400 行。超过这个量级，任何模型都会开始用「整体来看」这类话术敷衍。大 PR 拆成按文件批次跑，见下方变体 C。
• 合规强相关的改动（审计留痕、加密实现）。这类需要一个能被追责的人签字，AI 的输出只能当输入不能当结论。

最容易犯的错：把它的 建议项当成必须处理。这条 prompt 的价值恰恰在于它区分了「阻塞合并」和「有空再改」，如果你把所有层级的评论都当成待办，等于又退回到「20 条平铺评论 = 0 条」。

Prompt

请像 Staff Engineer 一样审查以下代码。不要评论代码风格、命名偏好、注释多少——这些交给 linter。只报真正的问题。

## 审查层级（按严重度排序）

### 🔴 严重（必须修复，否则不能合并）
- Bug：空指针、越界、竞态条件、资源泄露
- 安全：SQL 注入、XSS、密钥泄露、权限绕过
- 数据丢失风险：未处理的异常导致数据不一致

### 🟡 重要（建议修复，不阻塞合并）
- 性能：O(n²) 循环、N+1 查询、不合理的内存使用
- 错误处理：吞异常、缺少重试、没有超时
- 并发：缺少锁、死锁风险

### 🟢 建议（可选，有空再改）
- 可维护性：函数过长、职责不清、缺少抽象
- 测试：边界 case 未覆盖、缺少异常路径测试

### ❌ 不要报
- 代码风格（空格、括号位置）
- 命名偏好（除非真的有歧义）
- 注释多少
- 个人偏好

## 输出格式

对每个问题：
- **[层级] 文件:行号** — 问题描述
- 原因：为什么这是问题
- 建议：怎么改（给代码示例）

如果某个层级没有问题，明确写「无」。

## 最后
列出你看完后不确定的地方（需要更多上下文才能判断的点）。不要猜。

---

代码：
（粘贴代码或 PR diff）

效果

不加 prompt 时 AI 的 review 通常 20+ 条评论，一半是风格建议，开发者很快就忽略所有评论。

加了这条 prompt 后输出变成：3-5 个真问题，每个都有行号 + 原因 + 修复代码。信噪比大幅提升，开发者愿意看。

为什么有效

• 显式列「不要报什么」比列「要报什么」更关键：AI 的默认是讨好式输出，不给负面清单它就会把风格意见塞满评论区。
• 严重度分层把「必须改」和「有空改」分开：-review 的价值取决于可行动性，20 条平铺的评论等于 0 条。
• 要求给行号 + 原因 + 修复代码：这三件套让评论从「观点」变成「可执行任务」，也是信噪比提升的根源。

验收判据：怎么判断这次 review 是可信的

AI review 的失败模式不是「漏报」，而是**「看起来很专业的误报」**——它给出行号、给出修复代码，但那个 bug 在你的上下文里根本不存在。用这四条量化：

第四条是最容易被忽略、也最致命的。 一条写满了自信结论却没有任何「需要更多上下文」的 review，几乎一定包含幻觉。

变体

A. 只看 diff，不看全文件（降低噪音）

只审查下面 diff 中新增或修改的行。未改动的代码即使有问题也不要报告。
如果判断某个问题必须结合未改动的上下文才能确认，请明确说明「需要看 <文件名> 的 <函数>」，
而不是直接下结论。

B. 让它自己证伪（压误报）

对每个 🔴 级问题，先写一段「最小复现步骤」或「触发输入」。
如果你无法给出可执行的复现路径，就把该问题降级到 🟡 并在末尾注明「未验证」。

C. 大 PR 按文件分批 + 管道化

# 只送本次改动的文件，逐个跑，避免超大 diff 导致敷衍
git diff --name-only origin/main...HEAD -- "*.ts" | while read -r f; do
  echo "=== $f ==="
  git diff origin/main...HEAD -- "$f" | claude -p "$(cat prompts/review-staff.txt)"
done | tee /tmp/review.md

# 只让人看阻塞级
grep -E '^\[严重|🔴' /tmp/review.md

claude -p 是非交互管道模式；Codex、Gemini CLI、Qwen Code 同理。管道化的关键收益是「AI review 结果本身也是一个 diff-able 的产物」，可以进 PR 评论而不是聊天记录。

进阶（自动化）

接进 CI 当作第一道筛（人工只审它标红的部分）：

# 只对本次变更的文件跑，避免全仓噪音
git diff --name-only origin/main...HEAD -- "*.ts" | while read -r f; do
  ai-review --file "$f" --severity blocking
 done

配套工作流见 AI 代码审查流水线 Playbook；工具化方案见 AI 代码审查工具横评。

反例（AI 默认会写的烂版本）

默认输出：「建议把变量名 data 改成 userData」「这里可以加个注释」「考虑使用更函数式的写法」——15 条里 12 条是风格，真 bug 被淹掉。

加了 prompt 之后：[严重] src/auth.ts:42 — refresh token 失败时未清理旧 session，存在会话固定风险；建议：在 catch 分支调用 invalidateSession(id)，并注明「可维护性层级：无」。

延伸阅读

• PR Review 第一道筛 Prompt · 安全审计 Prompt — 更聚焦的专项审查
• AI 代码审查工具横评 — CodeRabbit/Greptile 等自动化方案
• 搭一条自动化 PR Review 流水线 — 把这条 prompt 接进 CI