官方文档：https://cursor.com/cn/docs/context/rules
规则的工作原理：大型语言模型在不同补全之间不会保留记忆。规则在提示级别提供持久、可重用的上下文。应用后，规则内容会被加入到模型上下文的开头。这为 AI 在生成代码、理解编辑或协助处理工作流时提供一致的指导。
一、什么是 Cursor Rules
简单来说，Rules 就是你给 AI 助手设定的"行为准则"——告诉它在帮你写代码时应该遵循什么规范、偏好和约束。可以把它理解为：给 AI 配置一份"员工手册"，让它按照你的要求来工作。
简单理解，Cursor Rules 就是你为 AI 设置的一些规则，你可以定义技术栈、代码规范、目录结构、组件规约等各类要求。当 AI 生成代码时，这些规则会约束 AI 的各种“奇思妙想”，以便生成更加符合预期的项目代码。
当一条规则被触发后，规则中的内容会被附加到提示词中，为 AI 提供参考，无论是在自动补全、代码生成、重构还是错误修复时都能遵循这些规范。
1、全局规则 and 项目规则
打开 Cursor 的 Settings-Rules 界面进行配置。
全局规则：User Rules - 这些规则全局起效，适合存放一些个人的编程习惯或实现偏好。例如 Cursor 中文版默认的 “Always respond in 中文” 。
项目规则：Project Rules - 这些规则仅对当前项目生效，文件格式存储，方便版本控制，适合整个团队共享相同规则。
点击 Project Rules 右侧的“Add Rules”即可新增。
注意，新建的 Rules 文件后缀名是 .mdc，而不是原来的 .cursorrules，但 Cursor 依然兼容原来的 cursorrules，记得勾选 “Includes .cursorrules file” 即可。
2、规则类型：主要包括以下几种
- Always：总是生效，规则内容会始终包含在模型上下文中。
- Auto Attached：根据后面配置的文件规则才会起效，比如，指定
src下的文件、指定 java 文件等。 - Agent Requested：你可以将你的想法写入后面的输入框，AI会判断是否需要追加规则到上下文，比如，当生成界面效果时应用当前规则。
- Manual：在与 AI 对话时，手动指定规则，比较灵活，仅当通过 @Cursor Rules 显式调用时包含。
简而言之，如果你想手动调用规则，用 Manual；想自动触发用 Auto Attached；想始终生效用 Always；想让 AI 自己决定是否用，就用 Agent Requested。
3、Rules 文件的结构
---
description: # 规则描述（可选）
globs: # 匹配的文件模式，如 "**/*.vue"
alwaysApply: true # 是否始终应用
---
# 规则内容（Markdown 格式）
关键配置项：
| 配置 | 说明 |
|---|---|
| alwaysApply: true | 始终生效 |
| globs: "**/*.vue" | 仅在编辑 .vue 文件时生效 |
| description | 让 AI 按需引用的描述 |
4、Rules 文件怎么来？
（1）针对全局规则 - 自己整理：这是最可靠的方式，但估计也是大家最不喜欢的方式。一句一句地整理技术栈、代码规约、项目约定等内容，耗费巨大，但是长期效果最佳，毕竟，最适合的才是最好的。
（2）针对项目规则 - 自己整理 + Cursor 自己生成 Rules：这是新版本 Cursor 的一大亮点，直接在 AI 对话框中输入“/”，会弹出快捷指令 “Generate Cursor Rules” 回车后发送指令即可。
也可以直接在 Chat 中让 AI 分析项目并生成规则：提示词示例
请分析当前项目的技术栈、目录结构和代码风格，
为我生成一份 .cursor/rules/project-guidelines.mdc 规则文件，包含：
1. 项目使用的技术栈约束
2. 代码风格规范
3. 命名规范
4. 组件/模块拆分原则
（3）使用社区规则模板：从 cursor.directory 获取现成的规则模板，按项目技术栈选择
地址：https://cursor.directory/
二、Cursor 四种规则类型对比
| 类型 | 存放位置 | 作用范围 | 特点 | 适用场景 |
|---|---|---|---|---|
| User Rules | Cursor Settings | 所有项目 |
1.全局生效，所有项目都会应用 2.不会被版本控制，纯个人配置 3.始终加载，无法按文件类型过滤 |
语言偏好、个人习惯等通用性的
|
| Project Rules | .cursor/rules/*.mdc | 当前项目 |
1.支持 globs 按文件类型匹配 2.支持 alwaysApply 控制是否始终生效 3.可被 Git 版本控制，团队共享 4.支持子目录独立规则 |
技术栈约束、代码规范、目录结构、特定文件规则：globs: "**/*.vue" |
| Team Rules | 云端管理 + 本地 | 团队所有成员 |
1.需要 Cursor Business/Enterprise 版本 2.管理员可设置「推荐」或「强制」 3.自动同步到团队所有成员 4.适合大型团队统一管理 |
团队标准、企业编码标准、API 设计规范、安全审计要求、统一的架构模式等 |
| AGENTS.md | 项目根目录AGENTS.md | 当前项目 |
1.纯 Markdown 格式，无需 frontmatter 2.适合简单项目，快速上手 3.功能较 Project Rules 简单 4.无法按文件类型过滤 |
简单场景、小型项目快速配置、开源项目简单说明、不需要复杂规则匹配的场景 |
1、选择建议
| 你的需求 | 推荐类型 |
|---|---|
| 个人习惯，所有项目通用 | User Rules |
| 项目级规范，需要版本控制 | Project Rules |
| 大型团队，统一管理 | Team Rules |
| 简单项目，快速配置 | AGENTS.md |
| 需要按文件类型匹配 | Project Rules（globs） |
2、优先级（从高到低）：User Rules > Project Rules > Team Rules > AGENTS.md
三、最佳实践
1、分层策略：什么规则放哪里
| 层级 | 放什么内容 | 示例 |
|---|---|---|
| User Rules | 个人习惯、语言偏好 | "用中文回复"、"简洁风格" |
| Workspace Rules | 项目规范、技术栈约束 | "使用 Vue 3"、"代码不超过500行" |
| 按文件类型的 Rules | 特定文件的处理方式 | .vue 文件用组合式 API |
2、规则文件的组织方式：推荐按功能模块拆分多个规则文件
.cursor/rules/
├── project-guidelines.mdc # 通用项目规范（alwaysApply: true）
├── vue-components.mdc # Vue 组件规范（globs: "**/*.vue"）
├── api-design.mdc # API 设计规范（globs: "**/api/**"）
└── testing.mdc # 测试规范（globs: "**/*.test.ts"）
好处：（1）规则按需加载，不会给 AI 太多无关信息（2）便于维护和更新（3）团队成员各司其职
3、编写有效规则的技巧
✅ 好的规则特征
# 具体、可执行、有边界✅ "函数参数不超过 5 个，超过时使用对象参数"
✅ "组件文件使用 PascalCase 命名，如 UserCard.vue"
✅ "API 请求统一使用 src/api/ 下的封装方法"
❌ 避免的写法
# 模糊、主观、无法衡量❌ "写出高质量的代码"
❌ "保持代码整洁"
❌ "尽量优化性能"
4、 三种触发模式的选择
| 模式 | 配置方式 | 适用场景 |
|---|---|---|
| 始终生效 | alwaysApply: true | 核心规范，如代码风格 |
| 按文件匹配 | globs: "**/*.vue" | 特定文件类型的规范 |
| 按需引用 | 只写 description | 参考性内容，AI 自行判断是否需要 |
推荐组合：
---
description: "Vue 组件开发规范，包含组合式 API 使用指南"
globs: "**/*.vue"
alwaysApply: false
---
5、实用规则模板（可以自己准备一套，平时积累，不断优化更新）
少即是多：写 10 条清晰可执行的规则，胜过 100 条模糊的"建议"
6、要充分发挥 Cursor 规则的效果，需要编写简洁、明确的规则并在 Prompt 中正确调用。以下是一些实践建议：
- 规则简洁具体： 保持规则简洁，控制在 500 行以内是一个不错的目标
- 拆分复杂概念： 将复杂的概念拆分为多个可组合的小规则
- 使用示例与代码片段： 在有帮助的情况下提供具体示例或引用的文件
- 在提示中引用规则： 当需要时，可以在聊天提示中使用
@规则名来手动应用特定规则。 - 尽可能清晰： 避免模糊的指导。编写规则的方式应像写一份清晰的内部文档
- 及时更新： 当你发现自己在对话中重复强调某个事情时，可以将其编写成一条规则
- 团队协作： 团队内共享同一份规则，定期与团队讨论和更新，确保它们与当前代码实践保持一致。
通过以上实践，将规则编写与清晰的提示指令结合使用，Cursor AI 就能更智能地理解上下文和需求，从而产生高质量的代码结果。
Project Rules的三种层级：根据我们的实际开发场景，我们需要用到的 Rules（规则/规范）大致可以分为三个层级：
（1）通用规范：适用于所有项目，不受编程语言和框架影响
（2）编程语言规范：适用特定编程语言的最佳实践，遵循语言设计思想和惯例
（3）框架规范：适用特定框架，确保与框架生态系统兼容和一致性
这三种规则层层递进，从通用性到特定性，共同构成完整的编码规范体系。
四、Cursor Rules 的分层设计
一个新人来到项目首先要看文档，大模型也是一样，Cursor Rules 就是大模型看的项目文档。用好 Cursor Rules，可以让大模型接管中、大型项目的开发工作。
1、通用开发规则，使用 alwaysAppy: true 代表模型每次请求都需要查看这个 RULES
适用场景：通用的开发规则，比如让他更新完代码后，要更新 Rules
---
description: *** 项目核心开发规范
globs:
alwaysApply: true
---# *** 项目开发规范
## 技术栈约束
## 目录结构规范
### 组件放置原则
## 命名规范
## 代码风格
## 代码限制
## 禁止行为
## Rules 自更新机制完成功能开发后，检查是否有可抽离的通用模式：### 触发条件- 新增了可复用的组件模式
- 发现了新的代码约定或最佳实践
- 封装了新的组合式函数（compositions）
- 定义了新的 API 调用模式### 更新规则1. **识别模式**：判断本次改动是否具有通用性（≥3 处可复用）
2. **选择文件**：- 通用规范 → `project-guidelines.mdc`- Vue 组件相关 → `vue-components.mdc`- API 相关 → `api-design.mdc`
3. **追加规则**：在对应文件中补充新的规范说明
4. **告知用户**：提示已更新的规则内容### 示例**场景**：开发了一个带搜索防抖的输入框组件**AI 分析**：- 该模式可复用于多个搜索场景 ✓
- 属于 Vue 组件模式 → 更新 vue-components.mdc**更新内容**：
搜索防抖模式
const keyword = ref('')
const debouncedSearch = useDebounceFn(() => {
fetchData()
}, 300)
watch(keyword, debouncedSearch)**提示用户**：> 检测到新增了「搜索防抖」通用模式，已追加到 vue-components.mdc### 不更新的情况- 一次性的业务逻辑
- 已有规则覆盖的场景
- 用户明确拒绝
这样示例完整包含了：（1）触发场景（2）AI 分析过程（3）实际更新的规则内容（4）给用户的提示
2、精准打击
适用场景：中大型项目，按模块设计 Cursor Rules，减少 Token 消耗，让模型更好地理解你的需求
注意，中大型项目一定要使用 Cursor Rules 的 globs功能，模块化分层设计。
比如 A 功能，产品代码在 src/components/xxx/* 目录下，那么用好 globs 参数，这样当你动这个目录的功能，会自动关联这个 Rules，实现精准打击
学会使用 Cursor Rules 的分层设计，你就不会说大模型幻觉，越用越傻的问题了，这其实就是和 AI 协同办公的方式。