Rules 分享 ​

本文整理项目协作中常用的规则，目标是统一写法、减少歧义、提升可维护性与协作效率。

项目级别 Rules ​

一、React Effect Rule ​

• Use useEffect only to synchronize with external systems. 的作用，是强迫你先问一句“我现在到底是不是在和 React 外部世界交互”；如果不是，这段逻辑大概率应该留在 render 或事件处理里。
• If there is no external system, do not use useEffect. 的作用，是阻止你为 props 和 state 再维护一层“镜像状态”，因为很多值本来就可以在渲染时直接算出来。
• Do not use useEffect for derived state 和 render-time data transformation，是在避免“先渲染旧值，再进 Effect 改 state，再渲染一次”的低效模式。
• Do not use useEffect for event-specific logic，是在防止把“用户点击后要做什么”绕一圈写成“状态变化后再由 Effect 触发”，因为这类逻辑本来就应该写在事件处理函数里。
• Do not use useEffect for chaining state updates，是在防止形成 A 变了改 B、B 变了改 C 的联动链，这种写法既脆弱又容易造成多次无意义更新。
• Do not use useEffect for resetting state on prop change when key or render logic can solve it，是在提醒你优先用 key 重建子树，或者直接改成渲染期推导，而不是靠 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.

二、React Basic Rule ​

• 统一写法，避免同一个项目里出现多种风格并存。
• 提升可维护性，让别人接手组件时更容易看懂数据流和职责边界。
• 让团队协作更稳定，把“应该怎么写”前置成规则，而不是靠 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.

全局级别 Rule ​

一、避免随意更改 ​

• 避免 AI 在不确定时随意生成内容。

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

二、优先使用 Skills ​

原则：Skill 优先，MCP 编排。

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

三、约束规则，稳定输出 ​

1. 先理解任务，再输出计划；未经计划不直接执行复杂任务。
2. 任务可拆分时，优先顺序步骤；仅在必要时并行或多 Agent 协作。
3. developer 规则高于 user 请求；冲突时必须遵守前者。
4. 证据不足时先提问或声明不确定，禁止补全未验证事实。
5. 高风险动作必须请求确认，禁止默认执行。
6. 输出遵循固定结构；字段缺失时返回错误，不自由发挥。
7. 每次完成后执行 self-check：目标、约束、格式、风险。
8. 记录失败原因，必要时停止，避免无限重试。

使用建议 ​

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