编写 Cursor Rules 规则
大家好，前面的课程呢我们已经完成了项目基础的登录和注册功能。
后面呢我们要去做具体的业务开发。在做具体的业务开发之前呢，我们先来配置一下规则。
什么是 Rules
打开规则设置
我们点击右上角的”用户设置”，然后选择”Cursor 设置”，点击左侧的”规则”。
这里有简单的描述：
规则可以帮助 Builder 理解当前项目的约定。
查看文档说明
然后我们看一下文档（翻译为中文）：
Cursor 支持项目特定的规则配置，这些规则存储在
.cursorrules目录中，仅适用于当前的项目。它们优化模型适应，以符合您的编码偏好，包括项目框架和代码风格。
我们看最后一句话：符合您的编码偏好，包括框架和代码风格。
理解规则的作用
所以，规则其实就是我们给大模型的约束。我们要告诉他：
- 我们喜欢哪种编码偏好
- 我们当前项目的框架和代码风格是什么样的
这样呢，就不需要我们每次在对话的时候把这些信息手动再告诉他一遍。
下面其他的信息呢，我们就不去详细去分析了，我们直接去添加一个规则。
创建规则文件
创建后端规则
点击”添加”，输入规则的名称。
我们先新建一个服务端的规则，比如就叫 backend-rules。
建好之后呢，项目根目录下的这个 .cursor 目录下面就会有一个 rules 目录，下面就是我们新建的规则文件。
创建客户端规则
然后我们再建一个 client 的规则（客户端的规则），叫 client-rules。
编写后端规则
那么这个规则文件怎么去写呢？我们还是让 AI 来帮我们写。
新建对话
点击右上角的加号，新建一个对话。
然后右键选中服务端的规则文件，“添加到对话”。
编写提示词
然后开始写我们的提示词：
这个文件是当前项目服务端代码的编码规则文件。
帮我分析一下当前目录下的 account-backend 项目。
分析一下当前项目使用的编程语言、框架、项目结构等必要的信息，
整理一份编码规则出来。
要包含项目的基本信息、编码规范等等。
不要过长，要清晰一点。然后直接回车。
查看生成结果
我们来看一下，现在后端的编码规则呢已经生成好了。
1. 项目信息
下面列出了我们的技术栈：
- TypeScript + Express
- TypeORM 框架
- MySQL 8
- 认证用的是 JWT
- 以及集成了阿里云的短信
2. 项目结构
并且列出了每一个目录的含义。
3. 编码规范
- 分层架构
- 命名规范
- 实体的定义
继续往下看，还定义了：
- 错误处理
- 环境配置
- 中间件的使用
- 数据库的操作
- 依赖注入
- 代码注释等等
包括最后还列出了开发的命令。
看起来没有什么问题，我们点击”采纳”。
编写客户端规则
添加到对话
接下来我们继续去完成客户端的规则。
右键点击客户端的规则文件，选择”添加到对话”。
编写提示词
然后我们直接告诉他：
再整理一下客户端的规则。
要求和服务端的规则一致，尽可能精简，但是也要包含必要的项。然后回车就行了。
因为我们在当前对话中已经描述了服务端的规则的要求，所以我们在写客户端规则的时候呢，直接告诉他规则要同服务端一致。
查看生成结果
客户端的规则现在也生成好了，我们来看一下。
最上面呢，也是项目的基础信息，包括：
- 技术栈
- 项目结构
然后是编码规范：
- 组件与页面的规范
- 命名规范
- API 接口如何去定义
- 状态管理
- 路由拦截等等
看起来也没有什么问题，然后我们点击”采纳”。
创建通用规则
创建 common 规则
除此之外呢，我们还可以再建一个通用的规则，比如我们叫它 common。
通用的规则一般是和语言、框架无关的。所以当前的项目用什么语言、什么框架，我们这里的 common 规则呢都不需要去关心。
使用重构原则
比如呢有一些人，他对自己的代码质量要求非常的高，他可能就会在通用的规则里面去写一些《重构》这本书相关的规则。
遵循《重构》这本书的规则去写代码，一般代码都比较好维护，质量比较高。
编写提示词
比如我们可以让 AI 来写一下（我们只是示范一下，不一定要用这个规则）：
我现在还要写一个通用的规则，这个规则和编程语言、框架无关。
我希望遵循《重构》这本书的原则，但是强调的是代码的生成，
而不是重构代码本身。
尽可能精简。为什么我们要强调这句话呢？
因为《重构》它本身是在已有代码的基础上去做修改，但是我们的功能呢都是去生成新的代码，所以呢我们就这样去写一下。
然后回车让它生成一下试试。
查看生成结果
我们来看一下生成的结果：
1. 核心原则
下面有 10 个点
2. 反模式清单
也就是说禁止的编码方式
3. 代码生成检查清单
4. 优先级原则
正确性 > 可读性 > 性能 > 简洁性
那么这个看起来呢也没有什么问题，我们先采纳，并且类型我们也作为手动引入。
创建 always 规则
创建始终生效的规则
最后我们再添加一个规则，我们叫它 always（always-rules）。
这个规则呢，作为一个始终生效的规则。
编写规则内容
我们可以这样写：
修改代码时，请务必确认：
1. 不要修改无关的代码和逻辑
2. 一定要按照要求去修改代码这个规则是我自己个人用 AI 编码时的一个习惯。
如果说我没写这个规则的话，我一般会把这句话加在我的提示词最下面，这样可以尽量避免 AI 去给我们修改代码的时候胡乱改代码。
提交规则文件
暂存更改
最后我们把这些规则也提交一下，推送到远程仓库。
进入到”源代码管理”，然后在目录上点击加号暂存更改。
提交代码
然后点击”提交”，我们在 message 里面去写一下：
添加 rules简单一点，然后推送到远程仓库。
规则文件总结
创建的规则文件
| 规则文件 | 用途 | 内容 |
|---|---|---|
backend-rules | 后端编码规范 | TypeScript、Express、TypeORM、MySQL、JWT |
client-rules | 客户端编码规范 | uni-app、uni-best、组件规范、路由拦截 |
common | 通用编码规范 | 重构原则、代码质量、反模式清单 |
always-rules | 始终生效规则 | 不修改无关代码、按要求修改 |
规则文件的优势
- 减少重复说明：不需要每次对话都描述项目结构
- 统一编码风格：AI 生成的代码符合项目规范
- 提高代码质量：遵循最佳实践和重构原则
- 避免错误修改：明确告知 AI 不要修改无关代码
规则文件位置
project-root/
└── .cursor/
└── rules/
├── backend-rules.md
├── client-rules.md
├── common.md
└── always-rules.md使用规则的最佳实践
1. 保持规则精简
规则不要写得太长，否则会占用过多的 token，影响 AI 的理解。
2. 包含必要信息
- 技术栈
- 项目结构
- 命名规范
- 编码风格
- 特殊约定
3. 定期更新规则
随着项目的发展，及时更新规则文件以反映最新的项目约定。
4. 分类管理规则
- 项目特定规则：backend、client
- 通用规则：common
- 始终生效规则：always
遇到问题？
如果在配置规则过程中遇到问题，可以扫描下方的微信二维码帮您看下（免费咨询）
下一步
规则配置完成后，接下来我们需要：
