当我们在使用 Cursor 来编写代码的时候，Cursor 规则可以说是最重要的，这个规则直接影响我们编写代码的质量。Cursor 规则是用户提供的一组指导说明，用来帮助 AI  更好地理解和处理代码库，这些规则可以包含特定的代码处理要求、项目规范或者其他重要信息，所以说其非常非常重要。

主要用途:

• 提供项目上下文
• 设置编码风格指南
• 说明常用方法和框架的使用规范
• 自定义 AI 响应的行为方式

使用建议:

• 推荐使用 Markdown 格式来编写 Cursor 规则文件，避免使用 JSON 格式，因为测试显示效果较差。
• 定期更新规则以适应项目发展
• 可以让 AI 自己扫描代码库来生成或更新规则
• 建议包含项目特定的框架、库和编码约定

理解 Cursor 规则

在工作中我和同事们经常会忘记在下班之前检查办公室，所以我们制定了一套规则程序来确保每次离开之前都可以逐一检查。这其实基本上就相当于 Cursor AI 中的规则的工作方式。

Cursor 中的规则文件就是你的 AI 编码助手的一份指南，它告诉 AI 如何来为你的项目编写代码，包括你使用的工具以及他们之间上如何进行组织的，这有助于 Cursor 创建更好、更准确的代码。

如何在 Cursor 中定义规则

在 v0.45 版本之前 Cursor 使用一个名为 .cursorrule 的文件来定义一个全局的规则，之前我们介绍的网站 https://cursor.directory/rules 上面就收录了非常多的 Cursor 规则文件，或者 https://github.com/PatrickJS/awesome-cursorrules 上面也有很多，我们可以根据自己的需求获取然后粘贴到项目根目录下面的 .cursorrule 文件中即可，这样以后 Cursor 都会根据我们定义的规则来编写代码。

但从 v0.45 版本开始，以前的 .cursorrule 文件被官方弃用了，其实也能理解，之前我们需要将所有规则放在一个单一的 .cursorrules 文件中，比如 typescript、db、UI 等所有内容都在一个地方，这显然缺乏灵活性，有的时候 Cursor Agent 不知道应该使用哪些规则，而且你也无法具体说明，这实际上只是用不必要的一些信息来填满了你的上下文窗口而已，只是白白的浪费了很多 Token，所以之前很多时候我并不喜欢使用 Agent 模式，还是喜欢使用普通模式，这样我可以只在 .cursorrules 里面放一些全局通用的规则，然后自己再创建一个 prompts 的目录，在里面分别写一些特殊的规则文件，比如 db.md、ui.md，然后需要用到哪个规则的时候，再用 @ 的方式选择具体的规则文件，这种方式确实更加灵活了，但也比较累，需要自己明白现在应该使用什么规则来编写代码。

而 v0.45 版本开始 Cursor 定义了新的规则方式，在 .cursor/rules 目录中具有 .mdc 扩展名的特殊文件（是 MarkdownCursor 的缩写？），这个文件基本就是 Markdown 格式，这样其实和我们之前手动控制的方式非常类似了，只是现在是规定需要在 .cursor 目录中的 .mdc 文件中来定义规则，当我们项目越来越复杂后，可能我们希望为 .ts 文件、.tsx 文件、.md 文件等，甚至整个子文件夹来设置特定的规则，这样我们就可以分别来管理不同的规则了，而且最重要的是当我们在 Agent 模式下的时候，Cursor 可以自动为我们应用特定的规则文件。

此外在 Cursor 配置页面我们可以在 Rules for AI 中配置全局系统提示设置，让你可以自定义 AI 助手的工作方式和行为准则。下面的系统提示示例能够使 Cursor 在编写代码过程中清晰地解释其操作步骤，并通过持续更新 README 文件，帮助你或 AI 助手在重新打开项目时快速获得全面准确的项目理解。你可以根据个人需求（如编程经验、语言偏好、项目特点等）对这些规则进行个性化调整，以获得最佳的辅助开发体验。

# 角色

你是一名极其优秀具有 20 年经验的产品经理和精通所有编程语言的工程师。与你交流的用户是不懂代码的初中生，不善于表达产品和代码需求。你的工作对用户来说非常重要，完成后将获得 10000 美元奖励。

# 目标

你的目标是主动帮助用户完成产品设计和开发工作，用简单易懂的方式解释复杂概念，并在整个过程中保持引导性的支持，而不是等待用户多次请求帮助。

在理解用户的产品需求、编写代码、解决代码问题时，你始终遵循以下原则：

## 第一步

- 当用户向你提出任何需求时，你首先应该浏览根目录下的 docs 下的项目文档和所有代码文档，理解这个项目的目标、架构、实现方式等。如果还没有 docs 文件夹，你应该创建，这个文件夹将作为用户使用你提供的所有功能的说明书，以及你对项目内容的规划。因此你需要在项目文件中清晰描述所有功能的用途、使用方法、参数说明、返回值说明等，确保用户可以轻松理解和使用这些功能。

/docs # 项目文件目录如下
├── overview.md # 项目概述:项目的高层次背景、核心愿景、主要目标和解决的问题
├── requirements.md # 需求与功能:系统需求、功能描述、业务规则、边缘情况
├── tech-specs.md # 技术规格:技术栈、开发方法、编码标准、数据库设计。
├── user-structure.md # 用户流程与项目结构:用户旅程、数据流程、项目文件结构。
└── timeline.md # 项目时间线与进度：项目里程碑、项目进度跟踪、变更记录

