1. 为什么大多数人用 Cursor 只发挥了它三成实力我身边不少朋友都在用 Cursor但聊下来发现一个很普遍的现象大家基本只把它当成一个能自动补全的编辑器写代码时按 Tab 接受建议偶尔用 CmdK 让它改改函数然后就没了。问他们有没有配过.cursorrules十个人里八个反问我那是什么。这就是问题所在。Cursor 真正的威力不在于它的补全速度而在于它能不能理解你的项目上下文、遵守你的编码习惯、记住你的技术栈偏好。而这些全靠配置文件来约束。没有配置的 Cursor就像一个技术很强但完全不了解你项目的新同事——能力有但每次都要从头解释一遍背景效率自然上不去。我自己从去年开始系统性地折腾 Cursor 的配置体系中间踩了不少坑也总结出一套相对成熟的规则。配好之后最直观的感受是重复性的样板代码基本不用自己敲了AI 生成的代码风格和我手写的几乎一致改需求时它也不会再给我推荐那些我根本不用的库。这篇文章就把这套配置思路完整拆开讲从规则文件怎么写、忽略文件怎么配、到中文回复怎么设置尽量让不同基础的人都能直接抄作业。需要先说明的是Cursor 的配置体系这两年一直在演进早期主要靠根目录的.cursorrules单文件后来逐步转向.cursor/rules/*.mdc这种分文件、带元数据的结构。两种方式目前都还能用但新项目我强烈建议直接上.mdc方案灵活性和可维护性完全不是一个量级。下面会分别讲清楚。2. 规则文件的两代方案从 .cursorrules 到 .cursor/rules2.1 单文件 .cursorrules 的适用边界.cursorrules是 Cursor 最早支持的规则载体位置就在项目根目录纯文本或 Markdown 格式都行。它的工作逻辑很简单每次你向 AI 发起请求时这个文件的全部内容会被塞进系统提示词里作为项目背景一起发给模型。这种方式的优点显而易见——简单直接一个文件搞定不用管目录结构。对于个人小项目、临时脚本、或者只是想快速试水的人.cursorrules完全够用。我早期做几个小工具时就是这么干的写个二三十行的规则把技术栈和代码风格说清楚效果立竿见影。但它的短板也很明显。首先是全量注入不管你这次是改前端组件还是写数据库迁移脚本整个文件都会被塞进上下文规则一多就浪费 token还可能互相干扰。其次是无法分场景你没法告诉 Cursor写 React 组件时遵守这套规则写 Node 脚本时遵守那套规则。最后是团队协作困难一个文件几十上百行多人维护时冲突频繁改一行都要 review 半天。所以我的判断是.cursorrules适合个人快速起步一旦项目超过中等规模、或者要多人协作就该考虑迁移了。2.2 .cursor/rules/*.mdc 的分层设计逻辑.cursor/rules/目录下的.mdc文件是现在的主流方案。每个.mdc文件由两部分组成顶部的 YAML 元数据frontmatter和下面的规则正文。元数据决定了这条规则什么时候生效正文决定了生效时说什么。一个典型的.mdc文件长这样--- description: React 组件编写规范 globs: [src/components/**/*.tsx] alwaysApply: false --- - 所有组件使用函数式写法禁止 class 组件 - Props 必须用 interface 显式声明类型 - 样式统一用 Tailwind不写独立 CSS 文件 - 组件文件名用 PascalCase与组件名一致这里几个字段的含义需要说清楚因为它们是整套体系的核心字段作用常见取值description规则用途说明AI 会参考它判断是否相关一句话描述globs文件路径匹配模式命中才激活[src/**/*.ts]alwaysApply是否无条件始终生效true/falsealwaysApply: true的规则相当于全局约束比如始终用中文回复代码注释用中文这类。而带globs的规则只在编辑匹配文件时激活比如你只在写.tsx时才需要 React 规范写.sql时就不该被它干扰。这种分层设计的好处是精准投喂。AI 每次拿到的上下文都是和当前任务强相关的既省 token 又减少误判。我实测下来同样的模型用.mdc分层规则生成的代码符合项目规范的比例比单文件.cursorrules高出不少尤其是大型项目里差异非常明显。2.3 迁移时最容易忽略的元数据陷阱从.cursorrules迁到.mdc时很多人会直接把原来的内容复制过去然后随便加个 frontmatter 就完事。这里有个坑我踩过globs写错会导致规则完全不生效而且没有任何报错提示。比如你写globs: [src/components/*.tsx]注意这里只有一个星号它只能匹配src/components/下一层的文件子目录里的文件全部漏掉。正确写法应该是src/components/**/*.tsx双星号才能递归匹配所有层级。这个细节文档里提得不多但实际影响很大——你会以为规则配好了结果 AI 该不听话还是不听话。另一个陷阱是alwaysApply和globs同时存在时的优先级。如果你设了alwaysApply: true那globs基本就失去意义了规则会无条件生效。所以全局规则和场景规则一定要分文件写别混在一起。提示改完.mdc文件后建议新开一个对话测试规则是否生效因为已经加载的上下文可能还带着旧规则容易让你误判。3. 让 AI 真正听懂你的项目规则内容的写法3.1 技术栈声明要具体到版本和库规则文件里最基础的一块是技术栈声明。但我发现很多人写得太笼统比如只写这是一个 React 项目。这种信息对 AI 来说几乎没用因为 React 生态太庞大了它不知道该用哪个路由、哪个状态管理、哪个 UI 库。正确的写法是把关键依赖和版本都列清楚## 技术栈 - 框架Next.js 14App Router不用 Pages Router - 语言TypeScript 5.3strict 模式开启 - 样式Tailwind CSS 3.4 shadcn/ui 组件库 - 状态Zustand不用 Redux - 数据请求TanStack Query v5 - 表单react-hook-form zod 校验这样写的好处是当你说帮我加一个用户列表页时AI 会直接用 App Router 的目录约定、用 shadcn 的 Table 组件、用 TanStack Query 拉数据而不是给你生成一堆需要手动改的代码。我对比过技术栈写得越具体AI 一次生成就能用的概率越高返工次数明显下降。3.2 用禁止清单比推荐清单更有效这是个反直觉的经验。一开始我写规则时习惯列一堆推荐做法比如推荐使用函数式组件推荐用 const 声明。但实测下来明确禁止某些做法比推荐某些做法效果更好。原因在于推荐是开放的AI 可能理解成优先但不强制遇到它觉得更优雅的写法时还是会偏离。而禁止是封闭的边界清晰AI 更容易遵守。所以我现在写规则会专门留一个禁止区块## 禁止事项 - 禁止使用 any 类型不确定时用 unknown 加类型守卫 - 禁止在组件内直接写 fetch统一走 api 层封装 - 禁止使用 index 作为列表 key - 禁止提交 console.log调试用 logger 工具 - 禁止引入 lodash工具函数自己写或从 utils 引这份清单是我根据团队实际 code review 中最常打回的问题整理的。把它写进规则后AI 生成的代码在 review 阶段被挑刺的次数少了一大截。你可以观察自己项目里 review 时反复出现的问题把它们沉淀成禁止清单这是投入产出比最高的规则内容。3.3 代码风格规则要给出正反例光说用 PascalCase 命名组件还不够因为 AI 对命名规范的理解可能和你有偏差。更稳妥的做法是给出正例和反例让它有明确的参照。## 命名规范 组件文件UserProfile.tsx正例/ userProfile.tsx反例 工具函数formatDate.ts正例/ FormatDate.ts反例 常量MAX_RETRY_COUNT正例/ maxRetryCount反例这种正反例对照的写法比单纯描述规则要精确得多。尤其是团队里有约定俗成但不好用文字描述的命名习惯时举几个例子往往比写一段说明更管用。3.4 把项目特有的业务约束写进去这一块是很多人会忽略的但恰恰是让 AI 生成代码接地气的关键。每个项目都有一些外人不知道的业务约束比如金额字段统一用分为单位存储展示时再除以 100所有时间戳用 UTC展示层再转本地时区用户 ID 是雪花算法生成的 19 位数字前端要用 string 接收避免精度丢失接口返回统一包一层{ code, data, message }结构这些约束如果不写进规则AI 生成的代码很可能在细节上出错比如把金额当元处理、把用户 ID 当 number 解析导致精度丢失。我吃过这个亏——有次 AI 生成的订单金额计算直接用了浮点数测试时才发现精度问题回头一查就是因为规则里没写清楚金额单位。把这些业务约束单独整理成一个.mdc文件用alwaysApply: true让它全局生效能省掉大量后期调试。4. .cursorignore 与上下文管理别让 AI 看不该看的4.1 .cursorignore 到底忽略什么.cursorignore的作用和.gitignore类似但针对的是 Cursor 的索引和上下文。写进去的路径Cursor 在建立代码索引、检索上下文时会跳过AI 也就看不到这些文件。为什么需要这个两个原因。第一是性能如果项目里有node_modules、dist、build这些目录全量索引会非常慢而且这些文件对理解业务代码毫无帮助。第二是安全.env、密钥文件、证书这类敏感内容绝对不能让它们进入 AI 的上下文。一个我常用的.cursorignore模板node_modules/ dist/ build/ .next/ coverage/ *.log .env .env.* *.pem *.key .DS_Store4.2 忽略规则写错反而拖慢索引这里有个细节值得单独说。.cursorignore的匹配规则和.gitignore类似但不是完全一致。比如dist/和dist在某些情况下行为不同前者明确指目录后者可能匹配到同名文件。更关键的是如果你忽略的目录里其实有 AI 需要参考的文件会导致它断片。我遇到过一次把整个types/目录忽略了结果 AI 生成代码时老是猜错类型定义因为它根本看不到那些 interface。后来把types/从忽略列表移除问题立刻消失。所以忽略的原则是只忽略生成物、依赖、敏感文件源码和类型定义一律保留。拿不准的时候宁可先不忽略观察索引速度和 AI 表现再逐步调整。4.3 用 引用精准控制单次上下文除了全局忽略Cursor 还支持在对话里用手动引用文件或目录。这是精准控制上下文的好办法。比如你要改一个工具函数可以utils/format.ts把它拉进来AI 就能基于真实代码来改而不是凭空猜。我的习惯是涉及跨文件改动时主动 相关文件。比如改一个 API 调用我会同时 接口定义文件、调用方组件、以及类型文件。这样 AI 拿到的信息完整生成的改动一次到位不用来回追问。配合.cursorignore的全局过滤和的精准引用基本能做到该看的都看到不该看的不打扰这是用好 Cursor 的核心手感。5. 中文回复与界面汉化的完整设置路径5.1 让 AI 用中文回复的三种方式热词里cursor设置中文回复cursor怎么设置中文出现频率很高说明这是很多人的刚需。让 AI 用中文回复主要有三种做法效果和适用场景各不同。第一种在规则文件里声明。在alwaysApply: true的规则里加一句始终使用简体中文回复代码注释也用中文。这是最推荐的方式因为它跟着项目走换设备、换协作者都生效。第二种在对话里直接要求。每次开新对话时说一句请用中文回复。缺点是每次都要说容易忘。第三种改 Cursor 的界面语言设置。这个影响的是软件界面本身的语言不是 AI 回复的语言两者别搞混。界面汉化在设置里找 Language 相关选项切换即可但 AI 回复语言还是得靠规则或对话指令控制。我自己的做法是规则文件里写死中文回复这样最省心。需要注意的是代码本身变量名、函数名建议还是用英文只让注释和解释用中文。混用中英文命名会让代码可读性变差也不利于协作。5.2 界面语言与 AI 回复语言是两回事这一点必须强调因为太多人混淆了。Cursor 的界面语言设置改的是菜单、按钮、提示这些 UI 文案的显示语言。而 AI 在对话里用什么语言回复取决于你给它的指令或规则。我见过有人把界面切成中文后发现 AI 还是用英文回复就以为设置没生效。其实这俩根本不是一个开关。界面语言是软件本地化AI 回复语言是模型行为后者只能通过提示词控制。所以正确的组合是界面语言按自己习惯设AI 回复语言在规则文件里声明。两件事分开处理就不会困惑了。5.3 中文规则本身也可能被翻译还有个隐蔽的坑如果你用中文写规则AI 有时会在生成代码时把规则里的中文术语翻译成英文导致命名不一致。比如规则里写用户信息组件它可能生成UserInfoComponent而不是你期望的UserProfile。解决办法是在规则里明确给出中英对照尤其是涉及命名的部分## 术语对照 用户信息 → UserProfile 订单详情 → OrderDetail 支付记录 → PaymentRecord这样 AI 就知道中文术语对应哪个英文命名不会自由发挥。这个技巧在处理业务术语较多的项目时特别有用。6. 实测中那些文档不会告诉你的坑6.1 规则太多反而让 AI 精神分裂我一开始很兴奋把能想到的规则全写进去了结果发现 AI 反而变笨了——生成的代码时而遵守这条、时而忽略那条风格飘忽不定。后来才明白规则总量是有上限的塞太多会稀释每条规则的权重还可能互相冲突。我的经验是核心规则控制在 5 到 8 个.mdc文件每个文件聚焦一个主题技术栈、命名、禁止事项、业务约束等单个文件正文别超过 100 行。宁可精炼不要堆砌。真正重要的规则放alwaysApply次要的用globs按需激活。6.2 规则冲突时的优先级判断当两条规则对同一件事给出不同要求时AI 会怎么处理实测下来后加载的、更具体的规则通常优先。但这个行为不稳定不同模型版本表现不一样。所以最稳妥的做法是从源头避免冲突。写完规则后自己通读一遍检查有没有自相矛盾的地方。比如一个文件说用双引号另一个说用单引号这种必须统一。我建议专门花时间做一次规则审查把冲突项清理掉比事后调试划算得多。6.3 换模型后规则要重新验证Cursor 支持切换不同的底层模型而不同模型对规则的理解和遵守程度是有差异的。我遇到过同一个规则文件在 A 模型下效果很好换到 B 模型后 AI 就开始选择性失忆。所以每次换主力模型后建议拿几个典型任务测一下规则是否还生效。如果发现某些规则被忽略可能需要调整措辞把要求写得更明确、更靠前。这不是规则写错了而是模型特性不同需要适配。6.4 规则文件也要进版本控制最后一点.cursor/rules/目录和.cursorignore都应该提交到 Git 仓库。这样团队成员拉下代码就自动获得统一的 AI 行为新人不用单独配置协作时生成的代码风格也一致。我团队现在的做法是规则文件由技术负责人维护改动走正常的 PR 流程。谁发现 AI 生成的代码有共性问题就提 PR 补充规则。这样规则库会随着项目推进不断沉淀越用越顺手。7. 一套可以直接抄的配置骨架说了这么多原理和坑最后给一套我自己在用的配置骨架你可以直接拿去改。目录结构是这样的.cursor/ rules/ 00-global.mdc # 全局中文回复、通用原则 01-tech-stack.mdc # 技术栈声明 02-naming.mdc # 命名规范 03-forbidden.mdc # 禁止事项 04-business.mdc # 业务约束 .cursorignore00-global.mdc的内容示例--- description: 全局规则始终生效 alwaysApply: true --- - 始终使用简体中文回复代码注释用中文变量和函数名用英文 - 回答简洁直接不写客套话代码优先 - 涉及不确定的 API 时先说明假设再给代码03-forbidden.mdc的内容示例--- description: 代码禁止事项 alwaysApply: true --- - 禁止 any 类型 - 禁止组件内直接 fetch - 禁止 index 作列表 key - 禁止提交 console.log - 禁止引入未在技术栈中声明的库这套骨架我用了大半年覆盖了日常开发绝大多数场景。你可以根据自己的项目往里加但记住前面说的——别贪多精炼比全面重要。配置这件事没有一劳永逸的答案项目在变、模型在变规则也得跟着迭代。我的习惯是每个月抽半小时回顾一下规则文件把最近 review 中反复出现的问题补进去把已经内化成习惯的规则精简掉。这样维护下来Cursor 会越来越懂你的项目写代码时那种它怎么知道我要这么写的顺畅感就是这么一点点攒出来的。