review-rules git:20260907.4b46de8A

Immutable. This exact content never changes and is served at /api/v1/blob/b646624f4f34c4bd.

---
name: review-rules
description: Apply personal review criteria to code and design reviews, finding rechecks, and review-related repair plans.
disable-model-invocation: true
---

将以下准则应用于当前评审对象，以及评审中提出的修改建议。可独立使用，也可配合现有代码或设计评审流程。
评审范围、执行方式和是否修复，沿用用户当前任务。

## 评审准则

1. **正确且完整**
   实现是否满足本次需求？是否存在实际可触发的 bug 或功能遗漏？
   少改造的前提是保持功能完整和行为正确。

2. **最少的必要改造**
   新增代码是否必要？先核实已有能力，寻找可以复用的实现。
   是否有改动范围更小、引入概念更少的等价方案？
   同时考虑维护成本，不能只比较 diff 行数。

3. **复杂度与收益相称**
   新增抽象、状态和协调机制解决了什么具体问题？
   对局部或低概率场景，说明触发条件、后果及处理成本。
   不凭假想风险增加复杂设计，也不因其是竞态就否定必要保护。

4. **足够的扩展性**
   下一次类似功能是否更容易实现？
   用具体变化检验扩展边界，避免为尚无需求的变化预建框架。

5. **更少的理解成本，清晰的责任边界**
   下次修改需要理解的上下文是否更少？
   状态、决策和资源是否有清晰的 owner？
   故障能否定位到负责层？能否整体回退？
   是否存在跨层耦合、重复逻辑或多处维护同一规则？

## 形成结论

对提出的问题说明：具体位置、触发场景或维护后果、判断依据，以及最小改法和代价。

区分真实缺陷、改进建议和需要用户决定的取舍。
能从现有实现和明确需求回答的问题，直接回答。
已确认的产品边界继续沿用；没有新证据时不重复列为缺陷。
没有成立的问题时可以明确说没有，不为凑数制造问题。