Cursor Rules 四大原则：让AI代码生成更稳定高效
见字如面，与大家分享实践中的经验与思考。
之前我已经原创了好几篇关于 Cursor Rules 实战总结的文章，感兴趣的朋友可以点击查看：
经过以上一系列的优化和改进，在实际项目应用中，我发现仍然会遇到如下问题：
规则不生效：Rules 文件虽然配置正确，但代码生成时不按照要求执行
浪费 Token：每次请求时，Rules 文件会被加入到上下文中传递给大模型，文件过大会造成 Token 的浪费
规则文件维护困难：现在推行将 Rules 文件拆分细化，容易出现冗余或冲突，以及文件拆分不合理等问题
输出不稳定：相同的规则和类似的提示词，前后生成的代码却有较大差异
破坏现有项目风格：AI 生成大量代码时，代码风格迥异，导致经常需要 Reject All，然后重新编写提示词反复生成
接下来我将分享个人总结的 MSEC 理论，用于指导后续所有 Cursor Rules 的编写。
Cursor Rules 四大原则
使用一张图进行总结：
01 最小化原则（Minimization Principle）
短小而精悍，保持规则的简洁、专注、易理解。
这样做的主要原因有两点：
大而泛的规则，AI 不容易准确遵守，不要指望给它模糊的指令就能执行得很完美
每次请求都会被带入到输入当中，不仅不生效，还浪费 Token
具体操作建议：
规则文件尽量保持在 500 行以内
将大的规则拆分成多个可组合的小规则
保留必要的、可执行的规则，移除所有模棱两可、大而泛、抽象的、重复的规则
举个例子来进行对比：
将 general.mdc 简化成 core.mdc，移除重复的内容（如：技术栈）、大而泛不够具体的规则，只保留项目通用的、可具体执行的规则。
02 结构化原则（Structured Principle）
一份好的项目规则要结构清晰，具有层级和作用域，我们可以使用分层架构来结构化地管理规则上下文，明确职责边界。
通过上图的分层架构，可以将项目中涉及的核心规则进行很好的分类，有效避免规则的冗余、冲突、拆分不合理等问题，维护起来更加得心应手。这部分内容我已经发过好几篇文章进行详细讲解，这里简单描述一下。
通用规则：
core.mdc：项目核心行为与风格通用规则
tech-stack.mdc：项目技术栈定义和官方文档链接
project-structure.mdc：项目结构和文件组织规范
...
语言规则：
java.mdc：Java 编码规范和最佳实践
python.mdc：Python 编码规范和最佳实践
golang.mdc：Golang 编码规范和最佳实践
typescript.mdc：Typescript 编码规范和最佳实践
......
框架规则：
springboot.mdc：SpringBoot 3 编码规范和最佳实践
django.mdc：Django 编码规范和最佳实践
android.mdc：Android 框架开发规范和最佳实践
....
其他规则（可选）：
git.mdc
document.mdc
api-integration.mdc
security.mdc
ddd.mdc
...
以上涉及的 mdc 源码可以在 GitHub 中找到（不保证当前版本是最新的，一般会在验证有效后再更新）。
03 精准引用原则（Explicitness Principle）
明确告诉模型"看哪里"、"回答什么"、"基于哪个 source"，这里既包含规则的引用、代码文件的引用，也包含具体的示例引用等。
先来了解一下 Cursor 控制规则引用的方式：
每个规则文件使用 MDC（.mdc）格式编写，该格式支持元数据和内容。通过类型下拉菜单控制规则的适用方式，该菜单会改变属性 description、globs、alwaysApply。
结合 Cursor Rules 的分层架构，如何让 AI 更好地定位到我们编写的规则文件呢？
1）将通用规则都设置成 Always Apply，这些规则始终生效，为所有代码提供基础规范。
2）将语言规则设置成根据文件扩展名自动应用的语言特定规范（Apply to Specific Files），只包含语言本身的特性。
3）将框架规则设置成 AI Agent 自动判断或者根据文件扩展名自动应用（Apply to Specific Files 或者 Agent Intelligently）。
4）其他可选规则，按需设置即可。如：git.mdc 可以设置成 Apply Manual，使用时需要 @git.mdc 来调用。
此外，我们可以在规则中引入规则，以及模板代码。我列举两个例子：
1）当规则触发时，像 @service-template.ts 这样的模板代码文件会作为附加上下文被包含。
---
description: RPC Service boilerplate
globs:
alwaysApply: false
---
- Use our internal RPC pattern when defining services
- Always use snake_case for service names.
@service-template.ts2）在 project-structure.mdc 中引入 ddd.mdc，可以在 ddd.mdc 中编写符合企业或个人的 DDD 详细理论知识和最佳实践。
在 AI Chat 中使用时，当你引入代码文件时，会自动显示使用了哪些 Rules。
⚠️注意：框架和语言往往容易被混淆在一起，如：SpringBoot 和 Java、Android 和 Kotlin、MiniProgram 和 Wxml、Wxss 等，建议分开管理。
04 一致性原则（Consistency Principle）
无论是代码风格、模块结构、命名方式、流程设计、交互行为，项目中都应该保持统一的一致性，并在所有地方遵循既定标准或最佳实践。
要让 AI 从上到下执行统一的代码风格并不容易，但设计一套好的规则，能够减少这种不一致性。建议从以下几个方面入手：
第一，在通用层中的
core.mdc强制要求遵守现有的代码风格。如果你能够提前搭好项目架子，让 AI 直接遵守远比从零搭建要好得多第二，在通用层中的
project-structure.mdc设计不同端的项目组织架构，告诉 AI 你编写的代码应该放在哪个目录、哪个文件下面第三，在语言和框架层中，定义代码风格、命名方式和最佳实践
最后，所有 rules 文件也应该尽量保持风格统一、结构统一，既利于维护，又利于 AI 的学习和引用。
最后
如果你想要在一个中大型项目中使用 AI 来辅助编写代码，什么最重要？
那就是可维护性和可读性。
AI 可以快速生成大量的代码，代码质量可以后续持续优化或人工修改，但是代码生成位置、结构、风格不对，就需要反复 Reject，重新生成。这样既浪费时间和 Token，又达不到预期的生成效果。
Cursor 系列精选阅读
如果你对 Cursor AI 编程感兴趣，可以浏览我的更多专题文章，同时我也会不定期更新到视频号，欢迎观看和订阅。
🚀 快速上手
💻 开发环境配置
🔌 MCP 工具生态
📝 规范与项目管理
🎨 UI/UX 设计流程
🔬 实战案例
欢迎关注公众号"Eric技术圈"，原创技术文章第一时间推送。