“审查这个 PR”得到的反馈千篇一律，跟你到底改了什么没关系。一个真正有用的 PR 审查 Prompt 必须做到三点：限定在 diff 范围内（只看改动的行）、感知爆炸半径（动了 auth？schema？公开 API？）、输出带 file:line 证据的 action，而不是大段文字。下面 14 个模板就是按这个标准调的，可以直接粘进 Claude Code、Cursor、ChatGPT 或 GitHub Action。
太长不看
- 先跑 diff 范围 审查（模板 1）。整文件审查是另一回事，噪音大得多。
- 永远要求严重度分级（Critical / High / Med / Low）加
file:line证据——没证据基本就是幻觉。 - 高风险 PR（auth、支付、数据库迁移）把安全、爆炸半径、迁移三个 Prompt 叠着跑。
- 2026 年中的前沿模型审 diff 已经很强，但最终签字还得是人。Opus 4.7 在 SWE-bench Verified 上 87.6%，GPT-5.5 在 Terminal-Bench 2.0 上领先（82.7%）——强，但不是万无一失。
- 不想手动粘 Prompt，可以用自动审查器（Copilot、Claude Code Action、CodeRabbit、Cursor Bugbot）封装类似逻辑，见下方工具表。
适合哪些人
把 AI 当首轮 reviewer 的 tech lead、独自提 PR 的独立开发者，以及围绕 Claude Code 或 Codex 搭审查自动化的 staff 工程师。如果你想要的是真能拦住合并的反馈、而不是一堆吹毛求疵的噪音，这些 Prompt 就是给你的。
别让 AI 审一个你自己都还没扫过的 PR。没有人类先 framing，模型往往会盯着格式挑刺，反而漏掉结构性的改动。
2026 年的 AI Code Review 工具版图
下面的 Prompt 你可以粘进任意聊天窗口，也可以让自动审查器在每个 PR 上跑类似逻辑。价格与限制截至 2026 年 6 月：
| 工具 | 模型 | 计费（2026 年 6 月） | 备注 |
|---|---|---|---|
| Claude Code GitHub Action | Opus 4.7 / Sonnet 4.6 | 走 Anthropic API token（Pro $20 / Max $100–$200 套餐内含 Claude Code） | pull_request 触发后发 inline 评论；open + synchronize 时都跑。仅支持 Anthropic 模型。 |
| GitHub Copilot code review | GPT-5.5 等 | 2026 年 6 月 1 日起转用量计费：PRU 退场，改用 GitHub AI Credits（1 credit = $0.01）；一次审查约等于 13 个 request，并消耗 Actions 分钟 | 在 GitHub UI 内发 inline 评论；Pro $10，Pro+ $39。 |
| CodeRabbit | 多模型 | Pro 年付 $24/开发者/月（月付 $30），Pro Plus $48 | 只对提 PR 的开发者计费；开源项目有免费层。 |
| Cursor Bugbot | Sonnet 4.6 / GPT-5.5 | 2026 年 6 月 8 日后的下个续费周期起转用量计费（取消原来的 $40/席位）：约 $1.00–$1.50/次，默认 effort 约 $1.20，无公开上限 | 默认 effort 能解掉约 80% 的 bug，高 effort 多抓约 35%。/review（Cursor 3.7）可当本地 pre-commit 关卡跑。 |
2026 年常见的组合是：用一个自动 bot 做无聊的扫地工作（忘加的 env、缺的测试），再从本页挑一个手动 Prompt 攻坚高风险 diff。配合一篇驱动 agent 的指南更顺手——见 Claude Code 执行类 Prompt。
Prompt 结构公式
每个 PR 审查 Prompt 都应当带这六个要素：
- 角色：让 AI 扮演谁（Release Captain / QA Lead / SRE / staff 工程师）。
- 上下文：仓库 / 框架 / 运行时 / 分支 / diff / 失败日志。
- 目标：一个具体的可交付物——checklist、计划、测试文件、review 笔记、根因、ticket 列表。
- 限制：AI 不能做什么（别自动修、别静默改写、别瞎猜版本号）。
- 输出格式：编号清单、markdown 表格、JSON schema、unified diff，或可直接运行的代码。
- 示例 / 信号：给 1-2 条”好输出”示例，或者说明什么算糟糕输出。
14 个可直接复制的 Prompt 模板
1. diff 范围首轮审查
You are a senior engineer reviewing this PR. Read ONLY the diff (not the whole files). Surface the top 5 issues by impact, not the first 5 you see. For each: (a) file:line, (b) severity (Critical / High / Med / Low), (c) one-line description, (d) suggested fix in <= 30 words. Skip cosmetics — no whitespace / import-order comments.2. 爆炸半径评估
Assess BLAST RADIUS of this PR. Answer: (1) Does this touch auth / payments / schema / public API? (2) Is the change reversible in < 5 minutes? (3) Which other teams' code depends on the modified surfaces? List the dependency, file:line of import. (4) Should this be feature-flagged?3. diff 测试覆盖缺口
For the new / changed code in this diff, list the test gaps: (1) New branches without a test, (2) Modified branches whose existing test still passes against both old and new behaviour (i.e., the test doesn't prove anything), (3) Error paths added without tests. Don't propose tests for unchanged code.4. PR 描述草稿
Generate a PR description from this diff. Sections: (1) WHY (the problem in 2-3 sentences), (2) WHAT (bullet list of changes, <= 6 bullets), (3) RISK (one paragraph: what could break), (4) ROLLBACK (one sentence). Skip "How" — the diff shows that. Keep title <= 70 chars.5. diff 安全专项
Audit ONLY this diff for security issues: (1) New user input that reaches DB / shell / template / fetch without validation, (2) Secrets introduced, (3) Auth checks removed or weakened, (4) Logging that now leaks PII / tokens. Severity each. Ignore the rest of the codebase in this pass.6. 性能回归检查
Look at this diff for performance regressions: (1) New synchronous I/O in hot paths, (2) N+1 patterns introduced (loop + DB call inside), (3) New lodash / heavy import imported eagerly, (4) React: new context provider that wraps too much / unstable deps in useMemo. File:line + reason.7. 忘记更新探测
For this diff, list FORGOTTEN updates: (1) Changed an env var? Update .env.example and docs, (2) Changed an API route? Update OpenAPI / client SDK, (3) New migration? Update rollback / seed, (4) New feature? Update changelog / readme, (5) Changed a type? Update consumers. Return a checklist with each item marked resolved / missing.8. “这个 PR 是不是太大了”拆分器
Assess whether this PR should be split. Criteria: >= 500 LOC OR >= 3 unrelated concerns. If yes, propose a split plan: PR-A (foundation, no behaviour change), PR-B (the actual feature), PR-C (cleanup). For each, list which files belong. Don't propose a split if not needed.9. 向后兼容检查
Check this diff for backwards-compatibility breaks: (1) Renamed / removed public exports, (2) Changed function signatures still imported elsewhere, (3) Changed JSON / DB column names, (4) Bumped major version of a published package. For each: list callers / consumers that need to update.10. 给人类 reviewer 的便条
You're writing a Slack-length message to a human reviewer. Summarize this PR in 4-5 sentences so they know what to focus on. Highlight: the one decision that needs a second opinion, the one risky line, and what is "fine to skim". Tone: peer to peer, no emojis.11. 迁移 / DB 变更红旗
Audit DB / migration changes in this diff: (1) DROP / RENAME without backfill, (2) NOT NULL added to a large table without default, (3) Index missing on a new FK, (4) Migration not idempotent on retry. File:line + severity + safe-deploy strategy.12. diff 范围无障碍检查
For UI changes in this diff, check accessibility: (1) New interactive element without a keyboard handler, (2) Missing aria-label / accessible name, (3) Colour contrast change worsened on the modified components, (4) Loss of focus order. Skip unchanged UI.13. 披露 AI 参与的 PR 模板
代码大部分是 AI 写的时候用，让 reviewer 心里有底。
Generate a PR description that discloses AI assistance honestly: (1) Which parts were AI-written / AI-reviewed / human-written, (2) Where the human verified outputs, (3) Any tests the human wrote vs AI generated. Keep it short and factual. No marketing language.14. 修完之后复审
把 [oldSha] 换成上一轮审查那次 commit 的 SHA。
Re-review this PR. Focus ONLY on diffs that changed since the last review at SHA [oldSha]. Confirm each previously-raised issue is resolved (or explicitly punted with a ticket link). Don't re-raise unchanged code — that was already discussed.容易踩的坑
- 让 AI 审整个仓库而不是 diff——你会被噪音淹没。
- 接受吹毛求疵（空白、import 顺序）——这会让你的人类 reviewer 麻木。
- 不分严重度——每条评论看起来都一样紧急。
- 不让它评估爆炸半径——auth 和 schema 的雷区就漏掉了。
- 一键应用建议——它们经常带着细微的 bug。
- 把 AI 写的测试当人写的来审——它们经常对新旧代码都能过（模板 3 专抓这个）。
- 跳过”忘记更新”那一遍——changelog 和
.env.example总是在悄悄腐烂。
怎么把效果再往前推一步
- 每个 PR 都跑 忘记更新探测（模板 7），专抓人类容易漏的无聊细节。
- 每条结论都要求
file:line证据，没证据就是幻觉。 - 高风险 PR（auth、支付、迁移）把安全、爆炸半径、迁移三个 Prompt 一起跑。
- 在 PR 正文里披露 AI 参与（模板 13），让 reviewer 好校准。GitHub Copilot code review 从 2026 年 6 月 1 日起开始算 Actions 分钟，把哪些已经过了 bot 这件事说清楚，能避免重复跑、重复计费。
- 把你最顺手的审查 Prompt 存成
.claude-code/review.md（或一条 Cursor rule），让它跟着仓库走。Anthropic 官方的 Claude Code review 文档 讲了怎么把同一套逻辑接进pull_requestGitHub Action。
FAQ
- AI 能取代人类 reviewer 吗？ 不能。AI 负责抓无聊的部分（忘加的 env、缺的测试、命名），让人类专注在设计和意图上。哪怕是 2026 年 6 月最强的模型（Opus 4.7，SWE-bench Verified 87.6%）也会漏掉语义 bug。
- AI 会漏真 bug 吗？ 会，尤其是语义层面那种——代码跑得起来，但做的是错的事。把它当首轮，绝不当门禁。
- 怎么避免吹毛求疵的噪音？ 在 Prompt 里写”skip cosmetics”，并限制按 impact 排序、最多 5 条（模板 1 已经这么做了）。
- 该让 bot 直接发 inline comment 吗？ 加置信过滤再发。Cursor Bugbot 和 Claude Code Action 都会标严重度，按 severity >= High 设门槛，否则 comment 流会变成噪音。
- PR 多大 AI 还审得动？ 大约 600 行以内。Cursor 把 Bugbot 转成用量计费后（2026 年 6 月 8 日后的下个续费周期生效），每次成本随 diff 大小上升：默认 effort 约 $1.20，高 effort 的多文件审查更贵，而且没有公开上限。把大 PR 按文件或关注点拆开（模板 8），成本和噪音一起降。
- 该从哪个工具开始？ 如果你已经在付 Claude（Pro 套餐内含 Claude Code），直接接 GitHub Action。如果想要纯 PR 审查、又要免费开源层，CodeRabbit 是最便宜的入口。