review

代码审查

概述

使用此技能审查当前 git 工作区中尚未提交的更改。
重点关注正确性、安全性、可维护性，以及是否符合项目标准。

审查必须产出：

1. 对更改内容的简要总结
2. 按优先级排列并标注严重程度的发现
3. 可执行的修复建议
4. 最终结论（Approve 或 Request Changes）

工作流

第 1 步：收集上下文

1. 检查当前更改：
   • git diff
   • git diff --cached（如果存在已暂存的更改）
2. 阅读完整的已修改文件（不只是 diff 代码块），以了解周边逻辑和架构。
3. 在判断风格或模式之前，只加载与已修改文件相关的项目上下文：
   • 如果存在 docs/SUMMARY.md，先阅读。
   • 只加载与任务相关的详细文档。
   • 实现约定优先参考 Code Standard 文档。
   • 如果文档与代码或用户意图冲突，请使用可用的输入/提问工具，再进行大范围更改。
4. 对涉及的部分运行相关质量检查（条件允许时运行 lint、类型检查和测试）。

第 2 步：分析更改

从以下维度评估每项更改：

1. 正确性 - 行为是否符合预期要求？
2. 安全性 - 是否存在漏洞、数据泄露、授权缺口或不安全假设？
3. 可靠性 - 是否妥善处理边缘情况、空状态、重试和错误路径？
4. 风格与一致性 - 代码是否遵循项目约定和既有模式？
5. 性能 - 是否存在不必要的高开销操作或性能回退？
6. 测试 - 是否通过适当的测试覆盖关键路径？
7. 可维护性 - 代码是否清晰、模块化且易于演进？

第 3 步：按严重程度分类发现

根据以下标准，为每项发现指定一个严重程度：

• S0 - 严重

  • 导致生产环境故障、严重安全风险、数据损坏/丢失或不可逆副作用的问题
  • 合并前必须修复

• S1 - 高

  • 可能存在的 bug、正确性缺陷、重大可靠性问题或重要验证缺失
  • 应在合并前修复

• S2 - 中

  • 不会阻止合并，但会明显影响可维护性、性能或清晰度的问题
  • 建议尽快修复

• S3 - 低

  • 细微改进、润色或风格建议
  • 除非团队标准有要求，否则可选修复

第 4 步：生成结构化审查报告

严格按照以下顺序使用报告格式。

输出格式

1) 总结

• 更改内容（2-6 个要点）
• 风险等级（低/中/高）
• 审查范围（文件/模块）

2) 发现

每项发现均使用以下模板：

• ID：R-001（依次递增）
• 严重程度：S0 | S1 | S2 | S3
• 类别：Correctness | Security | Reliability | Style | Performance | Testing | Maintainability
• 位置：path/to/file.ext#Lx-Ly（或函数/类名）
• 问题：清楚说明问题
• 影响：对用户/系统的影响
• 建议：提供具体的修复指引
• 置信度：High | Medium | Low

如果没有发现问题，请明确写出：没有可执行的发现。

3) 正面评价

列出观察到的良好实践，例如：

• 新增了完善的测试覆盖
• 职责划分清晰
• 错误处理周全
• 风格和命名一致

4) 必须修复项检查清单

仅包含 S0 和 S1 发现：

• R-00X 简要修复说明
• R-00Y 简要修复说明

如果没有，请写明：没有必须修复项。

5) 结论

使用以下其中一项：

• Approve - 没有尚未解决的阻塞问题（S0/S1）。
• Request Changes - 发现一个或多个阻塞问题（S0/S1）。

可选添加：

• 重新审查重点：修复后需要重新检查的具体文件/部分。

规则

• 尽可能具体，并在可能的情况下引用确切位置。
• 不要孤立地评判代码；始终结合上下文考虑。
• 优先提出可执行的建议，而非含糊的批评。
• 明确区分阻塞性反馈和非阻塞性反馈。
• 避免推测性结论；如有不确定之处，请降低置信度并说明原因。
• 让反馈符合项目文档和编码规范。

评审质量检查清单

在完成前，请确认：

• 已结合上下文审查所有修改过的文件
• 每条发现都包含严重程度、影响和修复建议
• 阻塞性问题已单独列入必须修复清单
• 最终结论与发现的严重程度相符
• 反馈简洁、准确且可执行