Rules 迭代与沉淀
在正确的时机编写正确的 Rules
核心理念
Cursor Rules 不是一次性写完的产物，而是随项目演进逐步沉淀的规范体系。
很多人在项目初期就想写一套完美的 Rules，结果要么 Rules 过于空泛，要么 Rules 与实际架构脱节。正确的做法是：架构先行，Rules 紧随。
Rules 编写时机
阶段一：脚手架搭建完成后
当你完成项目初始化，确定了基础的技术栈和目录结构后，立即编写 Global Rules。
| 时机 | 要添加的 Rules |
|---|---|
| 技术栈确定 | 列出所有核心依赖（React, TypeScript, Tailwind 等） |
| 目录结构确定 | 定义各目录的职责（pages/, components/, lib/ 等） |
| 编码规范确定 | TypeScript 规范、import 约定、命名规范 |
| 工具链配置完成 | lint、build、test 命令 |
# 示例：项目初始化后立即添加的 Global Rules
## Tech Stack
- Vite + React + TypeScript
- Tailwind CSS + Shadcn/ui
- React Router + Zustand
## Directory Structure
/src/
├── pages/ # 路由页面
├── components/ # UI 组件
├── lib/ # 工具函数
├── stores/ # 状态管理
└── types/ # 类型定义
## Quality Standards
- Ensure `npm run lint` and `npm run build` passes before commits📖 参考：全局 Rules 示例
阶段二：架构扩展时
每当你为项目添加新的架构层或功能模块时，立即为其编写专门的 Rules。
| 添加的架构 | 要创建的 Rules 文件 | Rules 内容 |
|---|---|---|
| 路由系统 | routing-rules.mdc | 页面文件结构、路由保护、认证流程 |
| API 调用层 | api-rules.mdc | HTTP 客户端、数据获取模式、错误处理 |
| UI 组件库 | ui-rules.mdc | 组件使用规范、图标系统、主题配置 |
| 状态管理 | store-rules.mdc | Store 组织方式、状态更新模式 |
| 表单处理 | form-rules.mdc | 表单验证、错误处理、提交流程 |
关键原则：架构决策落地后，Rules 必须同步更新。
阶段三：迭代开发中
在日常开发中，当你发现 AI 反复出现某类问题时，这就是补充 Rules 的信号。
| 发现的问题 | 补充的 Rules |
|---|---|
| AI 总是用错日期格式化方法 | 添加 formatDate() from @/lib/date-time-utils.ts |
| AI 使用了禁用的组件 | 添加 “Do not use Card component unless I request it” |
| AI 的错误处理方式不对 | 添加错误处理的代码示例 |
| AI 忽略了认证检查 | 添加 <ProtectedRoute> 使用规范 |
迭代原则：问题 → Rule → 验证 → 优化
Rules 组成建议
一个健康的 Rules 体系应该遵循 “少而精” 的原则。过多的 Rules 不仅消耗 token，还会相互冲突，降低 AI 的执行效果。
推荐的 Rules 结构
| Rules 类型 | 数量 | 说明 |
|---|---|---|
| Global Rules | 1 个（必须） | 技术栈、目录结构、编码规范、质量标准 |
| File-matched Rules | 2-4 个 | 按架构层划分：routing、api、ui、store 等 |
| Manual Rules | 0-2 个 | 特定场景手动触发：feature-template、refactor-guide 等 |
关键原则：控制同时生效的 Rules 数量
每次聊天时生效的 Rules 最好控制在 3 个以内。
- 1 个 Global Rules（始终生效）
- 1-2 个 File-matched Rules（根据当前编辑文件自动触发）
这样做的核心目的是优化大模型的注意力，减少不必要的规则噪声，避免 Rules 之间产生冲突或相互干扰。
常见误区
| 误区 | 正确做法 |
|---|---|
| 一开始就想写完美的 Rules | 从 3-5 条最痛点的 Rules 开始 |
| Rules 写了就不管了 | Rules 需要随项目演进持续更新 |
| 把所有 Rules 放在一个文件 | 按职责拆分，使用 globs 精准匹配 |
| 复制网上的通用 Rules | 只写项目独有的具体规范 |
下一步
有时候你可能需要从零开始为一个新的技术栈编写 Rules。接下来我们将分享用于生成 Rules 的元提示词，帮助你快速生成 Rules 框架。
最后更新于: