Cursor Rules 怎么写？适合前端项目的规则模板

Cursor Rules 的作用，是把你的项目习惯、代码规范和 AI 协作边界写下来，让 Cursor 在生成代码时更接近你的真实项目要求。很多人用 Cursor 效果不稳定，不是模型不行，而是上下文和规则太模糊。

这篇文章给一套适合前端项目的 Cursor Rules 模板，并解释每一段为什么要写。

快速结论

Cursor Rules 不应该写成愿望清单，例如“请写高质量代码”。它应该写成具体约束：技术栈、目录结构、命名规则、组件边界、测试要求、禁止事项和输出格式。

好的规则可以减少 AI 乱改架构、引入不必要依赖、生成风格不一致代码的概率。

适合谁

  • 用 Cursor 开发 React、Vue、Next.js、Astro 或静态站的人
  • 经常让 AI 改代码，但发现风格不稳定的人
  • 想让 AI 遵守项目约定的独立开发者
  • 小团队想统一 AI 编程规范

Cursor Rules 应该包含什么

一份实用的规则通常包含：

  1. 项目背景
  2. 技术栈
  3. 目录结构
  4. 编码风格
  5. UI/样式约定
  6. 数据和状态管理
  7. 测试和验证方式
  8. 禁止事项
  9. 回答格式

前端项目通用模板

你可以从这个模板开始：

# Project Rules

## Project context
This is a content-focused static website. The priority is maintainability, SEO, fast page load, and simple deployment.

## Tech stack
- Use the existing framework and file structure.
- Do not introduce a new framework unless explicitly requested.
- Prefer static generation and simple data files over databases.

## Code style
- Keep functions small and readable.
- Prefer clear names over clever abstractions.
- Reuse existing helpers before creating new ones.
- Avoid large rewrites unless necessary.

## UI rules
- Keep layout responsive.
- Do not add heavy UI libraries without approval.
- Preserve existing visual style.

## SEO rules
- Every public page needs title, description, canonical URL, and semantic heading structure.
- Article pages should include updated date and structured data when possible.
- Do not create thin duplicate pages for keyword variations.

## Safety rules
- Do not delete existing content without asking.
- Do not add tracking, ads, or external scripts unless explicitly requested.
- Do not hardcode secrets.

## Output format
After changes, summarize:
1. Files changed
2. Why they changed
3. How to verify

针对 React / Next.js 的补充规则

## React / Next.js rules
- Prefer server components unless client interactivity is required.
- Add "use client" only when necessary.
- Keep components focused and composable.
- Avoid unnecessary global state.
- Use semantic HTML for content pages.
- Do not fetch the same data in multiple places if it can be passed down.

针对内容站的补充规则

## Content site rules
- Do not generate low-value SEO pages.
- Prefer fewer, deeper articles over many shallow pages.
- Each article should have a clear search intent and target reader.
- Add internal links where relevant.
- Preserve sitemap, RSS, robots.txt, and canonical behavior.

常见错误

错误 1：规则太抽象

比如：

Write clean code.

这句话几乎没有约束力。更好的写法是：

Keep functions under 80 lines when practical. If a function grows too large, suggest a refactor before editing.

错误 2：规则太多

规则不是越多越好。太长的规则会让重点变模糊。建议先写 30-80 行，后续根据项目问题迭代。

错误 3：没有禁止事项

AI 很容易为了完成任务引入新依赖、重写目录结构、删除旧逻辑。规则里一定要写清楚哪些事情不能做。

错误 4：不要求验证方式

每次修改后都应该说明如何验证，例如：

Run npm test
Run npm run build
Open /posts/example/ and check SEO meta

我的推荐写法

如果你是独立开发者，Cursor Rules 先不要追求完美。第一版只需要解决三个问题：

  • 不要乱引入依赖
  • 不要大规模重写
  • 修改后告诉我怎么验证

随着项目变复杂，再逐步加入测试、目录、样式、SEO 和安全规则。

总结

Cursor Rules 的价值不是让 AI “更聪明”，而是让 AI 更稳定地遵守你的项目边界。写规则时要具体、可执行、可验证，少写口号，多写约束。

对于前端项目，最推荐先从技术栈、禁止事项、SEO 要求和验证方式开始。这样能明显减少 AI 生成代码时的不可控行为。

一个真实使用场景

假设你正在维护一个内容站，希望 Cursor 帮你修改文章页样式。没有规则时，它可能会顺手引入新的 UI 库、改动构建脚本，甚至重写页面结构。加上规则后，你可以明确要求：只修改 CSS 和文章模板，不改变数据结构，不新增依赖。

这类规则能节省很多返工时间。一次错误的大改可能需要 30 分钟回滚和检查，而一份清楚的规则只需要几分钟维护。

维护成本估算

项目阶段Rules 维护方式预计耗时
刚开始写 30 行基础规则10-15 分钟
有固定技术栈增加目录和组件约定20-30 分钟
多人协作加入测试、Review、禁止事项30-60 分钟
长期项目每月根据踩坑更新10 分钟/月

如果你每周都会用 Cursor 改代码，这个投入通常是值得的。它不能保证 AI 不犯错，但能减少重复解释项目背景的成本。

建议放在哪里

不同版本的 Cursor 对规则文件支持方式可能变化，具体以官方文档和当前产品界面为准。实践上，你至少应该把规则保存在项目仓库里，例如：

.cursor/rules
.cursor/rules/project.md

如果你的团队暂时不使用专门规则文件，也可以把核心规则放进项目的 AI 协作说明文档里，确保每次让 AI 修改代码前都能引用。

顶部