把Cursor当普通编辑器用的人其实只发挥了两三成功力。我从VS Code换到Cursor小半年一开始也就是贪图它的AI补全和对话窗口觉得比在编辑器里复制代码去问ChatGPT方便点。但真正让我决定回不去的是认真折腾了一轮配置之后——尤其是把规则Rules体系搭起来同样的需求我手敲的代码量少了一半都不止。这篇文章不聊虚的就讲清楚Cursor的规则到底怎么配、配在哪、写什么内容才能真正帮你省代码顺带把中文设置、注册手机号、响应慢这些日常配置问题一并解决掉。1. 先搞清楚Cursor的规则到底在解决什么问题很多人第一次听说Cursor规则第一反应是这跟提示词有什么区别区别非常大。提示词是你每次对话时临时说的一句话而规则是常驻上下文、每次请求都会被送进模型里的项目档案。它的意义不是让AI更聪明而是让AI更懂你的项目。1.1 不配规则的Cursor和配了规则的Cursor差别在哪先说我配规则前的真实体验。让Cursor帮我生成一个列表页组件它默认给的是class组件、div套div、样式写在style标签里、变量命名是全拼。我的实际项目是TypeScript 函数组件 Tailwind 短命名。基本每一次生成结果我都要手工改一遍结构改完之后再让它照这个风格改一下——本质上是在用对话来弥补项目上下文的缺失效率极低。配了规则之后同样的需求Cursor给出来的代码直接就是函数组件、Props带类型定义、Tailwind类名组织得很规范连注释风格都是项目里约定好的。我不需要再逐行调整格式只需要在它生成的骨架上填充业务逻辑。这个差距就是少写一半代码的直观来源。1.2 少写一半代码的底层逻辑上下文压缩与代码风格锁定再往深一层说规则为什么能有这么大的杠杆效应我觉得是两个机制在起作用。第一是上下文压缩。大模型的上下文窗口是有限的它不可能把你整个代码库读完。规则相当于你手动筛选出这个项目的关键信息以极小的token开销持续注入给模型。它不用花额度去逐个文件翻你的目录结构、猜你的技术栈这些你已经写成规则了。省下来的上下文空间AI就能更集中地用于推理业务逻辑而不是用来猜变量命名。第二是代码风格锁定。项目的代码风格是一种隐性知识人的团队靠code review维持AI原本无法感知。规则把这些隐性知识变成显性条目等于给了AI一份什么代码算合格的判卷标准。AI生成的初稿质量越高你需要返工的部分就越少自然就少写了。2. 规则的三个存放位置全局、项目、单文件各管一段Cursor的规则配置分三个层级很多人一上来就在项目根目录建了一个.cursorrules文件以为这就够了。实际上三个位置各有分工用对了才算真正把规则体系搭起来。2.1 全局规则Global Rules适合放什么全局规则在Cursor设置里入口是打开设置面板Ctrl/Cmd ,找到General Rules for AI或者直接用命令面板Ctrl/Cmd Shift P搜索 User Rules 打开编辑器。全局规则作用于你所有项目的所有会话所以只放那些跨项目都成立的通用偏好。我自己的全局规则就几条始终用中文回复代码注释统一用英文生成代码时优先使用项目已有依赖不要擅自引入新库修改代码时保留原有接口签名除非明确要求重构禁止输出与任务无关的解释性文字这几条几乎适用于任何一个代码项目。不建议把具体技术栈、目录结构这类东西放到全局规则里——不同项目的技术栈可能不同全局规则写死了反而干扰。2.2 项目规则.cursor/rules目录适合放什么项目级别的规则官方推荐的路径是项目根目录下的.cursor/rules/文件夹。每个规则文件以.mdc后缀命名支持在文件头部用frontmatter声明这个规则适用的文件范围glob这样同一个项目里可以针对前端、后端、配置文件分别写不同的规则。以我目前的一个React项目为例.cursor/ rules/ frontend.mdc backend.mdc database.mdc每个文件里有类似这样的元信息--- description: React TypeScript 前端开发规范 glob: **/*.{ts,tsx,css,scss} ---glob字段决定了这条规则在什么情况下会被启用。Cursor会监测当前编辑的文件命中对应glob时就自动把该文件规则注入上下文没命中的规则不生效。项目规则适合放技术栈、目录结构、命名约定、接口调用规范、错误处理要求这些项目特有信息。2.3 .cursorrules文件和规则的读取优先级.cursorrules是早期版本的单文件机制现在仍然兼容——你放在项目根目录的.cursorrules文件会被读取只是官方已经推荐用.cursor/rules目录替代因为目录形式支持分模块、分作用域比单文件更好维护。三个层级的优先级关系是这样的项目规则高于全局规则同属上层的规则按文件维度的匹配精细度决定优先程度——匹配范围更小的、更具体的规则优先于宽泛的规则。例如在frontend.mdc里写了所有组件Props必须显式声明类型全局规则里也写了代码类型要清晰两个规则如果表述上有冲突以命中文件更精确的frontend.mdc为准。配置位置作用范围适合放什么维护频率全局规则User Rules所有项目语言偏好、通用禁止项、回复风格低频.cursor/rules目录当前项目技术栈、目录结构、命名规范、接口约定中频.cursorrules单文件当前项目小项目的完整约束或临时规则低频提示如果你刚上手又不想建目录结构可以先用.cursorrules单文件试一个项目。等规则多了、项目复杂了再拆到.cursor/rules目录里。两个机制并存时有优先级差异建议小项目二选一避免同一套规则写在两个位置造成互相覆盖。3. 一套可以直接抄的规则配置模板接下来是全文最实操的部分。我给出自己目前在用的规则模板分前端和后端两个场景你照着抄把项目名和技术栈替换一下就能用。3.1 规则骨架角色定义 技术栈白名单 输出契约不管什么项目的规则文件我建议都包含四块内容角色定义让AI知道它在你这个项目里扮演什么角色技术栈白名单明确允许使用的框架、库和版本禁止引入的新依赖输出契约代码结构应该是什么样的函数怎么组织、变量怎么命名、样式怎么书写负面清单明确列出绝对不能出现的写法这四块的顺序也有讲究。角色定义放在最前面是为了让AI接入对话时就建立正确的行为取向然后再给具体约束。3.2 前端项目的规则写法示例这是我目前React项目里的frontend.mdc简化版核心结构可以直接套用--- description: React TypeScript 前端开发规范 glob: **/*.{ts,tsx,css,scss,html} --- 你是一名资深React前端工程师负责维护本项目的所有前端代码。 ## 技术栈 - 框架React 18使用函数组件和Hooks禁止使用class组件 - 语言TypeScript禁止使用any类型 - 样式Tailwind CSS按需使用class名禁止使用内联style - 状态管理Zustand禁止引入Redux - 数据请求使用项目封装的request工具禁止直接使用fetch/axios ## 组件写法 - 组件文件使用PascalCase命名工具函数使用camelCase命名 - Props必须显式声明interface禁止使用inline类型 - 组件内部按状态声明 - 事件处理 - 副作用 - 渲染的顺序组织代码 - JSX中禁止使用index作为key必须使用唯一业务标识 - 表单校验统一使用react-hook-form禁止手写校验逻辑 ## 负面清单 - 禁止内联样式style{{}}一律改为Tailwind类名 - 禁止magic number常量必须提取到constants目录并命名 - 禁止在组件内直接写超过50行的逻辑必须拆分为自定义Hooks - 禁止使用ESLint-disable注释来跳过规范检查 ## 示例参考 当要求生成一个列表组件时参考以下结构 - 组件接收items和onItemSelect两个Props - 渲染使用ul/li结构每个li包含标题、时间戳和操作按钮 - 空数据时渲染empty状态组件加载中时渲染骨架屏这段规则里每一行都对应一次实际踩坑。比如禁止使用内联style是因为我接手过一个遗留项目大量内联样式导致Tailwind的响应式类名完全无法覆盖最后只能全部重写。写进规则后Cursor就再也没生成过内联样式。3.3 后端/数据库项目的规则写法示例后端的规则逻辑稍有不同更侧重接口规范、错误处理和数据访问层约束。这里给一个Node.js Express项目的示例--- description: Node.js Express 后端开发规范 glob: **/*.ts --- 你是一名资深后端工程师专注于Node.js服务和API设计。 ## 技术栈 - 运行时Node.js 20TypeScript严格模式 - 框架Express 4禁止引入NestJS等重型框架 - 数据库Prisma ORM禁止使用原生SQL拼接 - 校验Zod所有请求参数必须经过schema校验 ## 接口设计 - RESTful路由资源名使用复数名词禁止动词命名接口 - 所有接口返回统一结构{ code, message, data } - 错误处理异步handler必须包裹try/catch错误统一交给全局错误中间件 - 分页参数统一为page和pageSize禁止自定义limit/offset命名 ## 文件组织 - 路由文件放在routes/目录业务逻辑放在services/目录 - 每个模块包含路由、控制器、服务、校验器四个文件职责分离 - 控制器禁止直接访问数据库必须经服务层调用 ## 负面清单 - 禁止在业务代码中console.log必须使用项目封装的logger - 禁止在循环中执行数据库查询批量操作必须使用Prisma批量API - 禁止返回原始的Prisma错误信息给前端必须转换为友好提示这个东西的价值在于它把你们团队代码评审时才会提到的标准提前注入给了AI。AI生成的路由、错误处理、文件划分从一开始就符合项目约定而不是生成完再让你逐项修正。3.4 让规则真正生效的写法细节负面清单和示例驱动模板给完了再强调两个让规则真正生效的关键细节。第一个是负面清单比正面要求更管用。大模型对禁止做X的执行力远高于请注重代码质量这类模糊表述。这可能是工程经验里最反直觉的一点——你把不要什么写清楚生成结果比要什么写一大堆更稳定。原因在于大模型的创作过程本质上是在概率分布里采样正面要求约束的是应该出现什么负面清单约束的是绝不能出现什么——后者能直接切断每次都会犯的重复性错误。第二个是示例驱动。给AI一段期望输出的代码骨架比用十行文字描述效果更好。模型从示例里能学到的不只是结构还有命名习惯、注释风格、边界处理的表达方式。所以在规则里保留一个示例参考区块每次发现Cursor生成结构不对时就把正确的结构补进这个区块。提示规则文件里不要写提升代码质量代码要优雅这类形容词。我在迭代规则的过程中发现这种话模型读了之后不会采取任何行动因为缺乏可操作的具体行为标准。规则里的每一条都必须是可以被代码检查工具验证的、可判定的表述。4. 直接影响日常体验的几项配置连同规则一起调规则是核心但Cusor更好用还离不开几个常规配置项的配合。很多人在热搜里问cursor怎么设置中文cursor响应速度慢这些问题不解决规则配得再好也影响心情。4.1 界面语言与回复语言中文设置的正确姿势Cursor中文设置是高频搜索词但大多数人是把两个概念混在一起的。界面语言Cursor的界面目前主要跟随系统语言并没有一个独立的language中文的经典设置项。如果你在设置里搜索Language发现选项不多那说明你的系统语言已经是中文环境。我之前在某次版本更新后界面变成英文排查下来是系统语言区域的设置变了改回中文后Cursor界面自动恢复。不同版本对界面语言的支持方式有过调整但总体方向和跟随系统是一致的。回复语言这个真正影响体验的其实是让AI用中文回答。在全局规则User Rules里明确写一句始终用中文回复用户代码注释和标识符保持英文即可。需要注意如果你用的是某些第三方模型或镜像服务它们对系统提示的遵循程度可能参差不齐最简单稳妥的方式就是在每个会话开头也补充一句请用中文回复双保险。4.2 模型选择、免费额度与速度之间的取舍很多刚开始用Cursor的人会发现同样的提示词不同模型生成质量差异巨大。我的选择思路是分场景的日常的小改动、补注释、写测试用快速模型就够了便宜且响应快涉及跨文件重构、复杂业务逻辑生成、性能优化这类高难度任务才切换高能力模型生成质量高、返工少反而更省时间和额度。免费额度方面新注册用户可以体验基础模型但用量有上限。如果是重度使用建议直接按官方订阅方案来——高频使用者按用量订阅比反复拿免费额度排队要省心得多至少不用在写到一半时被额度限制打断思路。配置规则能省额度的逻辑在这里体现得特别明显同样的任务规则完善后一次成型比反复对话修改消耗的token少得多。我配好规则之后月度用量下降了大约三分之一。4.3 响应慢或taking longer than expected时排查什么Cusor响应速度慢和cursor taking longer than expected是另一类高频问题。我总结了三个最常见的诱因。索引膨胀Cursor默认会索引你的工作区文件如果一个项目里有大量node_modules、dist目录未被忽略索引体积会很大拖慢每次请求的上下文组装。先在设置里把不必要的目录加入忽略列表。上下文过长一次对话里积累了太多历史消息意味着每次新请求都要带上大量旧信息模型要处理的内容变多响应自然慢。这时候新开一个会话把必要的上下文信息比如相关文件路径重新给一次速度会明显提升。代码库级别的检索耗时AI需要先检索相关文件再回答如果项目里的文件组织非常混乱检索效率就低。规则里写清楚目录结构能显著缩短这个环节——AI不用逐目录扫描直接从规则里知道相关代码在哪。我在实际使用中最常遇到的是第二条。有时候连续修改同一个文件的多个问题对话历史越积越长响应时间肉眼可见地从3秒涨到20秒以上。开新会话是立竿见影的办法。这里有一个小技巧新会话不一定非要从头描述需求直接在Chat输入框里用at语法引用规则里规定的相关文件和目录既能继承项目上下文又不用陪它重新读一遍漫长历史。5. 注册与账号的常见坑手机号与多设备同步配置和规则都做好了还有一类问题绕不开——账号相关的基础操作。热搜里cursor注册时手机号怎么填写热度很高说明不少人在第一步就被卡住了。5.1 手机号注册时怎么填写首先明确一点Cursor的注册目前支持国内手机号不需要额外处理。真正让很多人卡住的是填手机号时输不进号码或者输入后格式不对。我见过最多的情况是输入法自作主张。某些输入法在输入数字时会自动插入括号或空格来美化号码格式比如138 **** 1234。而注册表单的校验只接受纯数字一旦带了空格、括号或横杠提交就会报格式错误。有网友反映cursor注册手机号自动打括号问题根源就在这里。解决办法很简单在输入手机号前先把输入法的自动格式化或符号配对功能关掉如果已经输入了带格式的号码先清空再手动将十一位纯数字完整输入如果是粘贴确保粘贴的是纯文本而不是带格式的富文本。国家区号选择上选86即可不要自己手动输入区号也不要重复输入。5.2 账号切换与多设备同步注意Cursor的配置跨设备同步能力并不是万能的。登录同一账号后大部分设置会同步比如主题、模型偏好、全局规则。但.cursor/rules和.cursorrules这类项目级文件是保存在本地项目目录里的不会自动跨设备同步。这意味着如果你在家里和公司两台电脑上工作必须把rules文件纳入版本管理手动拉取或同步。我的做法是把.cursor/rules/连同项目一起提交到Git仓库。这样每次换电脑clone项目后规则是完整的。因为规则本质上和代码一样是项目资产理应接受版本管理。另外一个建议是如果要切换账号使用先检查当前对话是否涉及正在开发中的业务敏感信息——新账号没有历史上下文旧会话里的内容不会自动带过去但代码库索引和项目规则是共享的需要留意不要和他人共用账号提交工作内容。6. 规则是迭代出来的我的维护习惯最后聊聊规则本身的维护。很多人的误区是期待一份规则配完就一劳永逸实际上规则和代码一样需要持续迭代。我自己的维护习惯是三个原则。第一每条规则必须对应一次真实踩坑。我从不为了写规则而写规则。每次Cursor生成的代码让我不满意、需要手工大改时我会暂停一下问自己这个错误重新发生的原因是什么可不可以写成一条规则来避免可以的话当场补进规则文件。比如禁止使用index作为key就是一次列表渲染错乱问题之后写进去的。这样积累起来的规则每一条都有实战价值而不是拍脑袋的空话。第二规则跟着项目演进而更新。项目换了UI组件库、新增了状态管理方案、重构了目录结构这些变化都要求规则同步调整。我一般在做技术升级的当周花十分钟把规则文件过一遍删掉失效条目、补充新约束。规则文件如果长期不动反而说明它已经脱离项目实际了。第三规则文件定期做减法。规则越多token开销越大还会稀释关键条目的权重。我个人体会是一个项目的规则控制在20条以内最合适超过这个量模型对靠后条目的遵从度会明显下降。每季度做一次瘦身把已经内化为常识的条目删掉比如AI已经稳定生成正确格式不再需要显式要求保留真正需要持续提醒的。提示如果你用的是Cursor官方提供的Rules模板或网上拿来的别人规则务必先审查再使用。每个团队的技术栈、命名习惯、工程质量标准都不同别人的规则可能引入你项目里并不适用的约束。我之前试用过一份社区热门的高强度规则里面有一堆代码风格强制项结果生成的代码风格和团队代码review标准冲突最后还是要一条条删。规则这套东西真正有用的必须是从自己项目里长出来的。我现在的习惯是每开一个新项目第一件事不是写业务代码而是花半小时把.cursor/rules搭好再动手。这套规则会陪我走过整个项目周期期间不断补充修整。平心而论初始投入的半小时换回的是后期大量重复劳动时间的节省——从这个角度看少写一半代码真不是标题党的说法。你如果还没试过认真配置规则建议从下个项目开始先搭一个最小可用的规则文件运行一周再根据实际踩坑去扩充它。
Cursor规则配置实战：如何让人工智帮你少写一半代码
把Cursor当普通编辑器用的人其实只发挥了两三成功力。我从VS Code换到Cursor小半年一开始也就是贪图它的AI补全和对话窗口觉得比在编辑器里复制代码去问ChatGPT方便点。但真正让我决定回不去的是认真折腾了一轮配置之后——尤其是把规则Rules体系搭起来同样的需求我手敲的代码量少了一半都不止。这篇文章不聊虚的就讲清楚Cursor的规则到底怎么配、配在哪、写什么内容才能真正帮你省代码顺带把中文设置、注册手机号、响应慢这些日常配置问题一并解决掉。1. 先搞清楚Cursor的规则到底在解决什么问题很多人第一次听说Cursor规则第一反应是这跟提示词有什么区别区别非常大。提示词是你每次对话时临时说的一句话而规则是常驻上下文、每次请求都会被送进模型里的项目档案。它的意义不是让AI更聪明而是让AI更懂你的项目。1.1 不配规则的Cursor和配了规则的Cursor差别在哪先说我配规则前的真实体验。让Cursor帮我生成一个列表页组件它默认给的是class组件、div套div、样式写在style标签里、变量命名是全拼。我的实际项目是TypeScript 函数组件 Tailwind 短命名。基本每一次生成结果我都要手工改一遍结构改完之后再让它照这个风格改一下——本质上是在用对话来弥补项目上下文的缺失效率极低。配了规则之后同样的需求Cursor给出来的代码直接就是函数组件、Props带类型定义、Tailwind类名组织得很规范连注释风格都是项目里约定好的。我不需要再逐行调整格式只需要在它生成的骨架上填充业务逻辑。这个差距就是少写一半代码的直观来源。1.2 少写一半代码的底层逻辑上下文压缩与代码风格锁定再往深一层说规则为什么能有这么大的杠杆效应我觉得是两个机制在起作用。第一是上下文压缩。大模型的上下文窗口是有限的它不可能把你整个代码库读完。规则相当于你手动筛选出这个项目的关键信息以极小的token开销持续注入给模型。它不用花额度去逐个文件翻你的目录结构、猜你的技术栈这些你已经写成规则了。省下来的上下文空间AI就能更集中地用于推理业务逻辑而不是用来猜变量命名。第二是代码风格锁定。项目的代码风格是一种隐性知识人的团队靠code review维持AI原本无法感知。规则把这些隐性知识变成显性条目等于给了AI一份什么代码算合格的判卷标准。AI生成的初稿质量越高你需要返工的部分就越少自然就少写了。2. 规则的三个存放位置全局、项目、单文件各管一段Cursor的规则配置分三个层级很多人一上来就在项目根目录建了一个.cursorrules文件以为这就够了。实际上三个位置各有分工用对了才算真正把规则体系搭起来。2.1 全局规则Global Rules适合放什么全局规则在Cursor设置里入口是打开设置面板Ctrl/Cmd ,找到General Rules for AI或者直接用命令面板Ctrl/Cmd Shift P搜索 User Rules 打开编辑器。全局规则作用于你所有项目的所有会话所以只放那些跨项目都成立的通用偏好。我自己的全局规则就几条始终用中文回复代码注释统一用英文生成代码时优先使用项目已有依赖不要擅自引入新库修改代码时保留原有接口签名除非明确要求重构禁止输出与任务无关的解释性文字这几条几乎适用于任何一个代码项目。不建议把具体技术栈、目录结构这类东西放到全局规则里——不同项目的技术栈可能不同全局规则写死了反而干扰。2.2 项目规则.cursor/rules目录适合放什么项目级别的规则官方推荐的路径是项目根目录下的.cursor/rules/文件夹。每个规则文件以.mdc后缀命名支持在文件头部用frontmatter声明这个规则适用的文件范围glob这样同一个项目里可以针对前端、后端、配置文件分别写不同的规则。以我目前的一个React项目为例.cursor/ rules/ frontend.mdc backend.mdc database.mdc每个文件里有类似这样的元信息--- description: React TypeScript 前端开发规范 glob: **/*.{ts,tsx,css,scss} ---glob字段决定了这条规则在什么情况下会被启用。Cursor会监测当前编辑的文件命中对应glob时就自动把该文件规则注入上下文没命中的规则不生效。项目规则适合放技术栈、目录结构、命名约定、接口调用规范、错误处理要求这些项目特有信息。2.3 .cursorrules文件和规则的读取优先级.cursorrules是早期版本的单文件机制现在仍然兼容——你放在项目根目录的.cursorrules文件会被读取只是官方已经推荐用.cursor/rules目录替代因为目录形式支持分模块、分作用域比单文件更好维护。三个层级的优先级关系是这样的项目规则高于全局规则同属上层的规则按文件维度的匹配精细度决定优先程度——匹配范围更小的、更具体的规则优先于宽泛的规则。例如在frontend.mdc里写了所有组件Props必须显式声明类型全局规则里也写了代码类型要清晰两个规则如果表述上有冲突以命中文件更精确的frontend.mdc为准。配置位置作用范围适合放什么维护频率全局规则User Rules所有项目语言偏好、通用禁止项、回复风格低频.cursor/rules目录当前项目技术栈、目录结构、命名规范、接口约定中频.cursorrules单文件当前项目小项目的完整约束或临时规则低频提示如果你刚上手又不想建目录结构可以先用.cursorrules单文件试一个项目。等规则多了、项目复杂了再拆到.cursor/rules目录里。两个机制并存时有优先级差异建议小项目二选一避免同一套规则写在两个位置造成互相覆盖。3. 一套可以直接抄的规则配置模板接下来是全文最实操的部分。我给出自己目前在用的规则模板分前端和后端两个场景你照着抄把项目名和技术栈替换一下就能用。3.1 规则骨架角色定义 技术栈白名单 输出契约不管什么项目的规则文件我建议都包含四块内容角色定义让AI知道它在你这个项目里扮演什么角色技术栈白名单明确允许使用的框架、库和版本禁止引入的新依赖输出契约代码结构应该是什么样的函数怎么组织、变量怎么命名、样式怎么书写负面清单明确列出绝对不能出现的写法这四块的顺序也有讲究。角色定义放在最前面是为了让AI接入对话时就建立正确的行为取向然后再给具体约束。3.2 前端项目的规则写法示例这是我目前React项目里的frontend.mdc简化版核心结构可以直接套用--- description: React TypeScript 前端开发规范 glob: **/*.{ts,tsx,css,scss,html} --- 你是一名资深React前端工程师负责维护本项目的所有前端代码。 ## 技术栈 - 框架React 18使用函数组件和Hooks禁止使用class组件 - 语言TypeScript禁止使用any类型 - 样式Tailwind CSS按需使用class名禁止使用内联style - 状态管理Zustand禁止引入Redux - 数据请求使用项目封装的request工具禁止直接使用fetch/axios ## 组件写法 - 组件文件使用PascalCase命名工具函数使用camelCase命名 - Props必须显式声明interface禁止使用inline类型 - 组件内部按状态声明 - 事件处理 - 副作用 - 渲染的顺序组织代码 - JSX中禁止使用index作为key必须使用唯一业务标识 - 表单校验统一使用react-hook-form禁止手写校验逻辑 ## 负面清单 - 禁止内联样式style{{}}一律改为Tailwind类名 - 禁止magic number常量必须提取到constants目录并命名 - 禁止在组件内直接写超过50行的逻辑必须拆分为自定义Hooks - 禁止使用ESLint-disable注释来跳过规范检查 ## 示例参考 当要求生成一个列表组件时参考以下结构 - 组件接收items和onItemSelect两个Props - 渲染使用ul/li结构每个li包含标题、时间戳和操作按钮 - 空数据时渲染empty状态组件加载中时渲染骨架屏这段规则里每一行都对应一次实际踩坑。比如禁止使用内联style是因为我接手过一个遗留项目大量内联样式导致Tailwind的响应式类名完全无法覆盖最后只能全部重写。写进规则后Cursor就再也没生成过内联样式。3.3 后端/数据库项目的规则写法示例后端的规则逻辑稍有不同更侧重接口规范、错误处理和数据访问层约束。这里给一个Node.js Express项目的示例--- description: Node.js Express 后端开发规范 glob: **/*.ts --- 你是一名资深后端工程师专注于Node.js服务和API设计。 ## 技术栈 - 运行时Node.js 20TypeScript严格模式 - 框架Express 4禁止引入NestJS等重型框架 - 数据库Prisma ORM禁止使用原生SQL拼接 - 校验Zod所有请求参数必须经过schema校验 ## 接口设计 - RESTful路由资源名使用复数名词禁止动词命名接口 - 所有接口返回统一结构{ code, message, data } - 错误处理异步handler必须包裹try/catch错误统一交给全局错误中间件 - 分页参数统一为page和pageSize禁止自定义limit/offset命名 ## 文件组织 - 路由文件放在routes/目录业务逻辑放在services/目录 - 每个模块包含路由、控制器、服务、校验器四个文件职责分离 - 控制器禁止直接访问数据库必须经服务层调用 ## 负面清单 - 禁止在业务代码中console.log必须使用项目封装的logger - 禁止在循环中执行数据库查询批量操作必须使用Prisma批量API - 禁止返回原始的Prisma错误信息给前端必须转换为友好提示这个东西的价值在于它把你们团队代码评审时才会提到的标准提前注入给了AI。AI生成的路由、错误处理、文件划分从一开始就符合项目约定而不是生成完再让你逐项修正。3.4 让规则真正生效的写法细节负面清单和示例驱动模板给完了再强调两个让规则真正生效的关键细节。第一个是负面清单比正面要求更管用。大模型对禁止做X的执行力远高于请注重代码质量这类模糊表述。这可能是工程经验里最反直觉的一点——你把不要什么写清楚生成结果比要什么写一大堆更稳定。原因在于大模型的创作过程本质上是在概率分布里采样正面要求约束的是应该出现什么负面清单约束的是绝不能出现什么——后者能直接切断每次都会犯的重复性错误。第二个是示例驱动。给AI一段期望输出的代码骨架比用十行文字描述效果更好。模型从示例里能学到的不只是结构还有命名习惯、注释风格、边界处理的表达方式。所以在规则里保留一个示例参考区块每次发现Cursor生成结构不对时就把正确的结构补进这个区块。提示规则文件里不要写提升代码质量代码要优雅这类形容词。我在迭代规则的过程中发现这种话模型读了之后不会采取任何行动因为缺乏可操作的具体行为标准。规则里的每一条都必须是可以被代码检查工具验证的、可判定的表述。4. 直接影响日常体验的几项配置连同规则一起调规则是核心但Cusor更好用还离不开几个常规配置项的配合。很多人在热搜里问cursor怎么设置中文cursor响应速度慢这些问题不解决规则配得再好也影响心情。4.1 界面语言与回复语言中文设置的正确姿势Cursor中文设置是高频搜索词但大多数人是把两个概念混在一起的。界面语言Cursor的界面目前主要跟随系统语言并没有一个独立的language中文的经典设置项。如果你在设置里搜索Language发现选项不多那说明你的系统语言已经是中文环境。我之前在某次版本更新后界面变成英文排查下来是系统语言区域的设置变了改回中文后Cursor界面自动恢复。不同版本对界面语言的支持方式有过调整但总体方向和跟随系统是一致的。回复语言这个真正影响体验的其实是让AI用中文回答。在全局规则User Rules里明确写一句始终用中文回复用户代码注释和标识符保持英文即可。需要注意如果你用的是某些第三方模型或镜像服务它们对系统提示的遵循程度可能参差不齐最简单稳妥的方式就是在每个会话开头也补充一句请用中文回复双保险。4.2 模型选择、免费额度与速度之间的取舍很多刚开始用Cursor的人会发现同样的提示词不同模型生成质量差异巨大。我的选择思路是分场景的日常的小改动、补注释、写测试用快速模型就够了便宜且响应快涉及跨文件重构、复杂业务逻辑生成、性能优化这类高难度任务才切换高能力模型生成质量高、返工少反而更省时间和额度。免费额度方面新注册用户可以体验基础模型但用量有上限。如果是重度使用建议直接按官方订阅方案来——高频使用者按用量订阅比反复拿免费额度排队要省心得多至少不用在写到一半时被额度限制打断思路。配置规则能省额度的逻辑在这里体现得特别明显同样的任务规则完善后一次成型比反复对话修改消耗的token少得多。我配好规则之后月度用量下降了大约三分之一。4.3 响应慢或taking longer than expected时排查什么Cusor响应速度慢和cursor taking longer than expected是另一类高频问题。我总结了三个最常见的诱因。索引膨胀Cursor默认会索引你的工作区文件如果一个项目里有大量node_modules、dist目录未被忽略索引体积会很大拖慢每次请求的上下文组装。先在设置里把不必要的目录加入忽略列表。上下文过长一次对话里积累了太多历史消息意味着每次新请求都要带上大量旧信息模型要处理的内容变多响应自然慢。这时候新开一个会话把必要的上下文信息比如相关文件路径重新给一次速度会明显提升。代码库级别的检索耗时AI需要先检索相关文件再回答如果项目里的文件组织非常混乱检索效率就低。规则里写清楚目录结构能显著缩短这个环节——AI不用逐目录扫描直接从规则里知道相关代码在哪。我在实际使用中最常遇到的是第二条。有时候连续修改同一个文件的多个问题对话历史越积越长响应时间肉眼可见地从3秒涨到20秒以上。开新会话是立竿见影的办法。这里有一个小技巧新会话不一定非要从头描述需求直接在Chat输入框里用at语法引用规则里规定的相关文件和目录既能继承项目上下文又不用陪它重新读一遍漫长历史。5. 注册与账号的常见坑手机号与多设备同步配置和规则都做好了还有一类问题绕不开——账号相关的基础操作。热搜里cursor注册时手机号怎么填写热度很高说明不少人在第一步就被卡住了。5.1 手机号注册时怎么填写首先明确一点Cursor的注册目前支持国内手机号不需要额外处理。真正让很多人卡住的是填手机号时输不进号码或者输入后格式不对。我见过最多的情况是输入法自作主张。某些输入法在输入数字时会自动插入括号或空格来美化号码格式比如138 **** 1234。而注册表单的校验只接受纯数字一旦带了空格、括号或横杠提交就会报格式错误。有网友反映cursor注册手机号自动打括号问题根源就在这里。解决办法很简单在输入手机号前先把输入法的自动格式化或符号配对功能关掉如果已经输入了带格式的号码先清空再手动将十一位纯数字完整输入如果是粘贴确保粘贴的是纯文本而不是带格式的富文本。国家区号选择上选86即可不要自己手动输入区号也不要重复输入。5.2 账号切换与多设备同步注意Cursor的配置跨设备同步能力并不是万能的。登录同一账号后大部分设置会同步比如主题、模型偏好、全局规则。但.cursor/rules和.cursorrules这类项目级文件是保存在本地项目目录里的不会自动跨设备同步。这意味着如果你在家里和公司两台电脑上工作必须把rules文件纳入版本管理手动拉取或同步。我的做法是把.cursor/rules/连同项目一起提交到Git仓库。这样每次换电脑clone项目后规则是完整的。因为规则本质上和代码一样是项目资产理应接受版本管理。另外一个建议是如果要切换账号使用先检查当前对话是否涉及正在开发中的业务敏感信息——新账号没有历史上下文旧会话里的内容不会自动带过去但代码库索引和项目规则是共享的需要留意不要和他人共用账号提交工作内容。6. 规则是迭代出来的我的维护习惯最后聊聊规则本身的维护。很多人的误区是期待一份规则配完就一劳永逸实际上规则和代码一样需要持续迭代。我自己的维护习惯是三个原则。第一每条规则必须对应一次真实踩坑。我从不为了写规则而写规则。每次Cursor生成的代码让我不满意、需要手工大改时我会暂停一下问自己这个错误重新发生的原因是什么可不可以写成一条规则来避免可以的话当场补进规则文件。比如禁止使用index作为key就是一次列表渲染错乱问题之后写进去的。这样积累起来的规则每一条都有实战价值而不是拍脑袋的空话。第二规则跟着项目演进而更新。项目换了UI组件库、新增了状态管理方案、重构了目录结构这些变化都要求规则同步调整。我一般在做技术升级的当周花十分钟把规则文件过一遍删掉失效条目、补充新约束。规则文件如果长期不动反而说明它已经脱离项目实际了。第三规则文件定期做减法。规则越多token开销越大还会稀释关键条目的权重。我个人体会是一个项目的规则控制在20条以内最合适超过这个量模型对靠后条目的遵从度会明显下降。每季度做一次瘦身把已经内化为常识的条目删掉比如AI已经稳定生成正确格式不再需要显式要求保留真正需要持续提醒的。提示如果你用的是Cursor官方提供的Rules模板或网上拿来的别人规则务必先审查再使用。每个团队的技术栈、命名习惯、工程质量标准都不同别人的规则可能引入你项目里并不适用的约束。我之前试用过一份社区热门的高强度规则里面有一堆代码风格强制项结果生成的代码风格和团队代码review标准冲突最后还是要一条条删。规则这套东西真正有用的必须是从自己项目里长出来的。我现在的习惯是每开一个新项目第一件事不是写业务代码而是花半小时把.cursor/rules搭好再动手。这套规则会陪我走过整个项目周期期间不断补充修整。平心而论初始投入的半小时换回的是后期大量重复劳动时间的节省——从这个角度看少写一半代码真不是标题党的说法。你如果还没试过认真配置规则建议从下个项目开始先搭一个最小可用的规则文件运行一周再根据实际踩坑去扩充它。