code-review-checklist

代码审查清单技能

为特定拉取请求生成定制的代码审查清单，根据语言、变更类型和风险等级进行调整，而非使用通用模板。

不太符合你的需求？ 如果你想凭借资深判断力实际执行审查，而不只是生成清单，请使用 code-review-guide。

必要输入

根据已有信息开展工作。即使缺少以下任何信息，也仍需生成完整输出：为每项缺失信息填写合理假设，并标记为 (假设，请确认)，并在末尾列出这些假设。只有在核心主题缺失（没有内容可写）时，才先提问。

• 语言和框架（例如 TypeScript + React / Python + FastAPI / Go）
• 变更类型（功能 / 错误修复 / 重构 / 依赖升级 / 安全补丁 / 性能）
• 风险等级（低 / 中 / 高 / 严重）
• PR 描述（粘贴描述或 PR 链接）
• 代码或差异（可选——粘贴关键变更文件或 git diff；这能显著提升清单的针对性）
• 作者背景（新手 / 经验丰富 / 外部贡献者）

输出格式

---

代码审查：[PR 标题或引用]

1. PR 概览

范围评估：[小 / 中 / 大 / 过大——应拆分] 建议审查深度：[略读 / 标准 / 深入审查] 预计审查时间：[例如 20–30 分钟——可粗略按每 50 行差异 5 分钟估算]

2. 正确性检查

根据所述语言选择相应的语言特定正确性检查：

针对 TypeScript/JavaScript：

• 类型定义与实际用法一致
• 非测试代码中没有隐式 any
• 一致使用 Async/await；没有未处理的 Promise
• 明确处理 Null/undefined

针对 Python：

• 公共函数包含类型提示
• 异常处理具体（不使用裸 except）
• 资源已关闭（使用上下文管理器、with 语句块）

针对 Go：

• 错误均已处理，或明确忽略并附带注释
• 上下文传递正确
• Goroutine 生命周期有明确边界

[仅包含与所述语言匹配的部分]

3. 变更类型专项检查

针对错误修复：

• 有能捕获此错误的测试
• 修复针对根本原因，而非表面症状
• 检查相关代码路径是否存在同类问题

针对功能：

• 满足验收标准
• 处理边界情况（空、大量、并发）
• 测试错误路径，而不只是正常路径
• 添加用于调试的遥测/日志

针对重构：

• 行为保持不变（测试仍然通过）
• 没有范围蔓延——仅进行重构
• 降低复杂度，而非只是转移复杂度

针对依赖升级：

• 已审查破坏性变更
• 已检查安全公告
• 已验证许可证兼容性

[仅包含与所述变更类型匹配的部分]

4. 与风险相称的检查

**低风险：**基本正确性、风格约定、测试覆盖率 **中风险：**以上内容 + 回滚计划、监控更新、性能考量 **高风险：**以上内容 + 安全影响、数据迁移安全性、功能标志/渐进式发布 **严重风险：**以上内容 + 预发布环境验证计划、事件响应计划、部署后验证清单

5. 测试充分性

• 单元测试覆盖新逻辑
• 集成测试覆盖契约变更
• 已测试边界情况
• 已测试故障模式
• 对性能敏感的场景已进行性能测试

6. 审查决策框架

批准条件：[根据此 PR 列出 2-3 项具体条件] 要求修改的条件：[具体阻碍项] 非阻塞性评论：[值得讨论但不影响合并的事项]

7. 此类变更的常见陷阱

根据变更类型和语言，指出审查者通常会忽略的 2-3 个相关问题。

---

更深入的资料

此技能附带支持文件——有需要时请使用：

• references/review-depth-calibration.md — 校准评审深度：并非每个 PR 都值得同等关注。生成输出时请应用其中的内容；该文件包含校准方法和判断要点，而上文的方法摘要对此有所简化。
• templates/review-record.md — 可填写的交付文档模板，内含质量门槛。若用户希望自己填写文档，而不是由你生成，请提供此模板。

评分标准（0–40）

提交前，请为此技能的任何输出评分；32 分及以上才达到可交付质量。

维度	0	5	10
语言针对性	检查项适用于任何语言——换成其他语言名称也不会有任何变化	选择了正确的语言部分，但检查项只是复述模板，而非针对本次 PR 中的构造	每项正确性检查都点明差异中实际出现的构造（goroutine、promise 链、上下文管理器）
风险与深度的校准	无论声明的风险级别如何，评审深度都相同	深度大致随风险级别变化，但缺少高风险场景所需的额外内容（回滚计划、分阶段发布、监控），或内容流于形式	深度与声明的风险级别完全匹配，评审时间估算也遵循差异大小指南
决策框架的明确性	“看起来不错就批准”——没有明确的条件	列出了阻塞项，但无法验证；评审者无法判断何时满足条件	每项批准／阻止／评论条件都可通过具体测试、标志、指标或产物进行检查
陷阱的针对性	缺少陷阱，或内容泛泛（“留意错误”）	陷阱符合该语言或改动类型，但没有同时符合两者	列出 2–3 个只有在这种特定语言与改动类型组合下才会出现的陷阱

质量检查

• 检查清单针对所声明的语言（而非通用清单）
• 包含针对改动类型的专属部分
• 深度符合所声明的风险级别
• 决策框架至少包含一项明确的阻塞条件和一项明确的非阻塞评论条件
• 常见陷阱针对所声明的语言与改动类型组合（而非“留意错误”这类泛泛建议）

反模式

• 不要生成忽视所声明语言的通用检查清单——Python 和 Go 检查清单关注的正确性问题有本质区别
• 不要把“看起来没问题”当作有效的评审结论——检查清单的目的是发现具体问题，而非确认表面上的审阅
• 不要对“高风险”评审采用与“低风险”评审相同的范围——深度必须随声明的风险级别调整
• 不要把每个风格偏好都列为阻塞问题——要区分阻塞性的正确性问题与非阻塞性评论
• 不要跳过所声明的语言与改动类型组合对应的“常见陷阱”部分——其中蕴含着最有价值的知识

使用示例

• “为 [PR 描述] 生成代码评审检查清单”
• “这个拉取请求需要检查什么？”
• “为 [语言] 的[改动类型]提供代码评审检查清单”
• “为 [语言] 的高风险 PR 提供评审检查清单”

示例触发语

• “评审代码。”
• “检查 PR。”
• “评审拉取请求。”
• “生成代码评审检查清单。”