---

name: review-code description: 当需要评审代码、PR、diff 或补丁的正确性、安全性、性能或可维护性风险时使用。

代码评审

概述

先找高风险问题，标出位置并给出可执行修复。

建议角色

• 🔍 代码评审者：识别逻辑缺陷、错误处理与可维护性。
• 🔒 安全专家：识别越权、注入、敏感信息泄露等。

何时使用

• 代码/PR/diff/补丁评审
• 关注 bug、安全、性能或可维护性风险
• 合并/审批前评审

不适用

• 未提供代码或 diff（先请求提供）
• 仅架构/设计讨论（用 architecture-review）

快速参考

输出格式

• 先列问题，按严重度排序。
• 每个问题包含：位置（文件:行 或片段）、严重度、影响、修复。
• 然后写开放问题/假设。
• 最后 1-2 句总结；亮点可选。
• 若无问题，明确说明 + 残余风险/测试缺口。
• 缺上下文：只问一个关键问题；否则写明假设。

严重度标准

• Critical：安全、越权、数据丢失、崩溃/恐慌
• Important：逻辑 bug、性能回退、不稳定行为
• Suggestion：可读性、命名、小型重构

盒式评审

时间/权威压力下可限时，但仍需扫高风险区域（鉴权、输入、写入、并发），并说明已检/未检。

示例

Copy问题
- b/api/users.ts:42
  严重度: Critical
  问题: 缺少鉴权/归属检查，任意用户可更新资料。
  修复: 要求 `requireUser()` 并校验 `user.id` 与目标一致。

- b/db/users.ts:88
  严重度: Important
  问题: 无界查询在负载下会引发 N+1 行为。
  修复: 增加 LIMIT 并批量获取关联数据。

问题/假设
- 该 handler 之前是否总有中间件设置 `req.user`？

总结
- 鉴权检查加入前阻止合并；性能问题可后续处理。

常见错误

• 先写总结后写问题
• 缺少位置或严重度
• 忽略正确性/安全/性能只挑风格
• 修复建议含糊（“优化一下”）而无具体行动

借口 vs 事实

红旗 - 立刻停止

• “随便扫一眼就批准”
• “只提风格意见”
• “不标文件/行”
• “只有总结，没有问题”
• “未说明是否有问题”