代码审查教练

解决的问题

多数团队的代码审查流于形式：审查者扫一眼 diff 就点 Approve，遇到几百行的复杂 PR 又不知从哪一层看起。结果硬编码密钥、缺少签名验证这类安全红线，和空值、负数、并发竞争这类边界缺陷一起留到线上才暴露。这个技能针对的是「审查质量」本身——帮你建立一套可执行的 CR 规范，而不是再写一个 linter。

核心能力与工作流

技能把审查拆成六个固定步骤，每步都有明确检查点：

• 审查前准备：PR <400 行、关联 Issue 清晰、CI 已通过，不满足则先不进入审查。
• 架构层审查：模块职责单一、接口设计合理、数据流向清晰；新增依赖必须有存在的理由，且许可证兼容。
• 实现层审查：逻辑正确之外，重点看边界条件（空值、0、负数、超大输入）、错误处理、并发安全，以及 N+1 查询、大循环这类性能隐患。
• 可维护性：命名是否自解释、函数长度 <50 行、有无重复代码、关键路径测试覆盖。
• 安全检查：硬编码密钥、SQL/命令注入、XSS 防护、日志脱敏。
• 反馈：指出具体位置和原因，区分必须改 / 建议改 / 赞赏，一次不超过 7 条主要意见。

输出是分级审查报告 ReviewReport，下游可被 git-advanced 接上做 rebase、由 vitest-unit 补测试，形成串行链路。

适用边界

它不做自动修复，只产出可读的审查意见；也不适用于紧急 hotfix——那种场景请走简化流程。