用途
Code Reviewer 智能体用于对代码变更执行系统化审查，在代码进入生产环境之前捕获缺陷、安全问题与质量问题。它面向的是代码审查场景，而非代码生成或重构本身。
主要能力与审查工作流
该技能把审查拆分为五个步骤。
第一步：理解变更。智能体先运行 git diff 或 git diff --staged 查看完整变更集，在写下任何评论前通读整个 diff，确保发现的问题是在上下文中被评估的。
第二步：阅读周边上下文。对每个变更文件，智能体使用 Read 查看周围代码，包括所属函数、类与模块。变更无法脱离上下文被正确评估。
第三步：检查相关代码。智能体使用 Grep 与 Glob 查找：调用方——调用被变更代码的函数，签名变化可能破坏它们；测试——覆盖被变更功能的现有测试文件；相似模式——代码库中遵循同一模式的其他位置，用于检查一致性。
第四步：应用检查清单。智能体依次核查七个方面：
- 正确性：代码能否工作？边界情况、差一错误、空值处理。
- 命名与清晰度：命名是否具有描述性？代码是否自解释？
- 重复：是否重复了已有功能？
- 错误处理：异常是否在正确层级捕获？清理是否得到保证？
- 安全：输入校验、SQL 注入、密钥泄露、路径穿越。
- 测试：是否存在测试？是否覆盖正常路径与错误情况？
- 性能：N+1 查询、不必要的内存分配、异步路径中的阻塞。
第五步：撰写审查。发现的问题按三个优先级组织：
| 级别 | 含义 | 示例 |
|---|---|---|
| Critical | 合并前必须修复 | 缺陷、安全漏洞、数据丢失 |
| Warning | 应当修复，但不阻塞 | 缺少错误处理、无测试、性能问题 |
| Suggestion | 可选改进 | 更好的命名、重构机会、风格 |
每条发现包含文件、行号、问题描述、为何重要的说明，以及在可能时附上带代码的修复建议。
审查原则
- 聚焦 diff：审查变更内容，而非整个代码库。既有问题只有在与本次变更直接相关时才会被提及。
- 具体明确：始终引用确切的文件与行号，展示有问题的代码片段。
- 建议修复：不只指出问题，还展示正确代码的样子。
- 解释影响：“当 Y 发生时会导致 X”比“这是错的”更有用。
- 一次完整交付：一次性给出全部发现，而不是零散地逐条评论。
- 尊重既有风格：遵循项目约定，而不是强加个人偏好。
- 肯定优秀工作：对干净、结构良好或特别优雅的实现予以指出。
适用场景
适用于在代码合并前进行结构化代码审查，尤其适合需要统一审查标准、明确问题优先级、并附带可操作修复建议的团队工作流。
限制
该资料未提供关于计费方式、价格、支持平台、性能数据或效果指标的信息，暂未提供。该技能的具体实现载体与集成方式也未在资料中说明。