★ FEATURED ARTICLE 1. 为什么你的Cursor总感觉“差点意思”很多人第一次打开Cursor感觉就是“套了AI壳的VS Code”写代码时补全偶尔灵光一现大部分时间还是靠自己敲。用了两周新鲜劲过了又回到原来的编辑器。问题不在Cursor本身而在于你只用了它20%的能力——剩下80%藏在规则配置里。我自己的经历很典型去年刚上手时我也觉得AI补全不过如此直到我把项目规范、技术栈约束、代码风格偏好全部写进规则文件补全准确率肉眼可见地往上跳。最直观的变化是以前AI总给我生成var和回调地狱配置规则后它默认输出const和async/await连注释风格都跟团队规范对齐了。粗略估算日常CRUD和工具函数的编写量少了将近一半更多时间花在架构设计和边界情况处理上。这篇文章面向所有正在用或准备用Cursor的开发者不管你写Python、TypeScript、Go还是Java规则配置的逻辑是通用的。我会把.cursorrules、.cursor/rules/*.mdc、.cursorignore这三个核心配置项拆开讲透配上可直接抄的模板和踩坑记录。读完你至少能省下两周自己摸索的时间。2. 规则体系全拆解三个文件各管什么2.1.cursorrules项目级全局指令.cursorrules放在项目根目录是Cursor最早支持的规则文件格式。它的作用是给AI一个“项目说明书”——你用什么技术栈、代码风格如何、有哪些禁忌。每次AI生成代码或回答问题时这个文件的内容会作为系统提示的一部分注入上下文。为什么需要它因为AI默认的训练数据太杂了。你不告诉它“这个项目用React 18 TypeScript严格模式”它就可能给你生成class组件或者any类型。规则文件本质上是把团队约定从“口口相传”变成“AI可读”。一个常见的误区是把它写成README。.cursorrules不需要项目介绍、安装步骤只需要约束性指令。比如# 项目技术栈 - React 18 TypeScript 5.x严格模式 - 状态管理用Zustand禁止引入Redux - 样式用Tailwind CSS禁止内联style - 包管理器用pnpm # 代码风格 - 函数组件一律用箭头函数 具名导出 - 异步操作统一用async/await禁止.then()链 - 类型定义优先用interface联合类型用type - 注释用中文只在复杂逻辑处添加 # 禁止事项 - 禁止使用any类型 - 禁止在组件内直接调用fetch统一走services层 - 禁止提交console.log这份规则大概30行但效果立竿见影。我实测下来配置后AI生成any的概率从大概三成降到几乎为零。2.2.cursor/rules/*.mdc模块化精细控制.cursorrules有个明显短板所有规则挤在一个文件里项目大了之后维护困难。比如前端规则和后端规则混在一起AI有时候会“串味”。Cursor后来推出了.cursor/rules/目录里面放多个.mdc文件每个文件可以指定生效范围。.mdc文件支持frontmatter元数据核心字段有三个--- description: React组件开发规范 globs: src/components/**/*.tsx alwaysApply: false ---description规则描述AI用来判断何时加载globs文件匹配模式只有操作匹配的文件时才激活这套规则alwaysApply是否始终生效设为true则忽略globs这个机制的好处是按需加载。你写后端接口时前端那套Tailwind规则不会干扰AI写测试文件时测试相关的规则才被激活。我一般会拆成这几个文件文件名生效范围核心内容frontend.mdcsrc/components/**组件规范、样式方案backend.mdcsrc/api/**接口规范、错误处理testing.mdc**/*.test.ts测试框架、断言风格database.mdcsrc/db/**ORM用法、查询规范global.mdc全部通用编码规范alwaysApply: true只留给global.mdc其他都靠globs自动激活。这样AI在写不同模块时拿到的上下文是精准的不会出现“用React的思维写SQL”这种荒唐事。2.3.cursorignore给AI划出禁区.cursorignore的语法跟.gitignore一样作用是告诉Cursor哪些文件不要索引、不要读取。为什么这个很重要两个原因第一性能。Cursor会把项目文件索引到本地向量库项目大了之后索引体积很可观。把node_modules、dist、build、.next这些目录排除掉索引速度能快好几倍。第二安全。.env、*.pem、credentials.json这类敏感文件绝对不能让AI读到。虽然Cursor官方说数据不会外传但把密钥送进上下文本身就是风险。我见过有人把.env留在索引里AI补全时直接把数据库密码吐在代码注释里场面相当尴尬。一份典型的.cursorignore# 依赖 node_modules/ .pnpm-store/ # 构建产物 dist/ build/ .next/ out/ # 环境与密钥 .env .env.* *.pem *.key credentials.json # 缓存与日志 .cache/ *.log coverage/ # 大型静态资源 public/videos/ *.psd *.zip注意.cursorignore修改后需要重启Cursor或手动触发重新索引才生效。我踩过一次坑改完文件以为立即生效结果AI还是读到了旧的敏感文件排查了半天才发现是索引没刷新。3. 从零搭建一套顺手的规则实操全流程3.1 第一步摸清项目底细再动笔别急着创建文件。先花十分钟把项目现状理清楚我一般会问自己几个问题技术栈和版本号是什么React 17还是18Vue 2还是3这直接影响AI生成的API用法。团队有没有现成的ESLint/Prettier配置有的话直接把规则抄进.cursorrules保证AI输出和lint结果一致。哪些目录是核心业务代码哪些是自动生成的自动生成的目录要放进.cursorignore。有没有历史遗留的“祖传代码”如果有规则里要明确写“新代码遵循以下规范不要模仿旧文件风格”否则AI会学坏。这一步看起来啰嗦但能避免后面反复改规则。我第一次配的时候跳过这步结果规则写了三版才稳定。3.2 第二步写一份最小可用规则新手容易犯的错是一上来写几百行规则恨不得把员工手册都塞进去。规则太长有两个问题一是AI可能忽略中间部分上下文注意力衰减二是维护成本高。我的建议是从20-30行起步只写最关键的约束。一个最小可用的.cursorrules模板# 技术栈 - 语言TypeScript 5.xstrict模式 - 框架Next.js 14 App Router - 样式Tailwind CSS shadcn/ui - 状态Zustand - 请求TanStack Query # 编码规范 - 组件用函数式具名导出 - 优先使用服务端组件需要交互时才加use client - 所有异步函数必须处理错误用try/catch或Result类型 - 变量命名用camelCase常量用UPPER_SNAKE_CASE - 禁止any不确定的类型用unknown 类型守卫 # 文件组织 - 组件放src/components一个文件一个组件 - 工具函数放src/lib按功能分文件 - 类型定义放src/types按领域分文件 # 回复语言 - 所有解释和注释用中文 - 代码本身保持英文命名这份规则覆盖了日常80%的场景。用一周后你会发现哪些地方AI还是“不听话”再针对性补充。3.3 第三步拆分模块化规则当.cursorrules超过50行就该拆了。在项目根目录建.cursor/rules/文件夹把规则按领域拆成多个.mdc。拆分的原则是高内聚低耦合同一领域的规则放一起不同领域之间不交叉。比如数据库规则里不要提React前端规则里不要提SQL。一个backend.mdc的完整示例--- description: 后端API开发规范 globs: src/app/api/**/*.ts,src/server/**/*.ts alwaysApply: false --- # API设计 - 路由用RESTful风格资源名用复数 - 响应统一格式{ code, data, message } - 错误码用HTTP状态码业务错误放message - 所有输入用Zod校验schema放同目录的schema.ts # 数据库 - ORM用Prisma禁止裸写SQL - 查询必须加select或include禁止返回全字段 - 事务用prisma.$transaction包裹 - 软删除用deletedAt字段查询默认过滤 # 错误处理 - 用自定义AppError类包含code和message - 全局错误中间件统一捕获 - 禁止在catch里吞掉错误至少console.error # 安全 - 所有用户输入必须校验 - 敏感操作加权限检查 - 禁止在日志里打印用户密码、token注意globs的写法多个模式用逗号分隔支持**通配。这样只有AI操作src/app/api/下的文件时这套规则才生效。3.4 第四步配置.cursorignore并验证.cursorignore的配置前面已经给了模板这里说验证方法。配置完后在Cursor里打开一个应该被忽略的文件比如.env然后问AI“这个文件里有什么”如果AI说读不到或拒绝回答说明配置生效了。另一个验证方式是看索引状态。Cursor设置里有“Indexing”选项能看到已索引的文件数和体积。配置前后对比一下正常项目能减少60%-80%的索引量。实操心得.cursorignore支持!取反语法可以排除某个目录但保留其中特定文件。比如node_modules/排除全部但!node_modules/my-package/保留某个本地开发的包。这个技巧在monorepo里特别有用。4. 让AI“说人话”中文回复与语言设置4.1 中文回复的三种配置方式热词里“cursor设置中文回复”出现频率极高说明这是很多人的痛点。AI默认用英文回复虽然能看懂但读起来费劲。配置中文有三种方式各有适用场景。方式一在.cursorrules里加语言指令。这是最推荐的做法一次配置全局生效# 回复语言 - 所有对话、解释、注释一律用中文 - 代码中的变量名、函数名保持英文 - 报错信息可以保留英文原文但需附中文解释方式二在Cursor设置里改。打开设置Ctrl/Cmd ,搜索“language”把“Response Language”改成中文。这个设置对全局生效但优先级低于项目规则文件。方式三对话时临时指定。在Chat里直接说“用中文回答”当次对话生效。适合临时切换但每次都要说一遍麻烦。我实测下来方式一最稳。方式二偶尔会被项目规则覆盖方式三容易忘。三者可以叠加规则文件里写死中文设置里也调成中文双保险。4.2 中文注释的坑让AI写中文注释有个隐患它有时候会把中文注释写在代码行尾导致行太长有时候中英文混排标点符号用错比如用英文逗号。我的做法是在规则里明确注释规范# 注释规范 - 注释单独成行写在被注释代码的上方 - 中文注释用中文标点英文注释用英文标点 - 函数注释用JSDoc格式描述用中文 - 禁止行尾注释除非是极短的说明配置后AI生成的注释干净很多。另外提醒一句如果你的项目要开源或给国际团队看中文注释可能不合适规则里要写清楚“注释用英文”。4.3 代码解释的语言策略AI解释代码时我建议保留关键术语的英文。比如“这个函数用了debounce防抖”比纯中文“防抖”更容易对应到技术概念。规则可以这样写- 技术术语首次出现时用“中文English”格式 - 例如闭包closure、防抖debounce、柯里化currying这样既保证可读性又不丢失专业性。5. 规则进阶让AI真正懂你的项目5.1 用规则注入项目上下文AI不知道你的项目结构、业务逻辑、历史决策。规则文件是注入这些信息的入口。但要注意规则文件不是文档只写影响AI输出的信息。比如你的项目有个约定“所有金额用分为单位存储展示时除以100”。这个必须写进规则否则AI会直接用元导致金额错100倍。类似的关键约定还有时间存储用UTC还是本地时区ID用自增还是UUID分页参数从0还是1开始枚举值用数字还是字符串这些细节不写清楚AI生成的代码看着对跑起来全是bug。我踩过最坑的一次是分页AI默认从0开始我们后端从1开始联调时发现第一页数据永远丢失。5.2 规则里的“反面教材”除了告诉AI“要怎么做”还要告诉它“不要怎么做”。特别是项目里有历史遗留问题时反面指令能防止AI模仿坏代码。# 禁止模仿的旧代码 - src/legacy/目录下的代码是历史遗留禁止参考其风格 - 旧代码用class组件和Redux新代码一律用函数组件和Zustand - 旧代码的错误处理用回调新代码用async/await - 如果AI生成的代码与legacy目录相似请主动提醒这条规则救过我。有次AI补全时自动引入了src/legacy/里的一个工具函数那个函数有已知的内存泄漏问题。加了规则后AI会主动避开legacy目录。5.3 动态规则与条件生效.mdc的globs支持条件生效但有时候需要更复杂的逻辑。比如“只在开发环境用mock数据”这种没法用globs表达。我的做法是在规则里写清楚环境判断# 环境相关 - 开发环境可以用mock数据但必须用if (process.env.NODE_ENV development)包裹 - 生产环境禁止任何mock逻辑 - 环境变量统一从src/config/env.ts读取禁止直接访问process.envAI看到这条规则后生成mock代码时会自动加环境判断。虽然不能100%保证但比不写强很多。5.4 规则的版本管理规则文件应该跟代码一起提交到Git。原因有三一是团队共享新人拉代码就自带规则二是可追溯出问题能查是哪次规则改动导致的三是可回滚新规则效果不好可以退回旧版。我一般把规则改动单独提交commit message写清楚改了什么、为什么改。比如git add .cursorrules .cursor/rules/ git commit -m rules: 禁止使用any类型补充Zustand用法规范这样规则演进有记录团队review时也能讨论。6. 常见问题与排查实录6.1 规则不生效的排查清单规则写了但AI不遵守是最常见的问题。按以下顺序排查排查项检查方法常见原因文件位置确认.cursorrules在项目根目录放错到子目录文件编码用UTF-8无BOM保存GBK编码导致读取失败索引状态设置里看Indexing是否完成索引未刷新规则冲突检查多个.mdc是否有矛盾指令前后规则打架规则长度超过200行考虑拆分上下文超限被截断优先级.cursor/rules/优先于.cursorrules旧规则覆盖新规则我遇到最多的是索引未刷新。改完规则后Cursor需要几秒到几十秒重新索引期间AI用的还是旧规则。养成改完规则等几秒再提问的习惯。6.2 AI“忘记”规则的场景即使规则配置正确AI在某些场景下还是会“忘记”。常见的有对话太长Chat历史超过上下文窗口早期规则被挤出。解决办法是开新对话或者把关键规则放在规则文件最前面。跨文件操作AI同时改多个文件时可能只加载了部分规则。这时候手动一下相关规则文件。复杂重构大范围重构时AI注意力分散。建议拆成小任务每次只改一个模块。实操心得在Chat里用.cursorrules显式引用规则文件能强制AI重新读取。这个技巧在AI“犯糊涂”时特别管用。6.3 规则写太严的副作用规则不是越严越好。我早期写过一条“禁止使用for循环一律用map/filter/reduce”结果AI在需要提前终止循环的场景硬套reduce代码反而更难读。后来改成“优先用数组方法但性能敏感场景可以用for循环”AI的判断就合理多了。规则要留出判断空间。用“优先”“建议”“除非”这类词比“禁止”“必须”更灵活。当然安全相关的规则还是要用“禁止”比如“禁止拼接SQL”。6.4 性能问题的排查规则文件太多太大会影响Cursor响应速度。如果感觉AI变慢检查这几点.cursorignore是否排除了大目录规则文件总行数是否超过500行是否有.mdc的alwaysApply: true过多项目索引体积是否异常我有个项目规则写了800多行AI响应明显变慢。拆成6个.mdc后只有相关规则被加载速度恢复正常。6.5 团队协作中的规则同步团队用Cursor规则文件要统一。但每个人的编码习惯不同容易各写各的。我的做法是规则文件由tech lead维护其他人提PR修改新规则先在个人分支试用一周有效再合并每月review一次规则删掉过时的规则改动在团队群里同步避免有人不知道这样既保证统一又允许渐进优化。7. 我的规则模板与日常维护习惯7.1 一份可直接抄的完整模板把前面所有内容整合这是一份我用了半年、迭代了十几版的模板。你可以直接复制到项目里按需删改# 项目技术栈 - 语言TypeScript 5.xstrict模式 - 框架Next.js 14 App Router - 样式Tailwind CSS shadcn/ui - 状态Zustand - 请求TanStack Query - 数据库Prisma PostgreSQL - 包管理pnpm # 编码规范 - 组件用函数式具名导出 - 优先服务端组件交互才加use client - 异步统一async/await必须处理错误 - 命名变量camelCase常量UPPER_SNAKE_CASE类型PascalCase - 禁止any用unknown 类型守卫 - 优先数组方法性能敏感场景可用for循环 # 文件组织 - 组件src/components一文件一组件 - 工具src/lib按功能分文件 - 类型src/types按领域分文件 - APIsrc/app/apiRESTful风格 # 注释规范 - 注释单独成行写在代码上方 - 中文注释用中文标点 - 函数用JSDoc描述用中文 - 禁止行尾注释 # 回复语言 - 对话、解释、注释用中文 - 代码命名保持英文 - 技术术语首次出现用“中文English”格式 # 禁止事项 - 禁止any类型 - 禁止组件内直接fetch - 禁止提交console.log - 禁止拼接SQL - 禁止在日志打印敏感信息 - 禁止模仿src/legacy/目录的代码风格 # 关键约定 - 金额用分存储展示时除以100 - 时间存储用UTC - ID用UUID - 分页从1开始 - 枚举用字符串这份模板大概60行覆盖了大部分场景。用的时候根据项目实际情况调整别照搬。7.2 日常维护的节奏规则不是写完就不管了。我的维护节奏是每天遇到AI输出不符合预期随手记下来晚上统一改规则每周review一次规则文件删掉没用的补充新发现的每月大版本review结合项目技术栈变化调整每季度清理历史规则合并重复的重写表述不清的这个节奏下规则文件始终保持精简有效。我见过有人规则写了两年没动过里面还有已经废弃的技术栈AI照着生成代码全是过时的写法。7.3 规则效果的量化评估怎么知道规则有没有用我一般看两个指标一是AI生成代码的返工率。配置规则前AI生成的代码大概30%需要手动改配置后降到10%左右。返工率下降就是规则有效的直接证据。二是补全采纳率。Cursor有统计功能能看到你采纳了多少AI建议。规则配置好后采纳率从20%多涨到50%以上。这个数字因人而异但趋势是向上的。如果配置规则后这两个指标没变化说明规则写得不对要么太泛要么跟实际需求不匹配需要重新调整。7.4 一个容易被忽略的细节规则文件里的示例代码AI会当成“标准答案”来模仿。所以示例必须是你想要的风格。我早期在规则里写了个function foo() {}的示例结果AI生成的全是function声明而我实际想要箭头函数。后来把示例改成const foo () {}AI就跟着改了。这个细节很小但影响很大。规则里的每一行代码AI都会认真对待。所以示例要精挑细选确保是你希望AI模仿的写法。8. 规则之外那些让Cursor更好用的小设置8.1 模型选择与额度管理Cursor内置多个模型不同模型能力差异明显。日常补全用默认的就行复杂重构或架构设计时切到更强的模型。免费额度有限我的策略是简单任务用快速模型复杂任务才用高级模型避免额度浪费。热词里“cursor免费额度是多少”问的人多具体额度会调整建议在设置里看实时用量。养成看用量习惯避免关键时刻额度用完。8.2 快捷键与工作流几个我常用的快捷键Ctrl/Cmd K行内生成选中代码后让AI改写Ctrl/Cmd L打开Chat问问题或让它改代码Ctrl/Cmd IComposer多文件编辑Tab采纳补全建议工作流上我习惯先写注释描述意图再让AI补全实现。比如写// 计算两个日期之间的工作日天数然后按回车AI会生成完整函数。这比直接让AI“写个函数”准确得多因为注释本身就是精确的需求描述。8.3 与版本控制的配合Cursor的AI改动建议先提交再应用这样出问题能回滚。我一般的工作流是确保当前分支干净没有未提交改动让AI生成或修改代码review改动确认无误提交commit message写清楚是AI辅助这样即使AI改错了git diff能看清所有改动git checkout能一键回滚。别在未提交状态下让AI大范围改代码出问题很难恢复。8.4 插件生态的取舍Cursor兼容VS Code插件但不是所有插件都值得装。我的原则是只装真正提升效率的避免插件冲突拖慢编辑器。必装的有GitLens、Error Lens、Path Intellisense其他按需。插件装多了会影响Cursor的AI响应速度因为编辑器整体变重了。我实测过装20个插件和装5个插件AI补全的延迟差了一倍。所以定期清理不用的插件。9. 最后分享几个踩坑换来的经验规则配置这件事说到底是把“你脑子里的项目约定”翻译成“AI能读的指令”。翻译得好AI就是得力助手翻译得差AI就是添乱。我最大的体会是规则要跟着项目走不能跟着感觉走。项目用什么技术栈、什么规范规则就写什么。别抄别人的规则因为别人的项目跟你的不一样。我早期抄过一份网上的“万能规则”结果里面全是React的约定而我当时写的是VueAI生成的东西驴唇不对马嘴。另一个体会是规则要迭代不能一劳永逸。项目在变团队在变AI模型也在变。三个月前的规则现在可能已经过时。养成定期review的习惯比写一份完美规则更重要。最后一个实用技巧把规则文件当成“给新人的入职文档”来写。想象一个新同事加入项目你需要告诉他什么就写进规则。这个视角能帮你抓住重点避免写成流水账。新人看了能上手AI看了能干活这份规则就到位了。
阅读完成 · 觉得有帮助？
