用了大半年的 Cursor我最大的感受是AI 不会主动懂你它只会按它自以为的方式猜你。早期我几乎不碰 Rules觉得每次对话多提一句要求就够了结果它在同一个项目里今天用 4 空格缩进、明天用 Tab今天写封装好的请求函数、明天自己发明一套新的请求层。后来我养成了一个习惯拿到任何项目先写一套 Rules再开始让 AI 干活。这期是 Cursor 工具系列专栏的第六篇前面几篇里我反复用到 Rules、Skills、Commands、subAgents 这些概念很多朋友一直催着让我拆开讲讲。今天先把最基础也最容易被忽视的 Rules 说透。简单讲Rules 就是给 AI 编辑器用的行为规范书告诉它在你这个项目里哪些能做、哪些不能做、用什么风格做。这篇文章主要适合两类人一类是已经用上这类工具、但总觉得生成代码风格不对、老改老忘的开发者另一类是团队里想把 AI 真正纳入开发流程、给多个项目统一标准化的人。先把规则这个点盘透了后面再聊 Skills、Commands 和 subAgents 才不会头晕。1. 先别急着让 AI 写代码先回答这个项目的规矩是什么1.1 没有 Rules 时AI 生成代码的几种典型野路子我见过太多人第一次用 AI 编辑器写项目时的场景新建一个文件输入一句需求回车代码出来了跑起来似乎也对。等代码量变大问题就全冒出来了。最典型的表现是风格漂移——同一个项目里有时候它用 4 空格缩进有时候又变成 2 空格有时候变量命名用驼峰有时候又用下划线。更让人头疼的是它特别喜欢重新发明轮子明明项目里已经封装好了统一的请求库、日志工具和错误码表它偏要自己再写一套仿佛完全没看见这些已有代码。另一个常见问题是擅自动架构。我有一个某内部数据看板项目最初只是在某个模块里让 AI 帮我补一个数据导出功能结果它直接把底层的数据访问层调用方式改了还顺手重构了好几个接口导致其他模块跟着报错。这个问题的根源不是 AI 能力不行而是它根本不知道这个项目的规矩是什么。人进到一个新团队会先看文档、问同事、了解代码规范AI 编辑器如果不注入规则它就只会靠通用常识和你当前对话里的碎片信息来猜。所以我的建议是新建项目的第一件事不是写业务代码而是把规则说清楚。你花半小时写规则可能省下后面几十次改回去的拉扯。1.2 Rules 和 Skills、Commands、subAgents 的分工这个系列标题里把 Rules、Skills、Commands、subAgents 放在一起很容易让人以为它们是同一类东西其实四者的定位差异很大。它们都是让 AI 按你想要的方式工作的手段但作用的时间尺度完全不同。我给它们的分工大致是这样一张表功能模块核心作用生命周期典型使用场景Rules定义长期行为约束持续生效代码风格、架构边界、安全红线Skills封装某一类任务的方法论按需加载代码审查、性能诊断、接口文档生成Commands一组可复用的提示词命令用户主动触发一键修复 lint、生成 commit messagesubAgents后台执行特定任务的代理任务进行时并行跑测试、批量改代码也就是说Rules 是地基。你在项目里把规则树起来了Skills、Commands 和 subAgents 才有统一的坐标系可依循。我几乎没把它们当独立功能用而是当成在规则框架下帮 AI 省事的工具。所以这一篇先把 Rules 讲透后面几篇再逐个拆剩下三个就不会绕弯路了。2. 规则文件放哪里、怎么读从单一文件到目录化规则2.1 项目根目录 .cursor/rules 与现代规则格式最早接触这套规则系统时很多人记住的是一个叫 .cursorrules 的单文件规则把 Markdown 内容写在里面AI 就会自动遵守。这种单文件用法确实简单但随着项目复杂起来把所有规则堆在一个文件里会有两个麻烦一是文件越来越大AI 每次都要把整个文件读进上下文浪费宝贵的上下文窗口二是没法做细粒度的按文件类型生效比如前端代码和后端代码的规则混在一起AI 经常分不清。所以现在更推荐的做法是在项目根目录建一个 .cursor/rules 文件夹里面放若干 .mdc 文件每个文件负责一类规则。这本质上和把大型单体模块拆成多个独立模块是同一个思路按职责拆分、按场景加载。目录结构大概是这样的项目根目录/ ├── .cursor/ │ └── rules/ │ ├── python-code-style.mdc │ ├── api-design.mdc │ ├── security-redline.mdc │ └── commit-message.mdc ├── src/ └── README.md建议文件后缀用 .mdc这是我目前验证过的、能被规则系统识别并解析 Frontmatter 的主流写法。如果你手头还有 .cursorrules 文件不必急着删但新写的规则建议放到目录里。2.2 .mdc 文件的三个字段.mdc 文件不是纯 Markdown它可以带一段 YAML Frontmatter用来告诉规则系统这条规则什么时候用、用在哪些文件上。我常用的字段是三个description用一句话描述这条规则的用途。这段话很重要因为规则引擎靠它来判断这条规则是否与当前任务相关写清楚场景能让匹配更精准。globs用通配符匹配文件路径。只有你打开或编辑的文件落在 globs 范围内这条规则才会被加载。alwaysApply可选字段为 true 时表示不管打开什么文件都无条件加载这条规则适合放全局性规范。举个例子我有个 Python 后端项目在 .cursor/rules/python-code-style.mdc 里写的规则是这样--- description: 所有 Python 文件的编码规范与工程约定 globs: [**/*.py] alwaysApply: false --- # Python 代码风格规则 - 必须使用类型注解禁止用 # type: ignore 掩盖问题 - 缩进统一为 4 空格单行长度不超过 100 字符 - 所有对外暴露的接口必须编写 docstring说明参数和返回值 - 禁止在业务代码中直接使用裸的 requests.get()必须走 src/utils/http_client.py 的统一封装 - 新增数据库查询必须经过 Review不得绕过 ORM 直接写原生 SQL这里的 globs 写的是**/*.py意味着当 AI 开始处理项目里的任何 Python 文件时这条规则就会被加载到它的上下文里。而 description 里的Python 文件又进一步帮助规则引擎判断何时值得把文件注入进去。2.3 全局规则、项目规则、目录规则怎么选除了项目里 .cursor/rules 目录规则系统还有两个层级值得区分。一是全局用户规则通常在编辑器的设置面板里维护它对所有项目生效适合放那些你个人风格极强、到哪都不变的偏好比如默认使用 4 空格缩进注释使用中文不要生成没用的空函数。二是项目级规则随仓库走团队协作时每个人拉下来都能生效适合放项目特有的架构约束和规范。目录级规则则是通过 globs 实现的局部细化比如只对src/tests/**/*.py生效的测试规范。我的经验是全局规则尽量少且克制只放跨项目通用的东西项目规则才是重点放真正和这个项目绑定的约定。如果全局规则和项目规则内容冲突通常项目规则更贴近当前项目应该以项目规则为准但最好在规则文本里明确写明这种意图不要让 AI 去猜。3. 从零写一套能落地的项目 Rules3.1 动笔之前先画好五个维度的边界我见过很多人的第一版规则写出来其实就是一句话请遵守项目的代码规范。这条规则说了等于没说。真正有效的规则必须把 AI 本来可能不知道的信息补进去。我的实践是把规则拆成五个维度来想。第一是代码风格解决写出来好不好看的问题包括缩进、命名、注释语言、空行习惯。第二是架构边界解决代码往哪个方向走的问题比如哪一层负责读写数据、哪一层只处理业务逻辑、哪些模块不允许互相直接引用。第三是安全红线解决哪些事情绝对不能做的问题比如不带进密钥、不把日志打成 Debug 级别、不绕过鉴权中间件。第四是测试标准解决怎么证明代码是对的的问题。第五是工作流约定解决AI 该按什么顺序干活的问题比如先改接口定义再改实现、提交信息怎么写。这五个维度不是一次就要写全。我建议从你最痛的那个点开始用一两周时间把规则补到稳定状态。一开始就追求全结果往往是每条规则都写不深。3.2 几个可以直接抄的规则模板下面分享三个我实际在用的模板场景都很有代表性。第一个是前端项目的组件规范--- description: 前端 React 组件开发规范 globs: [src/**/*.tsx] alwaysApply: false --- # React 组件规范 - 组件一律使用函数式组件禁止创建 class 组件 - 所有 props 必须使用 TypeScript 接口定义禁止用 any - 业务组件禁止直接调用接口必须通过 src/services 下的封装函数 - 组件文件命名使用大驼峰内部工具函数使用小驼峰 - 注释与文案统一使用中文第二个是提交信息规范。这类规则看起来跟代码无关但对团队协作影响很大--- description: Git 提交信息格式 globs: [**/*] alwaysApply: true --- # 提交信息规范 - 提交信息格式type(scope): subject - type 取值feat、fix、refactor、docs、test、chore - subject 使用中文不超过 50 个字符 - 禁止在提交信息中出现临时标记如临时wiptest注意这条规则的 globs 我写的是**/*并且 alwaysApply 为 true因为在任何文件改动上它都应该生效。第三个是后端接口设计规范--- description: 后端 API 接口设计约束 globs: [src/controllers/**/*.ts] alwaysApply: false --- # API 设计约束 - 所有接口响应必须统一为 { code, message, data } 结构 - 分页参数统一使用 page 和 pageSize禁止使用 offset/limit - 新增接口前先检查 src/routes 下是否已存在同类路由 - 不允许在 Controller 里直接操作数据库必须调用 Service 层这些模板都有同一个特征每条规则都是可验证的。AI 写完之后你可以直接去检查代码是否符合规则描述里不带尽量通常这类模糊词。3.3 规则的数量控制在多少合适写规则最忌讳的是贪多。规则文件一旦超过一定体量AI 反而记不住重点。我自己的经验是项目规则正文总长度控制在 2 到 3 个屏幕高度以内大概相当于 40 到 80 行 Markdown。超过这个体量AI 要么把后面的规则截断要么在上下文压缩时把低频规则压缩掉。那怎么判断该不该加一条新规则呢我有一个标准同一条规则AI 在三次不同任务里重复违反了才值得把它写进规则文件。如果只是偶发一次不如在对话里直接纠正还不会污染规则体系。规则是给 AI 的长期记忆不是临时差评簿。4. 怎么确认规则真的被 AI 读进去了4.1 一个提问就能验证规则写完最大的困惑是AI 到底有没有读到我的验证方法特别简单新开一个对话然后直接问它这个项目里你需要遵守哪些规则请逐条列出并说明它们分别应用于哪些文件。如果规则生效AI 会非常具体地复述出我刚才在 .mdc 里写的那些内容比如Python 文件必须使用类型注解API 响应统一为 { code, message, data } 结构。如果它只是泛泛地说我会遵守项目规范那基本可以断定规则没有正确加载。我还喜欢在规则里埋一个验证暗号。比如在某条规则里写用户界面文本统一叫文案禁止叫文字然后让 AI 描述一个页面结构看它是否真的用文案这个词。这种做法能在不打扰正常工作的情况下快速判断规则是被完整注入还是只是被 AI瞥过一眼。4.2 规则没生效时的完整排查链路验证发现没生效不要慌按下面的顺序排查。我先给一个排查表格下面再逐个展开。现象可能原因处理办法规则完全没被复述文件路径或扩展名不对检查 .cursor/rules 目录和 .mdc 后缀只有部分规则生效Frontmatter 格式错误用 YAML 语法检查工具看一下打开某个文件时规则缺失globs 没匹配到目标路径核对路径通配符和大小写修改规则后仍然不生效当前会话未重新加载新开一个对话再验证两条规则互相矛盾新旧规则重叠清理并合并冲突规则规则太短/被忽略描述不够具体重写加入可验证的行为描述第一个最常遇到的坑是文件路径不对。有人把规则文件写成了.cursor/rules/python-code-style.md记得规则文件应该用.mdc后缀目录也必须是 .cursor/rules。第二个坑是 Frontmatter 的 YAML 语法写错少了一个冒号或引号规则会被整个跳过这种情况 AI 不会报错只会沉默地忽略。第三个坑是 globs 的大小写在跨平台项目里src 和 Src 的匹配结果是不同的。还有一个非常隐蔽的场景你在当前对话进行到一半时修改了规则文件然后继续让 AI 完成当前任务。规则通常是在会话创建时加载的改完文件以后必须新开一个对话才能让新规则生效。这不是缺陷这是规则系统的设计逻辑——上下文里的规则不能在运行中随意变化否则 AI 的行为会变得不可预测。5. 规则写多之后的反噬维护成本与优先级冲突5.1 上下文被规则挤占后的规则失忆规则不是越多越好还有一层原因是它会和对话内容争夺同一个有限的上下文窗口。现在的 AI 编辑器上下文是有上限的你把 50 条、每条约几百字的规则塞进去相当于每轮对话开头都背着几百行陈年规定在跑。一旦对话历史变长工具会自动压缩早期内容而压缩时优先保留的信息往往是最近的指令和代码内容规则这类长期静态内容反而容易被压缩得只剩骨架。我实际遇到过这样的情况项目里写满了规则某次让 AI 修改几十个文件时它越到后面越失忆开始无视早期的约束。后来我把规则精简到 20 条以内情况立刻好转。这件事给我的教训是规则的数量不是在给 AI 增加能力而是在给它增加记忆负担。你要确保每一条留下来的规则都有它不可替代的价值。5.2 冲突规则的处理明确的优先级胜过模糊的妥协规则多了以后冲突是必然的。举一个很常见的例子项目级规则说所有请求必须经过统一封装但某个模块级规则为了兼容旧接口写的是该目录下允许直接调用原生请求。两条规则同时加载时AI 经常会给一个两头不讨好的方案——它试图既遵守封装要求又保留原生调用结果代码里多了一层无用的包装。我的处理方法是面对冲突时不指望 AI 自己判断而是主动把优先级写清楚。比如在两条规则里都加上若与本项目的全局请求封装规则冲突以全局规则为准这样一句话。更彻底的做法是删掉旧规则因为这种新旧冲突本身往往是规则体系没来得及清理的表现。记住规则是给人维护的不是给 AI 做算术题用的。5.3 把规则当成项目文档的一部分持续维护最后想说的是规则文件不是写完就一劳永逸的东西。它和项目里的 README、接口文档一样有生命周期。我的做法是把它纳入版本管理每次改规则就跟着代码一起走 Review。规则文件里最好标注更新原因和日期比如某次上线新增前端组件禁止直接调接口原因是上周出现了一次绕过鉴权的事故。这样后来维护的人看到一条规则时能知道它是为了什么而存在而不是被迫接受一堆来路不明的禁令。我对 Rules 和文档的分工是这样的项目文档写给人类看解释系统是怎么设计的规则写给 AI 看说明这个项目的代码必须怎么长。两边不要重复一旦重复改了一边忘了另一边就会让 AI 和人看到的信息开始分叉。规则需要保护的是那些文档里没说、但代码里必须坚守的隐性约定。最后分享一个我自己的小习惯每次新建项目我会把写规则当作第一次提交而不是等项目写得差不多再补。规则本身不产生业务功能但它决定了 AI 后续产出的每一行代码是否贴合项目这笔时间花在最前面是最划算的。等你用多了会发现把规矩讲清楚这件事可能占掉整个 AI 编程工作流里一半的精力。下一期我接着聊 Skills先挖个坑。