说实话，我第一次用Cursor的时候，内心是有点失落的。网上到处都说它多智能、多能提效，结果我装好后，Tab补全倒是挺快，可生成的东西跟我手写习惯差得太远，Agent改代码也经常南辕北辙。直到我把一套规则写进配置之后，体验才真正不一样，最直观的结果就是：要改的代码量少了一大半。这篇就是想把我调教Cursor的配置思路和规则模板全部摊开讲，包括怎么配、为什么这么配、配了之后踩过哪些坑，以及不同项目怎么定制自己的规则，让刚上手的朋友能直接照着抄，少走我走过的弯路。
1. 为什么同一个Cursor，别人用起来像两个人
很多人觉得Cursor“开箱即用”，装上就能变快。这句话只对了一半。默认状态下的Cursor更像一个聪明但没有团队规范的新人，它懂很多框架和技术，但对你这个项目的目录结构、命名习惯、设计取舍一无所知。它给出的补全和改动能跑，但往往不是你想要的写法，于是你花大量时间在“改回来”上面。这其实是绝大部分人觉得AI编程“没那么神”的真正原因：缺的不是模型能力，而是配置层的信息传递。
1.1 从“会用”到“会配置”的分水岭
怎么判断自己处在哪个阶段？很简单。如果你每次用Agent干活，都要先在对话里写一大段“这个项目用的React 18、风格是函数组件、不要用类组件、UI库是Antd、请求走src/api里的封装……”这就是还在“每次重新解释”的阶段。而配置好的人，只需要在规则文件里写一遍，之后无论开多少个新会话，AI都默认知道这些约束，不用你重复。
这一层差异，体感上非常明显。我后来帮几个同事也配置过，同一个项目，配置前AI改代码经常会把import路径换成自己的习惯，甚至在一个纯TS项目里生成带默认参数的对象和any类型；配置后这些情况基本消失。从这个角度说，配置规则不是“锦上添花”，而是决定Cursor能不能在具体项目里落地的关键动作。
1.2 规则的本质：一次说清楚，胜过每次扯嗓子喊
Cursor的规则，本质上是一段会在每次请求时被注入到模型上下文里的系统指令。你完全可以把规则理解成“永久的对话开场白”——每次它回答之前都会先读一遍你的要求。所以规则写得好不好，直接决定了模型是带着你的项目习惯在写代码，还是天马行空自己发挥。
这可以类比成团队里来了个新实习生。你要是每天早会口头叮嘱一遍“记得我们用了linter”“别在utils里放页面组件”，他大概率还是忘；但如果给他一本《团队开发手册》，写清楚技术栈、目录职责、命名规则、禁止事项，他干活时就会有章法。Cursor的规则就是这个手册，而且是放在代码仓库里、能被AI每次自动读取的手册。
1.3 先搞清楚规则从哪里来：加载顺序很重要
Cursor的规则实际有三层来源，理解它们的关系，你才不会写得乱七八糟：
- 全局规则（Global Rules）：对你所有项目生效，适合放通用要求，比如“始终用TypeScript”“变量命名用camelCase”。
- 项目级.cursorrules文件：放在项目根目录，只对该项目生效，放领域特定约定，比如“本项目的UI库是Antd，优先复用src/components里的组件”。
- .cursor/rules目录：Cursor新版本支持的按文件名和标签触发的规则，适合拆分维度，比如
frontend.mdc、backend.mdc，还能设置是否默认启用。
加载优先级上，我的经验是“具体覆盖通用、后加载覆盖先加载”。项目级规则能覆盖全局规则的矛盾项，.cursor/rules里按文件名触发的规则，在匹配情况下通常优先级更高。但别指望模型像程序一样严格按这个顺序执行，规则之间最好就不要写互相冲突的内容，冲突越少，AI犯迷糊的概率越低。
想清楚这个结构之后，接下来最有价值的操作就是：写一套“能少写一半代码”的规则模板。
2. 一套能“少写一半代码”的完整规则长什么样
下面这个模板是从我自己反复改过的版本里提炼出来的，适合大多数Web项目。你可以先直接抄，然后再按项目情况改。注意，这套规则不是越长越好，而是每一条都要有实际可执行的信息量。
# .cursorrules 你是本项目的资深工程师。项目采用以下技术栈： - 前端：React 18 + TypeScript + Vite - 状态管理：Zustand - UI库：Ant Design - 网络请求：统一使用 src/api 下的 axios 实例，禁止直接调用 fetch - 样式：CSS Modules，禁止使用全局 CSS 覆盖组件 ## 代码风格要求 1. 组件一律使用函数组件 + Hooks，禁止 class 组件 2. 优先复用 src/components 和 src/utils 下已有模块；看到相似功能的代码时，重构或复用而不是新写 3. 涉及表单提交、增删改查类功能，按照 src/modules/xxx 中的模式实现，保持 API 结构一致 4. 新增文件必须放入对应功能目录，禁止在 src 根目录堆文件 5. 所有通用配置项（如图表颜色、常量、状态枚举）集中放到 src/constants ## 响应要求 1. 直接给出完整代码，不要解释代码 2. 如果存在多方案，只选择最符合现有项目风格的方案 3. 改动时遵循最小改动原则，不要顺手重构无关代码 4. 结束答案前给出两行以内的变更说明（改了哪些文件、为什么）别急着复制，下面我把每一条背后的逻辑拆开，你理解之后才知道哪里该改。
2.1 明确技术栈和请求层约定
规则的前半段把技术栈说得清清楚楚，AI就不会每次都试探性地猜，更不会在一个用Rest API的项目里给你生成GraphQL。我个人觉得最有价值的一条是“统一使用src/api下的axios实例，禁止直接调用fetch”——这条能省掉很多隐患。没有这条规则的时候，AI经常会自己新建请求，甚至引入新的请求库，代码风格一下就乱了，你review的时候还得一个个改回封装函数。有规则之后，它每次会自动去找已有封装，生成的代码风格和团队规范天然一致。
2.2 强制复用，而不是重写
规则里专门要求“优先复用已有模块；看到相似功能的代码时，重构或复用而不是新写”。这条的核心是治AI的“失忆症”。模型没有项目全局记忆，它很容易为了一行日期格式化重新写个函数，哪怕项目里已经有三个相同功能的工具函数。加了这条规则之后，Agent下意识先扫项目结构，确认有没有现成函数可调用。
我开始写这条规则是因为一次惨痛经历：某个工具函数在utils/date.ts里已经封装得挺好了，AI却在另一个新组件里又生成了完全一样的格式化逻辑，还用了不同的参数命名。我后来补上了这条，类似情况一下就少了。能不能完全杜绝不敢保证，但出现频率大幅下降，这就足够值回票价了。
2.3 守规矩比创新重要：输出风格类规则
规则中“直接给出完整代码，不要解释代码”看起来有点暴力，但很实用。AI经常会在代码前后写五六行解释，告诉你它为什么这么实现、有什么好处。这些信息对学习可能有帮助，但对我这种只是想要一段可落地代码的人来说，全是噪声，还得一屏一屏往下滑。明确让它闭嘴之后，每次改动的信息密度高很多。
“最小改动原则”这条也值得单独说。如果不加限制，AI改一个函数时很可能会顺手把文件里其他代码的格式也改了，导致diff里塞满无关变更。这很糟心，因为你得从一堆无关改动里挑出真正重要的。我加了这个要求后，diff明显干净多了。
2.4 规则里千万别出现的内容
写了这么久规则，我也总结出几类纯属帮倒忙的内容：
- 空洞口号：比如“写出高质量代码”“保证代码可维护性”。这类话没有可执行的边界，模型听了等于没听，写不写没区别。
- 自相矛盾的约束：例如既说“禁止any”又说“遇到复杂类型可以使用any绕过”。模型会非常困惑，最后可能在不该用的地方用了any，该用的时候又不敢用。
- 过度细节的排版要求：比如要求“每个函数上方必须空一行”“注释必须用三斜杠”。这类规则太细碎，占上下文，又容易让AI在行文上过度紧张，反而影响主体功能的实现。
- 没写具体如何做的事：别只写“优化性能”，而是写“列表大于1000条时启用虚拟滚动”；别只写“注意错误处理”，而是写“所有请求失败时使用统一Toast提示并上报日志”。
规则的价值在于让AI少踩你的坑，而不是让它变成复读机。
3. 分场景定制：前端、后端、测试项目的侧重完全不同
通用模板在所有项目里都能用，但真正做到“少写一半代码”的话，每个项目还得有自己的定制。同一个规则文件，放进不同项目时，要调整的维度也完全不同。我拿三个最常写的场景举例。
3.1 前端项目：把样板代码交给AI
前端项目最耗时的往往是大量的页面样板、重复的CRUD表单、列表页逻辑。要让AI替你扛，规则里就要把样板模式固化下来。比如：
# 前端项目补充规则 - 列表页遵循 src/features/xxx/pages/ListPage.tsx 的现有模式 - 表单页必须包含校验逻辑，校验规则写在 src/utils/validators - 新建页面时同步生成路由配置和菜单配置 - 组件命名用 PascalCase，文件名与组件名一致 - 状态更新用 Zustand，不要给组件塞不必要的本地 state这套规则的核心思想是“把页面结构放到规则里，AI只需填充业务内容”。一旦它知道每个功能模块的页面结构是怎么组织的，生成出来的列表页和表单页跟团队手写风格就非常接近。我自己实测过，一个带搜索、分页、批量操作的列表页，配置前AI生成的代码有70%需要改；配置之后，基本能做到95%直接可用，剩下的5%只是一些特殊业务字段。所谓“少写一半代码”，其实是在“生成的代码几乎不用改”这个意义上达成的。
3.2 后端项目：约定优于配置，分层别乱
后端项目最大的问题是AI容易把所有逻辑都堆在一个文件里，service、dao、controller分不清。所以规则的重点要放在分层和命名上：
# 后端项目补充规则 - 项目结构必须遵循 controller -> service -> mapper 三层 - 错误处理统一使用全局异常拦截器，禁止在 controller 里 try-catch - 数据库操作通过 mapper 接口，不在 service 里直接写 SQL - 新增接口时同步补齐参数校验和Swagger注解 - 业务常量禁止散落各处，集中放入 constants 包这条规则生效后，AI新建接口的流程就会变得非常稳定：controller只做参数接收和路由映射，service写核心业务，mapper只管数据访问。代码一旦分清楚了，后续人review起来快很多。我最开始没写这条规则的时候，AI在一个controller里一口气写了三百行代码，又是校验又是事务又是数据查询，看着就头疼。后来把分层规则写死，再没出现过这种“大杂烩”文件。
另外，后端项目规则里一定要注明“遵循现有项目包结构”。比如已有monorepo结构，AI容易把新模块放进不对应的包里，必须由规则强制纠正。这一点你写规则时会发现，比想象中更管用。
3.3 测试项目：让AI按你的框架自动补齐测试
很多人没意识到，测试代码是最适合交给AI写的。因为单测结构高度重复：given、when、then，难以发挥什么创造性。规则只要定好测试框架、目录结构、命令约定，AI就能自动补齐。
# 测试项目补充规则 - 测试统一使用 Vitest，不使用 Jest - 新文件放在与源码相同路径的 __tests__ 目录 - mock 外部请求统一使用 vi.mock，不发起真实网络请求 - 测试用例命名格式：'should 行为描述 when 条件' - 每个工具函数至少覆盖正常情况和异常情况两个用例 - 不要在测试里写 sleep 等待逻辑，使用 fake timers这个场景下，AI能省的时间非常可观。以前功能代码写完了，测试一天补不了多少；现在配合规则，一个模块的测试几分钟就能产出初稿，再交点给人review边界情况。尤其是有很多工具函数的项目，规则里的“应覆盖正常和异常情况”等于给了AI默认的行为准则，它补测试时会主动想边界条件，而不是只写happy path。
3.4 定制思路：把“团队约定”写进去，而不是把“原理”写进去
写场景规则时我有个核心判断标准：只写“这个项目已经确定的约定”，不写“通用的最佳实践”。比如“用Vitest”是约定，而“测试很重要”是废话；“统一走Service层”是约定，“注意代码架构”是空话。你平时团队会写在规范里的、code review时会提的那些点，都可以逐步沉淀进规则。这也是为什么同一个模板放进不同项目时一定要改：每个团队各自的习惯不一样，规则也必然长得不一样。
4. 配置之外的几个关键开关：模型、上下文与操作习惯
规则文件只是Cursor配置里的一个重要部分。真正用起来，还有几个设置和习惯会直接影响效果。我单独拎出来说，是因为这几个点配置对了，规则才能发挥最大威力。
4.1 模型选择：同一份规则，不同模型反馈差异很大
Cursor支持切换底层模型。我自己的感受是，不同模型对规则的理解和执行力度确实不一样。比如Claude系列的模型在理解长上下文的规则约束上更稳，生成的代码整体更贴规则；GPT系列的模型在某些扩展场景里反应更快，但对“不要解释直接给代码”这类指令的执行一致性稍弱。
所以我的建议有两层：
- 代码生成/修改场景，优先选Claude系列的模型，它跟规则文件的配合度更高；
- 如果当前会话感觉AI明显不听话，先别急着改规则，切换一下模型往往能好转。
模型和规则是会“化学反应”的。同样一份规则，某个模型执行得不错，另一个模型可能无视其中几条。这也提醒我们，写完规则后要多换模型实测，找最适合自己项目的那一个。
4.2 项目上下文：让规则在新会话里“自动生效”
好的规则还需要配合正确的项目上下文。Cursor里模型能否看到项目文件，取决于你的设置和项目结构。我喜欢在规则里指定“涉及功能开发时，先读取src/features/xxx目录结构”，但前提是这个目录在上下文窗口里能读得到。所以我一般不开那种没有限制的完全体模式，避免AI把所有项目文件都读一遍，那样既浪费token，也容易让它被无关代码带偏。
另外推荐维护一个.cursorignore文件，作用跟.gitignore类似，把node_modules、dist、build等生成目录排除掉。这能让AI在搜索代码时更聚焦，不被几千个文件干扰。
4.3 Agent模式下的实用操作习惯
配置完规则后，要在日常工作流里真正用起来，我习惯了这样一套动作：
- 在Chat里用一句话说清楚目标，比如“在用户管理页新增批量导入功能”；
- 让Agent先在项目里搜索相关结构，按规则产出改动方案；
- 在diff里仔细review，重点是看它有没有偏离规则；
- 用Ctrl+Enter接受改动。如果AI跑偏了，Ctrl+Z回退，再补一句约束让它在当前会话里修正。
这里有个很多人忽略的细节：你把规则写进.cursorrules之后，新会话会默认加载，但当前已经打开的会话如果是在写规则之前启动的，它可能还停留在旧上下文里。所以改完规则后，最好开一个新会话再继续干活，不然你会误以为规则没生效。
5. 我踩过的坑：规则没生效、规则膨胀、规则打架
好用的配置都是踩坑踩出来的。我下面分享三个最常见的问题，以及完整的排查链路。如果你感觉规则写了没用，大概率是下面这些原因之一。
5.1 规则没生效：先按这三步排查
有一次我在项目根目录新建了.cursorrules，然后继续用刚才开的会话要求AI改代码，结果它完全无视新规则。我第一反应是文件没放对，后来又排查了目录层级、大小写、甚至重装了插件，最后才发现是会话没刷新。
这背后的完整排查顺序应该是：
- 确认文件位置：
.cursorrules必须在项目根目录，不能放在子目录里，否则不会被自动加载； - 确认会话状态：修改规则后，一定要重新打开一个会话，让上下文重新加载规则文件；
- 确认文件内容：如果规则文件本身有语法错误或Markdown结构异常，Cursor有时会静默忽略。所以写完规则后，先随便提个小需求，看AI是否遵守，而不是等改大功能时才发现问题。
还有一次我发现规则没生效，是因为把规则写在了.cursor/rules/frontend.mdc里，但文件名的触发标签跟我实际项目路径对应不上。这个规则没有匹配到当前文件，自然就不生效。新版规则的标签触发功能很灵活，但也很容易因为路径规则写错导致不匹配。排查这类问题时，我会直接看规则文件右上角是否有生效提示，没有就说明匹配条件有问题。
5.2 规则膨胀：越写越多，AI反而变笨
规则不是越多越好。有一段时间我太贪心，全局规则里塞了将近两千字，技术栈七八条、代码风格十几条、响应格式五六条、还有各种禁止项。结果就是AI开始变得极度保守，改动特别小，甚至经常回复“要按照规则理解，当前改动风险较高”之类的废话；而且因为每条请求都背着这坨规则，响应速度明显变慢，token也烧得凶。
后来我把规则砍到只剩最核心的十几条，把更多项目相关的细节移到了项目级规则里，全局规则只留“通用且必须”的部分。AI的执行质量反而回升了。这件事给我一个很重要的教训：规则不是法律条文，不需要面面俱到，只需要覆盖“最容易让AI犯错”的几条。规则的核心是“高信号”，而不是“多信息”。
另外，我还给规则做了一个“年度大扫除”：每隔几周看一眼，把已经过时的、AI自动遵守的、或者没起作用的规则删掉。规则一旦堆积，维护成本也在增加。你如果长期不清理，最终会得到一个让模型无所适从的巨型提示词。
5.3 规则打架：全局规则和项目规则起冲突
我在多个项目上遇到过“冲突”：全局规则里明确写了“禁止使用any”，但某个老项目里到处是any和遗留的JS文件，项目级规则里写了“兼容旧文件时允许局部any”。结果AI在处理旧文件时非常迟疑，有时候用了any，有时候又为了避开any做出一大堆不该有的类型断言。
这类问题的解法，我总结了两条：
- 全局规则只写“铁律”，就是任何项目、任何时间都不能违反的；
- 项目级规则明确声明“本项目特殊约定，若与全局冲突，以本规则为准”。
实际上，模型处理冲突的能力有限，与其让它去判断优先级，不如从源头上减少对抗性规则。你可以把全局规则里和项目实际情况不符的部分，在项目规则里先做“豁免声明”。一个实用的写法是：“在本项目内，全局规则关于TS类型严格度的要求放宽一级，允许在旧文件兼容层使用any，但新文件仍遵循严格模式。”先承认场景差异，AI反而执行得更明确。
6. 真正省时间的秘诀：把“说”变成“规则”
现在回头看，我配置Cursor最核心的心得就一句话：你越能把话一次性说清楚，AI就越不需要你第二次重复。很多人在对话框里花大量时间描述需求、澄清上下文、纠正错误，但如果把这些高频出现的内容提炼成规则文件，Cursor就从“你需要反复指挥的工具”变成了“熟悉你习惯的协作者”——后者省下的时间，一天可能只是半小时，一个月累计下来非常可观。
6.1 如果你只打算做一件事：先沉淀一周的“口头禅”
我不知道你第一次写规则时会不会迷茫。我的建议是：先不要看网上的各种模板，把你这一周内在code review或调试时最容易说的话记录下来。比如“这个函数应该复用utils里的封装”“新组件必须走路由配置”“不要把请求直接写在组件里”——这些话就是你的团队约定，也是最值得写进规则的素材。
把口头禅变成规则之后，你会明显发现AI不再重复犯同类型的错误。等它逐渐不再犯错，你再继续添加新的约束，让规则和项目一起“进化”。这种迭代式写规则的方式，比一次性憋一个完美模板要现实得多，也有效得多。
6.2 我最后的体会
有人会觉得“配置规则很麻烦，不如我手动改代码快”。我的真实感受是：短期确实多花了一点时间，但长期看，这些规则是复利资产。你给AI一条规则，它接下来几十次会话都在替你执行；你少做一次返工，就多赚回一点时间。更重要的是，规则沉淀的是你对项目的理解和团队的约定，换一个人来接手项目，看规则文件也能快速明白整个项目的套路，价值远超代码本身。
所以，如果你现在还在跟默认配置的Cursor“搏斗”，我建议你今天花二十分钟，写一个属于自己的.cursorrules，然后开个新会话试一次。大概率你会跟我第一次写完规则时一样：有点后悔，后悔没早做这件事。
)
