不少人照着教程给项目配了规则文件------早期是根目录那个 .cursorrules，新版本收进了 Rules（项目规则）里------结果用起来还是一股"外人"味：命名风格对不上、动不动就引入一个你从没用过的库、接口返回结构它想当然、甚至手伸进配置文件里乱改。然后得出结论：规则这东西没用，还是得自己盯着。
规则本身没毛病，是大多数人把它用成了"许愿池"------丢一句"你是资深工程师，请写出高质量代码"，就指望它瞬间熟悉你这个养了好几年的项目。上一篇讲 Cursor 高频功能时，我在项目规则那节埋了个引子，这篇往深里做：规则到底放哪、写什么、怎么拆、怎么维护，再配上 @ 引用和每次开场怎么交代，凑成一套你今晚就能照着抄、照着改的东西。
一、它在你项目里"水土不服"，缺的到底是什么
AI 不是不会写代码，它缺的是你这个项目的"地方性知识"。
一个新人入职，你会告诉他：咱们时间处理统一用某个库别自己造轮子、接口返回固定长什么样、src 下每个目录是干嘛的、配置和密钥那几个文件碰都别碰、提交信息按什么格式写。这些东西在团队里靠口口相传和一次次 code review 沉淀下来，而 AI 每次开一个新会话，都相当于一个刚入职、记忆清零、还特别勤快的新人------你不告诉他，他真的不知道。
它写代码时能看到的上下文，无非这么几类：当前在编辑器里打开的文件、你用 @ 主动喂给它的东西、这个会话里聊过的历史、规则文件里常驻的约定，以及它自己翻代码时读到的已有写法。规则文件的特殊之处在于：它是唯一"常驻"的那一类，不用你每次重复交代。
想明白这点，就能纠正一个最常见的误区：问题往往不是规则写得不够多，而是该常驻的约定没写进规则、该临时给的上下文没精准给、好不容易写进规则的又全是没法执行的空话。三件事叠在一起，规则自然像没写一样。
二、规则放哪：全局、项目、目录，别一锅炖
规则的入口这半年变过几次。早期普遍是项目根目录放一个 .cursorrules 单文件；新版本把它收进了 Rules（项目规则）设置里统一管理，支持建多条规则，新版本还能把规则绑定到特定目录或文件类型上，做到只在你改某块代码时才加载。具体入口长什么样、支持到什么程度，以你所用版本的官方文档为准，别拿几个月前的截图硬找。
不管界面怎么变，规则按"作用范围"分就是三层，各管一摊：
| 层级 | 该放什么 | 举例 | 放错的后果 |
|---|---|---|---|
| 全局规则 | 换任何项目都成立的个人习惯 | 注释用中文、commit 风格、默认不给显而易见的代码加注释 | 把某个项目的专用库写进全局，换个项目就误导它 |
| 项目规则 | 这个仓库特有的硬约定 | 技术栈、统一用的库、目录结构、接口规范、禁碰清单 | 只写个人偏好、不写项目约定，它照样乱选库 |
| 目录级规则 | 某个子目录才有的写法 | src/api 下接口怎么封装、scripts 下脚本的固定套路 | 全塞进项目规则，常驻内容臃肿，重点被稀释 |
目录级规则是很多人没用上、但回报很高的一层。它的价值有两个：一是规则按需加载，不动那块代码就不占上下文；二是不同模块互相矛盾的写法能各自隔离，不会出现"前端组件的规矩被强加到后端脚本上"这种打架。
三、规则写什么：一份能直接照抄的模板骨架
这是这篇的核心。下面是我在自己项目里反复精简后留下的规则骨架，做了脱敏，你可以整块抄过去，再按自己仓库改。它不追求大而全，追求每一条都能被执行、能被验证。
markdown
# 项目规则（示例骨架，按自己仓库改）
## 1. 这个项目是干什么的
- 一句话说明系统用途，以及当前技术栈（框架、语言的具体版本以仓库当期依赖清单为准）。
- 主要目录：src/api 放接口请求，src/views 放页面，src/utils 放纯函数，scripts 放一次性脚本。
## 2. 技术选型（硬约束）
- 时间处理统一用 dayjs，不要再引入第二个日期库。
- 网络请求统一走 src/api 里已封装好的实例，不要在组件里直接发请求。
- 新增第三方依赖前，先在对话里说明用途，没有明确必要不许加。
## 3. 代码风格与命名
- 变量和函数用小驼峰，组件文件用大驼峰，常量用全大写下划线。
- 一个函数只做一件事；超过一屏的函数，先和我确认怎么拆再写。
- 注释写"为什么"，不复述"是什么"，不给显而易见的代码加注释。
## 4. 接口与数据约定
- 接口返回固定是 code、data、msg 三段；code 不为成功值时走统一错误处理。
- 列表接口统一带 page、page_size，响应里取 list 和 total。
- 不确定字段含义时先问，不要看着字段名猜结构。
## 5. 不许碰的地方
- 不修改环境配置、密钥与证书文件、CI 配置，以及构建产物、依赖目录和自动生成的代码。
- 不改公共组件对外暴露的参数，也不改已有接口的字段名，除非我明确要求。
- 删除文件、改路由、动权限相关逻辑之前，先列出来等我确认。
## 6. 提交与测试
- 一个改动一个提交，commit message 用"类型: 说明"，类型从 feat、fix、refactor、docs、test 里选。
- 改了工具函数或接口处理逻辑，要同步补或改测试，跑通仓库既定的测试命令才算完。
- 不认识的测试或构建命令先问我，不要自己猜一个就跑。
## 7. 你（AI）的工作方式
- 接到任务，先用几句话复述你理解的目标和打算动哪些文件，等我确认再改。
- 小步修改，每步把改动摊清楚；拿不准的地方明说"这里不确定"，不要硬编。
- 遇到实际情况和本规则冲突，指出来一起改规则，不要默默违反。写规则有个贯穿始终的标准：每条都要能落到具体动作上。"写出高质量代码""注意性能和安全"这种话，它没法执行，等于占着位置不干活；而"时间处理统一用 dayjs、禁止再引入第二个日期库""接口返回固定三段式"，它照着做就行，你 review 时也一眼能看出它有没有遵守。
模板里凡是会随版本变的东西------框架版本号、具体命令、菜单路径------都别写死，写成"以仓库当期依赖清单为准""跑仓库既定命令"，否则下次一升级，你的规则就成了错误信息。
四、规则不是越多越好：几个反向坑
刚尝到甜头的人最容易走另一个极端：什么都往规则里塞，文件越写越长，然后发现它反而开始"时灵时不灵"。这几个坑我都踩过。
规则之间互相打架，是最隐蔽的一个。一条说"尽量抽公共函数复用"，另一条说"保持组件独立、不要提前抽象"，它遇到具体场景只能二选一，你没法预测它这次选哪条，外在表现就是同样的要求有时照做、有时无视。定期把规则通读一遍，把矛盾的地方合并成"默认怎样、什么情况下例外"。
规则写太死，也会帮倒忙。把实现细节规定到每一行，它就失去了根据具体问题变通的空间，甚至为了贴合规则硬套出低级错误。规则该约束的是"边界和约定"，不是"实现过程"。
规则和代码现状脱节，是长期项目的通病。库里早就从旧方案迁走了，规则里还写着旧方案，它会认认真真按过时的规矩来。所以每次重构、换库、改目录结构，顺手把对应规则一起更新，把它当一份"活文档"维护，而不是写完就埋掉。
还有一点：一次性的任务说明不要写进规则。"这个登录页按钮往左挪两像素"是这一次对话里临时交代的事，用完就过期；把它常驻进规则，只会让真正重要的长期约定被一堆噪音稀释。
给规则做体检，每条问三个问题就够了：它具体到能被执行吗？它在当前代码里还成立吗？它和别的规则冲突吗？三个问题有一个答不上来，这条就该改或者删。
五、规则管常驻，@ 管当下：临时上下文要喂准
规则解决的是"长期共性"，而每个任务还有大量"临时个性"的上下文，这部分靠 @ 引用和开场交代，别指望规则全包。
改哪几个文件，就 @ 哪几个；跨文件联动的改动，把相关文件和那份需求文档一起 @ 进去；能直接贴关键代码片段的，就别让它自己满仓库翻------它翻得越多，额度掉得越快，还容易翻错版本。这一点在前面"额度审计"那篇算过账：最贵的从来不是改代码，是反复搬运无关上下文。
每开一个新会话，我习惯用三句话把场子铺好，这也是个能直接抄的套路：先说这是个什么项目、当前要解决什么；再说这次能碰哪些文件、哪些绝对不许动；最后说做完的验收标准是什么。比如："这是个后台管理项目，这次给用户列表加一个按注册时间筛选的功能，只动用户列表页和对应的接口文件，别碰公共请求封装，筛选能正常传参、列表能正确分页就算完。"你会发现，这段话和规则模板里的约定是咬合的，等于把常驻规则在具体任务上又强调了一遍。
另外，别把文档全文复制进规则。把 README、架构说明、接口文档放在仓库里固定的位置，在规则里点明路径和各自用途，它需要细节时会自己去读，这比你把所有东西塞进一个臃肿的规则文件聪明得多。
最后补一句：这套思路不是 Cursor 专属。Claude Code 里常见的 CLAUDE.md、越来越多工具开始支持的 AGENTS.md，干的是同一件事------把项目的隐性约定显性化、常驻化（具体文件名和加载方式以各工具当期文档为准）。你在一个工具上整理好的规则，换工具时基本是平移，不用从头再学一遍。
六、今晚就能落地的顺序，外加一张排错表
不用一上来就写一份几十条的完美规则，按这个顺序来，阻力最小：
- 先写最小可用版，只放四块：技术栈、统一用哪些库、禁碰清单、提交规范。这四块能挡掉八成的低级跑偏。
- 拿一个真实的小任务跑一遍，观察它还在哪猜错，把那条具体约定补进去------只补"刚刚真的踩到"的，不凭想象预防性堆砌。
- 跑顺之后，把稳定下来的约定固化，把一次性的临时说明移出规则。
- 以后每踩一次坑，只把"反复出现"的约定沉淀下来，规则保持精简。
| 你遇到的情况 | 多半是怎么回事 | 怎么办 |
|---|---|---|
| 规则写了完全不生效 | 放错入口，或写的是空话 | 按当期文档确认规则位置；把套话改成可执行的具体约束 |
| 同样的规矩时灵时不灵 | 两条规则互相冲突 | 通读合并，写成"默认怎样、什么情况例外" |
| 它总爱碰不让动的文件 | 禁碰清单不够具体、没写进常驻规则 | 在项目规则里列明确切目录/文件，并在开场再强调一次 |
| 规则写得很全它还是乱选库 | 技术选型约束没写死，或规则和现状脱节 | 明确"统一用某库、禁止再加同类"，换库后同步更新规则 |
| 换了个 AI 工具要不要重写 | 各家文件名不同、思路相同 | 规则内容平移到对应工具的规则文件，按其文档调整格式 |
| 规则会不会泄密 | 规则会随项目被读取、分享 | 密钥、账号、内部地址一律不写进规则，尤其仓库要开源或给外人时 |
写在最后
让 AI 真正融入你的项目，靠的从来不是在对话框里敲一句"你是资深工程师"，而是把团队里那些没人专门整理、却处处约束着你的隐性约定，一条条显性化、常驻化，再用 @ 把每个任务当下需要的上下文精准补齐。规则文件是这里面成本最低、回报最持久的一步------写一次，之后每个新会话都白捡一个"已经入职培训过的新人"。
评论区留个数字，看看你现在到哪一层：1、从没配过规则；2、配了，但基本没用、也不知道该写啥；3、已经有一份能跑的项目规则；4、开始按目录拆分，还会随重构一起维护。 票数最高的那档，我下一篇往细里拆。
另外还有两篇在排期：一篇是"怎么判断一个接入渠道靠不靠谱"的避坑清单，只讲怎么分辨、不推任何东西；另一篇想写让 AI 接手陌生老代码、改祖传项目的实战。你更想看哪个，评论区说一声。
觉得有用，点个赞、收藏起来对着配一遍；顺手关注一下，这个系列我一篇篇往下更。