1. 先颠覆一个认知为什么你的Cursor越用越“笨”如果你也是从某天开始陆续把日常开发往Cursor上搬大概率有过类似的感受头一个星期觉得这工具简直是“天降外援”补全快、能读整个项目、还能照着issue直接改代码但用着用着就发现不对味了——AI越来越“轴”明明上一条消息里刚说过的约束下一条它就当没听见让它改一个函数它顺手把旁边三个不相干的文件也改了个遍有点难度的需求它反复给你“写好几版——你觉得不对——它再写一版——还是不对”的循环最后你还得自己撸起袖子收尾。问题出在哪我用了大半年之后得出一个结论不是Cursor不行而是我在用它的时候全程没给它立规矩。很多人把Cursor当成一个“升级版补全插件”打开对话框直接甩需求期待它像某个懂你所有心意的神仙同事那样看一眼就知道你要什么。但现实是它更像个“能力很强、但刚入职、没人带过”的新人代码库读得懂、框架也会用、语法不出错可它既不知道你们项目的规范也不知道你个人的审美偏好更不知道你现在手里的这个任务在整盘棋里是什么位置。你什么都不说它就只能按“它觉得合理”的方式来干活。而这恰恰是配置规则这件事的底层逻辑你不是在“调设置”而是在给这个高能力的初级工程师做一次“入职培训”。把项目背景、技术栈、代码风格、交付标准、沟通习惯这些你默认“人人都该知道”的事情提前写成一份说明书让它每次干活前先读一遍。我这套配置实践下来最直观的变化是以前一个功能要来回沟通七八轮改出三四版废代码现在基本是“需求丢过去——AI列出计划——我确认一下——它一把写完”。说“少写一半代码”可能有点标题党但说的其实是另一件事真正被砍掉的是“写了删、删了改”的无效劳动这比单纯让AI多吐几千行要有价值得多。下面直接上干货从目录结构到具体规则内容再到生效原理和翻车排查我把能直接抄的东西都摊开来讲。2. 把“入职培训”拆成两类文件全局规则与项目规则先说结论Cursor的规则文件不是只有一种。官方能力里最常用的是两类文件职责完全不同必须分开放。第一类是全局规则通常放在用户目录的.cursor/rules/下比如 macOS 的~/.cursor/rules/Windows 的对应用户目录下。这类文件对你所有项目生效适合放那些“不管写什么代码都成立”的通用偏好——比如“默认使用英文变量命名”“注释要简洁不要解释显而易见的代码”“拒绝生成未经 request 的额外文件”。相当于你给AI立的是“个人职业素养”。第二类是项目级规则放在项目根目录的.cursor/rules/下随仓库一起走。适合放这个项目特有的约束——技术栈声明、目录结构约定、关键框架版本、禁止使用的模式等。这类规则有个天然优势跟着仓库走团队里任何人打开项目AI自动继承同一套约定不用每个人重复配置一遍。实际配置时我强烈建议全局规则越少越好只写放之四海皆准的东西项目规则的比重应该远高于全局规则。原因很朴素——你为电商项目写的规则拿到一个嵌入式项目里可能全是反作用。全局规则写多了AI在无关场景里也会被莫名约束反而变得束手束脚。目录搞清楚了还得明白另一件事规则文件不是放在那里就自动生效的。Cursor 的规则读取机制比较直接——Agent 模式即 Tab 补全和 Composer/Agent 交互场景会在会话启动时扫描规则文件并注入上下文但触发的条件是“文件名匹配”或“路径匹配”。也就是说你把所有规则塞进一个名叫general.mdc的文件里它反而会在每个会话里都被加载如果你拆成frontend-react.mdc、backend-api.mdc这样的分文件AI 是按“与你当前打开的代码是否匹配”来决定加载哪些规则的。这意味着一个配置技巧规则文件尽量按场景拆细而不是一个大而全的文件一锅端。我见过很多人的做法是写一个两百行的巨型规则文件结果AI什么都记住了又等于什么都没记住——上下文窗口有限前面几百行规矩占用的是它理解当前任务的空间。我自己的拆分方式是这样global.mdc通用行为规范不超过20行。tech-stack.mdc项目技术栈、依赖版本、目录结构约定。code-style.mdc命名、格式化、注释、组件拆分等风格规则。deliverable.mdc任务交付标准要哪些文件、代码要过lint、测试要求等。每个文件都有明确的适用场景AI在使用时按需加载既精准又不浪费上下文。这是从“规则数量多但没效果”到“规则数量适中但每个都管用”的一个关键转折点。3. 一套能直接抄的规则模板四类文件的具体写法光说原则不够我把目前自己在用的这套规则直接贴出来每条都附上为什么这么写。你可以直接复制后按需修改跑一两天就能感受到差别。3.1 global.mdc管住AI的“手”和“嘴”--- description: Global behavioral rules for all projects globs: **/*.{js,ts,jsx,tsx,py,java,go,rs,cpp,c,html,css,json,yaml,yml,md,sql,sh,php,rb} --- - You are a senior engineer working on real codebases. Write code that is clean, idiomatic, and production-ready. - Do NOT add comments that merely restate what the code does. Only add comments explaining WHY. - Do NOT create or modify files outside the ones relevant to the current task. If you believe a file needs changing, say so explicitly and wait for confirmation. - Do NOT refactor unrelated code while implementing a feature. - When providing code changes, always show the full file paths and a brief summary of what changed and why. - If you are unsure about requirements, ask ONE concise clarifying question before proceeding, rather than guessing. - Never output placeholder comments like // TODO: implement this unless specifically requested. - When writing tests, prefer small, focused tests over large integration tests. - Keep changes as small as possible while still meeting the stated goal.这里前三条管的是“行为边界”——AI最容易犯的毛病就是自作主张扩大修改范围有了这两条它至少会先停下来问一句而不是把你项目翻个底朝天。后两条管的是“交付透明度”——让它把改了什么、为什么改讲清楚你review代码的时候就不需要在diff里一眼眼找它到底动了哪里。为什么特意加“ask ONE concise clarifying question”因为我实测下来不加这条的时候AI要么完全不问、按错误理解硬写要么一口气连问五个问题把对话节奏拖得很碎。限定只问一个最关键的问题能在“不耽误进度”和“避免跑偏”之间取得一个很实用的平衡。3.2 tech-stack.mdc让AI别在技术选型上自作主张--- description: Declares the tech stack and project constraints globs: * --- # Project tech stack - Language: TypeScript (strict mode) / Node.js 20 - Frontend framework: Next.js 15 (App Router) - UI: Tailwind CSS 4 shadcn/ui components - State management: Zustand (do NOT introduce Redux) - Data fetching: TanStack Query - Backend API: Next.js Route Handlers, REST style - Database: PostgreSQL Prisma ORM - Validation: Zod (do NOT add class-validator or joi) - Testing: Vitest React Testing Library - Package manager: pnpm. Never suggest npm or yarn commands. # Directory conventions - Reusable UI components stay in /src/components/ui/ - Feature-specific components live beside their feature, e.g. /src/features/cart/components/ - API route files live in /src/app/api/**/route.ts - Server-side logic must not be imported into client components directly # Critical constraints - Do NOT use any unless strictly necessary; prefer unknown with proper narrowing. - Do NOT create new files outside /src without explaining why. - Do NOT modify migrations unless explicitly asked — code should be compatible with existing schema.这是所有规则文件里价值密度最高的一个。AI模型本身的知识是通用的它知道一百种写法但不知道你这个项目选定了哪一百种里的哪一种。不告诉它“我们就是用Zustand、不要Redux”它极可能在某个场景里给出一个“技术上完全正确”的Redux方案然后你还得花时间解释为什么不这么写。写这段时有几个细节值得注意明确写“禁止引入什么”比“允许用什么”更重要。AI有很强的“用更流行方案”的倾向你只写允许列表拦不住它必须有显式的禁止项。目录约定要用“具体路径用途”的格式而不是笼统说“保持清晰目录结构”。AI需要的是可判定的规则不是审美建议。版本号最好写具体版本或主版本范围。AI的训练数据有滞后你不写版本它可能给你生成一个已经废弃的API用法。3.3 code-style.mdc让代码像是出自同一个人之手--- description: Enforced code style for this repository globs: **/*.{js,ts,jsx,tsx} --- - Use function declarations or arrow functions consistently. Do NOT mix unless there is a reason. - React components must be named with PascalCase. Hooks must be named with useXxx format. - Destructure props and state at the top of the component body. - Props interface naming: {ComponentName}Props. - Use as const for constant arrays/objects that need literal types. - Import order: builtin modules - external packages - internal modules - type-only imports. Separate groups by blank line. - Never use default export for components. Use named exports. - Prefer early returns for guard clauses. - Error handling: use try/catch, and NEVER swallow errors with empty catch block. Log or rethrow. - String literals: use single quotes unless the string contains single quotes or uses JSX attributes. Prefer template literals only for interpolation or multiline strings. - Always run pnpm lint after generating code; ensure zero lint errors.代码风格规则的本质是把团队代码评审时反复强调的那些“约定俗成”变成AI硬性约束。你能想象一个团队里每个成员写代码风格都不同会产生多少无意义的diff噪音吗AI在这方面比人类更需要约束——它每次生成的风格可能都不一样这周给的元素用箭头函数下周给的就变成了普通函数。这里要特别提一点风格规则不能凭感觉写最好直接从你项目现有的.eslintrc/ 代码里提取。最靠谱的做法是把lint配置里已经强制要求的规则翻译成自然语言AI在生成代码时就会与lint保持一致不然规则写着“用单引号”AI生成的全部是双引号你回头还得手动改。我后来学聪明了直接让AI“读取eslint配置并按此规范生成”比用自然语言描述来得更准确因为它读取规则文件后能精确遵守每一项约定。3.4 deliverable.mdc保证“交出来的东西能直接用”--- description: Defines what done looks like for AI-generated code globs: * --- - Before implementing, list the files you plan to create/modify and a one-sentence summary for each. Wait for confirmation if the plan involves creating new files. - For feature tasks: after writing code, run the type checker (pnpm typecheck) and fix all issues. - After completing the task, summarize the changes in under 150 words: what was changed, why, and what still needs human attention. - If a change cannot be verified locally, state that clearly, and suggest the exact command/way to verify. - Do NOT invent data or mock responses in a feature implementation without commenting that it is placeholder data. - If you need to use a new dependency, say so explicitly with justification, and wait for approval before adding it to package.json. - When fixing a bug, first explain what the root cause is, then give the fix, then describe how the fix addresses the root cause.这条文件的重点在最前面一句“列出计划、等确认”。你可能觉得这会拖慢速度实际上恰恰相反——让AI先花几十秒列计划确认后一把写完比让它闷头写完五六百行再发现方向错了要快十倍。这个习惯一开始需要你手动坚持等用熟了会成为条件反射。“dont invent data”这条尤其要划重点。Cursor对项目上下文的理解不完整时最爱干的事就是“按合理猜测给你虚构一个API返回结构”看起来有模有样跑起来才发现跟你后端定义的字段对不上。要求它“用注释标出placeholder”至少review时可以一眼看出来哪里需要补真数据。4. 让规则真正被AI读到上下文喂养与规则生效机制规则文件写好只是万里长征第一步。我的经验是很多人配置文件放了几天发现AI该怎么样还怎么样于是得出结论“这套规则没用”——其实问题不在规则内容而在规则根本没被AI读到。4.1 如何把规则“喂”进上下文先理解一件事Cursor在Agent模式下并不是每时每刻都把规则文件的全部内容塞进模型上下文里的而是先进行“规则匹配”再注入匹配到的那部分。所以配置规则的关键不只是“写得好”还包括“确保本次会话能命中它”。怎么提高命中率两个实操技巧。第一给规则文件的globs字段设置得足够准。.mdc文件支持 frontmatter 里的 globs 字段比如你把代码风格规则设置成globs: **/*.{ts,tsx}那么只有在你打开或提到 TypeScript 文件时这条规则才会被加载。反过来如果 globs 写成*它就是全局生效。所有规则都全局生效的结果是“看似什么都管实际每个都浅”因为上下文被撑满了。第二在对话开头主动点名要AI读取规则文件。这个动作至关重要尤其是在一次会话里涉及多个任务时。你不需要长篇大论直接说“先读一下 .cursor/rules/ 下的所有规则文件然后我们再聊这个需求”。这一句话会让Agent立刻去扫描规则目录并将内容纳入记忆比依赖自动匹配靠谱得多。我的习惯是每次新建会话后第一句永远是“Read the project rules in .cursor/rules/ and follow them strictly”。后面再贴具体需求。实测下来这句话的存在与否直接决定了AI对规则的遵守率——不是一个档次是好几倍的区别。4.2 用 .cursorignore 控制AI的“视野范围”除了写规则你还可以反向配置告诉AI“哪些东西不要看、不要动”。.cursorignore的语法沿袭 gitignore放在项目根目录。它解决的问题是Cursor在理解项目时会扫描大量文件而你的仓库里总有一堆无关紧要、或者看了反而误导AI的东西——比如node_modules、dist目录、lock文件、设计稿截图、文档草稿等。把这类文件排除掉有两个好处。第一是减少上下文的无关占用让AI把注意力放在真正重要的源码上。第二是避免AI从一些偏离事实的文档里“学到”错误信息——AI会读取仓库里的README、注释甚至过期设计稿来形成对项目的理解文件太杂就容易引入噪音。我常用的.cursorignore内容很简单node_modules/ dist/ build/ .next/ coverage/ *.lock .git/ .DS_Store *.log /tmp/ /docs/archive/其中/docs/archive/是我后来加的因为发现AI总是从旧设计文档里继承过期的命名约定加了这行之后清静了很多。5. 配置完后依然翻车的四类场景从根因到对策即使规则写得再完整也会遇到AI“有令不行”的时候。这里整理四个我反复踩过的场景每个都是真实经历先说现象再说根因最后给可执行的对策。5.1 场景一AI不报错但一直不改 —— “规则粘滞”现象你想让AI调整某个组件的写法它嘴上说“好的”给出来的代码还是老样子或者只有皮毛变化。根因分析多为规则与当前指令冲突且规则优先级执行“最近指令优先”。你说“按规则来”但具体任务描述里又带了一句半句相反的口头指令AI会倾向执行更具体的指令而不是抽象规则。对策把规则写进当前指令里不要只依赖远端的规则文件。比如想让AI把所有function改成箭头函数就在需求后面附加一句“这符合 .cursor/rules/code-style.mdc 中的约定”。如果你发现某条规则总被无视最有效的是把这条规则直接用大白话写进每一条相关指令里——虽然麻烦但这是最确定能生效的做法。5.2 场景二AI上下文“失忆”现象对话进行到第8轮AI突然忘了之前定下的约定把一个已经讨论过的问题又提出来甚至给出了跟前面一轮完全相反的回滚式答案。根因分析上下文窗口是有限的长对话后早期的规则与约定被“挤出”了有效上下文。不能说AI笨这是大模型的结构性限制。对策长任务拆短对话。一个功能需要多轮对话时不要在一整条长对话里反复改而是每完成一版新开一个会话把关键约定在第一句精简回顾一遍。我自己固定在每轮新会话开头写一行“项目规则和当前任务要求干、按照 code-style 约定、只改给定文件、完成后跑lint”。这样即使后边聊长了早前的核心约束也不会丢。5.3 场景三生成代码“技术过时”现象AI生成了一段在你看来“不太对但说不出哪不对”的代码查了下文档才发现某个API早就废弃了用了新方案而你自己也不知道新方案。根因分析模型训练数据有截止时间本地规则可以锁版本但无法弥补模型对“过期API”的认知。对策把关键依赖的版本和最佳用法明明白白写进规则文件。比如“Next.js 15 下不要再使用next/head而是用 metadata export”。这需要你对自己项目的技术栈有准确了解花30分钟把所有依赖的关键约定整理一遍收益非常可观。我在规则里写了“Prisma 5 中使用prisma.model.findUnique代替findOnepls dont use deprecated methods”这类版本陷阱就不会再犯。5.4 场景四AI修改了无关文件现象你只让它修一个 bug它却顺手把附近的几个文件格式化了、或者重构了一个函数git diff 变得面目全非。根因分析规则里写了“不要改无关文件”但AI判断什么是“相关”的标准比你宽松——它认为“顺手整理一下”是好事。对策这一步不能只靠规则约束要在操作层面堵死。我现在的做法是让AI一开始就说清楚要改哪些文件然后我直接用git status盯diff。如果AI动了规则外文件不等修复直接git checkout还原那些文件然后告诉它“只允许改刚才列出的文件其他一律不动”。做一两次之后AI在同一会话内就会变得收敛很多。这比任何规则文案都有力。6. 这套配置到底帮我省了多少事量化收益与长期习惯很多人关心的问题是这么一套规则配置下来到底值不值我的答案是前期一次大概半小时到一小时的投入换来的是后面每周末能多出半天属于自己可支配的时间。我从几个维度简单算笔账。往返沟通次数下降最明显。以前一个中等复杂度的功能从提需求到最终改完在对话里来回至少六到十轮其中至少三到四轮是在纠正方向性错误。配置规则后大部分对话压缩到三到四轮经常是一轮计划确认、一轮实现代码、一轮微调。这不只是省了“等AI生成”的时间更省的是你重新理思路的时间。无效代码产出显著减少。这里说的不是“总代码行数”而是“写完后被删除或被重写的代码比例”。没有规则时AI很容易感情发挥写出一堆你没要求但“它觉得有用”的封装、工具函数、扩展接口review下来基本删掉一半——相当于白干。有规则后它只做被要求的动作错误方向的比例明显下降。代码review的时间也被压缩了。之前review AI的diff你需要逐行看因为它可能在你不注意的地方偷偷改了逻辑。现在规则里强制它提供“改动文件清单改动原因摘要”我直接先看摘要再决定哪些diff需要细看效率至少提升一倍。这也间接给了我一个体会AI代码不是不能review省时间而是你要把“让它的变更可见、可控”这件事设计成流程而不是依赖人的运气。更隐性的一笔收益是团队其他人的体验也变好了。如果你的项目规则跟着仓库走其他协作者打开项目时也继承了这套约束至少不会出现“A用Cursor写出来的代码是A风格B用Cursor写出来又是B风格”的割裂感。Cursor本质上不是一个人的效率工具箱它也可以成为团队代码风格统一化的一部分——前提是规则以项目文件的形式沉淀下来而不是留在某一个人的“个人设置”里。最后说说长期习惯。我会建议你每个季度回头看一眼自己的规则文件把“这个季度里AI反复犯的错误”总结成新的规则条目把已经不再适用的规则删掉。规则不是一次配完就一劳永逸的它是你跟AI之间活的“共事协议”。我在第二季度往tech-stack.mdc里新增了一条“不要在API routes里直接用 Prisma client统一走 service 层”就是因为那段时间AI总是把数据库访问直接写在路由处理函数里代码闻起来就不对。这种高频踩坑点就是你规则文件里最该沉淀的内容。关于这套配置如果只记住三句话我想是规则要小而准不要大而全会话开头让AI显式读规则AI改动必须“可见、可控、可复盘”。做到这三条你不需要再用“会不会用AI”来区分开发效率因为工具本身已经变成了一套你可以不断调优的生产流程。