1. 为什么大多数人用Cursor只发挥了它三成实力我身边不少朋友都在用Cursor写代码但聊下来发现一个很有意思的现象大部分人把它当成能自动补全的VS Code在用装完插件、登录账号然后就开始写代码了。结果用了两周抱怨说也就那样补全还不如某某工具准。问题出在哪不是工具不行是配置没做对。Cursor真正的杀伤力不在于它内置的那个模型有多强而在于它能不能理解你的项目上下文、能不能按照你的编码习惯和团队规范来生成代码。这两件事靠默认配置是做不到的。默认状态下Cursor对你的项目一无所知它不知道你用的是React还是Vue不知道你的命名规范是驼峰还是下划线不知道你的API请求封装在哪个目录下。每次生成代码它都在猜。猜对了是运气猜错了你就得手动改改来改去反而比自己写还慢。这套配置体系的核心就是三个东西.cursorrules或者新版的项目规则目录、.cursorignore、以及编辑器层面的个性化设置。把这三样配好Cursor才能从一个通用代码生成器变成你的专属编程搭档。我自己配完之后最直观的感受是以前写一个CRUD接口要来回改三四次现在基本一次成型改动的量少了一半不止。这篇文章适合两类人看一是刚接触Cursor、还在摸索阶段的新手我会把每一步操作和背后的逻辑都讲清楚二是已经用了一段时间但觉得效果一般的开发者你可以对照检查一下自己的配置是不是漏了关键环节。全文基于我自己的实际使用经验结合常见的工程实践来展开不涉及任何特定平台的推广。2. 项目规则文件让Cursor真正读懂你的代码库2.1 .cursorrules与新版规则目录的区别和选择早期版本的Cursor只支持一个叫.cursorrules的文件放在项目根目录下里面写一段自然语言描述告诉Cursor这个项目是干什么的、用什么技术栈、有什么编码规范。这个方式简单直接但有个明显的短板所有规则挤在一个文件里项目一大就变得臃肿难维护而且不同模块可能需要不同的规则一个文件搞不定。后来Cursor引入了.cursor/rules/目录机制支持把规则拆成多个.mdc文件每个文件可以单独指定生效范围比如只对src/api/目录生效或者只对.tsx文件生效。这个改进非常关键因为它解决了规则冲突的问题。举个例子你的前端组件用PascalCase命名但工具函数用camelCase如果写在同一个规则文件里Cursor可能会混淆拆成两个.mdc文件各自指定globs匹配范围就不会打架了。那到底用哪个我的建议是新项目直接用.cursor/rules/目录机制老项目如果已经有.cursorrules且运行良好不必急着迁移但可以逐步把通用规则抽到新目录里。两者可以共存Cursor会同时读取。一个典型的.mdc文件结构长这样--- description: API层编码规范 globs: src/api/**/*.ts alwaysApply: false --- - 所有API请求必须通过 request.ts 中的封装函数发起 - 请求方法命名使用 动词资源名 格式如 getUserList、createOrder - 返回值统一使用 ApiResponseT 泛型包裹 - 错误处理统一在拦截器中完成业务层不重复try-catch头部那段YAML是元数据description说明这个规则的用途globs指定生效的文件范围alwaysApply控制是否全局强制应用。下面才是真正的规则内容。2.2 规则文件里到底该写什么四类高价值信息很多人写规则文件时不知道写什么要么写得太泛请写高质量的代码要么写得太细把整个架构文档贴进去。这两种都没用。根据我的经验规则文件里最值得写的是四类信息第一类技术栈和版本约束。明确告诉Cursor你用的是React 18还是19用的是Vue 3的组合式API还是选项式API状态管理用的是Zustand还是Redux Toolkit。这个信息直接影响它生成的代码风格。比如你说使用React 18 TypeScript 5 Zustand它就不会给你生成useState满天飞的代码。第二类目录结构和模块职责。简单描述一下项目的目录组织方式比如src/components/放通用组件、src/pages/放页面、src/hooks/放自定义Hook、src/utils/放工具函数。这样Cursor在生成新文件时会知道该往哪个目录放import路径也不会写错。第三类编码规范和命名约定。包括变量命名风格、文件命名规则、组件导出方式默认导出还是具名导出、注释语言中文还是英文。这些细节看起来琐碎但恰恰是影响代码一致性的关键。第四类常用工具函数和封装。告诉Cursor你项目里已经有哪些封装好的工具比如request.ts封装了axios、storage.ts封装了localStorage、formatDate在utils/date.ts里。这样它生成代码时会直接调用这些现成的函数而不是重新造轮子。注意规则文件不是越长越好。我见过有人写了三千多字的规则结果Cursor反而抓不住重点。建议单个.mdc文件控制在200-500字把最重要的约束放在前面。2.3 规则生效范围的精细控制globs匹配实战globs字段是.mdc规则文件里最实用的功能之一它决定了这条规则对哪些文件生效。写对了规则精准命中写错了要么不生效要么到处乱套。常见的匹配模式有这么几种匹配模式含义典型场景**/*.ts所有TypeScript文件通用TS规范src/api/**/*api目录下所有文件API层规范src/components/**/*.tsx组件目录下的TSX文件组件开发规范*.test.ts根目录下的测试文件测试规范!src/legacy/**排除legacy目录老代码不适用新规范我自己的项目里通常会建这么几个规则文件一个全局的general.mdcalwaysApply: true管技术栈和通用规范一个api.mdc管接口层一个component.mdc管组件层一个style.mdc管样式相关。这样分工明确维护起来也方便。有个容易踩的坑globs的路径是相对于项目根目录的不是相对于.cursor/rules/目录。我一开始就搞混了写了个./src/**结果一直不生效排查了半天才发现问题。2.4 从零写一份能用的规则文件完整示例光说理论没意思直接上一份我在实际项目中用的规则文件你可以根据自己的情况改。全局规则general.mdc--- description: 项目全局规范 alwaysApply: true --- ## 技术栈 - 框架React 18 TypeScript 5 - 构建Vite 5 - 状态管理Zustand - 路由React Router v6 - UI库Ant Design 5 - 请求axios已封装在 src/utils/request.ts ## 目录约定 - 页面组件src/pages/每个页面一个目录 - 通用组件src/components/按功能分子目录 - 自定义Hooksrc/hooks/ - 工具函数src/utils/ - 类型定义src/types/ ## 编码规范 - 组件使用函数式写法具名导出 - 变量和函数用camelCase组件和类型用PascalCase - 常量用UPPER_SNAKE_CASE - 注释用中文关键逻辑必须写注释 - 禁止使用any不确定的类型用unknownAPI层规则api.mdc--- description: API层编码规范 globs: src/api/**/*.ts alwaysApply: false --- - 所有请求通过 src/utils/request.ts 的 request 函数发起 - 每个模块的API单独一个文件如 user.ts、order.ts - 函数命名格式动词 资源名如 getUserList、updateOrderStatus - 返回值类型统一用 ApiResponseT定义在 src/types/api.ts - 请求参数超过3个时使用对象参数而非位置参数 - 错误处理由request拦截器统一处理业务层不写try-catch组件规则component.mdc--- description: 组件开发规范 globs: src/components/**/*.tsx alwaysApply: false --- - 使用函数式组件 TypeScript - Props类型命名为 组件名Props如 UserCardProps - 组件内部状态用useState跨组件状态用Zustand - 样式使用CSS Modules文件名格式 组件名.module.css - 每个组件文件不超过200行超出则拆分 - 事件处理函数命名handle 动作如 handleClick、handleSubmit这三份规则文件加起来不到100行但覆盖了日常开发90%的场景。配好之后Cursor生成的代码基本能直接用不需要大改。3. .cursorignore别让无关文件拖慢你的AI响应3.1 为什么需要.cursorignore.cursorignore的作用和.gitignore类似但目标不同。.gitignore是告诉Git哪些文件不用版本控制.cursorignore是告诉Cursor哪些文件不用索引、不用读取。为什么这件事很重要因为Cursor在回答你的问题时会扫描项目文件来构建上下文。如果你的项目里有node_modules、dist、.next这些目录文件数量可能几万甚至几十万。Cursor如果把这些都扫一遍响应速度会明显变慢而且上下文窗口会被无关内容占满真正有用的代码反而被挤出去了。我做过一个简单的对比测试同一个项目不配.cursorignore时问一个关于组件的问题响应时间大约8-12秒配好.cursorignore排除掉依赖目录和构建产物后响应时间降到3-5秒。差距非常明显。3.2 一份可以直接抄的.cursorignore模板下面这份是我在大多数前端项目里都会用的模板你可以根据项目类型增减# 依赖目录 node_modules/ .pnpm-store/ # 构建产物 dist/ build/ .next/ out/ .output/ # 缓存 .cache/ .parcel-cache/ .turbo/ .eslintcache # 环境与密钥 .env .env.local .env.*.local *.pem *.key # 日志 *.log logs/ # 编辑器与系统 .vscode/ .idea/ .DS_Store Thumbs.db # 测试覆盖率 coverage/ # 锁文件可选视项目而定 package-lock.json pnpm-lock.yaml yarn.lock关于锁文件要不要排除有个小争议。排除的好处是减少索引量坏处是Cursor看不到你用的具体依赖版本。我的做法是如果项目依赖比较稳定就排除如果经常需要Cursor帮你排查依赖冲突问题就保留。3.3 排除规则写错了会怎样两个真实翻车案例案例一把src/误排除了。有一次我复制了一份别人的.cursorignore模板里面有一行src/generated/我手滑写成了src/结果Cursor完全看不到我的源码问它什么问题都答我无法找到相关文件。排查了十几分钟才反应过来。所以写完.cursorignore后一定要检查一下有没有误伤源码目录。案例二排除了类型定义文件。有个项目我把*.d.ts排除了想着这些是自动生成的不用管。结果Cursor生成代码时完全不知道有哪些全局类型可用老是给我生成重复的类型定义。后来把*.d.ts从排除列表里去掉问题就解决了。提示.cursorignore的语法和.gitignore基本一致支持*通配符、/目录分隔、!取反。但注意Cursor对!取反的支持不如Git完善复杂场景建议直接用白名单思路只排除明确不需要的。3.4 大项目里的分层忽略策略如果你的项目特别大比如monorepo一刀切的.cursorignore可能不够用。这时候可以考虑分层策略根目录放一份全局的.cursorignore各个子包目录下再放各自的.cursorignore。Cursor会合并读取。比如一个典型的monorepo结构monorepo/ ├── .cursorignore # 全局排除 ├── packages/ │ ├── web/ │ │ └── .cursorignore # web包专属排除 │ ├── admin/ │ │ └── .cursorignore # admin包专属排除 │ └── shared/ │ └── .cursorignore # shared包专属排除全局的排除node_modules、.git这些通用目录各子包排除自己特有的构建产物和临时文件。这样既保证了覆盖面又不会误伤。4. 编辑器层面的配置中文回复、模型选择与快捷键4.1 让Cursor用中文回复你的三种方法很多人希望Cursor用中文回复但默认情况下它经常中英文混着来。有三种方法可以解决方法一在规则文件里声明。在general.mdc里加一行所有回复使用中文。这是最省事的方式一次配置全局生效。但缺点是规则文件主要影响代码生成对聊天回复的约束力有时不够强。方法二在对话中明确要求。每次开新对话时第一句话就说请用中文回复我。这个方法最直接但每次都要说一遍比较烦。方法三修改用户级别的设置。在Cursor的设置里找到Rules for AIAI规则选项在里面写上Always respond in Chinese。这个是用户级别的对所有项目生效不用每个项目都配。我自己的做法是方法一加方法三组合项目规则里写中文要求用户设置里也写一份。双保险基本不会出现英文回复的情况。4.2 模型选择不同任务用不同模型Cursor支持切换不同的底层模型不同模型在不同任务上的表现差异挺大的。根据我的使用经验任务类型推荐模型特点原因日常代码补全响应速度快的补全讲究即时性慢一秒体验就差很多复杂逻辑生成推理能力强的需要理解复杂业务逻辑生成多文件联动代码代码审查与重构上下文窗口大的需要读取大量文件理解整体架构简单问答与查询任意模型均可任务简单没必要用重型模型具体选哪个模型取决于你账号里可用的模型列表。我的建议是日常补全用一个轻量快速的遇到复杂任务时手动切换到更强的模型。不要所有任务都用最强的那个一来浪费额度二来响应慢影响心流。4.3 快捷键与交互习惯的调整Cursor默认的快捷键和VS Code基本一致但有几个AI相关的快捷键值得自定义Cmd/Ctrl K行内编辑选中代码后直接让AI修改Cmd/Ctrl L打开聊天面板Cmd/Ctrl I打开Composer多文件编辑Tab接受补全建议我个人的调整是把Cmd/Ctrl L改成了Cmd/Ctrl Shift L因为原来的组合和VS Code的选中当前行冲突了。这个看个人习惯没有标准答案。另外一个小技巧Cursor的聊天面板支持符号引用文件、Codebase引用整个代码库、Docs引用文档。善用这些引用符号能让AI更精准地理解你的意图。比如你想让AI参考某个已有组件的写法直接那个文件就行比用文字描述快得多。4.4 免费额度的合理分配Cursor的免费额度是有限的怎么把有限的额度用在刀刃上是个值得琢磨的事。我的策略是简单补全让它自动触发不用刻意省复杂任务先用免费额度试如果效果不好再考虑其他方案重复性的代码生成比如根据模板生成CRUD写好规则文件让一次生成到位减少来回修改消耗能用行内编辑解决的不开聊天面板因为行内编辑消耗的额度通常更少说到底配置做得好一次生成就到位消耗的额度自然就少。配置做得差来回改十次额度很快就见底了。5. 实战验证配置前后效率对比与常见问题排查5.1 一个真实项目的配置前后对比拿我最近做的一个后台管理项目举例。项目是React 18 TypeScript Ant Design 5大概30个页面50多个组件。配置之前的状态让Cursor生成一个列表页它给我生成了类组件我用的是函数式、用了fetch而不是项目封装的request、样式用了内联style而不是CSS Modules、类型定义直接写在组件文件里而不是放到types/目录。基本上生成完要手动改七八处。配置之后的状态同样生成一个列表页组件写法正确、请求走封装函数、样式用CSS Modules、类型定义自动放到types/目录、命名规范全部符合。需要手动改的地方降到一两处有时候甚至直接能用。这个差距不是模型变强了而是规则文件让模型知道了项目的约定。这就是配置的价值。5.2 规则不生效的排查清单配了规则但发现Cursor没按规则来按这个清单逐项排查文件位置对不对。.cursor/rules/目录必须在项目根目录下不能放在子目录里除非你用的是分层配置。YAML头部格式对不对。---必须是文件的第一行description和globs的缩进要正确。YAML对格式很敏感多一个空格都可能解析失败。globs匹配对不对。检查你的文件路径是否真的匹配了globs里写的模式。可以在Cursor的规则面板里看每条规则的状态确认是否生效。规则内容有没有冲突。如果两条规则对同一件事有不同要求Cursor可能会随机选一条。检查一下有没有矛盾的规则。有没有重启。修改规则文件后有时候需要重启Cursor或者重新加载窗口才能生效。规则是不是写得太模糊。写高质量的代码这种规则等于没写。规则要具体、可执行。5.3 几个我踩过的坑和对应的解法坑一规则文件写太长AI反而抓不住重点。一开始我把整个项目的架构文档都贴进去了结果Cursor生成代码时经常忽略关键约束。后来精简到只保留最核心的几条效果反而好了。规则文件不是文档是约束清单越精炼越好。坑二.cursorignore排除了.env文件导致AI不知道环境变量名。这个其实不算坑是安全考虑。但如果你需要AI知道环境变量的结构不涉及具体值可以在规则文件里描述一下有哪些环境变量比如API基础路径通过VITE_API_BASE_URL配置。坑三不同项目的规则文件互相复制导致水土不服。每个项目的技术栈和规范都不一样规则文件不能直接抄。我现在的做法是维护一份基础模板新项目基于模板改而不是直接复制。坑四忘了配.cursorignore项目大了之后响应特别慢。这个前面说过了养成习惯新项目第一件事就是配.cursorignore。5.4 团队协作中的规则文件管理如果是团队开发规则文件应该纳入版本控制让所有人共享同一套配置。但要注意几点规则文件里不要写个人的偏好比如我喜欢用单引号只写团队共识定期review规则文件随着项目演进更新新成员入职时把规则文件作为项目文档的一部分介绍如果团队里有人用不同的编辑器规则文件的内容可以作为编码规范的参考文档我现在的团队就是把.cursor/rules/目录纳入Git管理每次代码review时如果发现AI生成的代码有共性问题就更新规则文件。这样规则文件成了一个活的编码规范比写在Confluence里的文档实用多了。6. 进阶玩法让规则文件成为你的编码规范载体6.1 从规则文件反推项目规范有个很有意思的用法如果你接手了一个没有明确编码规范的老项目可以先让Cursor分析代码库总结出实际的编码习惯然后把这些习惯写成规则文件。这样既梳理了项目规范又让AI后续生成的代码能保持一致。具体操作打开Cursor聊天输入分析这个项目的代码风格和编码习惯包括命名规范、文件组织、常用模式等总结成一份规则文件。它会扫描代码库给出总结你再人工审核调整一下就是一份很实用的规则文件。6.2 规则文件的版本迭代思路规则文件不是一次写完就完事了它应该随着项目一起迭代。我的做法是每次发现AI生成的代码有重复性问题就想想是不是规则没写清楚是的话就补一条每个月review一次规则文件删掉过时的、合并重复的重大重构后同步更新规则文件这样坚持几个月规则文件会越来越贴合项目实际AI生成的代码也会越来越准。6.3 多项目复用的规则模板管理如果你同时维护多个项目可以建一个规则模板库把通用的规则抽出来各项目按需引用。比如rule-templates/ ├── base-frontend.mdc # 前端通用规范 ├── base-backend.mdc # 后端通用规范 ├── react.mdc # React专属规范 ├── vue.mdc # Vue专属规范 └── testing.mdc # 测试规范新项目启动时把需要的模板复制过去再补充项目特有的规则。这样既保证了规范性又减少了重复劳动。我在实际使用中最大的体会是Cursor的配置不是一劳永逸的事而是一个持续优化的过程。刚开始可能觉得麻烦但每配好一条规则后面就能少改一次代码。积少成多省下来的时间非常可观。另外规则文件写得好不好直接反映了你对项目的理解程度——如果你自己都说不清楚项目的编码规范那AI更不可能猜对。所以配置规则文件的过程其实也是梳理项目规范的过程一举两得。