Cursor Rules 深度玩法：从全局配置到项目级规则，让 AI 真正理解你的项目
上一篇讲了 用 AI Skill 封装你的工作流，很多人问：Skill 和 Rules 到底什么关系？Rules 怎么配才有效？本文从零开始，带你搞懂 Cursor Rules 的四种类型、三层作用域，手把手教你针对开发、数据库、团队协作等不同场景配置 Rules------由浅入深，附带完整实例。
前言：你的 AI 是"失忆助手"还是"项目老兵"？
用 Cursor 写了一段时间代码，你可能已经习惯了这种体验：
- AI 帮你写了一段 Java 代码------用了 Lombok 的
@Data，但你们项目禁止用 Lombok - AI 生成了 SQL------用了
SELECT *，但你们 DBA 明确禁止 - AI 帮你建了个表------没加
create_time和update_time，不符合你们的建表规范 - AI 写了个前端组件------用了 Class 组件，但你们全是函数式 + Hooks
每次都要纠正一遍，下次开新会话又忘了。
sql
问题的本质：
你的项目有一套"隐性知识"：
├── 技术栈偏好（Spring Boot 3.x / React 18 / Vue 3）
├── 代码规范（命名规则、分层结构、禁止事项）
├── 数据库规范（字段命名、索引策略、必备字段）
├── 团队约定（Git 流程、Code Review 标准、文档格式）
└── 业务约束（安全要求、性能指标、合规需求）
这些知识存在于：
├── 你的大脑里（会忘记，会遗漏）
├── 散落的文档里（AI 看不到）
└── 口头约定里（新人不知道，AI 更不知道）
Cursor Rules 的价值：
把"隐性知识"变成"显性配置"
→ AI 每次对话都自动加载
→ 不用重复说，不会忘记
→ 新人入项目也能直接用一、Cursor Rules 全景图：先搞清楚有哪些规则
1.1 四种规则来源
Cursor 的规则体系不是一个文件那么简单，它有四种来源，各有各的适用场景：
sql
┌─────────────────────────────────────────────────────────────────┐
│ Cursor 规则体系全景 │
│ │
│ ┌─────────────┐ 作用域：所有项目 │
│ │ User Rules │ 配置位：Cursor 设置界面 │
│ │ (用户规则) │ 特点：全局生效，不跟项目走 │
│ └──────┬──────┘ 适合：个人偏好、语言习惯、通用编码风格 │
│ │ │
│ ┌──────▼──────┐ 作用域：单个项目 │
│ │Project Rules│ 配置位：.cursor/rules/*.mdc │
│ │ (项目规则) │ 特点：跟 Git 走，团队共享 │
│ └──────┬──────┘ 适合：技术栈规范、数据库规范、业务约束 │
│ │ │
│ ┌──────▼──────┐ 作用域：团队/组织 │
│ │ Team Rules │ 配置位：团队管理后台 │
│ │ (团队规则) │ 特点：Team/Enterprise 计划可用 │
│ └──────┬──────┘ 适合：公司级编码标准、安全规范 │
│ │ │
│ ┌──────▼──────┐ 作用域：单个项目（简化版） │
│ │ AGENTS.md │ 配置位：项目根目录 │
│ │ (代理规则) │ 特点：纯 Markdown，无需 frontmatter │
│ └─────────────┘ 适合：轻量级项目、快速上手 │
│ │
│ 加载优先级：User Rules → Team Rules → Project Rules │
│ 冲突处理：后加载的覆盖先加载的 │
│ │
└─────────────────────────────────────────────────────────────────┘1.2 .cursorrules vs .cursor/rules/ ------旧版和新版
你可能在网上看到两种写法，别搞混了：
bash
旧版（已废弃，但仍兼容）：
项目根目录/.cursorrules ← 单个文件，所有规则塞一起
新版（推荐）：
项目根目录/.cursor/rules/ ← 文件夹，每个规则一个文件
├── java-backend.mdc ← Java 后端规范
├── database.mdc ← 数据库规范
├── git-commit.mdc ← Git 提交规范
├── react-frontend.mdc ← React 前端规范
└── code-review.mdc ← Code Review 检查清单
为什么推荐新版：
├── 按场景拆分，单个文件更聚焦
├── 支持四种加载模式（下面详讲）
├── 文件匹配模式精准控制作用范围
├── 团队协作时 diff 更清晰
└── 不会一个文件几千行看不过来二、四种加载模式详解------这是 Rules 最核心的设计
每个 .mdc 文件的开头有一段 YAML frontmatter，它决定了这条规则 什么时候生效：
2.1 Always Apply（始终生效）
yaml
---
description: "通用代码风格规范"
alwaysApply: true
---
# 通用代码风格
- 使用中文注释
- 变量命名用英文
- 函数不超过 50 行
- 禁止 console.log 遗留在生产代码中适用场景：无论你在写什么代码，这些规则都应该生效。比如代码风格、语言偏好、安全底线。
注意 ：Always Apply 的规则每次对话都会消耗 token。放太多东西在这里 = 白白烧钱。
scss
Always Apply 的黄金法则：
├── 只放"无条件适用"的规则
├── 控制在 200 行以内（≈ 600-800 tokens）
├── 不要把 Java 规范放在 Always Apply（写前端时完全浪费）
└── 适合放：语言偏好、安全底线、输出格式要求2.2 Auto-attached（自动附加）
yaml
---
description: "Java Spring Boot 后端开发规范"
globs: ["src/main/java/**/*.java", "pom.xml"]
alwaysApply: false
---
# Java Spring Boot 规范
## 分层架构
- Controller：只做参数校验 + 调用 Service
- Service：业务逻辑，事务在这层
- Mapper：继承 BaseMapper<T>
## 禁止事项
- 禁止在 Controller 写业务逻辑
- 禁止 System.out.println（用 slf4j）
- 禁止硬编码魔法数字适用场景 ：当你打开/编辑匹配 globs 模式的文件时，自动加载。
这是最推荐的模式------精准投递，不浪费 token：
css
globs 模式示例：
Java 后端： ["src/main/java/**/*.java", "pom.xml"]
React 前端： ["src/**/*.tsx", "src/**/*.ts", "package.json"]
Vue 前端： ["src/**/*.vue", "src/**/*.ts"]
数据库相关： ["**/*.sql", "**/mapper/**/*.xml", "**/migration/**"]
测试文件： ["**/*.test.*", "**/*.spec.*", "**/test/**"]
Docker 相关： ["Dockerfile*", "docker-compose*.yml"]
文档文件： ["**/*.md", "docs/**"]2.3 Agent-decided（AI 自主判断）
yaml
---
description: "数据库设计和 SQL 编写规范，当涉及建表、写 SQL、数据库迁移时使用"
alwaysApply: false
---
# 数据库规范
...适用场景：你不确定该匹配哪些文件，但描述了场景，让 AI 自己判断要不要加载。
关键 ：description 要写得足够明确。AI 是根据 description 来决定要不要加载这条规则的。
sql
description 写法对比：
✗ 模糊：description: "数据库规则"
→ AI 不确定什么时候该用
✓ 明确：description: "数据库设计和 SQL 编写规范，当涉及建表、写 SQL、数据库迁移、MyBatis XML 编写时使用"
→ AI 看到你在写 SQL 就会主动加载2.4 Manual（手动引用）
yaml
---
description: ""
alwaysApply: false
---
# 性能优化检查清单
...适用场景 ：不常用但偶尔需要的规则。使用时在对话中 @rules/performance-checklist 手动引用。
没有 description、没有 globs、alwaysApply 为 false → 只能手动触发。
2.5 四种模式怎么选？一张决策图
scss
你的规则每次对话都需要吗？
├── 是 → Always Apply
│ （通用代码风格、语言偏好、安全底线）
│
└── 否 → 能确定匹配哪些文件吗？
├── 能 → Auto-attached（用 globs）
│ （Java 规范配 *.java，React 规范配 *.tsx）
│
└── 不能 → 使用频率高吗？
├── 高 → Agent-decided（写好 description）
│ （数据库规范、Code Review 清单）
│
└── 低 → Manual
（性能优化清单、安全审计模板）三、由浅入深------从你的第一条 Rule 开始
3.1 入门：User Rules（全局配置）
打开 Cursor → Settings → Rules，这里可以写全局规则：
diff
推荐的 User Rules 配置：
- Always respond in 中文
- 使用中文变量注释，代码本身用英文
- 不要主动添加我没要求的功能
- 生成代码后简要说明改了什么
- 禁止在代码注释中解释修改内容User Rules 的定位是个人偏好------跟着你走，不跟项目走。
sql
User Rules 适合放什么：
✓ 语言偏好（用中文回复）
✓ 交互习惯（先解释再改代码 / 直接改不废话）
✓ 通用编码习惯（tab vs space、分号 vs 无分号）
✗ 项目技术栈（应该放 Project Rules）
✗ 团队规范（应该放 Team Rules 或项目内）
✗ 临时指令（直接在对话里说就行）3.2 基础：AGENTS.md（最快上手）
如果你觉得 .mdc 文件的 frontmatter 太麻烦，可以先用 AGENTS.md------纯 Markdown，零学习成本：
markdown
<!-- 项目根目录/AGENTS.md -->
# 项目规范
## 技术栈
- Java 17 + Spring Boot 3.2
- MyBatis-Plus 3.5
- MySQL 8.0
- Redis 7.x
## 代码规范
- Controller 只做参数校验和返回值封装
- Service 层处理业务逻辑
- 所有 API 返回 Result<T> 包装
- 异常使用全局 @RestControllerAdvice 处理
## 数据库规范
- 表名小写下划线（user_order）
- 必须有 id, create_time, update_time, is_deleted
- 禁止 SELECT *
- 索引命名：idx_表名_字段名
## 禁止事项
- 禁止在 Controller 写业务逻辑
- 禁止 System.out.println
- 禁止硬编码魔法数字
- 禁止直接拼接 SQLAGENTS.md 的定位：轻量、快速、够用。适合个人项目或小团队快速上手。
arduino
AGENTS.md vs .cursor/rules/ 对比：
AGENTS.md：
├── 优点：零学习成本，纯 Markdown
├── 优点：一个文件搞定
├── 缺点：没有条件加载（所有规则全量加载）
├── 缺点：不能按文件类型匹配
└── 适合：个人项目、小项目、快速验证
.cursor/rules/：
├── 优点：按场景拆分，精准加载
├── 优点：四种加载模式灵活控制
├── 优点：大项目不浪费 token
├── 缺点：需要学 frontmatter 语法
└── 适合：中大型项目、团队协作、多技术栈项目3.3 进阶：Project Rules（分场景精准配置）
这是真正发挥 Rules 威力的地方。我以一个全栈项目为例，展示完整的 Rules 目录结构：
scss
my-project/
├── .cursor/
│ └── rules/
│ ├── always/
│ │ └── code-style.mdc ← Always Apply：通用风格
│ │
│ ├── backend/
│ │ ├── java-spring.mdc ← Auto-attached：*.java
│ │ ├── database.mdc ← Agent-decided：SQL 相关
│ │ └── api-design.mdc ← Auto-attached：*Controller.java
│ │
│ ├── frontend/
│ │ ├── react-ts.mdc ← Auto-attached：*.tsx
│ │ └── styling.mdc ← Auto-attached：*.css, *.scss
│ │
│ ├── workflow/
│ │ ├── git-commit.mdc ← Agent-decided：Git 操作时
│ │ └── code-review.mdc ← Manual：手动触发
│ │
│ └── devops/
│ ├── docker.mdc ← Auto-attached：Dockerfile*
│ └── ci-cd.mdc ← Auto-attached：.github/workflows/*
│
├── src/
├── pom.xml
└── package.json四、实战场景一：开发类 Rules
4.1 Java Spring Boot 后端规范
yaml
---
description: "Java Spring Boot 后端开发规范，编写 Java 代码时使用"
globs: ["src/main/java/**/*.java", "pom.xml"]
alwaysApply: false
---
# Java Spring Boot 开发规范
## 分层架构Controller（入口层） ├── 只做：参数校验（@Valid）+ 调用 Service + 返回 VO ├── 禁止：写业务逻辑、直接调 Mapper、处理事务 └── 命名：XxxController，方法名见名知意
Service（业务层） ├── 负责：业务逻辑编排、事务管理 ├── 接口：定义 IXxxService 接口 ├── 实现：XxxServiceImpl └── 事务：@Transactional 加在 Service 方法上，不加在 Controller 上
Mapper（持久层） ├── 继承：BaseMapper（MyBatis-Plus） ├── 简单查询：用 LambdaQueryWrapper ├── 复杂查询：写在 XML 中 └── 禁止：在 Mapper 中写业务逻辑
DTO / VO / Entity ├── DTO：接收前端参数，用 @Valid 校验 ├── VO：返回给前端的数据结构 ├── Entity：对应数据库表，不要暴露给前端 └── 转换：用 BeanUtils.copyProperties 或 MapStruct
csharp
## 统一返回格式
所有 API 返回 Result<T>：
```java
{
"code": 200,
"message": "success",
"data": {}
}
// 错误返回
{
"code": 40001,
"message": "用户名不能为空",
"data": null
}异常处理
- 业务异常：throw new BusinessException(ErrorCode.USER_NOT_FOUND)
- 全局捕获：@RestControllerAdvice + @ExceptionHandler
- 禁止：catch 空块、吞异常、用 e.printStackTrace()
命名规范
| 类型 | 规则 | 示例 |
|---|---|---|
| 类名 | 大驼峰 | UserOrderService |
| 方法名 | 小驼峰 | getUserById |
| 常量 | 全大写下划线 | MAX_RETRY_COUNT |
| 包名 | 全小写 | com.example.user |
| Boolean 变量 | is/has/can 开头 | isDeleted, hasPermission |
| 接口方法 | 动词开头 | listUsers, getById, createOrder |
禁止事项
- 禁止 System.out.println（用 @Slf4j + log.info/error）
- 禁止硬编码魔法数字（定义常量或枚举）
- 禁止直接拼接 SQL 字符串（防注入）
- 禁止在循环中做数据库查询（N+1 问题）
- 禁止 @Autowired 字段注入（用构造器注入）
- 禁止返回 null 集合（返回 Collections.emptyList()）
yaml
### 4.2 React + TypeScript 前端规范
```yaml
---
description: "React TypeScript 前端开发规范"
globs: ["src/**/*.tsx", "src/**/*.ts", "package.json"]
alwaysApply: false
---
# React + TypeScript 前端规范
## 组件规范
- 使用函数式组件 + Hooks，禁止 Class 组件
- 文件名：PascalCase（UserProfile.tsx）
- 每个组件一个文件，不超过 200 行
- Props 必须定义 interface，命名为 XxxProps
- 使用 named export，不用 default export
## Hooks 使用规则
- useState：简单状态
- useReducer：复杂状态（多个关联字段）
- useMemo / useCallback：仅在性能瓶颈时使用，不要过早优化
- useEffect：依赖数组必须完整，禁止空依赖数组（除非明确只执行一次）
- 自定义 Hook：以 use 开头，抽离可复用逻辑
## TypeScript 规范
- strict: true，禁止 any（用 unknown + 类型守卫）
- 接口用 interface，类型别名用 type
- API 响应必须定义完整类型，不用 as any 跳过
- 枚举用 as const 对象替代 enum
## 样式
- 使用 Tailwind CSS，不写自定义 CSS 文件
- 响应式：mobile-first（sm → md → lg）
- 组件间距用 Tailwind 的 space/gap，不用 margin hack
## 禁止事项
- 禁止 var（用 const/let）
- 禁止 index 作为 key（除非是不会变化的静态列表）
- 禁止在 useEffect 回调中直接用 async（用 IIFE 或抽函数）
- 禁止 !important
- 禁止 inline style（用 Tailwind class）五、实战场景二：数据库类 Rules
数据库规范是很多团队最容易忽略的------直到某天 DBA 怒了。
5.1 数据库设计规范
yaml
---
description: "数据库设计和 SQL 编写规范，涉及建表、SQL 查询、数据库迁移、MyBatis XML 时使用"
alwaysApply: false
---
# 数据库设计规范
## 建表规范
### 必备字段（所有表必须有）
```sql
id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
is_deleted TINYINT(1) NOT NULL DEFAULT 0 COMMENT '逻辑删除：0-未删除 1-已删除'命名规范
| 对象 | 规则 | 示例 |
|---|---|---|
| 表名 | 小写下划线，带业务前缀 | sys_user, biz_order |
| 字段名 | 小写下划线 | user_name, order_amount |
| 主键 | id | id |
| 外键字段 | 关联表_id | user_id, order_id |
| 索引 | idx_表名_字段名 | idx_user_phone |
| 唯一索引 | uk_表名_字段名 | uk_user_email |
字段类型选择
scss
字符串：
├── 短文本（<256字符）→ VARCHAR(n)，n 按实际最大长度设置
├── 长文本 → TEXT
├── 固定长度（如状态码）→ CHAR(n)
└── 禁止 VARCHAR(9999)、禁止所有字符串都用 VARCHAR(255)
数字：
├── 主键/ID → BIGINT UNSIGNED
├── 金额 → DECIMAL(10,2)，禁止用 FLOAT/DOUBLE
├── 状态/标志 → TINYINT(1)
├── 数量 → INT UNSIGNED
└── 百分比 → DECIMAL(5,2)
时间：
├── 日期时间 → DATETIME（不用 TIMESTAMP，有 2038 问题）
├── 纯日期 → DATE
└── 禁止用字符串存时间SQL 编写规范
查询规范
- 禁止 SELECT *，必须列出具体字段
- WHERE 条件字段必须有索引（否则说明原因）
- JOIN 不超过 3 个表（超过考虑拆分或冗余）
- 分页查询必须有 ORDER BY
- 大表查询必须有 LIMIT
索引规范
- 单表索引不超过 5 个
- 联合索引遵循最左前缀原则
- 区分度低的字段不建索引（如 gender、is_deleted）
- 频繁更新的字段谨慎建索引
禁止事项
- 禁止在代码中拼接 SQL（用参数化查询 / #{} 不用 ${}）
- 禁止不带 WHERE 的 UPDATE/DELETE
- 禁止在循环中执行 SQL（N+1 问题）
- 禁止在大表上用 LIKE '%xxx'（前缀模糊走不了索引）
- 禁止在线上直接执行 DDL（需走变更流程）
yaml
### 5.2 结合 MCP 的数据库 Rule
如果你配了数据库 MCP（比如 MySQL、Doris、PostgreSQL），可以写一条专门的 Rule：
```yaml
---
description: "使用 MCP 数据库工具时的安全规范和操作指南"
alwaysApply: false
---
# MCP 数据库操作规范
## 安全底线
- 禁止执行 DROP TABLE / DROP DATABASE
- 禁止不带 WHERE 的 DELETE / UPDATE
- 禁止修改线上数据库的表结构（DDL）
- 查询必须加 LIMIT（默认 100，最大 1000）
## 查询习惯
- 先查表结构（DESCRIBE / SHOW CREATE TABLE）再写查询
- 大表先 COUNT 估算数据量，再决定查询策略
- 返回结果超过 50 行时，先确认是否需要这么多数据
- 复杂查询先 EXPLAIN 看执行计划
## Doris / OLAP 场景（如果有）
- 聚合查询优先使用物化视图
- 大范围扫描注意分区裁剪（按日期分区 → WHERE 必须带日期范围）
- 避免 SELECT DISTINCT 大数据量（用 GROUP BY 替代）六、实战场景三：全局 vs 项目级------怎么分配规则？
这是很多人纠结的问题：哪些规则放全局？哪些放项目级？
6.1 全局规则（User Rules / Always Apply）
vbnet
全局规则只放"跟项目无关"的个人偏好：
推荐放全局的：
├── 语言偏好：始终用中文回复
├── 交互风格：改完代码简要说明改了什么
├── 安全底线：不要在代码中硬编码密码/密钥
├── 输出格式：使用 Markdown 格式输出
└── 通用习惯：禁止生成超过 200 行的单个函数
不要放全局的：
├── 技术栈规范（Java / React / Vue → 应该按项目配）
├── 数据库规范（不同项目可能用不同数据库）
├── 业务逻辑（每个项目业务不同）
└── 框架特定配置（Spring / Next.js / Django → 按项目配）6.2 项目级规则的组织策略
sql
策略一：按技术栈分（推荐小项目）
.cursor/rules/
├── backend.mdc ← Java/Python/Go 后端规范
├── frontend.mdc ← React/Vue 前端规范
├── database.mdc ← 数据库规范
└── git.mdc ← Git 规范
策略二：按职责分（推荐中大项目）
.cursor/rules/
├── architecture.mdc ← 架构规范（分层、依赖方向）
├── coding-style.mdc ← 编码风格（命名、格式）
├── security.mdc ← 安全规范（注入、权限、加密）
├── database.mdc ← 数据库规范
├── testing.mdc ← 测试规范
├── api-design.mdc ← API 设计规范
└── deployment.mdc ← 部署规范
策略三：按模块分（推荐 Monorepo）
.cursor/rules/
├── common.mdc ← 通用规范
├── modules/
│ ├── user-service.mdc ← 用户服务特有规范
│ ├── order-service.mdc ← 订单服务特有规范
│ └── payment.mdc ← 支付模块（安全要求更高）七、Rules vs Superpowers vs Skill------三种体系的区别
你可能还听过 Cursor Superpowers 和 Skill（上篇文章讲的），它们和 Rules 到底什么关系？
sql
┌─────────────────────────────────────────────────────────────────────┐
│ 三种体系对比 │
│ │
│ ┌─────────────┐ ┌──────────────┐ ┌──────────────────────┐ │
│ │ Rules │ │ Skills │ │ Superpowers │ │
│ │ (规则) │ │ (技能包) │ │ (超能力/插件) │ │
│ └──────┬──────┘ └──────┬───────┘ └──────────┬───────────┘ │
│ │ │ │ │
│ 是什么： 是什么： 是什么： │
│ 持久化的编码 可复用的工作 社区维护的 │
│ 约束和规范 流程封装 预置 Agent 框架 │
│ │
│ 解决什么问题： 解决什么问题： 解决什么问题： │
│ "AI 生成的代码 "每次都要重复 "提供开箱即用的 │
│ 不符合我的规范" 描述工作流程" 高级开发工作流" │
│ │
│ 类比： 类比： 类比： │
│ 公司的编码规范手册 岗位 SOP 手册 外部顾问方法论 │
│ │
│ 格式： 格式： 格式： │
│ .mdc / .md 文件 SKILL.md 文件 插件包 │
│ │
│ 作用域： 作用域： 作用域： │
│ 项目级 / 全局 全局 / 项目级 全局 │
│ │
│ 加载方式： 加载方式： 加载方式： │
│ 文件匹配 / AI 判断 AI 按任务匹配 安装后自动激活 │
│ / 始终加载 / 按需加载 │
│ │
│ 典型内容： 典型内容： 典型内容： │
│ - 命名规范 - Code Review 流程 - TDD 工作流 │
│ - 禁止事项 - 需求分析框架 - 调试 Agent │
│ - 分层架构 - 文档写作模板 - 头脑风暴 Agent │
│ - SQL 规范 - 数据库设计流程 - 并行任务调度 │
│ │
│ 适合谁： 适合谁： 适合谁： │
│ 所有 Cursor 用户 有重复工作流的人 想要高级 Agent 能力 │
│ │
└─────────────────────────────────────────────────────────────────────┘7.1 它们是互补的，不是替代的
arduino
一个典型的配置组合：
Rules（约束层）：
├── "所有 Java 代码必须遵循阿里巴巴编码规约"
├── "数据库字段必须有 create_time"
└── "禁止 SELECT *"
→ 解决：代码质量的下限
Skills（流程层）：
├── "当做 Code Review 时，按 P0-P3 优先级检查"
├── "当分析需求时，用 MoSCoW 方法排优先级"
└── "当写文档时，按标准模板输出"
→ 解决：工作流的标准化
Superpowers（能力层）：
├── "用 TDD 模式开发：先写测试再写实现"
├── "用并行 Agent 同时处理多个文件"
└── "用调试 Agent 系统化排查 Bug"
→ 解决：开发能力的上限7.2 怎么选？取决于你的需求阶段
markdown
第一阶段（刚用 Cursor）：
└── 先配 Rules → 解决"AI 乱写代码"的问题
一个 AGENTS.md 或 3-5 条 Project Rules 就够了
第二阶段（用了一两个月）：
├── Rules 稳定了
└── 开始用 Skills → 封装你的重复工作流
Code Review、需求分析、文档写作
第三阶段（重度用户）：
├── Rules + Skills 都有了
└── 尝试 Superpowers → 解锁高级 Agent 能力
TDD、并行开发、系统化调试
核心原则：
不要一上来就搞一套复杂的配置。
先用最简单的方式解决最痛的问题，再逐步迭代。八、Rules 的优缺点------不吹不黑
优点
markdown
1. 零学习成本上手
└── 写个 AGENTS.md 放项目根目录，5 分钟搞定
2. 精准控制
└── Auto-attached 模式可以按文件类型精确匹配
└── 写 Java 的时候不会加载 React 规范
3. 团队可共享
└── .cursor/rules/ 跟 Git 走
└── 新人 clone 项目就自动有规范
4. 与 IDE 深度集成
└── 比对话中反复提示更可靠
└── AI 把 Rules 当作系统提示来遵守
5. 版本可追溯
└── 规范变更有 Git 记录
└── 可以 diff、review、rollback缺点
arduino
1. 不是 100% 强制执行
└── Rules 是"强烈建议"而非"硬性约束"
└── 复杂场景下 AI 偶尔会违反规则
└── 解决方案：关键规则用"禁止"而非"尽量不要"
2. Token 消耗
└── Always Apply 的规则每次对话都消耗 token
└── 规则写太多 = 上下文浪费
└── 解决方案：合理使用四种加载模式
3. 规则冲突
└── User Rules 和 Project Rules 可能冲突
└── 多个 Auto-attached 规则可能给出矛盾的建议
└── 解决方案：保持规则间无交叉，定期 review
4. 调试困难
└── 不确定某条规则是否被加载了
└── 不知道规则之间的优先级
└── 解决方案：对话中问 AI "你当前加载了哪些规则？"
5. 维护成本
└── 项目演进后规则可能过时
└── 需要定期 review 和更新
└── 解决方案：每月 review 一次，删除过时规则九、完整实战案例：我的真实项目配置
我日常维护 3 个项目（Java 后端 + React 前端 + 数据分析），以下是我的完整 Rules 配置：
9.1 User Rules（全局）
diff
- Always respond in 中文
- 始终不要开启 plan 模式，直接做就好了，复杂任务规划好 todos 就可以
- 禁止使用子代理，全部使用当前 agent 来完成功能
- 改完代码后简要说明改动点9.2 Java 后端项目 Rules
css
.cursor/rules/
├── java-backend.mdc ← [Auto-attached: *.java, pom.xml]
│ 核心内容：分层架构 + 命名规范 + 统一返回 + 异常处理
│
├── database.mdc ← [Agent-decided: SQL/数据库相关]
│ 核心内容：建表规范 + SQL 规范 + 索引策略
│
├── mcp-safety.mdc ← [Agent-decided: MCP 数据库操作]
│ 核心内容：禁止 DROP + 必须 LIMIT + 先 EXPLAIN
│
└── git-commit.mdc ← [Agent-decided: Git 操作]
核心内容：feat/fix/docs 类型 + 中文描述 + 72 字符限制9.3 效果对比
| 场景 | 没有 Rules | 有 Rules |
|---|---|---|
| 新建 Controller | 可能写业务逻辑在里面 | 严格只做参数校验 + 调 Service |
| 建表语句 | 忘了 create_time/update_time | 自动带上所有必备字段 |
| 写 SQL | 可能 SELECT * | 列出具体字段，加 LIMIT |
| Git Commit | 随便写 message | 规范格式 feat(scope): 描述 |
| Code Review | 每次都要说检查什么 | 自动按清单检查 |
| MCP 查询 | 可能查全表不限制 | 自动加 LIMIT，先看表结构 |
十、总结：适配比完美更重要
arduino
┌───────────────────────────────────────────────────────────────────┐
│ │
│ Cursor Rules 的核心理念： │
│ 不是要配一套"最完美的规则"， │
│ 而是要配一套"最适合你项目的规则" │
│ │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ 配置路径 │ │
│ │ │ │
│ │ 个人项目：AGENTS.md 就够了 │ │
│ │ ↓ │ │
│ │ 正式项目：3-5 条 Project Rules │ │
│ │ ↓ │ │
│ │ 多技术栈：按场景拆分 + Auto-attached │ │
│ │ ↓ │ │
│ │ 团队协作：Project Rules + Team Rules │ │
│ │ ↓ │ │
│ │ 深度用户：Rules + Skills + Superpowers 组合 │ │
│ │ │ │
│ └──────────────────────────────────────────────────────┘ │
│ │
│ 三条行动指南： │
│ │
│ 1. 从痛点出发 │
│ AI 哪里让你最烦？→ 先配那条规则 │
│ 不要一上来就追求"完整覆盖" │
│ │
│ 2. 逐步迭代 │
│ 一次加 1-2 条规则 → 验证效果 → 再加下一批 │
│ 比一次写 20 条然后不知道哪条有用要强得多 │
│ │
│ 3. 定期 Review │
│ 每月看一次：哪些规则有用？哪些过时了？哪些缺失？ │
│ Rules 和代码一样，需要维护 │
│ │
└───────────────────────────────────────────────────────────────────┘相关资源
如果这篇文章对你有帮助，点个赞让更多人看到。有问题欢迎评论区交流------你在 Rules 配置中踩过什么坑？欢迎分享。