代码审查与质量评估

要解决的问题

很多代码审查流程最后会退化成“测试通过就合并”：评论缺少优先级，作者不知道哪些必须改、哪些只是建议；大变更难以评审；AI 生成代码看起来合理但可能隐藏边界、安全或性能问题。这个技能把审查从主观偏好变成可执行的质量门禁，重点不是追求完美代码，而是判断变更是否稳定地改善了整体代码健康度。

技能如何工作

它会按 五个审查轴 展开检查：

• 正确性：功能是否符合需求，边界值、错误路径、竞态和状态一致性是否被覆盖。
• 可读性与简洁性：命名、控制流、抽象层次是否清楚，是否存在不必要复杂度。
• 架构：模块边界、依赖方向、重复代码和过度工程化是否合理。
• 安全：输入校验、密钥处理、权限检查、SQL 注入、XSS 和不可信外部数据。
• 性能：N+1 查询、无界循环、同步阻塞、缺失分页和热点路径中的大对象。

关键步骤包括：先理解变更意图，再优先审查测试，然后审查实现，最后用 严重程度前缀 标记反馈。例如 Critical: 表示阻塞合并，Nit: 表示可选风格问题，Optional: 或 Consider: 表示建议。技能还强调变更要足够小、描述要能独立说明上下文，并要求在合并前确认关键问题已解决、测试和构建通过、验证过程有记录。

适用边界与注意点

这个技能适合 PR 合并前、功能实现后、重构后、缺陷修复后，以及评估他人或模型生成代码时。它更偏向工程流程和审查标准，不替代项目专属的架构约束、安全规范或性能基准。遇到争议时，应以技术事实、风格指南和工程原则为依据；如果作者掌握完整上下文并坚持方案，评审应聚焦代码而不是个人。