code-review

代码审查

完成一次范围明确的审查，给出有证据支持且可采取行动的问题，或给出有依据的无问题结论。按适当比例运用实现、系统、设计和精简视角；与其提出推测性问题，不如不提问题。

范围与指导

审查指定的文件、子系统、分支、提交、PR 或差异。路线图、规范、问题、ADR 或迁移审查应涵盖其所约束的实现，而不只是文档。明确预期结果、所声称的里程碑、实现范围和编辑策略。如果没有指定目标，且存在未提交的更改，则使用这些更改；只有在无法推断目标时才询问。

阅读实现视角，了解核心审查和安全修复策略。当目标涉及其他维度时，再加载相应的详细视角：

• 系统：计划交付、技术选择或跨领域影响。检查是否确实实现了所要求的结果。
• 设计：职责、接口、依赖或使用方发生变化。检查契约和不变量是否有明确的负责人。
• 精简：新增的概念、状态、包装层、兼容路径或其他复杂性。检查这些机制是否值得其维护成本。

对于常规的本地编辑，可以简要检查这些方面，不必加载每个视角，也不必扩展为整个代码库审计。沿着受影响的需求和使用方路径进行检查；将引入的问题与既有技术债务区分开来。

问题与修复

每个问题只记录一次，并放在应由其修复的位置，说明触发场景、受影响的路径或约束性需求、后果、证据和可能的处理方式。架构品味和假设性的灵活性不构成问题。

• 类别 I — 安全修复： 范围明确且属于审查范围，可机械验证，且无需解决尚未明确的产品、设计、发布、兼容性或风险判断。默认直接应用，除非用户要求只做审查；此时应标记为建议。
• 类别 II — 需要决策： 确实存在问题，但仍有未解决的权衡或决策权问题。说明最小可行替代方案和所需决策。在授权范围内应用已明确给出的决策；只针对仍未解决的部分进行询问。

重新检查修复及受影响的验证，直到有证据支持的问题均已解决，或有具体限制导致无法继续。不要将此次审查变成自动循环，也不要在没有新证据时重复已通过的检查。除非用户要求，否则不要暂存、提交或推送。

报告

优先说明影响重大的问题及其已应用或建议的状态。对于计划审查，说明交付覆盖范围；同时说明验证情况和重要的剩余风险，并在有帮助时说明有意义的保留原样决定。审查未发现问题时，只需说明结论和验证限制，无需列出空类别或检查清单记录。