☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 免费无限量使用 DeepSeek R1 模型☜☜☜
长文提醒，建议收藏后阅读！！！
Cursor 0.5 版本的 Project Rules 系统突破了传统单一 .cursorrules 文件的限制，借助 三级规则架构 实现了精细化管控，我在最近的开发中也把 Cursor Rules 升级成了 Project Rules ，发现这一变化相当震撼。这意味着 Cursor 不仅仅是一款 AI 编码助手，它正在朝着真正的工程化开发工具转型。本文将分享我使用 Project Rules 的实际经验和方法。
Project Rules 的演进：从单文件到模块化设计
Cursor 最重要的改进就是放弃单一大文件，转向模块化的 .mdc 文件体系。这种转变具有以下几个关键优势：
- 更高的可维护性：不同规则分类存放，更便于管理
- 团队协作更友好：不同团队成员可以负责不同的规则模块
- 按需加载：AI 可以根据上下文自动加载相关的规则
分层规则管理：构建规则金字塔
通过实践，我发现搭建一个三层规则体系非常实用：
1. 通用层（.cursor/rules.general.mdc）
这一层包含团队共识和项目通用规范：
<code># 通用项目规则<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>- 复杂逻辑必须添加注释说明</code>
2. 语言层（如 .cursor/rules.python.mdc）
针对特定语言或框架的具体规范：
<code># 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/ 目录下</code>
3. 任务层（如 .cursor/rules.test.mdc）
针对特定开发任务的临时规则：
<code># 测试编写规范<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 时间</code>
模式化执行
我最喜爱的 Project Rules 高级技巧之一是利用模式标记来改变 AI 的工作方式。这有点像给 AI 分配不同的"角色"：
研究模式
<code>[MODE: RESEARCH]<br></br>- 仅分析代码，不直接修改<br></br>- 提供详细的代码结构解释<br></br>- 标记潜在问题并提供背景信息<br></br>- 禁止生成完整解决方案，仅提供方向性建议</code>
当我需要理解复杂的代码库时，这个模式特别有用。它让 Cursor 成为一个耐心的讲解者，而不是急于求成的修改者。
创新模式
<code>[MODE: INNOVATION]<br></br>- 允许提出多种解决方案<br></br>- 每个方案必须包含:<br></br> * 实现概述<br></br> * 技术优势<br></br> * 潜在风险<br></br> * 扩展性评估<br></br>- 必须提供至少 2-3 种不同方案比较</code>
当我面对架构决策或技术选型时，这个模式让 Cursor 成为我的头脑风暴伙伴。
执行模式
<code>[MODE: IMPLEMENTATION]<br></br>- 严格按照以下步骤执行代码修改:<br></br> 1. 检查依赖关系<br></br> 2. 修改目标文件<br></br> 3. 更新相关测试<br></br> 4. 验证代码是否符合项目规范<br></br>- 每个修改必须添加注释说明<br></br>- 生成修改前后的对比说明</code>
当我确定了解决方案，需要精确执行时，这个模式让 Cursor 成为一个专注的执行者。
自动化生成
让 AI 为 AI 编写规则，直接使用 Cursor 提供的两种生成 Project Rules 的方式：
使用命令生成：
直接在 Cursor 中输入 /Generate cursor rules
<code>/Generate cursor rules for monorepo with NestJS+React+TypeScript</code>
自动生成包含 rules.backend.mdc、rules.frontend.mdc、rules.shared.mdc 的完整规则体系
基于项目依赖生成：
Cursor 会分析 package.json 或其他配置文件，自动生成相应的规则
<code>cursor rules --from-package # 解析依赖生成技术栈规则</code>
生成逻辑：
- 识别
dependencies中的框架（如 React→生成组件规范） - 解析
devDependencies中的工具链（如 ESLint→同步代码风格）
我的实践是：先让 Cursor 自动生成一个基础版本，然后根据项目特点进行定制化调整。这节省了大量编写基础规则的时间。
案例研究：
我研究了 monorepo 项目 @languine_ai 的规则设计，它的 Project Rules 结构非常值得参考：
<code>.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</code>
特别值得学习的是它们如何处理包间依赖关系：
<code># 包依赖管理规则 (.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>- 禁止循环依赖</code>
Project Rules 核心思维
通过深入使用 Project Rules，我总结出三个核心思维：
1. 规则即文档
Project Rules 不仅是给 AI 看的，也是团队成员理解项目约定的活文档。优秀的规则应该：
- 解释"为什么"而不仅是"做什么"
- 提供具体示例
- 引用更深入的资源链接
2. 渐进式规则体系
不要一次性定义所有规则。最佳实践是：
- 从最基本、共识度最高的规则开始
- 随着项目发展逐步添加更细化的规则
- 定期回顾和精简不再适用的规则
3. 环境适应性
规则应该根据
