Code Review

触发与范围

仅变更代码模式（用户明确说「只 review 已变更代码」「仅看 diff」「changed code only」等）：

• 仅对当前已变更的代码进行 review
• 不评价未改动的文件、函数或行
• 需要上下文时，只读足够理解变更意图的最小范围，结论仍只针对 diff 中的行

全量模式（用户未限定范围）：可按模块或文件 review，但仍优先关注本次改动。

工作流

1. 收集变更

并行执行，确定 review 边界：

git status
git diff
git diff --staged

若存在 base 分支，补充：

git diff ...HEAD

记录：变更文件列表、每个 hunk 的增删改、用户描述的需求/任务目标。

2. 理解需求边界

在 review 前明确：

• 用户/任务要求改什么
• 哪些文件/逻辑理论上不应动

后续所有结论都对照这条边界判断。

3. 执行三项核心检查

按优先级审查 diff 中的每一处变更：

A. 需求外影响（最高优先级）

着重检查变更后的代码有没有影响需求以外的内容，防止无意修改无关代码或者破坏不应该修改的逻辑。

具体检查：

• 改动是否超出任务描述（顺手重构、格式化整文件、改命名/注释/导入等无关项）
• 是否修改了不应触碰的模块、公共 API、配置、鉴权、错误处理契约
• 删除/替换代码是否破坏原有调用方、分支、降级或兼容逻辑
• 变更是否引入行为回归（原功能静默失效、条件变宽/变窄、默认值变化）
• 测试/配置/文档的改动是否与需求一致，还是附带修改

疑似越界时：标出具体 hunk，说明「需求内应有 / 实际做了什么 / 风险」。

B. 冗余

检查已变更代码是否有冗余的部分：

• 重复逻辑、可合并的分支、无意义的中间变量或包装
• 未使用的导入、变量、函数、死代码
• 与现有工具函数/组件重复的实现
• 过度防御或重复的校验、日志、注释块
• 可用更小 diff 达成同样目标的写法

C. 逻辑漏洞

检查变更代码有没有逻辑漏洞：

• 边界条件：空值、空集合、0、越界、并发、超时、重试
• 条件与分支：遗漏 else、早返回、竞态、状态不同步
• 错误处理：吞异常、错误传播断裂、部分失败未回滚
• 数据流：类型不匹配、隐式转换、off-by-one、单位/时区错误
• 安全：注入、权限绕过、敏感信息泄露
• 与调用方/被调用方契约是否一致

4. 输出报告

使用以下模板，每条发现必须引用具体变更位置（文件 + 行号或 diff hunk）：

# Code Review — [范围: 仅变更代码 | 全量]

## 变更概览
- 需求/目标：[一句话]
- 变更文件：N 个
- 总体结论：[通过 | 需修改 | 阻塞]

## 发现

### 🔴 阻塞（必须修复）
1. **[类别: 需求外影响 | 冗余 | 逻辑漏洞]** `path:line`
   - 问题：
   - 风险：
   - 建议：

### 🟡 建议（建议修复）
...

### 🟢 可选优化
...

## 范围确认
- 疑似超出需求的改动：[无 / 列出]
- 未发现问题但需人工确认的点：[无 / 列出]

5. 行为约束

• 没有 diff 时：先获取变更，或请用户指定 commit/分支/文件，不凭空 review
• 只读 review：默认不修改代码，除非用户要求修复
• 不扩大范围：仅变更代码模式下，不对未改动代码提「顺便可以改」类建议，除非与本次 bug 直接相关
• 结论要有依据：每条发现对应 diff 中的具体变更，避免泛泛而谈

快速检查清单

- [ ] 已用 git diff 界定变更范围
- [ ] 已明确需求边界
- [ ] 已检查：需求外影响 / 无意破坏不应修改的逻辑
- [ ] 已检查：变更冗余
- [ ] 已检查：逻辑漏洞与边界条件
- [ ] 每条结论有文件/行号引用

示例

见 examples.md