Writing Cursor Rules
Cursor Rules Guide
What Are Cursor Rules?
Cursor Rules tell AI how your project works. By defining rule files, you give AI context about:
- Your coding standards
- Common patterns and conventions
- Mistakes to avoid
- Specific technical requirements
Required Rule Structure
Every rule file should follow this structure:
---
description: Clear, one-line description of what the rule enforces
globs: path/to/files/*.ext, other/path/**/*
alwaysApply: boolean
---
- **Main Points in Bold**
- Sub-points with details
- Examples and explanations
File References
# Use [filename](mdc:path/to/file) to reference files
[prisma.mdc](mdc:.cursor/rules/prisma.mdc) for rule references
[schema.prisma](mdc:prisma/schema.prisma) for code references
Code Examples
Use language-specific code blocks in rules:
// ✅ DO: Show good examples
const goodExample = true;
// ❌ DON'T: Show anti-patterns
const badExample = false;
Rule Content Guidelines
- Start with high-level overview
- Include specific, actionable requirements
- Show examples of correct implementation
- Reference existing code when possible
- Keep rules DRY by referencing other rules
Rule Maintenance
- Update rules when new patterns emerge
- Add examples from actual codebase
- Remove outdated patterns
- Cross-reference related rules
Best Practices
- Use bullet points for clarity
- Keep descriptions concise
- Include both DO and DON'T examples
- Reference actual code over theoretical examples
- Use consistent formatting across rules
Rule File Locations
- Project-level:
.cursor/rules/- project-specific rules - User-level:
~/.cursor/rules/- cross-project universal rules
Example: TypeScript Rule
---
description: TypeScript coding standards for this project
globs: '**/*.ts, **/*.tsx'
alwaysApply: true
---
- **Type Safety**
- Always use explicit return types for functions
- Avoid `any` type, prefer `unknown` for uncertain types
- Use strict null checks
- **Naming Conventions**
- Interfaces: PascalCase with `I` prefix (e.g., `IUser`)
- Types: PascalCase (e.g., `UserRole`)
- Constants: UPPER_SNAKE_CASE
- **Code Organization**
- One component per file
- Group imports: external, internal, types
- Export from index files
Example: Git Commit Rule
---
description: Git commit message standards
globs: ''
alwaysApply: false
---
- **Commit Format**: `type(scope): description`
- **Types**:
- ✨ feat: New features
- 🐛 fix: Bug fixes
- 📝 docs: Documentation
- ♻️ refactor: Code restructuring
- ✅ test: Tests
- **Best Practices**:
- Keep commits atomic and focused
- Write in imperative mood
- Explain why, not just what
Next Steps
Check out Git Commit Conventions & Emoji to level up your commit quality.
[VIBE_CODING_LAB_BANNER]
📚 相关资源
❓ 常见问题
关于本章主题最常被搜索的问题,点击展开答案
Cursor Rules 文件该放哪里?项目级和用户级有什么区别?
项目级放在 `.cursor/rules/`,跟着 repo 走,team 共用同一份规则;用户级放在 `~/.cursor/rules/`,跨项目通用,适合放个人代码偏好(命名习惯、注释语气)。同一规则两边都有时,项目级覆盖用户级,新人 clone 项目立刻拿到统一约定。
Rule 文件的 frontmatter 三个字段分别控制什么?
(1) `description` — 一行说明这条 rule 在管什么,AI 路由用;(2) `globs` — 文件匹配模式,例如 `**/*.ts, **/*.tsx`,决定哪些文件触发;(3) `alwaysApply` — boolean,true 表示无论文件类型都加载,false 只在 globs 命中时加载。Git commit 这种全局规则用 `alwaysApply: false` + 空 globs 让它按需调用。
Cursor Rule 里写 DO/DON'T 例子真的有用吗?
有用,比单纯写文字描述准确率高一截。模型读到 `// ✅ DO: const goodExample = true` 加上对应的 `// ❌ DON'T: const badExample = false`,能直接对齐 anti-pattern;只写一句"避免使用 any",AI 还是会偶尔回退。规则里两种例子一起放,命中率最高。
用 [filename](mdc:path/to/file) 这个语法是干嘛的?
Cursor 专用的文件引用语法,让 rule 文件里能交叉引用其他 rule 或代码文件。例如 `[prisma.mdc](mdc:.cursor/rules/prisma.mdc)` 让 AI 在解析 schema 时拉这条 rule,`[schema.prisma](mdc:prisma/schema.prisma)` 直接指向 source。规则保持 DRY 的关键 — 共享逻辑写一次,引用多次。
Cursor Rules 写多了会不会拖慢 AI 响应?
会,但分情况。`alwaysApply: true` 的 rule 每次对话都加载到 context,5-10 条还行,超过就明显挤占 token;用 `globs` 限定文件类型的 rule 只在匹配时加载,可以放几十条不卡。优化方法:把通用规范放 `alwaysApply: true` 短文件,框架/语言专属规则按 globs 切片。