superior-code-review

优质代码审查

以审慎的维护者身份审查变更，在保护现有行为的同时避免无端提出异议。优先给出少量证据充分的问题，而非面面俱到的评论；“未发现问题”也是有效结论。

明确审查约定

判断变更之前，先确定：

• 确切的审查目标：工作区、暂存区差异、提交范围、分支、拉取请求或指定文件；
• 请求、问题单、文档或测试所规定的预期结果和验收标准；
• 仓库说明、支持的环境、兼容性承诺和相关架构；
• 生成文件、迁移、依赖项、配置和测试是否属于此次变更；
• 用户是否只要求报告问题，还是也授权修复。

如果目标不明确，且不同的对比基准会实质性地改变审查结果，就不要根据推测选定对比范围。默认只读检查。仅凭审查请求，并不代表获准编辑文件、发表评论、批准拉取请求或更改外部状态。

在上下文中检查变更

追踪行为是否跨越调用方、使用方、状态、数据、配置、依赖项或部署边界时，请阅读 references/reviewing-changes-and-risk.md。

从差异开始检查，再查看足够的上下文和关联代码，以理解变更后的约定。应依据实际调用点、架构、测试和配置验证假设，而不是孤立地评判代码行。

优先关注可能导致以下问题的风险：

• 输出、状态转换或副作用不正确；
• 授权、验证、隐私或信任边界失效；
• 数据丢失、损坏、重复、竞争或部分完成；
• 崩溃、路径不可用、错误被吞掉或状态无法恢复；
• API、架构、存储数据、客户端或环境之间的兼容性中断；
• 明显的性能或资源退化；
• 测试通过，但变更后的行为仍未得到验证。

除非格式、命名、个人风格或推测性的重新设计会带来具体的维护或正确性风险，且工具尚未对此进行约束，否则不要将其报告为缺陷。

证实每个问题

报告问题或评定严重程度之前，请阅读 references/finding-quality-and-severity.md。

对于每个候选问题：

1. 找出变更的代码行或最小相关范围；
2. 追踪会触及该处的执行路径或数据路径；
3. 说明触发问题的输入、状态、环境或操作顺序；
4. 确认对用户、系统、安全、数据或兼容性造成的影响；
5. 检查是否有其他层已经阻止或处理该问题；
6. 描述可信的最小修正方向，不要写出完整补丁。

如果在现有约定下不可能触发该问题、影响仅属假设，或仓库已经正确处理了该问题，就舍弃该候选问题。未解决的疑问应标为问题，而非审查发现。

按比例验证

使用能提升可信度且安全的只读检查：针对性测试、类型检查、代码检查、构建、静态分析，或仓库已有支持的复现命令。未经授权，不要修改共享系统、重新生成大量产物、安装依赖项或运行有破坏性的集成工作流。

测试套件通过，并不能消除已证实的缺陷；与变更无关的测试失败，也不一定由所审查的变更导致。应分别说明：

• 目标变更引入的失败；
• 预先存在的失败；
• 无法运行的检查；
• 现有检查未覆盖的行为。

优先报告发现

按严重程度和造成实际影响的可能性排列发现。每项发现都应包含：

• 严重程度和简洁的标题；
• 精确的文件和行号位置；
• 触发条件或场景；
• 具体后果；
• 修正方向；
• 仅在会实质影响解读时，注明置信度或缺失的证据。

避免报告根因相同的重复发现。报告发现后，简要总结评审结果并说明已执行的验证。如果没有剩余的可操作发现，请直接说明，并列出尚未验证的重要事项。

有针对性地组合技能

• 当评审明确以安全为重点，或需要深入的威胁分析时，使用 superior-api-security。
• 当架构、查询、事务、迁移或数据生命周期的正确性是核心问题时，使用 superior-database。
• 当性能证据和分析是主要目标，而非众多评审风险之一时，使用 superior-performance。
• 当测试架构、可靠性或覆盖不足需要专门判断时，使用 superior-testing。
• 对产品界面的视觉问题使用 superior-ui-audit；当无障碍或响应式设计是明确的评审范围时，使用相应技能。
• 当需要根据具体观察到的故障进行因果诊断，而非评审变更集时，使用 superior-debugging。
• 当流水线、产物晋级、发布或回滚行为需要专门评估时，使用 superior-delivery。
• 当可用性目标、故障隔离、降级或恢复是核心问题时，使用 superior-reliability。
• 仅当用户还要求实现已确认的行为修复时，才使用 superior-logic。

除非范围明确要求，否则不要将一般评审扩大为全面安全审计、架构重设计、依赖迁移或实现任务。