说实话我第一次用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重点是看它有没有偏离规则用CtrlEnter接受改动。如果AI跑偏了CtrlZ回退再补一句约束让它在当前会话里修正。这里有个很多人忽略的细节你把规则写进.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然后开个新会话试一次。大概率你会跟我第一次写完规则时一样有点后悔后悔没早做这件事。
说实话我第一次用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重点是看它有没有偏离规则用CtrlEnter接受改动。如果AI跑偏了CtrlZ回退再补一句约束让它在当前会话里修正。这里有个很多人忽略的细节你把规则写进.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然后开个新会话试一次。大概率你会跟我第一次写完规则时一样有点后悔后悔没早做这件事。
