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

用法

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

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 条。
• 要求给行号 + 原因 + 修复代码：这三件套让评论从「观点」变成「可执行任务」，也是信噪比提升的根源。

进阶（自动化）

接进 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