/review

代码审查。完成功能实现后、提交前使用。

代码审查

步骤

1. 运行 git diff HEAD 或 git diff main..HEAD 查看所有变更
2. 运行 git log --oneline -5 了解近期提交上下文
3. 按以下清单逐项检查，仅关注本次变更引入的问题

审查原则

只报高信号问题

• 只标记你有高度把握的问题，不确定的不报
• 每条问题标注置信度：🔴 确定 / 🟡 较可能 / ⚪ 存疑
• 宁可漏报也不误报——假阳性会浪费开发者时间，侵蚀对审查的信任

区分新旧问题

• 只审查本次 diff 引入的问题，不翻旧账
• 如果某段代码在 diff 之前就已存在且未被本次修改触及，跳过
• 必要时用 git blame 确认问题是否为本次变更引入

不报以下内容（假阳性清单）

• 变更前就已存在的问题
• Linter/formatter 会捕获的问题（不需要人工审查）
• 代码中已通过注释显式 suppress 的警告（如 eslint-disable）
• 主观的风格偏好或锦上添花的建议
• 依赖特定输入或运行时状态才可能触发的潜在问题

审查维度

正确性（Must Check）

• 逻辑是否正确，边界条件是否处理
• 空值/undefined 是否防御
• 异步操作的错误处理是否完整
• 类型是否严格，有无隐式 any

安全性（Light Check — 深度扫描用 /security-review）

• 用户输入是否做了校验（zod schema）
• 是否有明显的 SQL 注入、XSS 风险
• 敏感信息是否暴露在响应或日志中

性能（Should Check）

• 是否有不必要的重复渲染（缺少 memo/useMemo）
• 数据库查询是否有 N+1 问题
• 大列表是否做了分页

规范（Should Check）

• 是否符合 CLAUDE.md 中的编码规范
• 命名是否清晰、一致

规格对照（当有设计文档时）

如果存在 prd.md 或 API 契约：

• 逐条检查验收标准是否都已实现
• 对照 API 契约，检查接口定义（路径、方法、请求/响应 schema）是否匹配
• 标记：Pass / Fail / Partial

审查粒度

• Review 覆盖一组相关的 commit，而非逐 commit 审查
• 用 git diff main..HEAD 查看完整变更，理解整体改动意图
• 按功能单元审查：关注最终结果是否正确，而非中间重构步骤

输出格式

按严重程度分类：

• 必须修复：安全漏洞、逻辑错误、数据丢失风险
• 建议改进：代码异味、缺失错误处理、性能问题
• 小建议：命名优化、风格统一

每条包含：置信度标记、文件名:行号、问题描述、修复建议。

如果没有发现高信号问题，直接输出"审查通过，未发现问题"。

IMPORTANT：客观报告，不美化。没有问题就说"审查通过"，有问题就直说。不报低置信度的凑数问题。