.cursorrules 配置
版本说明（2026-10-27）：
.cursorrules为旧版格式；新项目规则应查看 Cursor 官方 Rules 文档↗ 中的.cursor/rules方案。下文的优先级与应用方式需结合当前版本核对。
很多人用 Cursor 一段时间以后，都会碰到同一个问题：为什么同样的问题，今天改出来的代码像团队项目，明天改出来的代码像临时 demo？
原因通常不复杂。Cursor 虽然能看代码，但它并不会自动知道你团队长期坚持的约束。.cursorrules 的意义，就是把那些你不想每次重复说一遍的话，变成项目级默认规则。
#1. .cursorrules 真正在解决什么
它解决的不是“让 AI 更聪明”，而是“让 AI 少跑偏”。
最典型的偏差包括：
- 明明项目用 TypeScript strict，它却给你一段很松的类型
- 明明团队统一 named export，它又写回 default export
- 明明大家不用 snapshot test，它还是顺手给你加了
这些问题单看都不大，但积累起来会很烦。规则文件的价值，就是把这种重复纠偏提前做掉。
#2. 规则层级怎么理解
Cursor 的规则优先级通常是：
Team Rules → Project Rules → User Rules
.cursorrules 属于 Project Rules，也就是“这个仓库自己的长期规则”。
我会把它理解成项目说明书，而不是个人偏好清单。写进去的东西，最好是这个仓库长期都成立的，不要把临时任务也塞进去。
#3. 规则类型
常见会分成两类：
- Always Apply：每次都生效
- Apply Manually：只有你手动启用时才生效
如果是团队共识、技术栈约束、测试底线，这类通常适合 Always Apply。
如果是某一类特定任务才需要的规则，例如“本次 PR 只做性能优化，不改 UI”，那更适合手动应用，不要混进长期规则里。
#4. 怎么写，才不会越写越乱
这是最关键的一点。很多 .cursorrules 文件越写越长，最后变成一份没人敢改的愿望清单。
我更建议按下面这几类写：
- 技术栈
- 代码风格
- 测试要求
- 输出语言和注释规则
- 明确禁止事项
也就是说，优先写“长期稳定成立的东西”，不要写“当前这次任务想怎么做”。
#5. 一个更像真实项目的例子
markdown# Project Rules ## Tech Stack - Next.js 14 App Router - TypeScript - Styled-components - Jest for tests ## Code Style - Use functional components with hooks - Prefer named exports - Use async/await for async logic ## Testing - Add unit tests for new utilities - Avoid snapshot tests unless necessary ## Output - Respond in Chinese - Keep code comments concise
这类规则的价值不在于“写得多”，而在于它确实会反复影响生成结果。
#6. 我更建议补上的一类规则
如果你已经开始在项目里稳定用 Cursor，我会建议再补一类很实用的规则：禁止项。
例如：
- 不要在未确认时修改数据库 schema
- 不要引入新的状态管理库
- 不要把临时调试代码留在最终输出里
- 不要为了通过类型检查而使用
any
禁止项通常比鼓励项更能减少返工，因为它直接限制了最常见的偏航方向。
#7. .cursorrules 最容易写错的地方
#写得太空
比如“请遵循最佳实践”“保持代码简洁”。这种话人看着都知道什么意思不稳定，模型更不可能稳定执行。
#写了太多临时要求
今天在做登录页，明天换功能了，规则里还留着一堆只针对那次任务的限制。
#什么都想管
规则太长以后，模型不一定抓得住重点，人自己也会越来越难维护。
#8. 规则为什么也会影响内容质量和索引
如果你用 Cursor 来写 wiki、文档、博客或 SEO 页面，规则文件其实也会影响最后的内容质量。
因为很多“AI 味”不是来自模型本身，而是来自输出边界不清。比如你希望：
- 用中文解释，但保留英文技术词
- 不要写成营销语气
- 标题尽量直白，少用空洞小节名
这些东西都可以通过项目级规则慢慢固定下来。长期看，这会让整个站点内容风格更统一，也更利于索引。
#下一步
如果你现在只准备做一件事，我会优先把项目里最常见的 5 条长期约束写进 .cursorrules，而不是一口气写 50 条。
