Awesome 15docs 字数:1.3k 字
预计:4 分钟
阅读量:
Rules 分享
作者:winches
更新于:16 天前
本文整理项目协作中常用的规则。重点不是把规则堆在一起，而是说明这些规则为什么值得保留，以及在日常协作里该怎么用。
适合场景：团队协作、AI Coding 约束、React 代码评审。
阅读方式：先看“项目级规则”和“全局级规则”；需要落地时，直接复制对应的规则原文即可。
先看结论
- 项目级规则用于约束具体技术实践，降低组件和数据流失控的概率。
- 全局级规则用于约束 AI 与人的协作方式，减少误改、过度设计和无效输出。
- 好规则要短、稳、可执行；越像口号，越难真正落地。
项目级规则
1. React Effect Rule
一句话：useEffect 只用来和 React 外部系统同步，不用它来补救本该在渲染期或事件里完成的逻辑。
为什么要有这条规则
- 它强迫你先判断：当前逻辑是不是在和 React 外部世界交互。
- 它能避免为 props 和 state 再维护一层镜像状态，减少重复渲染和数据漂移。
- 它能阻止把“用户操作后的逻辑”绕远路写成“状态变化后再由 Effect 触发”的链式更新。
规则原文
md
# 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 临时争论。
规则原文
md
# 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 在语义不清时靠猜测推进任务。
- 把“先确认再执行”变成默认流程，减少返工。
推荐写法
md
每次指令若存在歧义，你先列出所有可能性并由我确认，再开始执行。2. 输出约束，稳定协作
K 神总结，下面这些约束的目标，是让输出更克制、更接近真实工程协作：
- 不要加用户没要求的功能。
- 不要过度抽象，三行重复代码好过一个不成熟的抽象。
- 不要给你没改的代码加注释和文档字符串。
- 不要做不必要的错误处理和兜底逻辑。
- 不要设计面向未来的抽象。
- 先读代码再改代码。
- 不要轻易建新文件。
- 不要给时间估计。
- 方法失败了先诊断，不要盲目重试，也不要一次失败就放弃。
- 结果要如实汇报，没跑过的不要说跑过了。
K 神 prompt
md
你是代码助手。完成任务时严格遵守以下约束：
<工作原则>
- 先阅读相关代码和上下文，再开始修改。
- 只完成我明确要求的内容；不要擅自扩展功能。
- 采用最小必要改动，优先保持现有结构和行为不变。
- 可以接受少量重复，也不要过早抽象、过度封装，或为未来需求预留设计。
- 非必要不要新增文件。
- 非必要不要补充注释、文档字符串、额外的错误处理或兜底逻辑。
- 不要提供时间预估。
<遇到问题时>
- 如果方案失败，先分析原因，再调整做法。
- 不要盲目重复同样的尝试，也不要因为一次失败就直接放弃。
<输出要求>
- 如实说明哪些内容已完成，哪些未完成。
- 如实说明哪些内容已验证，哪些未验证。
- 没运行过的不要说运行过，没检查过的不要说检查过。
在以上约束下，完成我接下来的任务。
执行上下文存储在 `memory/process.md` 中。
```
### 实用性建议
- Bugfix：一定要挖掘 root case，必要时让 AI 打 Log 辅助排查。
- 长任务一定要分布，每一步都带一些可观测性的测试，避免 AI 一次长任务 bigbang 一堆更改，最后再测试的时候一堆问题，调整起来十分困难，有些甚至是方向性的错误。