# 提示词：代码评审

> 让智能体以评审者而非作者的身份审阅 diff，只报告影响正确性、安全和需求的问题，并附证据与复现场景，减少无意义的风格挑刺。

## 适用场景

你或智能体刚写完一批改动，合并前想要一次认真的二次检查。如果让刚写完代码的同一个会话去评审，它会偏向认可自己的写法；让评审者带着新的上下文、只看 diff 和标准，效果好得多。

另一个常见问题是，被要求「找问题」的评审者几乎总能找出点什么，其中大多是风格偏好。这份提示词专门压制这种噪声：只收有证据、会影响结果的问题。

## 模板

```text
你现在是代码评审者，不是作者。请评审当前分支相对于【main】的改动。
先运行 git diff 【main】...HEAD 查看全部改动，再阅读被改动文件的上下文。

评审依据：
- 需求：【粘贴需求、Issue 描述或 SPEC 链接】
- 项目约定：以仓库根目录的说明文件为准。

请检查这几类问题，按此顺序：
1. 正确性：逻辑错误、遗漏的分支、边界值、空值、并发与竞态、错误处理。
2. 需求符合度：是否每一条需求都实现了；是否改动了需求之外的东西。
3. 安全：注入、权限校验缺失、敏感信息泄露、不安全的反序列化或路径拼接。
4. 兼容性与数据：接口变更是否破坏调用方、数据库迁移是否可回滚、是否影响已有数据。
5. 测试：新逻辑是否有测试；测试是否真的会在逻辑出错时失败。

输出要求：
- 只报告「会影响正确性、安全或需求」的问题。命名、格式、个人偏好不要报。
- 每条发现包含：严重程度（阻塞 / 重要 / 建议）、文件与行号、
  具体触发场景（输入是什么、会出什么错）、建议的修改。
- 无法确认的怀疑放进单独的「待验证」小节，写明如何验证；不要把猜测写成结论。
- 如果没有发现问题，就明确写「未发现阻塞问题」，并列出你实际检查过的内容，不要为了显得有用而凑数。
- 不要修改任何文件。
```

## 怎么用 / 怎么改

1. **换一个新会话，或交给子智能体。** 在 Claude Code 里，可以对智能体说「用一个子智能体评审这个 diff，对照 PLAN.md 检查每条需求是否实现」。子智能体只看到 diff 和你给的标准，不带着写代码时的思路。
2. **有现成的评审技能时优先用。** Claude Code 自带 `/code-review`，它会在新的子智能体里审阅当前 diff 里的 bug 并把结果交回会话。本模板适合你想自定义评审维度时使用。
3. **按风险调整检查清单。** 支付、权限、数据迁移类改动，把第 3、4 条放最前面并要求逐条给出结论；纯文档或样式改动，只保留第 2 条。
4. **配合验证。** 评审给出「阻塞」项后，让作者会话逐条修复，再让评审者针对这些项复查，而不是整个重来。

## 常见问题或注意事项

- **评审者建议了大量重构。** 在提示词末尾强调「只收影响正确性或需求的问题，其余忽略」。官方也提醒，追着每一条发现改，容易引入过度设计：多余的抽象、防御式代码和永远不会发生的情况的测试。
- **评审者看不到全貌。** diff 很大时分批评审，按模块切开，每批附上相关的说明文档。
- **误报怎么办。** 让它为每个阻塞项写出能让问题出现的输入或步骤。写不出来的，降级为「待验证」。
- **别把评审意见当成定论。** 智能体评审能抓到一类常见问题，但替代不了人对业务的判断。涉及资金、权限、数据删除的改动，仍需要人认真看。