AI Code Review
工具页：复制 Prompt → 只 Review Diff → 人做最终判断。AI 初检 ≠ 最终 Review。
什么时候用？
AI 完成代码修改后（以及 PR 前自查、修 Bug / 重构后查副作用）。
目标
在合并前拿到：分级问题清单 → 人工确认 → 最小修复 → 二次 Review → 测试验收。
最短路径
text
AI 生成
→ AI Review（复制下方 Prompt，不改代码）
→ 人工检查（真问题 / 误报 / 可忽略）
→ 修复
→ 再次 Review
→ 测试
→ 验收核心原则：
让 AI 扩大检查范围，人负责最终判断。不是所有 AI 建议都必须改。
可直接跳到：可复制 Review Prompt
什么时候使用（补充）
适合：
- AI 生成代码后
- 功能开发完成后
- 提交 PR 前自查
- Bug 修复后查副作用
- 重构后检查行为是否被破坏
- 人工 Review 前做第一轮扫描
不适合：
- 一上来 Review 整个仓库
- 把 AI 结论直接当合并条件
- 用 Review 当借口做无关大重构
Review 流程（完整版）
与上方「最短路径」同一闭环，展开为：
text
Diff
→ AI 初检（只找问题，不改代码）
→ 人工判断（真问题 / 误报 / 可忽略）
→ 问题分级（P0～P3）
→ 修复（确认后再改）
→ 测试 / 运行验证
→ 二次 Review（再看 Diff）
→ 验收更细的防误报与修复 Prompt 见下文「验证」与「修复」两节。
Review 检查维度
扫描项即可，不必每项写长文。不确定标「需要确认」。
| 维度 | 看什么 |
|---|---|
| 正确性 | 业务逻辑是否按需求实现 |
| 边界条件 | 空值、极值、空集合、非法输入 |
| 异常处理 | 失败路径、错误码、是否吞异常 |
| 数据一致性 | 事务、多表写入、状态机 |
| 并发 | 竞态、重复提交、锁范围（若相关） |
| 安全 | 权限、注入、敏感信息、越权 |
| 性能 | 明显 N+1、无界查询、热路径浪费 |
| 可维护性 | 重复、命名混乱、无关大改 |
| 兼容性 | 是否破坏已有接口 / 数据 / 调用方 |
| 测试 | 关键路径有无覆盖或验收步骤 |
核心问题始终是：
这次修改有没有引入问题？
问题分级
| 级别 | 含义 | 怎么处理 |
|---|---|---|
| P0 | 严重：功能错误、数据损坏、安全漏洞 | 必须立即处理，不修不合并 |
| P1 | 高风险：易在边界/并发下出错 | 本次尽量修；否则有明确风险说明 |
| P2 | 一般：稳定性 / 可维护性问题 | 评估后决定本次或后续 |
| P3 | 优化建议 | 可选；不为「看起来更好」硬改 |
明确：
- AI 列出来的不一定是真问题
- P3 多数可以不改
- 风格偏好 ≠ 缺陷
使用前准备
尽量提供：
- Git Diff（优先）
- 相关调用链 / 业务代码
- 接口与表结构（若涉及）
- 已知业务规则
- 相关测试或验收步骤
- 报错 / 现象（若有）
只丢孤立片段 → 结果只能当参考。
可复制：Review Prompt
直接复制。要求：只 Review 当前 Diff，不许改代码。
text
你现在作为我的 Code Reviewer。
请对下面「代码变更」做一次问题优先的 Code Review。
## 硬性约束
- 只 Review 本次 Diff / 我提供的变更，不要扩散到整仓无关代码
- 不要修改任何代码
- 不要为了「看起来更好」建议无意义重构
- 不要仅因代码风格不同提问题
- 不确定的问题明确标「需要确认」
- 不要假设不存在的业务规则
- 没有明显问题就直接说没有，不要硬凑
## 检查维度（扫描项）
正确性、边界条件、异常处理、数据一致性、并发、安全、性能、
可维护性、兼容性、测试遗漏、是否影响已有功能。
## 输出格式
先列问题，再解释。每个问题必须包含：
- 级别：P0 / P1 / P2 / P3
- 类型：真实问题 / 需要确认 / 优化建议
- 文件 / 位置
- 问题是什么
- 为什么可能存在
- 可能影响
- 建议（最小改动）
分组输出：
### P0 / P1
### P2
### P3
### 已检查但未发现问题的方面
### Review 结论
- 是否建议合并：是 / 否 / 需要确认
- 最重要的 1～3 个问题
- 还需要我人工确认什么
下面是本次代码变更：
[粘贴 Git Diff / 代码]人工最终检查
AI 初检之后，开发者必须自己回答：
- 是不是真问题？
- 要不要改？现在改还是以后改？
- 是否影响真实业务 / 数据 / 权限？
- 要不要补测试或手工验收？
- 修复会不会扩大修改范围？
AI 初检 ≠ 最终 Review。业务正确性与合并责任在人。
验证问题（防误报）
AI 指出问题后，先验证，再动手：
text
你刚才指出了这个问题：
[粘贴问题]
现在不要修改代码。
请重新检查相关调用链、业务逻辑和上下文，判断这个问题是否真实存在。
请给出：
1. 问题是否真实存在
2. 判断依据
3. 如果是误报，为什么
4. 如果是真问题，最小修改方案
5. 修改后可能产生的副作用
不要为了证明之前的结论而强行支持它。修复与二次 Review
确认真问题后：
text
请只修复已经确认的问题：
[问题列表，含级别]
要求：
1. 只进行必要修改
2. 不改变未确认的业务逻辑
3. 不进行无关重构
4. 不修改无关文件
5. 保持现有代码风格
6. 补充必要测试或说明如何验收
7. 修改前先给方案，我确认后再执行
8. 完成后说明改了什么、可能副作用然后：
text
修复
→ 跑测试 / 手工验收
→ 再对「新 Diff」做一次 Review（可复用上面 Prompt）
→ 人验收通过再合并Cursor / Agent 建议：分析与修改拆开；先只分析当前 Diff，确认后再逐个修。
完整闭环（可背）
text
Diff → AI 初检 → 人工判断 → 分级
→ 修复 → 测试 → 二次 Review → 验收相关：
我的判断
AI Code Review 最适合：
第一轮广泛扫描，而不是最终质量保证。
它提高发现问题的概率；业务正确性与最终责任仍由人承担。