1. 为什么你的Cursor总感觉“差点意思”用了大半年Cursor从最初的新鲜感到中途的“也就那样”再到后来彻底离不开中间踩的坑真不少。刚开始我跟大多数人一样装完就用默认配置走天下结果就是它写它的我改我的AI补全的代码风格跟我项目里其他文件格格不入生成的函数命名一会儿驼峰一会儿下划线注释语言中英文随机切换最要命的是它老爱“自作主张”引入一些我根本没装的依赖。后来我才意识到Cursor跟普通编辑器最大的区别在于它是一个需要“调教”的工具。你给它的约束越清晰它给你的产出就越接近“直接能用”的状态。这套约束体系核心就是三个东西.cursorrules项目级规则、.cursor/rules/*.mdc模块级规则、.cursorignore上下文排除。把这三样配好配合一些界面和模型层面的设置才能真正做到“少写一半代码”。这篇文章适合两类人一是刚下载Cursor、还在纠结怎么设置中文回复和基础配置的新手二是用了一段时间但觉得AI产出质量不稳定、想系统性优化工作流的老用户。我会从整体设计思路讲起然后逐个拆解每个配置文件怎么写、为什么这么写再给出一套可以直接抄的完整方案最后分享一些排查问题的实战经验。全程不废话都是我自己项目里跑通的东西。2. 整体配置思路把Cursor当成一个新同事来带2.1 核心逻辑规则先行上下文其次模型最后很多人配置Cursor的顺序是反的先折腾模型选哪个、额度够不够用再去想规则的事。我的经验是规则体系才是第一优先级。原因很简单模型再强如果你不告诉它你的项目用什么框架、什么命名规范、什么目录结构它就只能靠猜。猜对了是运气猜错了你还得手动改改的时间比自己写还长。打个比方Cursor就像一个刚入职的高级工程师技术能力没问题但他不知道你们团队的代码规范、不知道你们封装了哪些工具函数、不知道哪些目录是自动生成的不能动。.cursorrules就是他的入职手册.cursor/rules/*.mdc是各个模块的详细文档.cursorignore是告诉他“这些文件你不用看看了反而干扰”。所以整体思路分三层第一层全局偏好设置。包括界面语言、自动补全触发方式、模型选择策略。这层解决的是“用得顺手”的问题。第二层项目级规则。.cursorrules放在项目根目录定义整个项目通用的技术栈、代码风格、禁止事项。这层解决的是“产出符合项目规范”的问题。第三层模块级规则与上下文控制。.cursor/rules/*.mdc针对特定目录或文件类型给出更细的规则.cursorignore排除无关文件。这层解决的是“AI理解得准不准”的问题。2.2 为什么不用全局User Rules搞定一切Cursor支持在设置里配全局的User Rules但我强烈建议项目相关的规则一定写在项目里。原因有三个第一不同项目的技术栈可能完全不同。你上午写React下午改Python脚本全局规则里写死了“使用函数式组件”下午的Python项目就会受干扰。项目级规则跟着代码走换项目自动切换。第二.cursorrules可以提交到Git仓库团队其他人拉下来就生效。全局规则只存在你本地换台电脑就没了也没法共享。第三项目级规则可以写得更具体。比如你可以写“API请求统一走src/utils/request.ts里的封装不要直接用fetch”这种规则只有放在具体项目里才有意义。2.3 配置的优先级关系这里有个容易搞混的点当全局规则、项目规则、模块规则同时存在时谁说了算根据我的实测越具体的规则优先级越高。也就是说.cursor/rules/下针对某个目录的.mdc文件会覆盖.cursorrules里的通用规则。而.cursorrules又会覆盖全局User Rules。这个优先级设计很合理因为它符合“就近原则”。但要注意覆盖不是完全替换而是叠加后以更具体的为准。所以你在写规则时通用规则里可以写宽松一些具体模块里再收紧。3. 核心配置文件逐个拆解3.1 .cursorrules项目根目录的“宪法”.cursorrules是一个放在项目根目录的纯文本文件Cursor在每次对话和补全时都会读取它。它的写法没有严格的语法要求就是自然语言描述但结构清晰与否直接影响AI的理解效果。我见过很多人把.cursorrules写成一大段流水账效果很差。我的建议是按模块分段写每段用简短的标题开头。下面是我在一个ReactTypeScript项目里实际在用的版本你可以直接参考结构# 项目技术栈 - React 18 TypeScript 5 Vite - 状态管理使用Zustand不要用Redux - 样式使用Tailwind CSS不要写单独的.css文件 - 路由使用react-router-dom v6 # 代码风格 - 组件一律使用函数式组件 hooks - 组件文件使用PascalCase命名工具函数使用camelCase - 所有导出使用命名导出不用default export - 类型定义优先使用interface联合类型用type # 目录约定 - 页面组件放在src/pages/下每个页面一个文件夹 - 通用组件放在src/components/下 - API请求封装在src/utils/request.ts不要直接使用fetch或axios - 类型定义放在src/types/下 # 禁止事项 - 不要引入lodash用原生方法或自己封装 - 不要使用any类型实在不确定用unknown - 不要写console.log调试用debugger或项目封装的logger - 不要修改src/generated/下的任何文件那是自动生成的 # 注释规范 - 注释使用中文 - 复杂逻辑必须写注释说明意图 - 函数注释使用JSDoc格式这份规则大概200字但信息密度很高。写的时候有几个要点技术栈要写版本号。React 18和React 17的写法有差异写清楚版本能避免AI用旧写法。TypeScript 5的一些新特性也值得注明。“不要用什么”比“要用什么”更重要。AI的训练数据里什么写法都有你不明确禁止它就可能给你混着来。比如不写“不要用Redux”它可能真的给你生成Redux的代码。目录约定要具体到文件路径。写“API请求要封装”太模糊写“封装在src/utils/request.ts”它才知道往哪找。注意.cursorrules不要写太长控制在500字以内。太长了AI反而抓不住重点而且每次请求都带上这些内容会消耗上下文窗口。把真正重要的规则放进去细节留给模块级规则。3.2 .cursor/rules/*.mdc模块级的“细则”.cursor/rules/目录是Cursor后来推出的更细粒度规则机制里面的文件用.mdc后缀。跟.cursorrules的区别在于.mdc文件可以指定生效范围比如只对某个目录生效或者只在特定类型的对话中生效。.mdc文件有一个简单的frontmatter格式用来声明元信息--- description: React组件开发规则 globs: src/components/**/*.tsx alwaysApply: false --- # 组件开发规范 - 每个组件必须定义Props接口命名为组件名Props - 事件处理函数使用handle开头如handleClick - 组件内部状态用useState跨组件状态用Zustand - 副作用统一用useEffect依赖数组必须完整这里的globs字段是关键它指定了这条规则对哪些文件生效。alwaysApply设为false表示只在编辑匹配文件时应用设为true则每次对话都带上。我一般会建这么几个.mdc文件react-components.mdc针对src/components/**管组件写法api-layer.mdc针对src/api/**和src/utils/request.ts管请求封装styles.mdc针对样式相关文件管Tailwind使用规范testing.mdc针对测试文件管测试写法这样拆分的好处是当我在写组件时只有组件相关的规则会被加载不会把API层的规则也塞进上下文既省token又减少干扰。3.3 .cursorignore给AI“划重点”.cursorignore的语法跟.gitignore一样用来告诉Cursor哪些文件不需要索引和读取。这个文件太重要了但很多人忽略了它。为什么重要因为Cursor在回答问题时会尝试从你的项目里找相关文件作为上下文。如果你的项目里有大量自动生成的文件、依赖包、构建产物它可能会把这些也读进去导致两个问题一是上下文被无关内容占满真正相关的代码反而没被读到二是AI可能被生成代码里的模式误导。我的.cursorignore通常包含这些# 依赖和构建产物 node_modules/ dist/ build/ .next/ out/ # 自动生成的文件 src/generated/ *.min.js *.bundle.js # 日志和缓存 *.log .cache/ .turbo/ # 环境配置含敏感信息 .env .env.local .env.*.local # 大型数据文件 *.csv *.sql public/data/ # 编辑器配置 .vscode/ .idea/配好之后Cursor的索引速度会明显变快回答的准确率也会提升。因为它不用在一堆无关文件里“大海捞针”了。提示.cursorignore不影响Git它只作用于Cursor的索引和上下文读取。所以不用担心加了之后代码提交出问题。3.4 界面与模型层面的设置除了文件配置Cursor的设置界面里也有几个关键项需要调整。语言设置。很多人搜“cursor怎么设置中文回复”其实Cursor的界面语言和AI回复语言是两回事。界面汉化可以在扩展市场装中文语言包操作跟VS Code一样。但AI回复的语言最可靠的方式是在.cursorrules里明确写“所有回复和注释使用中文”。我试过在设置里改locale效果不稳定还是写进规则里最靠谱。模型选择。Cursor支持切换不同的模型免费额度用完后需要订阅。我的策略是日常补全用默认的快速模型复杂重构和架构设计时手动切到更强的模型。不要所有场景都用最强模型一是额度消耗快二是简单任务用强模型反而慢。自动补全触发。默认是打字时自动触发但有时候会干扰思路。我习惯把触发延迟调高一点或者用快捷键手动触发。这个看个人习惯在设置里搜“autocomplete”就能找到相关选项。禁止自动更新。如果你搜过“cursor设置禁止更新”说明你也被自动更新坑过。更新后有时候规则会失效或者行为变化。在设置里关掉自动更新等社区反馈稳定了再手动更新能省不少事。4. 完整实操从零配一套能用的规则4.1 第一步初始化项目规则文件在项目根目录创建.cursorrules文件。如果你用的是Mac或Linux可以直接在终端操作touch .cursorrules mkdir -p .cursor/rules touch .cursorignoreWindows用户直接在文件管理器里新建就行。注意.cursor是个隐藏目录需要开启“显示隐藏文件”。4.2 第二步写一份适合自己项目的.cursorrules不要直接抄网上的模板因为每个项目技术栈不同。我的方法是打开项目里写得最好的那个文件看看它用了什么写法然后把这种写法提炼成规则。比如你项目里所有API请求都走一个封装函数那就在规则里写“所有网络请求必须使用src/utils/request.ts里的request方法”。如果你项目里组件都用命名导出就写“使用命名导出禁止default export”。写完之后做一次测试新建一个文件让Cursor生成一个简单组件看它是否遵守了规则。如果没遵守说明规则写得不够明确回去改。4.3 第三步配置模块级.mdc规则以React项目为例创建.cursor/rules/react-components.mdc--- description: React组件开发规范 globs: src/components/**/*.tsx,src/pages/**/*.tsx alwaysApply: false --- # 组件结构 - 先写类型定义再写组件 - Props接口命名为组件名Props - 使用解构赋值获取props # 状态管理 - 组件内部状态用useState - 跨组件共享状态用Zustandstore放在src/stores/ - 不要用useContext传全局状态 # 事件处理 - 事件处理函数以handle开头 - 避免在JSX里写内联箭头函数抽出来定义 # 样式 - 使用Tailwind类名不要写style对象 - 条件类名用clsx或cn工具函数再创建一个.cursor/rules/api-layer.mdc--- description: API请求层规范 globs: src/api/**/*.ts,src/utils/request.ts alwaysApply: false --- # 请求封装 - 所有请求走src/utils/request.ts的request方法 - 请求方法命名使用动词名词如getUserInfo、createOrder - 返回值类型必须显式声明 # 错误处理 - 请求错误统一在request方法里处理 - 业务层只处理成功逻辑 - 错误提示使用项目封装的toast组件4.4 第四步配置.cursorignore根据项目实际情况把不需要索引的目录和文件加进去。一个通用的起点node_modules/ dist/ build/ coverage/ *.log .env* .DS_Store然后根据项目特点补充。比如你项目里有大量JSON mock数据可以把mock/加进去如果有自动生成的API类型定义把那个目录加进去。4.5 第五步验证配置效果配置完成后做三个测试测试一新建组件。让Cursor生成一个带状态的React组件检查是否用了函数式组件、是否用了命名导出、注释是否是中文。测试二修改现有文件。打开一个现有组件让Cursor加一个功能看它是否遵循了现有的代码风格。测试三跨文件操作。让Cursor“在用户列表页面加一个搜索功能”看它是否能正确找到API封装、是否正确使用了状态管理。如果三个测试都通过说明配置基本到位。如果有问题针对性调整对应的规则文件。5. 常见问题与排查技巧实录5.1 AI不遵守规则怎么办这是最常见的问题。排查顺序如下首先确认规则文件的位置对不对。.cursorrules必须在项目根目录.cursor/rules/必须在根目录下的.cursor文件夹里。放错位置等于没放。其次确认规则写得够不够具体。“使用TypeScript”这种规则太宽泛AI可能忽略。改成“所有.ts和.tsx文件必须声明类型禁止使用any”就具体多了。再就是检查是否有冲突规则。如果.cursorrules里写“使用default export”而.mdc里写“使用命名导出”AI就懵了。确保各层规则一致。最后有些规则AI确实可能不遵守尤其是涉及复杂判断的。这时候可以在对话里直接提醒它比如“注意遵循项目规则使用命名导出”。多提醒几次它会在当前会话里记住。5.2 上下文不够用、回答变慢Cursor的上下文窗口是有限的。如果你项目很大索引的文件很多每次对话能用的上下文就少了。解决办法一是把.cursorignore配好排除无关文件。这是最有效的。二是对话时用符号精确指定文件而不是让AI自己去找。比如输入src/components/UserList.tsx 帮我加个分页比直接说“帮我给用户列表加分页”要准得多也省上下文。三是定期清理不需要的对话历史。Cursor的对话是累积的聊得越长上下文越满。开新对话解决新问题。5.3 中文回复时好时坏前面提过最可靠的方法是在.cursorrules里写死“所有回复使用中文”。如果还是偶尔冒英文可以在对话开头加一句“请用中文回复”。另外检查一下设置里的locale虽然它主要影响界面但有时候也会影响AI的默认语言。5.4 规则文件要不要提交到Git.cursorrules和.cursor/rules/建议提交这样团队共享。.cursorignore也建议提交统一索引范围。但如果你在规则里写了个人偏好比如“注释用中文”这种团队可能有人不喜欢的可以先跟团队商量。.cursor/目录下可能还有Cursor自己生成的缓存文件那些不需要提交。可以在.gitignore里加.cursor/cache/之类的排除项。5.5 常见问题速查表问题现象可能原因解决办法AI不遵守命名规范规则没写具体命名方式在.cursorrules里明确写“组件用PascalCase函数用camelCase”生成的代码引入未安装的依赖没写禁止事项在规则里列出项目实际使用的依赖禁止其他回答越来越慢上下文被无关文件占满完善.cursorignore用精确指定文件中文回复不稳定没在规则里强制.cursorrules首行写“所有回复使用中文”模块规则不生效globs路径写错检查globs是否匹配目标文件路径更新后规则失效自动更新导致行为变化关闭自动更新回退到稳定版本5.6 几个我踩过的坑坑一规则写太多。一开始我恨不得把所有规范都写进去结果AI反而抓不住重点。后来精简到只写最关键的十几条效果反而更好。规则不是越多越好是越准越好。坑二忽略.cursorignore。有段时间AI老是引用node_modules里的代码作为参考生成的代码风格很奇怪。后来把node_modules加进.cursorignore就正常了。坑三不同项目用同一套规则。我试过把React项目的规则复制到Vue项目里结果AI生成的Vue组件里混着React的写法。规则一定要跟项目走。坑四不测试就大规模用。配好规则后先在小范围测试确认没问题再全面使用。我有次改完规则直接让AI重构了一个大文件结果风格全乱了回滚花了不少时间。6. 进阶技巧让规则体系更聪明6.1 用规则文件做“代码模板”除了约束.cursorrules还可以用来定义代码模板。比如你项目里所有API模块都遵循同样的结构可以在规则里写# API模块模板 每个API模块文件结构如下 1. 导入request方法 2. 定义请求参数类型 3. 定义返回数据类型 4. 导出请求函数 示例 export interface GetUserParams { id: string } export interface GetUserResult { name: string; age: number } export const getUser (params: GetUserParams) requestGetUserResult(/api/user, params)这样AI生成新API模块时就会照着这个模板来省去你反复调整格式的时间。6.2 针对不同任务类型切换规则.mdc文件的frontmatter里除了globs还可以用alwaysApply控制是否每次都加载。我的做法是核心规范技术栈、禁止事项放.cursorrules里always生效具体模块的细则放.mdc里按需加载。这样既保证底线又不浪费上下文。6.3 定期回顾和更新规则项目在演进规则也要跟着变。我一般每个月回顾一次.cursorrules看看有没有过时的内容。比如项目从Redux换成了Zustand规则里就要相应更新。规则文件不是写完就不管了它应该跟代码一样被维护。6.4 团队协作时的规则管理如果是团队项目建议把规则文件的维护纳入代码评审流程。谁改了技术栈或代码规范就要同步更新规则文件。可以在PR模板里加一条检查项“是否更新了.cursorrules”。另外团队里可以指定一个人负责规则的最终审核避免多人同时改导致冲突。规则文件虽然简单但它是AI产出的“总开关”值得认真对待。7. 我个人的配置清单与日常习惯最后分享一下我目前稳定在用的配置组合以及一些日常使用习惯。文件清单.cursorrules约300字涵盖技术栈、代码风格、目录约定、禁止事项.cursor/rules/react-components.mdc组件开发细则.cursor/rules/api-layer.mdcAPI层规范.cursor/rules/testing.mdc测试文件规范.cursorignore排除node_modules、dist、.env、自动生成文件日常习惯新开对话时如果涉及具体文件一定用指定不让AI自己找复杂任务拆成小步骤一步步让AI做不要一次性让它改太多每次AI生成代码后快速扫一眼是否符合规则不符合就当场纠正每周花十分钟看看规则文件有没有需要更新的地方遇到AI反复犯同一个错误就把这条写进规则里这套配置跑下来我的感受是前期花一两个小时配置后期每天能省下大量调整代码的时间。AI产出的代码从“能跑但要改”变成了“基本能直接用”这才是“少写一半代码”的真正含义。不是AI替你写了一半而是它写的那一半你几乎不用返工。如果你刚开始用Cursor建议先从.cursorrules和.cursorignore这两个文件入手把最基本的约束建立起来。等你熟悉了再逐步加.mdc模块规则。不要一上来就追求完美配置先用起来在用的过程中慢慢调这样最实际。