合并 PR 之前，让 AI 做初轮审查，生成结构化意见，供人工审查者参考。不替代人工审查，擅长发现模式性问题，不擅长发现需要业务知识才能判断的逻辑错误。
什么时候用
每次合并 PR 前。AI 审查用于初筛——把明显问题过滤掉，让人工审查者把精力放在业务逻辑和架构判断上。
已有 /code-review 技能时，可直接使用该命令，不需要手动触发。
准备什么
- 代码差异（diff）：PR 的完整 diff，不要只给修改的文件
- PR 描述：标题 + 说明，包含这次改动的背景和目的
- 相关接口定义：被修改代码依赖或实现的接口。没有这个，AI 无法判断实现是否符合契约
- 新增或修改的测试：让 AI 判断测试覆盖是否充分
怎么触发
单次任务
先读 04-prompt/review/pr-review.md，
PR 描述：[标题 + 说明]，
diff：[粘贴或给文件路径]，
相关接口：[文件路径]，
测试：[文件路径]。
请生成审查意见，按必须修改 / 建议改进 / 值得关注三类分组。
通过 /code-review 命令（推荐）
直接运行 /code-review，该命令已内置此审查逻辑。
好的输出是什么样的
- 意见按三类分组：必须修改（阻塞合并）、建议改进（不阻塞）、值得关注（提醒人工审查者注意）
- 每条意见指向具体的文件和行号，不是泛泛的”这里有问题”
- 整体风险评估：低 / 中 / 高，一句话说明理由
- 不给出”代码写得很好”这类无信息量的评价
审查覆盖的维度
按重要性排序：
1. 正确性：实现是否与接口定义一致，是否有明显逻辑错误或边界条件遗漏
2. 安全性：注入风险、权限绕过、敏感数据暴露，外部输入是否经过验证
3. 可维护性：函数职责是否单一，是否引入难以理解的隐式依赖
4. 测试充分性：是否覆盖主要边界情况，是否有明显的测试空白
常见失败模式
- 意见太模糊：”这里可以优化”，没有说具体哪里、怎么优化。要求每条意见指明文件和行号
- 漏掉业务逻辑问题：AI 不了解业务规则，无法判断某个计算结果是否正确。这类问题依赖人工审查，AI 审查不能替代
- 没有提供接口定义：AI 无法判断实现是否符合契约，只能看代码本身的内部一致性。把接口文件给进来
- diff 太大：超过 500 行的 diff，AI 审查质量下降明显。大 PR 拆小，或分模块审查
版本历史
- v1.0：初始版本
- v1.1：增加安全性审查维度
- v1.2：要求指明行号，减少模糊意见