bingooyong Code Review 检查清单 Skill
根据 PR 变更内容，生成按关注维度分类的结构化 review 检查清单，帮助 review 者系统性检查而非凭感觉。
何时使用
- 准备 review 一个 PR，需要系统化的检查清单
- 团队需要统一的 review 标准，避免遗漏关键检查项
- 新人需要 review 参考指南
- 变更涉及安全/性能等高风险领域，需要专项检查
不适用：自动化 lint/CI 检查配置、与 code review 无关的代码分析。
检查清单维度分类
| 维度 | 关注点 | 默认严重性 |
|---|---|---|
| 正确性 | 逻辑正确、边界条件、空值处理、并发安全 | 高 |
| 安全性 | 输入校验、注入防护、鉴权、敏感数据处理 | 高 |
| 性能 | 查询效率、内存使用、缓存策略、N+1 问题 | 中 |
| 可维护性 | 命名清晰、函数长度、职责单一、复杂度 | 中 |
| 可测试性 | 依赖可注入、副作用隔离、可 mock | 中 |
| 向后兼容 | 接口签名、返回结构、枚举值、序列化格式 | 高 |
| 文档与注释 | 公共接口文档、复杂逻辑注释、变更说明 | 低 |
输入
| 输入类型 | 说明 | 必需 |
|---|---|---|
| 变更的 diff 内容 | PR 的完整 diff 或关键变更 | 是 |
| 项目技术栈 | 语言、框架、主要依赖 | 是 |
| 变更类型 | feature / bugfix / refactor / chore | 否 |
| 团队 review 规范 | 团队特有的检查要求 | 否 |
输出
- 按维度分类的检查清单，每项含检查要点和判断依据
- 按严重性排序的条目
- 语言/框架专项检查项
- 跳过项说明（本次变更不涉及的维度及原因）
执行步骤
1. 分析变更类型与范围
- 统计变更文件数、新增/删除/修改行数
- 识别变更涉及的模块和层次（UI / API / 数据层 / 基础设施）
- 判断变更类型：新功能 / 修复 / 重构 / 配置 / 文档
- 标记高风险区域：涉及认证、支付、数据迁移、外部集成
2. 匹配检查维度
IF 变更涉及数据流或状态变更 → 激活"正确性"维度
IF 变更涉及输入处理或鉴权 → 激活"安全性"维度
IF 变更涉及循环/查询/缓存 → 激活"性能"维度
IF 变更涉及接口签名 → 激活"向后兼容"维度
IF 变更超过 200 行 OR 涉及 3+ 文件 → 激活"可维护性"维度
IF 变更涉及外部依赖 OR 新增模块 → 激活"可测试性"维度
IF 变更涉及公共接口 OR 配置项 → 激活"文档与注释"维度
3. 语言框架专项补充
根据技术栈补充专项检查项：
| 技术栈 | 专项检查 |
|---|---|
| TypeScript | 类型安全、any 使用、枚举 vs 联合类型 |
| React | 重渲染、key 使用、useEffect 依赖、状态提升 |
| Go | goroutine 泄漏、error 处理、interface 滥用 |
| Python | 类型注解、异常层级、可变默认参数 |
| SQL | 索引使用、N+1 查询、事务范围、SQL 注入 |
4. 生成检查清单
## Review 检查清单
### 正确性 (严重性: 高)
- [ ] **空值处理**: 检查新增路径上是否存在未处理的 null/undefined
- 判断依据: 所有外部输入和 API 返回值是否做了空值检查
- 常见问题: 解构时未处理 undefined、可选链使用不一致
- [ ] **边界条件**: 检查新增逻辑的边界输入
- 判断依据: 空数组、零值、超大值、特殊字符是否正常处理
### 安全性 (严重性: 高)
- [ ] **输入校验**: 检查新增的输入处理路径
- 判断依据: 是否使用校验库、是否白名单优于黑名单
- 常见问题: 仅前端校验、正则拒绝服务
5. 输出结构化结果
- 完整检查清单（按严重性排序）
- 跳过项说明
- 建议关注的高风险区域
- 参考已有的 error-pattern-library 中相关模式
边界与非目标
- 不做实际代码 review — 只生成检查清单，review 由人执行
- 不做自动化检查执行 — 这是 lint/CI 的职责
- 不做API 设计审查 — 这是 api-design-reviewer 的职责
- 不做测试策略设计 — 这是 test-strategy-designer 的职责
- 不做重构建议 — 这是 refactoring-planner 的职责
- 不做错误模式管理 — 这是 error-pattern-library 的职责
验收标准
- 每个激活的维度都有具体的检查项，而非笼统提醒
- 检查项包含判断依据，review 者知道怎么判断通过/不通过
- 高严重性维度排在前面
- 跳过的维度有明确的跳过原因
- 语言框架专项检查项与项目实际技术栈匹配