Cursor Rules 实战：.cursorrules 与 .cursorignore 怎么写（含模板）

很多人用 Cursor 用到一段时间会遇到同一个问题：

小改动越改越大，最后不敢点“Apply”
代码风格和团队规范对不上（命名、目录、错误处理、测试策略）
项目越大越慢，@codebase 像“看不见”你的仓库
公司代码不敢随便索引，担心把敏感文件卷进去

解决思路不是写更长提示词，而是把“口头约束”固化成 规则文件。

这篇文章讲三件事：

.cursorignore：哪些文件/目录不要参与索引与上下文
.cursorrules：Cursor 在这个项目里应该怎么做事（边界、风格、输出格式）
如何按“单仓/monorepo/团队协作”三种场景落地

三个文件分别解决什么问题

文件	你用它来做什么	典型效果
`.cursorignore`	排除不该索引/不该喂给 AI 的内容	变快、跑偏减少、敏感目录更安全
`.cursorrules`	固定团队规范与边界（“怎么改、改到哪、怎么交付”）	输出更一致、改动更可控
`.gitignore`	Git 不追踪哪些文件	与 AI 无关，但常和上面两者同时存在

注意：具体规则细节会随 Cursor 版本迭代而变化。本文给的是可落地的通用写法，你可以按团队实际再裁剪。

落地顺序：先 ignore，后 rules，最后再优化

推荐顺序：

先写 .cursorignore，把噪音和敏感数据排掉
再写 .cursorrules，把输出边界和交付格式固定
用 1 周数据复盘，再迭代规则（不要一口气写很长）

`.cursorignore` 模板（建议从“保守”开始）

目标：把依赖、构建产物、缓存、日志、密钥等排除掉。

你可以先直接复制，然后再按你的仓库删减：

# 依赖与包管理
node_modules/
.pnpm-store/

# 构建产物 / 缓存
.nuxt/
.output/
dist/
build/
.next/
coverage/

# 工具缓存
.vscode/
.idea/
.DS_Store
*.log

# 环境变量与密钥
.env
.env.*
*.pem
*.key
*.p12

# 大文件与数据（按需）
*.zip
*.tar
*.gz
*.7z
*.mp4
*.mov
*.pdf

常见踩坑

把整个仓库都索引了：很慢，而且“相关文件建议”会更乱
把生成目录也索引了：AI 会参考生成代码，导致改动方向偏
忘了排除 .env：就算不直接输出，参与上下文也不放心

monorepo 额外建议

如果你是多包仓库，建议把“非当前包”的大目录先排除，再按需放开。这样可以减少跨包误改和索引负担。

`.cursorrules` 模板（把“边界”写清楚）

.cursorrules 的目标不是写一堆口号，而是让 Cursor 每次改动都更可控。

推荐结构：

项目概述（让它别乱引框架）
目录与边界（改哪里、不改哪里）
代码风格（命名、类型、错误处理）
输出格式（先计划、后补丁、附验证步骤）

核心原则：规则要“可执行、可检查、可争议”

可执行：出现明确动作（例如“先输出文件清单”）
可检查：review 时能判断有没有遵守
可争议：团队成员可对规则本身提 PR 调整

下面给一份偏通用的模板（你可以把技术栈替换成自己的）：

# .cursorrules

## 项目概述
- 这是一个基于 Nuxt/Vue + TypeScript 的前端项目。
- 优先复用现有工具与组件，不要引入新框架/新工程方案。

## 目录边界（非常重要）
- 只允许修改：src/、app/、components/、composables/、server/（按项目实际调整）
- 禁止修改：scripts/、infra/、CI 配置、锁文件（除非我明确要求）
- 禁止跨目录重构：不要为了“更优雅”移动文件

## 代码规范
- 不使用 any（除非我明确允许）
- 遇到不确定的类型先提问，不要猜
- 保持现有 API 不变，除非我明确要求调整
- 错误处理必须明确：不要吞错误

## 输出要求
- 先输出：将修改的文件清单 + 每个文件的修改点 + 验证步骤
- 我确认后再生成代码/补丁
- 改动尽量小步，避免一次改太多文件

## 验证
- 如有脚本：优先给出可执行的验证命令（lint/typecheck/build）
- 如是 UI：给出最小手动验证路径

monorepo 专用模板（可直接改名使用）

如果你的仓库按 packages/* / apps/* 管理，推荐再加一条“作用域约束”：

# .cursorrules (monorepo)

## Scope First
- 每次任务必须先确认目标包，例如 packages/landing。
- 未明确范围时，先提问再改动。
- 禁止跨包重构，除非需求明确要求。

## Change Budget
- 单轮最多修改 2-4 个文件。
- 超过预算时先输出计划，等待确认。

## Safe Commands
- 不执行会产生全局副作用的命令（端口清理、全仓格式化、批量删除）
- 高风险命令必须二次确认。

## Delivery Format
- 输出包含：改动文件、改动理由、验证步骤、回滚方案。

这类模板最适合团队协作，能明显减少“改到别的子项目”的事故。