review-changes
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseReview Changes
变更审查
Overview
概述
Review recent code changes against the repo's documented guidelines.
Default to review mode: identify concrete violations, risks, regressions, and missing tests first. Only give a brief clean bill of health when no meaningful findings exist.
对照仓库文档化的指南审查近期代码变更。
默认使用审查模式：优先识别具体的违规项、风险、回归问题和缺失的测试。仅当不存在有价值的发现时，才给出简短的无问题说明。
Workflow
工作流程
- Inspect the latest change set.
- Read the relevant parts of the project's guidelines (AGENTS.md, CLAUDE.md, or any onboarding doc referenced there).
- Read the changed code directly.
- Compare the implementation against repo rules, not generic style opinions.
- Report findings first, ordered by severity, with file references.
- If no findings exist, say that explicitly and note any residual risk or verification gap.
- 检查最新变更集。
- 阅读项目指南的相关部分（AGENTS.md、CLAUDE.md或其中引用的任何入门文档）。
- 直接阅读变更后的代码。
- 将实现与仓库规则进行比较，而非通用的风格观点。
- 优先按严重程度排序输出发现结果，并附上文件引用。
- 如果没有发现问题，明确说明，并指出任何残留风险或验证缺口。
Inspect The Change Set
检查变更集
Prefer the smallest source of truth that answers the review request:
git status --shortgit diff --statgit diff -- <path>git log -1 --statgit show <commit>
If the user asks about committed work, review the relevant commit or commit range instead of the working tree.
Do not review from summaries alone. Read the affected files.
优先选择能响应审查请求的最小可信数据源：
git status --shortgit diff --statgit diff -- <path>git log -1 --statgit show <commit>
如果用户询问已提交的工作，请审查相关提交或提交范围，而非工作树。
不要仅根据摘要进行审查，请阅读受影响的文件。
Review Focus
审查重点
Use the project's documented guidelines as the review standard. Focus especially on:
- correct file and feature placement per the project's directory conventions
- DRY and reuse of logic, components, and flows
- state management following the project's chosen patterns
- dependency injection and service resolution following project conventions
- repository and data access contracts matching established patterns
- tests added or updated when behavior changes
- files growing beyond roughly 800 lines without being split
Do not invent standards beyond what the repo documents unless a change is obviously broken on its own terms.
将项目文档化的指南作为审查标准，尤其关注：
- 符合项目目录规范的正确文件与功能放置位置
- 逻辑、组件和流程的DRY原则遵守与复用情况
- 状态管理遵循项目选定的模式
- 依赖注入（DI）和服务解析遵循项目规范
- 仓库和数据访问契约与既定模式匹配
- 行为变更时新增或更新了测试
- 文件未在未拆分的情况下增长到约800行以上
除非变更本身明显存在问题，否则不要自创仓库文档之外的标准。
Repo-Specific Checks
仓库特定检查
Treat these as high-value checks:
- duplicated components or near-identical UI that should be shared or parameterized
- new services or repositories instantiated ad hoc inside views/components
- raw exceptions escaping into state management or UI layers
- hardcoded user-facing text that should be localized (if the project uses i18n)
- behavior changes without matching test updates
- large files that should be split into focused files
Use the checklist below when you need to scan quickly.
将这些视为高价值检查项：
- 重复的组件或几乎相同的UI，应当被共享或参数化
- 视图/组件内部临时实例化的新服务或仓库
- 原始异常泄漏到状态管理或UI层
- 应当本地化的面向用户的硬编码文本（如果项目使用i18n）
- 未同步更新测试的行为变更
- 应当拆分为专注功能文件的大文件
需要快速扫描时使用下方的检查清单。
Review Checklist
审查清单
Architecture
- Does the code belong in the shared/core layer or in the feature that owns it?
- Did the change duplicate a shared concern instead of reusing existing code?
- Did any file grow beyond roughly 800 lines without being split?
State Management
- Does the state management approach follow the project's chosen pattern?
- If a new pattern was introduced, is there real complexity to justify it?
Data And DI
- Are dependencies resolved via the project's DI system instead of ad hoc construction?
- Do repositories and data access layers follow the established contracts?
- Do mock or test implementations still match the real contract?
UI And Reuse
- Is there an existing component that should have been reused?
- Could the new UI be parameterized instead of cloned?
- Should the component live in shared code because multiple features can use it?
User-Facing Behavior
- Is all visible text localized (if the project uses i18n)?
- Were any persistence changes made in a way that could create partial or inconsistent state?
Tests
- Did behavior change without test updates?
- If a reusable abstraction changed, were existing callers protected with tests?
- Is there any residual risk because validation was not run?
架构
- 代码是否属于共享/核心层，还是属于其所属的功能模块？
- 变更是否复制了共享关注点，而非复用现有代码？
- 是否有文件在未拆分的情况下增长到约800行以上？
状态管理
- 状态管理方式是否遵循项目选定的模式？
- 如果引入了新模式，是否有实际的复杂性来支撑其必要性？
数据与DI
- 依赖是否通过项目的DI系统解析，而非临时构造？
- 仓库和数据访问层是否遵循既定契约？
- 模拟或测试实现是否仍然匹配真实契约？
UI与复用
- 是否存在本应被复用的现有组件？
- 新UI是否可以参数化而非克隆？
- 该组件是否应当存放在共享代码中，因为多个功能都可以使用它？
面向用户的行为
- 所有可见文本是否都已本地化（如果项目使用i18n）？
- 是否存在可能产生部分或不一致状态的持久化变更？
测试
- 行为变更是否未同步更新测试？
- 如果可复用的抽象发生了变更，现有调用方是否有测试保护？
- 是否存在因未运行验证而导致的残留风险？
Output Format
输出格式
Findings are the primary output.
For each finding:
- state the severity
- state the problem
- explain why it violates the project's guidelines or creates a concrete risk
- include a file reference
- suggest the fix direction briefly
After findings, optionally include:
- open questions or assumptions
- a short summary if needed
If there are no findings, say that explicitly. Mention residual risks such as unrun tests, incomplete diff scope, or unverified runtime behavior.
发现的问题是主要输出。
对于每个发现项：
- 说明严重程度
- 说明问题
- 解释其为何违反项目指南或造成具体风险
- 包含文件引用
- 简要建议修复方向
在问题之后，可选择性包含：
- 未解决的问题或假设
- 必要时的简短总结
如果没有发现问题，明确说明。提及残留风险，例如未运行的测试、不完整的差异范围或未验证的运行时行为。
Review Discipline
审查规范
- Prefer repo-specific reasoning over generic best-practice language.
- Do not request documentation updates unless the user asks for doc maintenance separately.
- Do not suggest broad rewrites when a focused fix would satisfy the repo rule.
- Be strict about architectural drift, duplication, and missing tests.
- Be careful with false positives: confirm the code actually violates the rule before flagging it.
- 优先使用仓库特定的理由，而非通用最佳实践表述
- 不要要求更新文档，除非用户单独要求进行文档维护
- 当针对性修复即可满足仓库规则时，不要建议大规模重写
- 严格把控架构漂移、重复和缺失测试的问题
- 小心误报：在标记问题前确认代码确实违反了规则