很多人第一次用Cursor头两天会觉得这玩意儿简直通人性写个需求它就哗哗给你把代码铺出来。但用一周左右很多人会开始骂骂咧咧AI写的代码跟我的项目风格完全不搭要么乱引库要么注释风格跟屎一样要么生成一堆用不上的封装改来改去比自己写还累。问题出在哪儿大概率不是Cursor不行而是你没给它立规矩。我用了很长一段时间中间反复调教最后把一套规则文件沉淀下来配合Tab补全和Agent模式写业务代码的效率差不多翻了一倍好多重复性的样板代码根本不用手敲。这篇就聊聊我是怎么配置Cursor的以及这些规则为什么能省掉一大半工作量。1. 为什么别人的Cursor比你的好用先搞清楚规则到底是什么1.1 默认配置下的“AI糊涂蛋”现象先问你一个问题你装好Cursor之后第一件事是干嘛大概率是打开一个项目然后直接在对话框里说“帮我写一个用户列表页面”。Cursor确实能写但它是在对你一无所知的情况下硬写的。它不知道你用的是React还是Vue不知道你是用TypeScript还是JavaScript不知道你项目里有没有封装好的请求库不知道你变量命名是camelCase还是snake_case更不知道你们团队习惯把组件放哪个目录。于是它只能按照“绝大多数项目的样子”来猜猜出来的东西放在通用场景下没错放到你的项目里就是一堆需要返工的垃圾代码。我刚开始用的时候就是这种状态每次让它生成一个模块拿过来一看好嘛又给我造了一个新的axios实例组件文件可能超过两百行接口地址直接写死在代码里。我删掉重写的时间比自己写还长那段时间我差点把Cursor卸载了。后来我才意识到问题不在AI在于我把它当成了一个无所不知的全能助手却没给它任何“你的项目上下文”。1.2 Cursor的三级规则体系后来我去翻官方的文档和社区的教程发现Cursor其实提供了一整套规则机制可以让AI在生成代码之前先“读一遍”你的偏好。这套机制我把它分成三级第一级是全局规则。你在设置里配置的Rules任何时候、任何项目都会生效。适合放一些通用的、跨项目都成立的约束比如“代码注释用中文”“不使用console.log调试”“不生成示例类的伪代码”。这一层管得宽但管得浅对特定项目来说没什么针对性。第二级是项目级规则。在项目根目录放一个.cursorrules文件Cursor在对话时会自动读取这个文件里的内容并把它作为隐式的上下文。这一层是核心因为每个项目的技术栈、目录结构、编码规范都不一样只有项目级规则才能真正贴合代码库。我很多项目都有自己的.cursorrules里面写了这个项目特有的约束AI的表现在不同项目里完全是两个档次。第三级是你手动指定的文件或规则。在会话里通过符号引用指定文件告诉AI“你现在重点看这几个文件”或者直接在对话里补充一句额外的要求。这一层是动态的适合临时任务。三级配合用的逻辑是全局规则堵住通用问题项目规则解决特定项目的痛点手动引用处理临时的上下文。很多人只配了全局规则或者干脆一个都没配那自然感受不到Cursor的神奇之处。1.3 规则文件从哪里加载既然项目级规则这么重要那就得说一下它的加载逻辑。Cursor会在开发环境启动时读取当前工作区根目录下的.cursorrules文件如果你是DevChat或者Agent模式它在处理任务之前就会把这份规则作为系统提示词的一部分送进模型。这一点非常关键它不是等你开口问才生效的而是在整个对话窗口里始终存在。规则在这里的作用等于给模型设定了一个“人设”它会在生成每一个回答、每段代码之前先考虑你的约束条件。话说回来.cursorrules文件本质上就是个纯文本的规则描述用什么语言写都行我习惯用中文写约束、用英文写代码相关的名词这样Cursor在解析的时候能更准确地理解技术栈相关术语。规则写清楚、写具体模型才能给出贴合项目的结果我后面会给出完整模板。2. 建规则前必做的三件事技术栈、代码习惯、输出约束2.1 先定义技术栈和依赖别让AI“自由发挥”我见过不少人写的规则上来就是“你是一个资深程序员请写出高质量的代码”。这种话说了等于没说模型当然知道自己是个资深程序员——它的训练数据里塞满了优质代码问题是它不知道你的项目属于哪一卦。所以在规则里第一要务就是把你项目的技术栈交代清楚。拿我手头一个后台管理项目来说我会明确告诉Cursor前端是Vue3 TypeScript ViteUI库用的是Element Plus样式方案是SCSS且用BEM命名规范状态管理是Pinia不用Vuex接口请求必须走项目里封装好的src/utils/request.ts不允许直接引axios实例。后端是Node.js NestJS数据库用MySQL所有数据库操作必须走Prisma。这些信息写进去之后Cursor生成的代码一下子就有“内味儿”了。比如让它写一个用户列表页它自动就会从/api/system/user导入接口用ElTable渲染数据分页组件也用的是项目里二次封装的Pagination。在后面几乎不用改什么放到项目里直接能跑。有人可能会觉得这些信息我每次对话里手动说一下不就行了吗是可以但你要想清楚每次新开会话都得重新说一遍稍微漏说一个条件AI就开始飘。规则文件的好处是它把一切固化了你以后一个回车它就已经站在正确轨道上了。2.2 用项目代码习惯约束AI的命名和结构技术栈之外还有一个经常被忽略的东西代码风格。不同团队、不同项目的代码风格差异太大了不约束的话AI会按它训练数据里的“最大公约数”来写。我在规则里会写清楚命名规范组件文件名用PascalCase页面路由组件也统一PascalCase普通工具函数用camelCase常量用全大写下划线CSS类名用BEM。注释风格也要规定中文注释且每个函数都要有JSDoc注释说明参数和返回值。再比如说组件内部逻辑要遵循“组合式API优先不要在setup里写大量面条式代码复杂逻辑抽到独立useXxx函数里”。这些约束看着琐碎实际上每条都能让AI的输出质量上一个台阶。因为大模型是“看菜下饭”的你给了越具体的框架它越容易在这个框架里产出符合预期的东西。反之你只给一句“代码要好维护”它根本不知道对你而言什么叫好维护。这里有个小技巧不要只写“禁止什么”还要写“偏好什么”。比如写“不要用any”的时候同时写“遇到不确定的类型时优先使用类型收窄或定义interface”。AI对“不要”的理解往往不如“要”来得直接把禁止转换成更优的做法效果立竿见影。2.3 输出约束告诉AI“什么不要做”比“做什么”更重要技术栈和风格说完了第三块是“行为边界”。就是明确告诉AI什么情况下别自作主张什么情况下要先问。我在规则里的行为边界大概长这样不要生成没有任何调用方的工具函数如果发现重复代码先检查项目已有工具函数能复用就复用。不要擅自添加新的依赖如果确实需要第三方库先说明理由并等待确认。不要“假装实现”业务逻辑如果某个接口、某段逻辑需要调用后端但你现在不知道接口返回结构先写一个明确的TODO注释不要编造字段。不要修改与当前任务无关的代码哪怕是顺手能优化也别动保持diff最小化。遇到不确定的需求细节先列出问题清单而不是直接按最可能的方向瞎做。这些边界非常有用尤其是“不要编造接口字段”这一条。插件做多了你就知道AI特别喜欢自己编一个res.data.userInfo.name之类的变量名出来当你改成真实接口时一大片代码都要跟着调。有了这条规则之后它会先停下来问你“这个接口的字段结构是什么”这才是真正靠谱的搭档。3. 直接可抄的规则模板前端、Python后端、全栈通用3.1 一套通用基础规则模板技术栈、习惯、边界这三块讲清楚了下面直接给模板。这是我自己用的一套通用版本任何项目拿过来微调一下就能用我平时新开项目第一件事就是把它复制进去。你是一名资深软件工程师请严格遵循以下规则完成任务。 ## 代码风格 - 代码必须与当前项目的主流风格保持一致先查看项目中已有文件的写法再动手。 - 命名规范组件、类名使用 PascalCase函数、变量使用 camelCase常量使用 UPPER_SNAKE_CASE。 - 所有代码需要引导性注释解释“为什么这么做”而不是解释“代码做了什么”。 - 注释统一使用中文代码里的标识符一律使用英文。 ## 质量红线 - 只输出可运行、可交付的代码禁止输出示例性质的伪代码。 - 不新增依赖。如必须新增先说明用途、体积、替代方案等待确认后再实施。 - 不编辑与当前任务无关的文件保持变更范围最小化。 - 不编造不存在的接口字段、配置项或API遇到信息缺失先提问。 ## 任务处理 - 动手前先阅读相关文件理解数据流和模块边界。 - 涉及多处调用关系时先列出改动影响面再开始编码。 - 如果任务描述模糊先提出2-3个关键问题而不是直接开写。 - 实现完成后说明你改了哪些文件、每个变更的用途、以及测试验证方法。这个模板覆盖了行为、风格、任务边界三个维度基本能Hold住大部分项目。你看里面几乎没有某个具体框架的痕迹所以换项目它都能用这也是放在全局规则里的首选。3.2 前端项目规则示例如果项目是React TypeScript我会在项目根目录单独加一份补充规则或者直接把全局规则里没覆盖到的细节塞进.cursorrules里。# 项目技术栈 - 框架React 18 TypeScript Vite - 路由React Router v6 - 状态管理Zustand禁止使用Redux - UI库Ant Design 5避免引入其他UI组件库 - 样式CSS Modules禁止使用内联style动态变量除外 - 请求统一使用 src/api/request.ts 中的封装 # 组件开发规范 - 函数组件为主禁止使用class组件。 - Props类型必须使用interface定义导出供复用。 - 组件拆分粒度要合理超过200行必须考虑拆分。 - 列表渲染的key不能用index必须用业务唯一ID。 - 状态提升优先共用状态抽到最近公共父组件或用Zustand。 # 接口对接 - 所有API调用必须在 src/api 目录下建独立模块禁止在组件里直接写请求逻辑。 - 接口函数返回类型需要明确定义禁止返回 any。 - loading、error状态必须在调用处处理不要抛到全局。这套规则下AI生成的代码几乎可以无缝嵌进现有项目。我印象特别深的是有一次我需要做一组批量操作按钮让Cursor在表格上方生成一个工具栏它自动判断了操作按钮禁用条件还用useState管理选中行整个过程只手动微调了两三处样式这种体验跟之前那种“刷新后全是红线”完全两个世界。3.3 Python后端规则示例Python后端项目的侧重点又不一样。我自己的一个FastAPI项目里规则文件长这样# 项目语言与框架 - Python 3.11 FastAPI SQLAlchemy 2.0 - 数据库模型用Declarative Base不在业务逻辑中裸写SQL。 - Pydantic v2模型负责请求与响应校验禁止使用v1风格。 # 开发约束 - 类型标注必须完整函数入参、返回值、变量一律标注类型。 - 使用 async def 声明异步接口并在依赖中注入DB会话。 - 业务错误使用自定义异常全局异常处理器禁止在视图函数中 try-except 各种吞异常。 - 日志统一用 logging.getLogger(__name__)禁止print。 # 目录结构 - routers/ 放路由与参数定义services/ 放业务逻辑models/ 放ORM模型。 - 视图函数内不写业务逻辑只负责参数校验、调用service、返回结果。 - service层函数职责单一一个函数只做一件事。从实际效果看这套规则最大的价值在于让AI生成的代码天然贴合分层架构。之前我把需求丢给Cursor它会在路由里写一堆业务逻辑几十行代码糊在一个函数里。现在规则约束之后它生成的是“路由薄薄一层、service清晰分层、模型定义完整”的结构化代码代码评审的时候舒服太多了。3.4 规则文件怎么组织最不容易乱模板有了我再介绍下我的文件组织习惯。全局规则我放在Cursor Settings里的Rules框里长驻生效。项目规则我放.cursorrules每个项目一份。有人还会用.cursor/rules/目录来拆分多条规则文件但当下的版本里直接维护一个.cursorrules其实最省事。需要注意.cursorrules是跟着项目走的如果你们团队多人协作建议把它提交到Git仓库里。这样新同事拉下代码规则一起拉下来大家看到的AI行为是一致的这比口头传递技术债务强得多。我自己的做法是一个项目从初始化开始就建好规则文件技术栈升级或者团队规范变化时同步更新尽量让规则文件活起来。4. 让规则真正生效Tab补全、Agent模式与上下文管理4.1 为什么AI偶尔会“不听”规则——上下文窗口的真相规则文件写了但很多人会问为啥我配了规则它偶尔还是像失忆一样乱来问题往往出在上下文管理上。当前的模型都有上下文窗口限制Cursor免费版和不同套餐覆盖的模型不同可用的上下文长度也不太一样。对话篇幅一长早期喂给模型的规则和代码就被挤出了有效窗口AI自然会“变回原形”开始自由发挥。应对办法是让上下文尽量保持精简。你不需要把整个项目都塞给它每次任务只把相关的文件引用给它规则文件在项目里自动生效再加上本次任务的描述这个信息量是合适的。不要在一个会话里连续问十几个不相关的事情问完之后再回头看前面那些上下文反而挤占了规则的空间。从实际操作来说我习惯一个会话只处理一个模块。比如“把商品列表页做完”是一个会话“把订单详情页做完”开新会话。这样上下文干净AI不仅能记住规则还能记住前面几轮对话里的具体决策生成质量最稳定。4.2 用引用文件和指令让规则落地规则的另外一个大用途是配合引用。比如我在处理一个历史遗留代码时会让Cursor先读一遍对应的文件再结合规则说“基于这个文件的现有风格帮我新增一个XX功能”。它在规则约束下会先模仿旧代码的结构再按照新需求的逻辑去扩展生成的东西能维持整个项目风格的一致性这个体验在接手老项目时特别值钱。具体操作也很简单在对话框里输入选择要引用的文件或文件夹。我习惯至少把下面几个文件丢给它涉及修改的页面文件、对应的接口定义、路由配置文件、以及数据库模型文件如果有。这些文件是规则之外最宝贵的上下文AI有了真实的数据结构就不会再瞎猜字段名。4.3 Agent模式下的长任务处理技巧如果你的任务比较复杂比如“实现用户权限管理模块包括角色管理、菜单配置、接口权限”建议直接用Agent模式而不是普通对话。Agent模式会自己规划步骤、读文件、改代码、跑命令一步步推进。我在Agent模式下会额外给它几条指令先列出你理解的模块边界和涉及文件清单再分步骤实施每一步完成后自查一次是否符合规则涉及数据库变更时先整理字段列表和初始数据。这样它不会一头扎下去闷头大改。这里再分享一个我的独门提效思路对于重复性的增删改查页面我会在规则里直接把“标准页面生成协议”写进去比如列表页必须包括哪些列、搜索区需要哪几个筛选项、新增和编辑是否共用一个弹窗、删除是否需要二次确认。以后每次提一句“帮我写一个XX管理页面”Cursor就会照这个协议把页面完整生成出来我不需要每次重复讲页面细节。这才是“少写一半代码”的真正来源。5. 常见问题与避坑实录5.1 规则写得越多越好吗别把规则变成裹脚布规则确实重要但千万别走向另一个极端——把.cursorrules写成一部长篇小说。规则太长有两个问题一是上下文窗口被规则占掉一大块留给真实代码的空间变小二是规则之间容易冲突AI反而不知道该听哪条。我见过有人把规则写成上千行从设计模式到部署流程全塞进去结果生成的代码畏手畏脚动不动就停下来问“是否需要先确认”。怎么算合适我建议项目规则控制在150行以内全局规则控制在80行以内。规则只写“当前项目中反复出现且影响巨大的问题”那些一年碰不上一回的边缘约束就不用写了。规则文件应该像牛肉高汤浓缩但精华而不是一大盆白开水。5.2 规则之间冲突了优先级怎么定规则写多了冲突是难免的。比如全局规则说“代码注释用中文”但某个项目里团队规定英文注释。我遇到过几次这种情况AI的应对方式是偶尔中文偶尔英文飘忽不定。解决办法很简单项目规则优先于全局规则。我在项目规则里会用一句明确的话开头“本文件规则覆盖全局规则中的同名约束。”这句话能有效让模型把注意力转移到项目级规则上。如果项目内部还想再细分比如某个目录下的代码风格不同就在当前任务中用对话补充说明这比继续堆规则更灵活。5.3 规则文件明明写好了但好像完全没生效每次有朋友来问我“为什么我的规则没生效”我最先问的都是同一个问题你重新打开会话了吗.cursorrules文件在会话建立时读取如果你改了规则文件但还在旧会话里继续聊AI用的是旧规则。改完规则直接开新会话或者至少用新建对话的方式测试一次。另外也要检查一下规则文件放的位置。.cursorrules要在项目根目录Cursor才会自动读到。如果你不小心放到了子目录它找不到自然不会生效。还有一个容易踩的坑规则里使用了文件路径但当前会话的引用方式是绝对路径还是相对路径没写清楚。我一般会在规则里统一用相对路径以项目根目录为基准这样不管在谁的电脑上拉下来都能用。5.4 从“能用”到“好用”规则需要持续迭代最后聊聊规则迭代这件事。我自己的规则不是一开始就完美的甚至踩过很多坑最早那版规则写得特别空泛比如“要写出高质量的代码”“要遵循最佳实践”效果跟没写差不多。后来我养成了一个习惯每遇到一次AI犯了同样的错误就把它改成一条新规则。举个例子我做支付模块的时候Cursor连续两次把金额类型生成了number而我们项目的金额一律用string存储避免浮点精度问题。第一次我手动改了第二次我又自己改了第三次我实在忍不住了就在规则里加了一条“金额字段类型必须为string禁止使用number涉及金额计算时统一使用decimal库。”从那以后支付模块相关代码再也没犯过这个错。规则就是这么一点一滴堆出来的它不是一份写完就能一劳永逸的文档更像你给AI做的一套“成长笔记”每次踩坑就补一条慢慢它就从一个通用AI进化成“熟悉我这个项目的老开发”。我个人在实际操作中最深的体会是Cursor的规则体系值得你花一个下午好好打磨这个投入的回报极其可观。如果你现在还在忍受AI乱写代码的折磨真心建议你把.cursorrules当成项目的一等公民对待从今天开始第一条规则开始不断迭代。坚持一两个月你再看自己的开发速度一定会感谢当初认真配规则的那个自己。