“审查一下这段代码”只会得到通用反馈。下面这 13 条 Prompt 命中资深 reviewer 会抓的具体失败模式，而且每条都只钉住一个审查维度，让信号不被稀释。
一句话总结
- 一条 Prompt 只看一个维度：bug、安全、或性能，绝不三个一起上。混在一起是 AI 审查读起来像噪音的头号原因。
- 每条发现都要
file:line加上 Critical/High/Med/Low 严重度。没给行号的，多半是幻觉。 - 用 Claude Code 或 Cursor 时，让 agent 直接从 git 读 diff，别贴片段——上下文更全，截断更少。
- 把这些 Prompt 和审查机器人搭配使用（截至 2026 年 6 月，可选 GitHub Copilot code review、Claude Code Review 或 Cursor Bugbot）跑机械那一遍，意图和产品上下文留给人来判断。
适合哪些人
PR 前自查的工程师、一周要 triage 10+ PR 的技术负责人、没有 peer reviewer 的独立开发者，以及刚接手陌生仓库的人。
什么时候别用这些 Prompt
一行的 diff、生成类文件（lockfile、快照更新、自动生成的客户端）跳过——成本大于收益。也别在自己还没读过的 AI 生成补丁上直接跑：先自己过一遍草稿，否则就等于让一个模型给另一个模型打分，而你对两边都两眼一抹黑。
Prompt 结构：六个要素
下面每条审查 Prompt 都带这同样六个部分，缺一个质量就断崖式下跌：
| 要素 | 作用 | 例子 |
|---|---|---|
| Reviewer 角色 | 设定视角和深度 | ”后端资深 reviewer”、“SRE”、“staff 前端” |
| 审查焦点 | 一次只看一个维度 | bug、安全、或性能 |
| 证据要求 | 让发现可复核 | 每条都要 file:line |
| 严重度分级 | 强制排序，不是平铺清单 | Critical / High / Med / Low |
| 置信度门槛 | 压低误报 | ”确信再标” |
| 输出形态 | 保持可扫读 | 编号清单或 markdown 表格 |
13 个可直接复制的 Prompt 模板
下面 { } 里的占位符是故意放在代码块里的——整条 Prompt 照抄，把占位符换成你真实的 diff 或文本即可。
1. 聚焦 bug
下面是 diff。只查可能的 bug。每条：file:line、严重度（高/中/低）、错在哪、建议修复。不查样式。保守——确信才标。
{粘贴 diff}2. 聚焦安全
查安全：注入、鉴权、密钥、输入校验、不安全反序列化、竞态。每条：file:line、攻击场景、修复。
{粘贴}3. 性能审查
只查性能：N+1、热路径同步调用、冗余工作、缺缓存、无界增长。Top 3 给前后对照。
{粘贴}4. 可读性 + 命名
只查可读性：命名不清、函数过长、嵌套过深、抽象层级混。建议具体改名。不要重写。
{粘贴}5. 测试覆盖审查
下面是改动 + 测试。请识别：未覆盖情况、脆弱测试模式、测实现而非测行为。建议 3 个缺失用例。
{粘贴}6. API 设计审查
审查公开 API：参数清晰度、错误处理一致性、破坏性变更风险、{语言} 习惯。若合适给一个替代形态。
{粘贴}7. diff 上下文检查
此 diff 中作者可能没读够上下文的地方（如改了函数没更新调用者）。每处说可能缺什么。
{粘贴}8. PR 描述对齐
我在写 PR 描述。这是草稿 + diff。描述准确覆盖了这次改动吗？请列出不一致。
描述：{粘贴}
diff：{粘贴}9. 迁移 / schema 变更审查
此 diff 含一个数据库迁移。请审查：缺回填、不可逆的 ALTER、大表上的锁时长、新外键缺索引、下游代码仍引用旧结构。每条：file:line、风险、建议缓解。假设该表在生产有约 1000 万行。
{粘贴}可替换变量： 迁移文件 + 涉及的 model / ORM 改动。“约 1000 万行”这句话能逼出对锁时长的真实考量，而不是教科书式答案。
10. 并发问题审查
此 diff 只查并发问题：共享可变状态、缺锁/互斥、异步竞态窗口、事务内 await、React effect 或 handler 的重复触发。每条：file:line、会出错的交错时序、建议修复。其余一概跳过。
{粘贴}11. 把资深 review 翻译给新人
我会贴一条资深 reviewer 的评论。请为刚入职的新人改写：用 2 句话讲清背后的原理，再引一段前后对照的代码片段展示修复。保留原评论的锋利度，但去掉行话。
Reviewer 评论：{粘贴}
原代码：{粘贴}12. “这个 PR 该拆吗”
下面是一个改了 N 个文件的 PR diff。判断是否该拆成更小的 PR。输出：(1) 结论（直接合 / 拆成 2 个 / 拆成 3+ 个），(2) 该沿哪几条线拆，(3) 即便在一个 PR 内、也该单独成一个 commit 的改动。
{粘贴}13. Reviewer 行为自审
把自己最近的 review 评论扔进去，识别你自己审查时的盲区。
下面是我这个月留的 20 条 review 评论。请聚类：(1) 我最擅长抓哪类问题，(2) 我系统性漏掉什么（安全？性能？测试设计？），(3) 哪些语气模式可能显得苛刻，(4) 我该对审查风格做的 3 个具体改变。
{粘贴评论}给这些 Prompt 配一个 2026 年的审查机器人
上面的 Prompt 是给聊天窗口或 IDE 里的交互式审查用的。要每个 PR 都自动跑的常驻那一遍，截至 2026 年 6 月有三个正经选项：
| 工具 | 运行方式 | 模型 | 价格（2026 年 6 月） | 备注 |
|---|---|---|---|---|
| GitHub Copilot code review | PR 内联评论，2026 年 3 月起 agentic | Copilot 模型 | 含在 Copilot 付费档；2026 年 6 月 1 日起消耗 Actions 分钟数 + 13 倍 premium request 倍率 | Low/Medium 两档投入；可把修复交给 coding agent |
| Claude Code Review | 通过 claude-code-action 内联评论；托管服务 2026 年 3 月上线 | Claude Opus 4.7 / Sonnet 4.6 | 自托管 Action 任意档可用（自付 API 费）；托管服务约 15-25 美元/PR，仅限 Team/Enterprise | 托管模式不会批准、阻断或自动修复；自托管则完全掌控 prompt |
| Cursor Bugbot | GitHub PR 内联评论；Autofix 2026 年 2 月退出 beta | Bugbot 模型 | 40 美元/人/月加购项；Pro 每月 200 PR 上限，Teams 不限 | 设计上只查 bug；仅支持 GitHub（无 GitLab/Bitbucket） |
实操拆分：每个 PR 都用机器人跑机械的第一遍，再用这里的 Prompt 处理高风险 diff（迁移、鉴权、并发），那些场景你想自己掌控审查视角。本地 CLI 审查的话，Claude Code 的 /review 直接读工作区 diff，连贴这一步都省了。
容易踩的坑
- “审一下这段代码”无焦点——拿到的是浅薄的、什么都查一点的大杂烩。
- 跳过 AI 标的”低置信度”项不复核。微妙 bug 恰恰藏在那里。
- 审查模式让 AI 整段重写。审查找问题，重构改问题，两种模式要分开。
- 没有 severity，所有发现看起来一样紧急，于是你先去修了无关紧要的那条。
- 发现没
file:line——无法验证，整次审查的证据门槛就塌了。
优化技巧
- 一次只钉一个维度——bug、安全、性能不要混，混了信号就被稀释。
- 每条发现都要
file:line，给不出的多半是幻觉。 - 在 prompt 里写明 severity（Critical / High / Med / Low），让 AI 排序而非只罗列。
- 用 Claude Code 或 Cursor 时让 agent 从 git 读 diff，比贴片段上下文更全、截断更少。
- 加一轮反向人格自审（“现在评一下你自己的发现，哪几条最弱？”），动手前先过滤误报。
- PR 超过 500 行时，先让 AI 列”最高风险的文件”，再只 review 那几个。这比改任何单条 prompt 都更能压噪音。
- 把 Prompt 和回复存进 PR 评论线，后续 reviewer 能看到 AI 已经查过什么，不重复同一遍。
FAQ
- AI review 能替代人工 review 吗？ 不能。把它当机械那一遍的约 80%：AI 抓空指针、缺失的错误处理、明显的注入，人抓产品意图和上下文漂移。两个都要，别互相替代。
- 可以拿来跑同事的 PR 吗？ 可以，但要披露。补一句”已用 AI 跑了 bug + 安全维度，发现 X、Y”，免得被当成偷偷自动化。
- 为什么我说”跳过样式”AI 还在标 style？ 长输出上的约束漂移。结尾追加一句：“If a finding is about style or formatting, drop it from the output entirely.”
- Review prompt 应该多长？ Prompt 本身 60-150 字；粘贴的 diff 单次 ≤ 约 1500 行，更大的按目录分批，或直接把 git diff 交给 agent 以免被截断。
- AI 建议的修复我不同意怎么办？ 别用。在同一对话里让 AI 替自己的建议辩护；辩护无力，就说明原代码本来没问题。
- 什么时候可以让 AI 自动应用修复？ 只允许 lint 类（命名、未用 import）。逻辑或安全修复绝不自动应用——会把你没意识到接受的 bug 一并带上去。