“审查这个 PR”得到的反馈千篇一律，跟改了什么没关系。好的 PR review Prompt 必须限定在 diff 内，感知爆炸半径（动了 auth？schema？公开 API？），输出 action 而不是大段文字。
适合哪些场景
把 AI 当首轮 reviewer 的 tech lead、独自 PR 的独立开发、围绕 Claude Code / Codex 做审查自动化的 staff 工程师。
什么时候不建议这样写 Prompt
别让 AI 审你完全没看过的 PR——没人 framing，AI 会挑细枝末节，漏掉结构性变化。
Prompt 结构公式
每个 PR 审查 Prompt 都要带这六个要素：
- 角色：让 AI 扮演谁（Release Captain / QA Lead / SRE / staff 工程师）。
- 上下文：仓库 / 框架 / 运行时 / 分支 / diff / 失败日志。
- 目标：一个具体可交付物——checklist、计划、测试文件、review 笔记、根因、ticket 列表。
- 限制：AI 不能做什么（别自动修、别静默改写、别瞎猜版本号）。
- 输出格式：编号清单、markdown 表格、JSON schema、unified diff、可直接运行的代码。
- 示例 / 信号：1-2 条”好输出”示例，或者说明什么是糟糕输出。
这套 Prompt 适合用在哪
- 邀请人类 reviewer 之前先跑一遍
- 在 diff 范围内做安全 / 性能 / 无障碍专项
- 从 diff 反推 PR 描述
- 抓出忘记更新的测试 / 文档 / 迁移 / changelog
- 合并前做爆炸半径评估
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 checklist with each item 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 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, the rest 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 large table without default, (3) Index missing on 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 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. 修完之后复审
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.可替换变量： oldSha 上一轮审查的 commit
容易踩的坑
- 让 AI 审整个仓库——噪音淹没真问题。
- 接受 AI 鸡蛋里挑骨头（空白、import 顺序）——会让真 reviewer 麻木。
- 不分严重度——每条都看着同样紧急。
- 不让它评估爆炸半径——auth / schema 雷区漏掉。
- 一键应用建议——经常带细微 bug。
- 把 AI 写的测试当人写的测——它们经常对新旧代码都过。
- 不跑”忘记更新”探测——changelog / env.example 一直在烂。
优化技巧
- 永远先跑 diff 范围 review，整文件 review 是另一个 Prompt。
- 强制严重度 → Critical / High / Med / Low，reviewer 才好 triage。
- 要求 file:line 证据，没证据就是幻觉。
- 每个 PR 都跑”忘记更新”模板——专抓人类容易漏的细节。
- 高风险 PR（auth / 支付 / migration）安全 + 爆炸半径 + 迁移 Prompt 一起跑。
- 在 PR 描述里披露 AI 参与，让 reviewer 校准。
- 把常用 review Prompt 存进
.claude-code/review.md，跟着仓库走。
FAQ
- AI 能取代人类 reviewer 吗？: 不能。AI 抓琐碎（漏的 env、缺的测试、命名），人类专注在设计和意图上。
- AI 会漏 bug 吗？: 会，尤其是语义层面的。当首轮使用，不当门禁。
- 怎么避免吹毛求疵？: Prompt 加”skip cosmetics”，要求 ≤ 5 条按 impact 排序。
- 该让 bot 直接发 inline comment 吗？: 加置信过滤（severity ≥ High）再发，否则 comment 流变噪音。
- PR 多大 AI 还审得动？: 约 600 行以内稳定。再大就按文件 / 关注点切块。
- 安全 PR 能完全信 AI 吗？: 能用来跑已知模式（XSS、明文 secret、缺鉴权），最终一定要人类签字。