很多人用 Cursor 的第一周，会觉得它很聪明；用到真实项目里，问题就开始出现：命名风格不统一、目录边界被打乱、测试命令猜错、组件写法和团队习惯不一致。原因通常不是模型不行，而是你把“项目规则”都放在聊天框里临时补充，AI 每次只记住一小段。
Cursor Rules 要解决的就是这个问题：把项目里的长期约定写成可复用规则，让 AI 在读代码、改代码、生成测试时自动参考。它不适合写成一本公司制度，更适合写成一组短、准、可执行的项目说明。本文重点讲 Project Rules 的落地写法，适合已经看过 AI编程工具专题、正在比较 Cursor、Claude Code、Codex 的开发者继续往下做。
Cursor Rules适合解决什么问题
先把边界说清楚。Cursor Rules 不是提示词收藏夹，也不是让 AI 永远听话的魔法开关。它更像项目里的“工程约束说明”，适合放这些内容：
- 项目技术栈：例如 React、Next.js、Vue、Node、Python、WordPress 主题开发等。
- 目录边界：哪些目录可以改，哪些目录只读，公共组件放在哪里。
- 代码风格：命名、错误处理、状态管理、样式方案、接口封装方式。
- 验证命令：改完代码后优先跑哪些 lint、test、typecheck 或构建命令。
- 禁区提醒：不要直接改生产配置、不要硬编码密钥、不要绕过权限检查。
如果你只是临时让 AI 写一个小脚本，Rules 的收益不明显；如果你在一个项目里反复改功能、修 bug、写测试，它的价值会很快体现出来。站内这篇 2026年AI编程工具推荐：Cursor、Claude Code、Codex、Windsurf怎么选 讲的是工具选择，本文则把焦点放到 Cursor 进入真实项目后的规范落地。
推荐的规则分层：别把所有内容写进一个文件
很多新手会把所有说明都塞进一个长规则文件，最后 AI 读到一半就抓不住重点。更稳的做法是按场景拆分：
- 项目总规则：说明项目定位、主要技术栈、绝对不能做的事。
- 前端规则：组件、样式、状态管理、页面结构、可访问性要求。
- 后端规则：API、数据库、鉴权、错误码、日志和安全边界。
- 测试规则：什么时候补单测，什么时候跑端到端测试，失败时怎么处理。
- 发布规则：构建、检查、提交信息、变更说明和回滚注意点。
这和 Claude Code 项目记忆怎么写？CLAUDE.md 实战模板与避坑清单 的思路相似：把长期规则写在项目内，让 AI 少猜、少问、少重复犯错。不同点是 Cursor 更强调 IDE 内的上下文触发，适合配合代码编辑和文件范围来使用。
一个可直接改的Cursor Rules模板
下面这个模板可以作为项目总规则的起点。不要照抄所有内容，先替换成你的项目真实情况，再根据最近三次 AI 改代码的问题继续补充。
---
description: 项目通用开发规则，适用于所有代码修改
alwaysApply: true
---
你正在维护一个中文内容站点/业务系统项目。
基本原则：
- 优先理解现有代码结构，再提出改动。
- 不要重写无关模块，不要顺手重构没有被要求的文件。
- 不要把密钥、Token、服务器密码写入代码、日志或文档。
- 新增依赖前先说明原因；能用现有工具完成时优先复用。
代码风格：
- 跟随当前文件已有风格，包括命名、缩进、错误处理和组件拆分方式。
- 公共逻辑只在出现真实重复时抽象，不为了“看起来高级”新增层级。
- 用户可见文案保持简洁、自然，避免模板腔。
验证要求：
- 修改前端交互后，优先运行 lint/build，并用浏览器检查关键页面。
- 修改共享函数、接口或数据结构后，补充或更新相关测试。
- 如果测试无法运行，必须说明原因和剩余风险。
这个模板的关键不是“写得长”，而是把 AI 最容易犯错的地方压住：不乱改、不泄密、不新增无意义抽象、改完要验证。对个人站长、小团队和独立开发者来说，这几个约束比一堆抽象价值观更有用。
前端项目可以加这一组规则
如果你主要用 Cursor 改前端，建议单独加一份前端规则。它能明显减少“页面能跑但体验很粗”的问题。
---
description: 前端页面和组件开发规则
globs:
- "src/**/*.{tsx,jsx,ts,js}"
- "app/**/*.{tsx,jsx,ts,js}"
---
前端实现要求：
- 优先复用现有组件、图标库、样式变量和布局模式。
- 不要创建只服务一次的复杂抽象；重复出现后再提取组件。
- 表单必须考虑加载、成功、失败、空状态和禁用状态。
- 文案不要解释“这个功能怎么用”，界面本身要清楚。
- 移动端不能出现按钮文字溢出、卡片重叠或横向滚动。
验证：
- 修改页面后检查桌面和移动端主要断点。
- 涉及数据提交时检查错误提示和重复提交保护。
如果你经常做工具站、后台、SaaS 页面，这部分尤其重要。AI 很容易生成漂亮但不耐用的界面：首屏看着热闹，真实用户一操作就发现状态缺失、按钮乱跳、移动端挤成一团。Rules 要写的就是这些“每次都该提醒”的硬标准。
后端和API规则要写得更保守
后端规则的目标不是让 AI 写得更多，而是让它少做危险动作。尤其是数据库迁移、鉴权、支付、用户数据、生产配置，规则要明确告诉 AI 先解释影响，再改动。
---
description: 后端接口、数据库和安全相关规则
globs:
- "server/**/*"
- "api/**/*"
- "src/**/*.ts"
---
后端安全要求：
- 不要绕过鉴权、权限校验或输入校验。
- 涉及数据库结构变更时，先说明迁移影响和回滚方式。
- 错误信息可以帮助排查，但不能暴露密钥、内部路径或用户隐私。
- 外部 API 调用必须考虑超时、重试、失败降级和成本控制。
- 日志只记录必要字段，避免写入完整请求体和敏感数据。
这类规则也适合和 Agent 工作流一起用。比如你用 Cursor 做开发，用 Claude Code 或 Codex 做更长链路的排查，可以参考 AI智能体与自动化专题 里的实践思路，把“先读、再改、最后验证”固定成流程。
Rules不要写成愿望清单
我见过最常见的错误，是把规则写成“代码要优雅、性能要好、体验要佳”。这些话对人也许有点用，对 AI 基本没有约束力。更好的写法是把抽象要求改成可执行动作：
- 不要写“性能要好”，要写“列表超过 100 条时不要一次性渲染全部复杂子组件”。
- 不要写“注意安全”，要写“不要把 API Key 写入前端代码或提交记录”。
- 不要写“保持风格一致”，要写“新增组件优先参考 src/components/ui 目录现有写法”。
- 不要写“测试充分”，要写“修改价格、权限、登录流程时必须补测试或说明无法补测的原因”。
Rules 的维护方式也要轻。每次 AI 犯了一个可复用的错，就补一条；如果一条规则三个月都没有被用到，就删掉或合并。规则越像真实项目的“事故复盘”，越能减少后续返工。
Cursor Rules和Claude Code记忆怎么搭配
如果你的工作流里同时有 Cursor、Claude Code、Codex，不需要给每个工具写完全不同的规则。可以把项目事实沉淀成一份核心规范，再按工具分发：
- Cursor Rules：更适合 IDE 内按文件、目录、任务类型触发。
- CLAUDE.md：更适合 Claude Code 在项目根目录长期读取和执行。
- AGENTS.md：更适合多 Agent、自动化任务、项目维护流程说明。
这也是我建议先写“短规则”的原因。你可以把同一套项目原则复用到不同 AI 编程工具里，而不是为每个工具维护一套庞大的说明书。想继续比较工具分工，可以看 Cursor、Windsurf还是Claude Code 这篇旧文，再结合自己的项目复杂度决定主力工具。
老达建议的落地顺序
如果你今天就想把 Cursor Rules 用起来，不要一上来追求完整体系。按这个顺序做就够了：
- 先写一份项目总规则，只放技术栈、禁区和验证命令。
- 用 Cursor 完成一次真实小改动，观察 AI 哪些地方仍然猜错。
- 把重复出现的问题补成前端、后端或测试规则。
- 每周清理一次规则，删除空话、重复话和过时命令。
- 团队协作时，把规则变更和代码变更一起审查。
Cursor Rules 的本质，是把你脑子里的项目经验变成 AI 能持续读取的上下文。它不会替你做工程判断，但能让 AI 少走弯路。对长期维护项目的人来说，这比多背几个提示词更实用。
