用途
Code Review 是一个代码审查技能，用于依据经过实战检验的工程原则，通过全面的质量门禁对代码进行审查。它适用于审查单个文件、git diff 变更或整个 PR 的合并就绪情况。
主要能力
审查流程包含以下步骤：阅读代码并理解其功能；验证功能正确性；评估测试覆盖；评价测试质量；检查 AGENTS.md/CLAUDE.md 规范符合性；应用工程哲学视角；运行 QA 检查（在修复后执行 lint、类型检查、测试）；输出结构化、分类的可执行反馈。
功能验证方面，检查代码是否实现预期功能、是否满足全部需求与验收标准、是否处理边界情况（null、空值、边界值、溢出）、是否优雅处理错误条件、正常路径是否被测试且可用、是否存在竞态条件、状态管理是否正确。Bug 检测信号涵盖差一错误、空值/未定义、类型强制转换、资源泄漏、无限循环、整数溢出、安全漏洞（SQL 注入、XSS、路径遍历、密钥泄露）。
测试覆盖评估要求：新代码必须有覆盖主要功能的测试；Bug 修复必须有证明修复的回归测试；变更代码的测试应覆盖修改后的行为；关键路径（认证、支付、数据变更）需要高覆盖率。覆盖分析流程为：变更代码是否被测试→否→阻止并添加测试；边界情况是否覆盖→否→要求补充；错误路径是否测试→否→要求补充；覆盖充分则通过。资料还引用了 Google 的覆盖率指南：60% 为可接受最低值，75% 值得称赞，90% 堪称典范，每次提交变更行 90%+ 是合理的，重点应放在未覆盖的部分而非追求任意数字。
测试质量方面强调 FIRST 原则：快速、隔离、可重复、自验证、及时。Flaky 测试的常见原因包括时间/日期依赖、无种子控制的随机数据、测试间共享可变状态、网络/外部服务调用、异步竞态、文件系统依赖、数据库状态泄漏、顺序依赖。测试质量检查清单包括：确定性、自清理、不依赖执行顺序、正确等待异步操作、模拟/桩外部依赖、使用受控时间、使用带种子的随机生成器、有意义的断言、描述行为的测试名称、每个测试一个逻辑断言。测试中的危险信号包括 sleep() 或任意延迟、被注释掉的断言、吞掉失败的空 catch 块、删除逻辑后仍能通过的测试、仅检查 toBeDefined() 而不检查值、it() 块间共享状态、未模拟的网络调用。
QA 检查在批准前验证：lint 通过、类型检查通过、测试通过、构建成功。自动化 QA 流程为：运行 lint→失败→合并前必须修复；通过→运行类型检查→失败→必须修复；通过→运行测试→失败→必须修复（除非是既有问题）；通过→构建→失败→必须修复；通过→QA 通过。
规范符合性检查代码库是否有 AGENTS.md 或 CLAUDE.md 指导文件，并核对：遵循文档化的代码风格、使用批准的库/模式、遵守命名约定、遵循目录结构指南、尊重禁止模式、匹配文档化的架构决策。
工程哲学视角包括 Grug Brain 检查（是否是最简方案、新人能否 30 秒理解、是否有不必要的抽象）、代码坏味道检测（长方法、长参数、特性依恋、霰弹式修改、死代码）、Unix 哲学检查（每个函数是否只做好一件事、组件能否独立测试、纯函数是否有副作用）、DRY/KISS。
使用方式
直接告诉它要审查什么，例如：
- "Review src/auth.ts"
- "Review the changes in git diff HEAD~3"
- "Review this PR for merge readiness"
输出格式
输出包含：摘要（一行结论：APPROVE / NEEDS WORK / RETHINK）、QA 状态（lint、类型检查、测试、构建的通过情况）、功能问题、测试覆盖缺口、测试质量问题、规范违规、代码质量、小建议、做得好的地方。严重级别分为：🔴 严重（Bug、安全、数据丢失、测试损坏，阻止合并）、🟠 重要（缺少测试、设计问题，应修复）、🟡 建议（可以更好，考虑）、🟢 小挑剔（风格、轻微偏好，可选）。
主决策树为：功能是否正确→否→先修 Bug；是→是否有测试→否→添加测试；是→测试是否良好（不 flaky）→否→修复测试质量；是→QA 是否通过→否→修复 QA 失败；是→是否遵循规范→否→对齐标准；是→是否简单→否→考虑简化；是→批准。
限制与不应做的事
不要挑剔格式（使用格式化工具）；不要要求不必要的抽象；不要因风格偏好而阻止合并；不要仅为优雅而重写可工作的代码；不要将测试失败当作“可能是 flaky”而忽略。
适用场景
适用于代码提交前的审查、PR 合并就绪评估、变更集质量把关，以及需要同时检查功能、测试、QA 和项目规范符合性的场景。