代码审查清单

问题从哪来

Pull request 评审很容易变成「扫一眼 diff、留几句风格意见就点 Approve」。改动一多，评审者往往漏掉边界条件、安全面或测试缺口；作者也常不清楚该在提交前自检哪些项。团队若缺少统一标准，新人更难对齐「什么叫审完」。

技能如何组织审查

本技能把审查拆成 八大类清单 与 四步工作流，让评审有固定扫描顺序，而不是凭感觉挑文件看。

清单维度（可按优先级逐项勾选）：

• Correctness & Logic：预期输出、边界与 off-by-one、循环/递归、数据结构使用是否合理
• Code Style & Readability：项目规范、命名、函数粒度、DRY、复杂逻辑注释与格式一致
• Performance & Efficiency：多余循环、缓存、SQL 优化、内存与算法复杂度、资源释放
• Security：输入校验、SQL 注入 / XSS、密钥硬编码、鉴权与敏感数据保护
• Error Handling：捕获方式、用户可读错误信息、空 catch、日志与降级
• Testing：单测、 happy path 与边界、Mock、覆盖率与 flaky 测试
• Documentation：公开 API、README / 破坏性变更说明
• Architecture & Design：架构模式、SRP、依赖注入、耦合与无谓技术债

每类还附带 该看什么、红旗项、可向作者提的问题；并单列 JavaScript/TypeScript、Python、Java、Go 的常见注意点（如 async/await、PEP 8、try-with-resources、goroutine 泄漏等）。

推荐工作流：

1. Context（约 2–3 分钟）：读 PR 描述与动机，对照 issue / 文档
2. Overview（约 3–5 分钟）：扫变更文件，标高风险区域
3. Detailed Review（约 15–30 分钟）：按清单优先级深读并分类反馈
4. Summary（约 3–5 分钟）：汇总 Blocking / Suggestion / Question，给出结论

单次评审输出可按技能约定结构化（发现项、严重级别、可执行建议）。可与 github（PR 场景）、coding-agent（质量检查）、opencli（lint / formatter）等流程配合，但技能本身 不执行代码 验证行为。

适用边界

• 无法替代运行测试或掌握完整系统上下文； niche 语言的专项条目可能不完整
• 各项目最佳实践不同，清单应作为团队基线再 自定义（语言 / 框架）
• 适合：提 PR 前自检、担任 reviewer、制定团队标准或培训新人审查习惯