27

Writing Cursor Rules

⏱️ 15 min

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 切片。