Rules 分享 ​

本文整理项目协作中常用的规则。重点不是把规则堆在一起，而是说明这些规则为什么值得保留，以及在日常协作里该怎么用。

适合场景：团队协作、AI Coding 约束、React 代码评审。

阅读方式：先看“项目级规则”和“全局级规则”；需要落地时，直接复制对应的规则原文即可。

先看结论 ​

• 项目级规则用于约束具体技术实践，降低组件和数据流失控的概率。
• 全局级规则用于约束 AI 与人的协作方式，减少误改、过度设计和无效输出。
• 好规则要短、稳、可执行；越像口号，越难真正落地。

项目级规则 ​

1. React Effect Rule ​

一句话：useEffect 只用来和 React 外部系统同步，不用它来补救本该在渲染期或事件里完成的逻辑。

为什么要有这条规则

• 它强迫你先判断：当前逻辑是不是在和 React 外部世界交互。
• 它能避免为 props 和 state 再维护一层镜像状态，减少重复渲染和数据漂移。
• 它能阻止把“用户操作后的逻辑”绕远路写成“状态变化后再由 Effect 触发”的链式更新。

规则原文

# React Effect Rule
- Use `useEffect` only to synchronize with external systems.
- If there is no external system, do not use `useEffect`.
- Do not use `useEffect` for:
  - derived state
  - render-time data transformation
  - event-specific logic
  - chaining state updates
  - resetting state on prop change when `key` or render logic can solve it
- Prefer:
  - render-time calculation
  - `useMemo` for expensive pure computation
  - event handlers for user actions
  - `useSyncExternalStore` for external subscriptions
  - custom hooks or framework data APIs for fetching
- Keep raw `useEffect` calls rare and review them carefully.

阅读提示

• derived state 和 render-time data transformation 通常应该在渲染期直接算出来。
• event-specific logic 应该写在事件处理函数里，而不是先改状态再等 Effect 响应。
• resetting state on prop change 优先考虑 key 或渲染期推导，而不是事后补救。

2. React Basic Rule ​

一句话：统一组件和 Hook 的基本写法，让数据流更清楚、组件职责更单一。

为什么要有这条规则

• 避免同一项目里出现多套并存风格，降低维护成本。
• 让别人接手组件时更容易看懂数据流和职责边界。
• 把“应该怎么写”前置成规则，而不是每次都靠 code review 临时争论。

规则原文

# React Basic Rule
1. Components and hooks must follow the Rules of React.
2. Prefer deriving data during render instead of storing derived state.
3. Extract reusable stateful logic into custom hooks.
4. Keep components small and single-purpose.
5. Optimize only after measuring; do not memoize by default.

全局级规则 ​

1. 避免随意更改 ​

目的

• 避免 AI 在语义不清时靠猜测推进任务。
• 把“先确认再执行”变成默认流程，减少返工。

推荐写法

每次指令若存在歧义，你先列出所有可能性并由我确认，再开始执行。

2. 优先使用 Skills ​

原则：Skill 优先，MCP 编排。

执行顺序

1. 开始任务前，先检查是否有匹配当前目标的 Skill 或 MCP。
2. 若存在，优先遵循 Skill 的流程、约束、示例和输出格式，不临时自由发挥。
3. 任务需要实时数据、外部系统访问、结构化工具调用或执行动作时，再调用 MCP。
4. 若同时存在 Skill 与 MCP，优先由 Skill 编排 MCP；除非 Skill 明显不适用或执行失败，不直接裸调工具。

3. 输出约束，稳定协作 ​

下面这些约束的目标，是让输出更克制、更接近真实工程协作：

• 不要加用户没要求的功能。
• 不要过度抽象，三行重复代码好过一个不成熟的抽象。
• 不要给你没改的代码加注释和文档字符串。
• 不要做不必要的错误处理和兜底逻辑。
• 不要设计面向未来的抽象。
• 先读代码再改代码。
• 不要轻易建新文件。
• 不要给时间估计。
• 方法失败了先诊断，不要盲目重试，也不要一次失败就放弃。
• 结果要如实汇报，没跑过的不要说跑过了。

使用建议 ​

• 在 code review 中，把 useEffect 视为“需要额外解释其必要性”的语句。
• 新增规则时，尽量补上“适用场景 + 反例 + 推荐写法”，降低误用概率。
• 团队可按季度回顾规则执行情况，保留高价值规则，删除低收益约束。