长文提醒，建议收藏后阅读！！！

Cursor 0.5 版本的 Project Rules 系统突破了传统单一 .cursorrules 文件的限制，借助 三级规则架构 实现了精细化管控，我在最近的开发中也把 Cursor Rules 升级成了 Project Rules ，发现这一变化相当震撼。这意味着 Cursor 不仅仅是一款 AI 编码助手，它正在朝着真正的工程化开发工具转型。本文将分享我使用 Project Rules 的实际经验和方法。

Project Rules 的演进：从单文件到模块化设计

Cursor 最重要的改进就是放弃单一大文件，转向模块化的 .mdc 文件体系。这种转变具有以下几个关键优势：

1. 更高的可维护性：不同规则分类存放，更便于管理
2. 团队协作更友好：不同团队成员可以负责不同的规则模块
3. 按需加载：AI 可以根据上下文自动加载相关的规则

分层规则管理：构建规则金字塔

通过实践，我发现搭建一个三层规则体系非常实用：

1. 通用层（.cursor/rules.general.mdc）

这一层包含团队共识和项目通用规范：

# 通用项目规则<br></br>?<br></br>## 代码提交规范<br></br>- 所有提交消息必须遵循 Conventional Commits 规范<br></br>- 格式: `(): `<br></br>- 常见类型: feat, fix, docs, style, refactor, test, chore<br></br>?<br></br>## 文档规范<br></br>- 所有公共 API 必须有 JSDoc 或相应语言的文档注释<br></br>- README.md 必须包含项目描述、安装说明和基本用法<br></br>- 复杂逻辑必须添加注释说明登录后复制

2. 语言层（如 .cursor/rules.python.mdc）

针对特定语言或框架的具体规范：

# Python 代码规范<br></br>?<br></br>## 代码风格<br></br>- 遵循 PEP 8 规范<br></br>- 使用 4 空格缩进，不使用 Tab<br></br>- 行长度最大不超过 88 个字符<br></br>- 使用 black 和 isort 进行代码格式化<br></br>?<br></br>## 命名约定<br></br>- 类名使用 PascalCase<br></br>- 函数和变量使用 snake_case<br></br>- 常量使用大写 SNAKE_CASE<br></br>?<br></br>## 项目结构<br></br>- 使用虚拟环境管理依赖<br></br>- 包结构应遵循 src/package_name 模式<br></br>- 测试代码放在 tests/ 目录下登录后复制

3. 任务层（如 .cursor/rules.test.mdc）

针对特定开发任务的临时规则：

# 测试编写规范<br></br>?<br></br>## 测试组织<br></br>- 测试文件命名为 test_.py<br></br>- 每个测试函数应当只测试一个功能点<br></br>- 使用 pytest 作为测试框架<br></br>?<br></br>## 测试覆盖率<br></br>- 新功能必须有对应的单元测试<br></br>- 核心业务逻辑必须有集成测试<br></br>- 测试覆盖率目标: 行覆盖率 > 85%<br></br>?<br></br>## Mock 策略<br></br>- 外部依赖应当被 mock<br></br>- 数据库操作应使用测试数据库或事务回滚<br></br>- 避免在测试中使用 sleep()，优先使用 mock 时间登录后复制

模式化执行

我最喜爱的 Project Rules 高级技巧之一是利用模式标记来改变 AI 的工作方式。这有点像给 AI 分配不同的"角色"：

研究模式

[MODE: RESEARCH]<br></br>- 仅分析代码，不直接修改<br></br>- 提供详细的代码结构解释<br></br>- 标记潜在问题并提供背景信息<br></br>- 禁止生成完整解决方案，仅提供方向性建议登录后复制

当我需要理解复杂的代码库时，这个模式特别有用。它让 Cursor 成为一个耐心的讲解者，而不是急于求成的修改者。

创新模式

[MODE: INNOVATION]<br></br>- 允许提出多种解决方案<br></br>- 每个方案必须包含:<br></br> * 实现概述<br></br> * 技术优势<br></br> * 潜在风险<br></br> * 扩展性评估<br></br>- 必须提供至少 2-3 种不同方案比较登录后复制

当我面对架构决策或技术选型时，这个模式让 Cursor 成为我的头脑风暴伙伴。

执行模式

[MODE: IMPLEMENTATION]<br></br>- 严格按照以下步骤执行代码修改:<br></br> 1. 检查依赖关系<br></br> 2. 修改目标文件<br></br> 3. 更新相关测试<br></br> 4. 验证代码是否符合项目规范<br></br>- 每个修改必须添加注释说明<br></br>- 生成修改前后的对比说明登录后复制

当我确定了解决方案，需要精确执行时，这个模式让 Cursor 成为一个专注的执行者。

自动化生成

让 AI 为 AI 编写规则，直接使用 Cursor 提供的两种生成 Project Rules 的方式：

使用命令生成：

直接在 Cursor 中输入 /Generate cursor rules

/Generate cursor rules for monorepo with NestJS+React+TypeScript登录后复制

自动生成包含 rules.backend.mdc、rules.frontend.mdc、rules.shared.mdc 的完整规则体系

基于项目依赖生成：

Cursor 会分析 package.json 或其他配置文件，自动生成相应的规则

cursor rules --from-package # 解析依赖生成技术栈规则登录后复制

生成逻辑：

• 识别 dependencies 中的框架（如 React→生成组件规范）
• 解析 devDependencies 中的工具链（如 ESLint→同步代码风格）

我的实践是：先让 Cursor 自动生成一个基础版本，然后根据项目特点进行定制化调整。这节省了大量编写基础规则的时间。

案例研究：

我研究了 monorepo 项目 @languine_ai 的规则设计，它的 Project Rules 结构非常值得参考：

.cursor/<br></br>├── rules.monorepo.mdc # Monorepo 特有规则<br></br>├── rules.general.mdc # 通用规则<br></br>├── rules.frontend.mdc # 前端规则<br></br>├── rules.backend.mdc # 后端规则<br></br>├── rules.ci.mdc # CI/CD 规则<br></br>└── packages/ # 包特定规则<br></br> ├── rules.api.mdc<br></br> ├── rules.ui.mdc<br></br> └── rules.core.mdc登录后复制

特别值得学习的是它们如何处理包间依赖关系：

# 包依赖管理规则 (.cursor/rules.monorepo.mdc)<br></br>?<br></br>## 依赖流向<br></br>- 核心包 (@languine/core) 不应依赖其他内部包<br></br>- API 包 (@languine/api) 可以依赖核心包，但不应依赖 UI 包<br></br>- UI 包 (@languine/ui) 可以依赖核心包，但不应依赖 API 包<br></br>- 应用包可以依赖任何内部包<br></br>?<br></br>## 版本管理<br></br>- 所有包版本必须同步更新<br></br>- 包之间的依赖必须使用 workspace 协议 (例如: ”workspace:*“)<br></br>- 禁止循环依赖登录后复制

Project Rules 核心思维

通过深入使用 Project Rules，我总结出三个核心思维：

1. 规则即文档

Project Rules 不仅是给 AI 看的，也是团队成员理解项目约定的活文档。优秀的规则应该：

• 解释"为什么"而不仅是"做什么"
• 提供具体示例
• 引用更深入的资源链接

2. 渐进式规则体系

不要一次性定义所有规则。最佳实践是：

• 从最基本、共识度最高的规则开始
• 随着项目发展逐步添加更细化的规则
• 定期回顾和精简不再适用的规则

3. 环境适应性

规则应该根据