编程开发 编辑复核
代码 Review 风险清单
按严重程度检查 bug、回归、权限、性能和测试缺口，优先输出能阻止上线的问题。
PROMPT WORKBENCH
复制后替换变量
保留结构，先填真实信息，再把结果交给模型运行。
你是一名以发现真实风险为目标的代码审查员。请只基于提供的 diff、上下文和测试证据提出问题，不要把风格偏好包装成 bug。
审查顺序：
1. P0：数据丢失、越权、支付错误、生产不可用。
2. P1：确定会影响核心流程的 bug、兼容性破坏和高概率回归。
3. P2：边界条件、错误处理、性能和可维护性风险。
4. P3：可选的清理和文档建议。
每个问题必须包含：位置、触发条件、实际影响、证据、修复建议和验证方式。若没有证据，标记为待验证。最后补充遗漏测试和上线后观察指标。
变更目标：{{change_goal}}
代码 diff：{{diff}}
相关上下文：{{context}}
已有测试：{{tests}}HOW TO USE
使用说明
- 把真实 diff 和测试结果一起提供，审查质量明显高于只贴一段函数。
- 先修 P0/P1，再决定是否处理样式或重构建议。
WHEN IT FITS
适用判断
适合这些情况
- 要 review 的改动较大，需要先列出风险点再逐个看。
- 团队 review 标准不统一，需要一份共同的检查项。
- 你能提供 diff 内容，让检查项对应到具体代码。
换个做法更好
- 你要写的是 PR 描述：用《Pull Request 说明生成器》。
- diff 很小且逻辑直白：直接看比列清单快。
- 你希望模型替你判断代码对错：它看不到运行时行为和完整上下文，只能提示该看哪里。
FAILURE MODES
常见翻车与修正
- 清单全是「检查是否有单元测试」这类通用条目。
通用清单谁都会写。把 diff 粘进输入，要求每条检查项都指向具体的文件和行，说明这段代码为什么值得多看一眼。
- 模型断言某处有 bug，但实际是它没看到的上下文里已经处理了。
要求所有风险表述为「需要确认 X」而不是「这里有 bug」，并说明确认的方法。
- 只看代码风格，漏掉了并发、边界和错误处理。
在输入里明确要求覆盖错误路径、边界输入、并发与幂等、权限校验这几类，风格问题放到最后且不占篇幅。
ACCEPTANCE
怎么判断输出合格
- 每条检查项都指向 diff 里的具体位置。
- 风险表述为待确认项，不是武断的 bug 断言。
- 覆盖了错误处理、边界输入和权限这些容易漏的方面。
- 按风险高低排了序，时间有限时知道先看哪几处。
SAFETY BOUNDARY
使用边界
- 删去私有域名、账号、令牌和用户数据后再分享代码。
- 模型输出是审查意见，不等于安全审计或发布批准。