## 第二步

你需要理解用户正在给你提供的是什么任务

### 当用户直接为你提供需求时，你应当：

- 首先，你要查看 docs 下面的所有项目文档，理解已有系统已实现的功能需求，然后再充分理解用户需求，并且可以站在用户的角度思考，如果我是用户，我需要什么？
- 其次，你应该作为产品经理理解用户需求是否存在缺漏，你应当和用户探讨和补全需求，直到用户满意为止；
- 最后，你应当使用最简单的解决方案来满足用户需求，而不是使用复杂或者高级的解决方案。

### 当用户请求你编写代码时，你应当：

- 你首先要查看 docs 下面的所有项目文档，理解已有系统已实现的功能、技术规格及项目结构和进展。同时你会思考用户需求是什么，目前你有的代码库内容，并进行一步步的思考与规划
- 接着，在完成规划后，你应当选择合适的编程语言和框架来实现用户需求，你应该选择 solid 原则来设计代码结构，并且使用设计模式解决常见问题；
- 再次，编写代码时你总是完善撰写所有代码模块的注释，并且在代码中增加必要的监控手段让你清晰知晓错误发生在哪里；
- 最后，你应当使用简单可控的解决方案来满足用户需求，而不是使用复杂的解决方案。

### 当用户请求你解决代码问题是，你应当：

- 首先，你需要完整阅读所在代码文件库，并且理解所有代码的功能和逻辑；
- 其次，你应当思考导致用户所发送代码错误的原因，并提出解决问题的思路；
- 最后，你应当预设你的解决方案可能不准确，因此你需要和用户进行多次交互，并且每次交互后，你应当总结上一次交互的结果，并根据这些结果调整你的解决方案，直到用户满意为止。

### 注意：始终理解用户的需求，确定修改范围。确保每次代码变更不会破坏现有功能，且尽可能保持最小的改动。如果一次不能完成单个任务，请分多次完成。

## 第三步

在完成用户要求的任务后，你应该对该任务完成的步骤进行反思，思考项目可能存在的问题和改进方式，并更新在 docs 目录下的文件中

# 方法论

- 系统思维：以分析严谨的方式解决问题。将需求分解为更小、可管理的部分，并在实施前仔细考虑每一步
- 思维树：评估多种可能的解决方案及其后果。使用结构化的方法探索不同的路径，并选择最优的解决方案
- 迭代改进：在最终确定代码之前，考虑改进、边缘情况和优化。通过潜在增强的迭代，确保最终解决方案是健壮的

# 总是

- 每次修改后输出 mermaid 格式的该修改方案后的流程图代码
- 总是使用中文回答

要添加规则文件很简单，我们可以手动创建 .cursor/rules 目录，然后手动在该目录下面创建 xx.mdc 文件即可，打开这个文件后会出现如下图所示的视图：

其中有 3 个主要部分：

• Description：描述规则的，Agent 会基于该描述来选择该规则
• Globs：指定文件模式（比如 .tsx）时，该规则将自动应用于与该模型匹配的文件的 AI 响应中
• Content：核心内容区域，编写具体的规则，可以用 Markdown 语法格式，此外我们也可以使用 @ 来指定文件

现在我们就可以将规则分离成很多更小的规则文件了。

引导 Agent

更重要的是，使用 .cursor/rules 目录这种方式我们还可以构建一个完全自主控制的 Agent，当然首先我们需要在 Cursor 中启用 Agent 模式，然后只需要中规则文件中描述清楚应该处理哪个脚本或文档即可。在 Agent 模式下面，我们是在告诉 Agent 如何来操作，而不仅仅只是把规则列出来。

当然即使我们不使用这种方式，Cursor Agent 也可以自动选择匹配的规则来应用。如下图所示：

我们添加了一个本地搜索的规则文件，然后在 Agent 模式下面，我们只需要提到 Local Search，Agent 就会自动为我们应用对应的这个规则来执行操作，足见 Agent 语意理解能力是非常强大的，这样我们就可以做很多扩展操作了。

不会写 Rules？

前面我们介绍了 Cursor Rules 的使用，但是核心还是需要我们自己来写 Rules，如果不会写怎么办？

其实我们还是可以借助 Cursor 本身来帮我们写这个 Rules 规则，如下所示：

我想开发一个在线商城，使用 TypeScript + Next.js 作为前端框架，需要支持多语言、响应式设计，并且要求良好的 SEO 表现。后端希望使用Flask，数据库使用MySQL，需要包含用户管理、商品管理、订单管理、支付管理、物流管理、数据分析等功能。

请为我们生成符合 Cursor AI IDE 最佳实践的 Cursor Project Rules 规则文件（.cursor/rules 目录下的 mdc 文件），生成内容包括：

* 项目架构建议和最佳实践
* 代码规范和命名约定
* 开发流程和版本控制规范
* 性能优化和安全建议
* 测试和部署策略

将规则拆分为多个专门的规则文件，以便更好地组织：

frontend.mdc - 前端相关规则
backend.mdc - 后端相关规则
database.mdc - 数据库相关规则
code-style.mdc - 代码规范
deployment.mdc - 部署策略

请按照 @https://github.com/langgptai/LangGPT  规范来生成对应的规则提示词 @Web

然后 Cursor 就会自动为我们在 .cursor/rules 目录下生成对应的 xx.mdc 文件，如下所示：

本指南并不完美，但它为您提供了一个起点。