review-changes

审查变更

概述

根据仓库记录的指南审查近期代码变更。

默认采用审查模式：优先指出具体违规、风险、回归问题和缺失的测试。只有在不存在有意义的问题时，才简要说明代码整体状况良好。

工作流

1. 检查最新的变更集。
2. 阅读项目指南中相关部分（AGENTS.md、CLAUDE.md，或其中引用的任何入门文档）。
3. 直接阅读变更的代码。
4. 根据仓库规则而非通用风格意见对比实现。
5. 优先报告问题，并按严重程度排序，同时注明文件位置。
6. 如果没有发现问题，请明确说明，并指出任何残余风险或验证缺口。

检查变更集

优先选择能够满足审查需求的最小事实来源：

• git status --short
• git diff --stat
• git diff -- <path>
• git log -1 --stat
• git show <commit>

如果用户询问已提交的工作，请审查相关提交或提交范围，而不是工作区。

不要只根据摘要进行审查。请阅读受影响的文件。

审查重点

以项目记录的指南作为审查标准。重点关注：

• 文件和功能是否根据项目目录规范放置
• 是否遵循 DRY 原则并复用逻辑、组件和流程
• 状态管理是否遵循项目选定的模式
• 依赖注入和服务解析是否遵循项目惯例
• 仓库和数据访问契约是否符合既有模式
• 行为变更时是否新增或更新了测试
• 文件增长到约 800 行以上时是否应该拆分

除非变更本身明显有问题，否则不要臆造仓库未记录的标准。

仓库特定检查

请将以下内容视为高优先级检查项：

• 是否存在重复组件或近乎相同的 UI，本应共享或参数化
• 是否在视图／组件中临时实例化了新服务或仓库
• 是否有原始异常泄漏到状态管理层或 UI 层
• 用户可见的硬编码文本是否应本地化（如果项目使用 i18n）
• 行为变更是否缺少相应的测试更新
• 是否有应拆分为多个专注文件的大型文件

需要快速扫描时，请使用以下清单。

审查清单

架构

• 代码应放在共享／核心层，还是归属于拥有它的功能？
• 变更是否复制了共享逻辑，而没有复用现有代码？
• 是否有文件增长到约 800 行以上，却没有拆分？

状态管理

• 状态管理方式是否遵循项目选定的模式？
• 如果引入了新模式，是否有足够复杂度来证明其合理性？

数据与依赖注入

• 是否通过项目的 DI 系统解析依赖，而不是临时构造？
• 仓库和数据访问层是否遵循既定契约？
• 模拟或测试实现是否仍符合真实契约？

UI 与复用

• 是否有应当复用的现有组件？
• 新 UI 是否可以参数化，而不是克隆？
• 如果多个功能都能使用该组件，它是否应放在共享代码中？

用户可见行为

• 所有可见文本是否都已本地化（如果项目使用 i18n）？
• 持久化变更是否可能导致状态不完整或不一致？

测试

• 行为变更是否缺少测试更新？
• 如果可复用抽象发生变化，是否通过测试保护了现有调用方？
• 验证未运行是否带来残余风险？

输出格式

问题发现是主要输出内容。

对于每项问题发现：

• 说明严重程度
• 说明问题
• 解释其为何违反项目准则或造成具体风险
• 提供文件引用
• 简要建议修复方向

列出问题发现后，还可以包括：

• 未解决的问题或假设
• 必要时附上简短总结

如果没有发现问题，请明确说明。提及尚存风险，例如未运行测试、差异范围不完整或运行时行为未经验证。

审查准则

• 优先结合仓库自身情况进行分析，而不是使用泛泛的最佳实践表述。
• 除非用户另行要求维护文档，否则不要要求更新文档。
• 如果局部修复即可满足仓库规则，不要建议大范围重写。
• 对架构偏离、重复代码和缺少测试的问题应严格把关。
• 避免误报：标记问题前，先确认代码确实违反了规则。