1. 为什么你的代码编辑器总是“差点意思”用了大半年各类AI编程工具我最大的感受是工具本身的上限很高但大多数人的配置方式把它的下限拉得很低。你可能也遇到过这种情况——同一个AI编程助手在别人手里像开了挂自动补全精准、重构干净利落、生成的代码几乎不用改到了自己这儿补全出来的东西驴唇不对马嘴改一个函数它能给你顺带删掉三个引用气得想砸键盘。问题出在哪不在模型本身在于你给它的“规则”太少、太模糊。打个比方AI编程助手就像一个刚入职的实习生技术底子不错但完全不了解你们团队的代码规范、项目结构、命名习惯。你不告诉他“我们项目用4空格缩进、组件一律用函数式写法、API请求统一走封装好的request方法”他就只能按自己的理解来写出来的东西自然跟你的项目格格不入。这套“规则”在Cursor里叫Rules规则系统。它本质上是一组持久化的指令每次AI生成代码、回答问题、执行操作时都会自动加载相当于给AI装了一本“项目开发手册”。配置得好AI就像团队里干了三年的老员工写出来的代码直接能提交配置得不好它就是个不断制造返工的外包。这篇文章我会把Cursor规则配置这件事彻底讲透——从规则文件的结构、不同类型规则的适用场景到具体怎么写、写什么、怎么调优再到我踩过的坑和实测有效的模板。不管你是刚接触Cursor的新手还是已经用了一段时间但觉得“也就那样”的老用户看完都能直接抄作业把AI编程助手的效率真正拉满。2. Cursor规则系统的底层逻辑拆解2.1 规则到底是怎么生效的很多人以为规则就是“给AI的一段提示词”写完了事。实际上Cursor的规则系统有一套明确的加载机制理解这个机制才能写出真正有效的规则。Cursor的规则分为三个层级优先级从高到低规则类型存放位置作用范围适用场景项目规则项目根目录.cursor/rules/文件夹仅当前项目项目特有的技术栈、代码规范、目录结构用户规则全局配置中的User Rules所有项目个人编码偏好、通用习惯自动规则通过对话中引用或自动检测单次对话临时性的特定要求项目规则是核心。它存放在项目根目录的.cursor/rules/文件夹下每个规则是一个独立的.mdc文件注意不是.md是Cursor自定义的格式。这些文件会随项目一起提交到版本控制团队协作时所有人共享同一套规则保证AI生成的代码风格一致。用户规则是全局生效的适合放一些你个人在所有项目中都希望遵守的偏好比如“注释用中文”“变量命名用驼峰”“不要生成console.log调试语句”这类。自动规则则是在对话中临时指定的比如你突然说“这次帮我用递归实现”它就只在当前对话生效不会持久化。2.2 四种规则触发模式的区别这是很多人忽略的关键细节。每个.mdc规则文件头部可以配置触发模式决定了这条规则什么时候被加载Always始终加载每次AI交互都会带上这条规则。适合放最核心的、所有场景都适用的规范比如代码风格、命名约定。但注意Always规则太多会占用上下文窗口导致AI“记不住”后面的内容。Auto Attached自动附加当AI操作涉及特定文件类型或路径时自动加载。比如你配置了globs: [*.tsx]那么只有操作.tsx文件时这条规则才生效。这是最推荐的方式精准且不浪费上下文。Agent Requested代理请求AI在需要时主动请求加载。适合一些特定场景才用到的规则比如“数据库迁移规范”。Manual手动加载只有你在对话中用规则名显式引用时才加载。适合一些实验性的、不常用的规则。我实测下来最合理的配置策略是全局通用规范用Always技术栈相关规范用Auto Attached特殊场景用Manual。这样既保证核心规范始终生效又不会让上下文窗口被无关规则塞满。2.3 为什么规则比每次手动提示更有效有人会问我每次对话时手动打一段要求不就行了为什么要费劲写规则文件三个原因。第一一致性。手动提示每次措辞不同AI的理解也会有偏差而规则文件是固定的每次加载的内容完全一致。第二效率。你不可能每次让AI写代码都重新打一遍“用4空格缩进、组件用函数式、样式用tailwind”这些重复劳动交给规则自动完成。第三团队协同。规则文件可以提交到Git团队所有人共享新人入职拉下代码就自带一套AI行为规范不需要口口相传。说白了规则系统就是把“你脑子里的隐性知识”变成“AI能读懂的显性文档”。这件事做一次后面所有对话都受益。3. 手把手配置一套真正好用的规则3.1 规则文件的目录结构设计先看一个我实际在用的目录结构这是一个中型前端项目的配置.cursor/ ├── rules/ │ ├── 00-core.mdc # 核心规范Always加载 │ ├── 01-code-style.mdc # 代码风格Auto Attached │ ├── 02-react.mdc # React相关规范 │ ├── 03-api.mdc # API请求规范 │ ├── 04-testing.mdc # 测试规范Manual加载 │ └── 05-git.mdc # 提交信息规范文件名前面的数字是排序用的方便在编辑器里按顺序查看。每个文件只负责一个主题不要把所有内容塞进一个大文件——规则文件越聚焦AI的理解越准确。3.2 核心规则文件怎么写附完整模板以00-core.mdc为例这是最重要的一个文件我直接给出一份经过多次迭代的模板--- description: 项目核心开发规范所有代码生成必须遵守 globs: alwaysApply: true --- # 项目核心规范 ## 技术栈 - 框架React 18 TypeScript 5.x - 构建工具Vite - 样式方案Tailwind CSS CSS Modules复杂组件 - 状态管理Zustand - 请求库Axios已封装为统一request方法 - 路由React Router v6 ## 代码风格 - 缩进2个空格禁止使用Tab - 引号字符串统一用单引号JSX属性用双引号 - 分号语句末尾必须加分号 - 命名组件用PascalCase函数和变量用camelCase常量用UPPER_SNAKE_CASE - 文件命名组件文件用PascalCase.tsx工具函数用camelCase.ts ## 目录约定 - 组件放在 src/components/按功能分子目录 - 页面放在 src/pages/每个页面一个文件夹 - 工具函数放在 src/utils/按功能拆分文件 - 类型定义放在 src/types/全局类型统一导出 - API封装放在 src/api/每个模块一个文件 ## 禁止事项 - 禁止使用any类型必须定义明确类型 - 禁止在组件内直接写fetch/axios必须走封装好的request方法 - 禁止使用index作为列表key除非列表是静态的 - 禁止提交console.log调试用logger工具 - 禁止使用var统一用const/let这里有几个关键点值得展开说。frontmatter的配置。alwaysApply: true表示这条规则始终加载。globs留空表示不限制文件类型。description是给AI看的规则说明写清楚这条规则管什么AI在判断是否加载时会更准确。技术栈要写具体版本。不要只写“React”要写“React 18”。因为React 18和React 17的写法有差异比如并发特性、自动批处理AI知道版本才能生成匹配的代码。禁止事项比推荐事项更重要。AI天生倾向于“多写”你不明确禁止它就会生成一堆你不需要的东西。把项目里绝对不能出现的东西列清楚比列一堆“建议这样做”有效得多。3.3 技术栈专属规则的写法02-react.mdc这类技术栈规则重点是告诉AI“在这个项目里这类代码应该长什么样”。我给一个React组件的规则示例--- description: React组件开发规范 globs: [src/components/**/*.tsx, src/pages/**/*.tsx] alwaysApply: false --- # React组件规范 ## 组件定义 - 统一使用函数式组件 箭头函数 - Props必须定义interface命名格式为 组件名Props - 组件必须有明确的返回类型 React.ReactElement 或 JSX.Element ## 示例模板 tsx interface UserCardProps { user: User; onSelect: (id: string) void; } const UserCard ({ user, onSelect }: UserCardProps): JSX.Element { const handleClick useCallback(() { onSelect(user.id); }, [user.id, onSelect]); return ( div classNamerounded-lg p-4 shadow onClick{handleClick} h3 classNametext-lg font-medium{user.name}/h3 /div ); }; export default UserCard;Hooks使用规范自定义Hook统一以use开头放在src/hooks/目录useEffect依赖数组必须完整禁止用eslint-disable跳过复杂状态逻辑抽成自定义Hook不要堆在组件里禁止在循环、条件、嵌套函数中调用Hook性能优化列表渲染必须用React.memo包裹子组件回调函数用useCallback计算值用useMemo大列表使用虚拟滚动项目已集成react-window注意这里我直接给了一个**完整的组件模板**。这是最有效的写法——与其用文字描述“组件应该怎么写”不如直接给一个标准范例AI照着模仿的准确率远高于理解文字描述。 ### 3.4 用户全局规则的配置 项目规则之外我还建议配置一份用户全局规则放在Cursor设置的User Rules里。这份规则不随项目走但对你所有项目生效。我的全局规则大概长这样所有注释和文档用中文回答问题时先给结论再给解释代码修改时只改相关部分不要顺手重构无关代码生成代码后简要说明改了什么、为什么这么改遇到不确定的地方先问我而不是猜不要生成TODO注释要么实现要么明确告诉我需要我补充这几条看似简单但每一条都是我踩坑之后加的。比如“只改相关部分”这条——早期我没写让AI改一个bug它顺手把我整个文件的代码风格都“优化”了一遍diff一看几百行review起来想死。 ## 4. 让规则真正落地的实操技巧 ### 4.1 规则调试的完整流程 写完规则不是就完事了得验证它是否真的生效。我的调试流程是这样的 第一步**新建一个对话让AI生成一段代码**。比如“帮我写一个用户列表组件”。观察生成的代码是否符合规则——缩进对不对、命名对不对、有没有用禁止的东西。 第二步**如果不符合检查规则是否被加载**。在Cursor的对话面板里可以看到当前对话加载了哪些规则。如果规则没被加载检查frontmatter配置——alwaysApply是否为trueglobs是否匹配当前文件路径。 第三步**如果加载了但没遵守说明规则表述不够明确**。这时候要具体化。比如你写“代码要简洁”AI理解不了改成“函数不超过50行超过就拆分”AI就能执行。 第四步**迭代优化**。规则不是一次写完的是在使用中不断补充的。每次发现AI犯了同样的错误就把对应的禁止事项加进规则。用一两周规则就趋于完善了。 ### 4.2 规则冲突的处理策略 多个规则文件之间可能产生冲突。比如核心规则说“用单引号”某个技术栈规则说“用双引号”AI就懵了。 处理原则是**越具体的规则优先级越高**。核心规则管全局技术栈规则管特定文件如果冲突以技术栈规则为准。为了避免混乱我在核心规则里会加一句“如无特殊说明遵循本规则特定技术栈有特殊约定的以技术栈规则为准”。 另一个常见冲突是**规则与用户即时指令的冲突**。比如规则说“用函数式组件”但你这次说“帮我写个类组件”。这种情况下AI应该听你的即时指令。所以规则里最好加一句“用户明确要求与本规则冲突时以用户要求为准但需提醒用户这偏离了项目规范”。 ### 4.3 团队协作中的规则管理 如果是团队使用规则文件的管理有几个要点。 **规则文件必须进版本控制**。.cursor/rules/目录要提交到Git这样所有人拉下代码就自带规则。新人不需要问“我们项目AI怎么配置”拉代码就完事了。 **规则变更要走Code Review**。规则文件影响所有人的AI行为改规则相当于改团队开发规范应该像改代码一样review。我见过有人随手改了规则导致全团队的AI生成代码风格突变review时才发现。 **定期清理过时规则**。技术栈升级了、规范调整了对应的规则要及时更新。过时的规则比没有规则更糟糕因为它会让AI生成已经废弃的写法。 ### 4.4 规则效果的量化评估 怎么知道规则配置得好不好我一般看三个指标 | 指标 | 衡量方式 | 目标值 | |------|---------|--------| | 代码采纳率 | AI生成代码直接使用或小改即用的比例 | 70% | | 返工次数 | 同一功能需要AI重新生成的平均次数 | 2次 | | 风格一致性 | 生成代码与项目现有代码的风格差异 | 无明显差异 | 如果采纳率低于50%说明规则太模糊或缺失关键约束。如果返工次数超过3次说明规则里有AI理解不了的内容需要具体化。风格不一致则通常是规则没覆盖到某些场景。 我自己的项目在配置规则前代码采纳率大概40%左右配置并迭代两周后稳定在75%以上。这个提升是实打实的——每天少改一半代码一个月下来省的时间相当可观。 ## 5. 常见问题与避坑指南 ### 5.1 规则写了但AI不遵守怎么办 这是最高频的问题。排查顺序如下 先确认规则文件格式正确。.mdc文件的frontmatter必须用---包裹alwaysApply和globs的拼写不能错。我见过有人把alwaysApply写成always_apply规则一直不生效排查了半天。 再确认规则是否被加载。Cursor对话面板里能看到当前加载的规则列表如果规则不在列表里说明触发条件没满足。 如果规则加载了但不遵守大概率是**规则表述太抽象**。AI不是人它需要明确的、可执行的指令。“代码要优雅”这种话AI理解不了“函数不超过50行、嵌套不超过3层”它就能执行。把每一条规则都写成“如果X则Y”的形式遵守率会大幅提升。 还有一个容易被忽略的点**规则太多导致AI“注意力分散”**。如果你有20条Always规则AI可能只记住前几条。解决办法是把非核心规则改成Auto Attached或Manual减少Always规则的数量控制在5条以内。 ### 5.2 规则导致AI变得“死板”怎么破 规则太严格会走向另一个极端——AI变得死板稍微特殊一点的需求它都按规则硬套生成的代码虽然合规但不合适。 我的经验是**规则要留“例外通道”**。比如代码风格规则里加一句“特殊场景下可偏离规范但需在代码注释中说明原因”。这样AI在遇到规则不适用的场景时会主动说明而不是硬套。 另外**不要把规则写成绝对禁令**。比如“禁止使用any”改成“避免使用any如必须使用需注释说明原因”。给AI留一点判断空间它反而表现更好。 ### 5.3 不同项目之间规则怎么复用 如果你同时维护多个项目规则复用是个现实问题。我的做法是维护一份**基础规则模板**新项目直接复制过去然后根据项目技术栈调整。 基础模板包含那些所有项目通用的规范命名约定、注释规范、Git提交规范、代码审查要点。技术栈相关的规则则每个项目单独写。 Cursor目前不支持规则文件的跨项目继承所以复制粘贴是最实际的方式。我建了一个cursor-rules-template的仓库新项目初始化时直接拷贝省去重复劳动。 ### 5.4 规则与项目现有代码风格冲突 有时候规则写了一套风格但项目里已有的代码是另一套风格。这时候AI会困惑——按规则写还是按现有代码写 处理原则是**新代码按规则旧代码不动**。规则里明确写“新生成的代码遵循本规则修改现有代码时保持原有风格”。这样AI在改老文件时会模仿老文件的风格写新文件时用新规则不会造成风格混乱。 如果项目要做整体风格迁移那就先把规则定好然后让AI逐个文件迁移迁移完的文件自然符合新规则。 ### 5.5 规则配置的常见误区速查 | 误区 | 后果 | 正确做法 | |------|------|----------| | 所有规则都用Always | 上下文被占满AI记不住 | 核心用Always其余用Auto Attached | | 规则写得太抽象 | AI理解不了不遵守 | 写成具体可执行的指令 | | 规则文件太大 | AI只读前面部分 | 拆分成多个聚焦的小文件 | | 规则里全是“建议” | AI选择性忽略 | 明确区分“必须”和“建议” | | 规则写完不迭代 | 效果越来越差 | 每周review一次持续优化 | | 团队规则不共享 | 各人配置不同代码风格混乱 | 规则文件进Git统一管理 | ## 6. 进阶玩法让规则系统发挥更大价值 ### 6.1 用规则实现代码审查自动化 规则不仅能约束AI生成代码还能让AI帮你审查代码。我配置了一条Manual规则叫code-review.mdc内容是一份审查清单 markdown --- description: 代码审查清单审查代码时加载 alwaysApply: false --- # 代码审查要点 审查代码时按以下清单逐项检查 1. 类型安全是否有any、类型断言是否必要 2. 错误处理异步操作是否有try-catch边界情况是否处理 3. 性能是否有不必要的重渲染、是否有N1查询 4. 安全是否有XSS风险、敏感信息是否硬编码 5. 可维护性函数是否过长、命名是否清晰、是否有重复代码 6. 测试核心逻辑是否有测试覆盖 输出格式按严重程度分级阻塞/建议/提示每条给出具体位置和修改建议。需要审查代码时code-review引用这条规则AI就会按清单逐项检查。这比让AI“随便看看”有效得多因为它有了明确的检查框架。6.2 规则与项目文档的联动规则文件本身可以成为项目文档的一部分。我在规则里会引用项目的README、架构文档、API文档让AI在需要时去读这些文档获取更详细的上下文。比如API规则里写“详细的接口定义见docs/api.md生成API调用代码前先阅读该文档”。这样AI生成的请求代码就能和实际接口对齐不会出现字段名写错、参数遗漏的问题。6.3 针对不同任务类型的规则切换不同的开发任务需要不同的规则侧重。我配置了几套规则组合按任务类型切换写新功能加载核心规则 技术栈规则 测试规则修bug加载核心规则 调试规则强调最小改动、加日志、写复现步骤重构加载核心规则 重构规则强调保持行为不变、小步提交、充分测试写文档加载文档规则强调结构清晰、示例完整、面向读者这种按需加载的方式让AI在每个场景下都能获得最相关的约束而不是被一堆无关规则干扰。6.4 规则系统的持续演进规则系统不是配一次就完事的它应该随着项目演进持续更新。我的做法是每次Code Review发现AI生成的代码有共性问题就往规则里加一条。每次技术栈升级就更新对应的规则文件。每个季度做一次规则清理删掉过时的、合并重复的、补充缺失的。这样坚持下来规则系统会越来越贴合项目实际AI的表现也会越来越稳定。我现在的新项目基本配置好规则后AI生成的代码有八成以上能直接用剩下的两成也只需要小改。这个效率提升是单纯换模型或者调参数达不到的。说到底AI编程工具的能力上限取决于模型但你能用出多少取决于你给它的规则有多好。花一个下午把规则配好后面几个月都受益这笔账怎么算都划算。
1. 为什么你的代码编辑器总是“差点意思”用了大半年各类AI编程工具我最大的感受是工具本身的上限很高但大多数人的配置方式把它的下限拉得很低。你可能也遇到过这种情况——同一个AI编程助手在别人手里像开了挂自动补全精准、重构干净利落、生成的代码几乎不用改到了自己这儿补全出来的东西驴唇不对马嘴改一个函数它能给你顺带删掉三个引用气得想砸键盘。问题出在哪不在模型本身在于你给它的“规则”太少、太模糊。打个比方AI编程助手就像一个刚入职的实习生技术底子不错但完全不了解你们团队的代码规范、项目结构、命名习惯。你不告诉他“我们项目用4空格缩进、组件一律用函数式写法、API请求统一走封装好的request方法”他就只能按自己的理解来写出来的东西自然跟你的项目格格不入。这套“规则”在Cursor里叫Rules规则系统。它本质上是一组持久化的指令每次AI生成代码、回答问题、执行操作时都会自动加载相当于给AI装了一本“项目开发手册”。配置得好AI就像团队里干了三年的老员工写出来的代码直接能提交配置得不好它就是个不断制造返工的外包。这篇文章我会把Cursor规则配置这件事彻底讲透——从规则文件的结构、不同类型规则的适用场景到具体怎么写、写什么、怎么调优再到我踩过的坑和实测有效的模板。不管你是刚接触Cursor的新手还是已经用了一段时间但觉得“也就那样”的老用户看完都能直接抄作业把AI编程助手的效率真正拉满。2. Cursor规则系统的底层逻辑拆解2.1 规则到底是怎么生效的很多人以为规则就是“给AI的一段提示词”写完了事。实际上Cursor的规则系统有一套明确的加载机制理解这个机制才能写出真正有效的规则。Cursor的规则分为三个层级优先级从高到低规则类型存放位置作用范围适用场景项目规则项目根目录.cursor/rules/文件夹仅当前项目项目特有的技术栈、代码规范、目录结构用户规则全局配置中的User Rules所有项目个人编码偏好、通用习惯自动规则通过对话中引用或自动检测单次对话临时性的特定要求项目规则是核心。它存放在项目根目录的.cursor/rules/文件夹下每个规则是一个独立的.mdc文件注意不是.md是Cursor自定义的格式。这些文件会随项目一起提交到版本控制团队协作时所有人共享同一套规则保证AI生成的代码风格一致。用户规则是全局生效的适合放一些你个人在所有项目中都希望遵守的偏好比如“注释用中文”“变量命名用驼峰”“不要生成console.log调试语句”这类。自动规则则是在对话中临时指定的比如你突然说“这次帮我用递归实现”它就只在当前对话生效不会持久化。2.2 四种规则触发模式的区别这是很多人忽略的关键细节。每个.mdc规则文件头部可以配置触发模式决定了这条规则什么时候被加载Always始终加载每次AI交互都会带上这条规则。适合放最核心的、所有场景都适用的规范比如代码风格、命名约定。但注意Always规则太多会占用上下文窗口导致AI“记不住”后面的内容。Auto Attached自动附加当AI操作涉及特定文件类型或路径时自动加载。比如你配置了globs: [*.tsx]那么只有操作.tsx文件时这条规则才生效。这是最推荐的方式精准且不浪费上下文。Agent Requested代理请求AI在需要时主动请求加载。适合一些特定场景才用到的规则比如“数据库迁移规范”。Manual手动加载只有你在对话中用规则名显式引用时才加载。适合一些实验性的、不常用的规则。我实测下来最合理的配置策略是全局通用规范用Always技术栈相关规范用Auto Attached特殊场景用Manual。这样既保证核心规范始终生效又不会让上下文窗口被无关规则塞满。2.3 为什么规则比每次手动提示更有效有人会问我每次对话时手动打一段要求不就行了为什么要费劲写规则文件三个原因。第一一致性。手动提示每次措辞不同AI的理解也会有偏差而规则文件是固定的每次加载的内容完全一致。第二效率。你不可能每次让AI写代码都重新打一遍“用4空格缩进、组件用函数式、样式用tailwind”这些重复劳动交给规则自动完成。第三团队协同。规则文件可以提交到Git团队所有人共享新人入职拉下代码就自带一套AI行为规范不需要口口相传。说白了规则系统就是把“你脑子里的隐性知识”变成“AI能读懂的显性文档”。这件事做一次后面所有对话都受益。3. 手把手配置一套真正好用的规则3.1 规则文件的目录结构设计先看一个我实际在用的目录结构这是一个中型前端项目的配置.cursor/ ├── rules/ │ ├── 00-core.mdc # 核心规范Always加载 │ ├── 01-code-style.mdc # 代码风格Auto Attached │ ├── 02-react.mdc # React相关规范 │ ├── 03-api.mdc # API请求规范 │ ├── 04-testing.mdc # 测试规范Manual加载 │ └── 05-git.mdc # 提交信息规范文件名前面的数字是排序用的方便在编辑器里按顺序查看。每个文件只负责一个主题不要把所有内容塞进一个大文件——规则文件越聚焦AI的理解越准确。3.2 核心规则文件怎么写附完整模板以00-core.mdc为例这是最重要的一个文件我直接给出一份经过多次迭代的模板--- description: 项目核心开发规范所有代码生成必须遵守 globs: alwaysApply: true --- # 项目核心规范 ## 技术栈 - 框架React 18 TypeScript 5.x - 构建工具Vite - 样式方案Tailwind CSS CSS Modules复杂组件 - 状态管理Zustand - 请求库Axios已封装为统一request方法 - 路由React Router v6 ## 代码风格 - 缩进2个空格禁止使用Tab - 引号字符串统一用单引号JSX属性用双引号 - 分号语句末尾必须加分号 - 命名组件用PascalCase函数和变量用camelCase常量用UPPER_SNAKE_CASE - 文件命名组件文件用PascalCase.tsx工具函数用camelCase.ts ## 目录约定 - 组件放在 src/components/按功能分子目录 - 页面放在 src/pages/每个页面一个文件夹 - 工具函数放在 src/utils/按功能拆分文件 - 类型定义放在 src/types/全局类型统一导出 - API封装放在 src/api/每个模块一个文件 ## 禁止事项 - 禁止使用any类型必须定义明确类型 - 禁止在组件内直接写fetch/axios必须走封装好的request方法 - 禁止使用index作为列表key除非列表是静态的 - 禁止提交console.log调试用logger工具 - 禁止使用var统一用const/let这里有几个关键点值得展开说。frontmatter的配置。alwaysApply: true表示这条规则始终加载。globs留空表示不限制文件类型。description是给AI看的规则说明写清楚这条规则管什么AI在判断是否加载时会更准确。技术栈要写具体版本。不要只写“React”要写“React 18”。因为React 18和React 17的写法有差异比如并发特性、自动批处理AI知道版本才能生成匹配的代码。禁止事项比推荐事项更重要。AI天生倾向于“多写”你不明确禁止它就会生成一堆你不需要的东西。把项目里绝对不能出现的东西列清楚比列一堆“建议这样做”有效得多。3.3 技术栈专属规则的写法02-react.mdc这类技术栈规则重点是告诉AI“在这个项目里这类代码应该长什么样”。我给一个React组件的规则示例--- description: React组件开发规范 globs: [src/components/**/*.tsx, src/pages/**/*.tsx] alwaysApply: false --- # React组件规范 ## 组件定义 - 统一使用函数式组件 箭头函数 - Props必须定义interface命名格式为 组件名Props - 组件必须有明确的返回类型 React.ReactElement 或 JSX.Element ## 示例模板 tsx interface UserCardProps { user: User; onSelect: (id: string) void; } const UserCard ({ user, onSelect }: UserCardProps): JSX.Element { const handleClick useCallback(() { onSelect(user.id); }, [user.id, onSelect]); return ( div classNamerounded-lg p-4 shadow onClick{handleClick} h3 classNametext-lg font-medium{user.name}/h3 /div ); }; export default UserCard;Hooks使用规范自定义Hook统一以use开头放在src/hooks/目录useEffect依赖数组必须完整禁止用eslint-disable跳过复杂状态逻辑抽成自定义Hook不要堆在组件里禁止在循环、条件、嵌套函数中调用Hook性能优化列表渲染必须用React.memo包裹子组件回调函数用useCallback计算值用useMemo大列表使用虚拟滚动项目已集成react-window注意这里我直接给了一个**完整的组件模板**。这是最有效的写法——与其用文字描述“组件应该怎么写”不如直接给一个标准范例AI照着模仿的准确率远高于理解文字描述。 ### 3.4 用户全局规则的配置 项目规则之外我还建议配置一份用户全局规则放在Cursor设置的User Rules里。这份规则不随项目走但对你所有项目生效。我的全局规则大概长这样所有注释和文档用中文回答问题时先给结论再给解释代码修改时只改相关部分不要顺手重构无关代码生成代码后简要说明改了什么、为什么这么改遇到不确定的地方先问我而不是猜不要生成TODO注释要么实现要么明确告诉我需要我补充这几条看似简单但每一条都是我踩坑之后加的。比如“只改相关部分”这条——早期我没写让AI改一个bug它顺手把我整个文件的代码风格都“优化”了一遍diff一看几百行review起来想死。 ## 4. 让规则真正落地的实操技巧 ### 4.1 规则调试的完整流程 写完规则不是就完事了得验证它是否真的生效。我的调试流程是这样的 第一步**新建一个对话让AI生成一段代码**。比如“帮我写一个用户列表组件”。观察生成的代码是否符合规则——缩进对不对、命名对不对、有没有用禁止的东西。 第二步**如果不符合检查规则是否被加载**。在Cursor的对话面板里可以看到当前对话加载了哪些规则。如果规则没被加载检查frontmatter配置——alwaysApply是否为trueglobs是否匹配当前文件路径。 第三步**如果加载了但没遵守说明规则表述不够明确**。这时候要具体化。比如你写“代码要简洁”AI理解不了改成“函数不超过50行超过就拆分”AI就能执行。 第四步**迭代优化**。规则不是一次写完的是在使用中不断补充的。每次发现AI犯了同样的错误就把对应的禁止事项加进规则。用一两周规则就趋于完善了。 ### 4.2 规则冲突的处理策略 多个规则文件之间可能产生冲突。比如核心规则说“用单引号”某个技术栈规则说“用双引号”AI就懵了。 处理原则是**越具体的规则优先级越高**。核心规则管全局技术栈规则管特定文件如果冲突以技术栈规则为准。为了避免混乱我在核心规则里会加一句“如无特殊说明遵循本规则特定技术栈有特殊约定的以技术栈规则为准”。 另一个常见冲突是**规则与用户即时指令的冲突**。比如规则说“用函数式组件”但你这次说“帮我写个类组件”。这种情况下AI应该听你的即时指令。所以规则里最好加一句“用户明确要求与本规则冲突时以用户要求为准但需提醒用户这偏离了项目规范”。 ### 4.3 团队协作中的规则管理 如果是团队使用规则文件的管理有几个要点。 **规则文件必须进版本控制**。.cursor/rules/目录要提交到Git这样所有人拉下代码就自带规则。新人不需要问“我们项目AI怎么配置”拉代码就完事了。 **规则变更要走Code Review**。规则文件影响所有人的AI行为改规则相当于改团队开发规范应该像改代码一样review。我见过有人随手改了规则导致全团队的AI生成代码风格突变review时才发现。 **定期清理过时规则**。技术栈升级了、规范调整了对应的规则要及时更新。过时的规则比没有规则更糟糕因为它会让AI生成已经废弃的写法。 ### 4.4 规则效果的量化评估 怎么知道规则配置得好不好我一般看三个指标 | 指标 | 衡量方式 | 目标值 | |------|---------|--------| | 代码采纳率 | AI生成代码直接使用或小改即用的比例 | 70% | | 返工次数 | 同一功能需要AI重新生成的平均次数 | 2次 | | 风格一致性 | 生成代码与项目现有代码的风格差异 | 无明显差异 | 如果采纳率低于50%说明规则太模糊或缺失关键约束。如果返工次数超过3次说明规则里有AI理解不了的内容需要具体化。风格不一致则通常是规则没覆盖到某些场景。 我自己的项目在配置规则前代码采纳率大概40%左右配置并迭代两周后稳定在75%以上。这个提升是实打实的——每天少改一半代码一个月下来省的时间相当可观。 ## 5. 常见问题与避坑指南 ### 5.1 规则写了但AI不遵守怎么办 这是最高频的问题。排查顺序如下 先确认规则文件格式正确。.mdc文件的frontmatter必须用---包裹alwaysApply和globs的拼写不能错。我见过有人把alwaysApply写成always_apply规则一直不生效排查了半天。 再确认规则是否被加载。Cursor对话面板里能看到当前加载的规则列表如果规则不在列表里说明触发条件没满足。 如果规则加载了但不遵守大概率是**规则表述太抽象**。AI不是人它需要明确的、可执行的指令。“代码要优雅”这种话AI理解不了“函数不超过50行、嵌套不超过3层”它就能执行。把每一条规则都写成“如果X则Y”的形式遵守率会大幅提升。 还有一个容易被忽略的点**规则太多导致AI“注意力分散”**。如果你有20条Always规则AI可能只记住前几条。解决办法是把非核心规则改成Auto Attached或Manual减少Always规则的数量控制在5条以内。 ### 5.2 规则导致AI变得“死板”怎么破 规则太严格会走向另一个极端——AI变得死板稍微特殊一点的需求它都按规则硬套生成的代码虽然合规但不合适。 我的经验是**规则要留“例外通道”**。比如代码风格规则里加一句“特殊场景下可偏离规范但需在代码注释中说明原因”。这样AI在遇到规则不适用的场景时会主动说明而不是硬套。 另外**不要把规则写成绝对禁令**。比如“禁止使用any”改成“避免使用any如必须使用需注释说明原因”。给AI留一点判断空间它反而表现更好。 ### 5.3 不同项目之间规则怎么复用 如果你同时维护多个项目规则复用是个现实问题。我的做法是维护一份**基础规则模板**新项目直接复制过去然后根据项目技术栈调整。 基础模板包含那些所有项目通用的规范命名约定、注释规范、Git提交规范、代码审查要点。技术栈相关的规则则每个项目单独写。 Cursor目前不支持规则文件的跨项目继承所以复制粘贴是最实际的方式。我建了一个cursor-rules-template的仓库新项目初始化时直接拷贝省去重复劳动。 ### 5.4 规则与项目现有代码风格冲突 有时候规则写了一套风格但项目里已有的代码是另一套风格。这时候AI会困惑——按规则写还是按现有代码写 处理原则是**新代码按规则旧代码不动**。规则里明确写“新生成的代码遵循本规则修改现有代码时保持原有风格”。这样AI在改老文件时会模仿老文件的风格写新文件时用新规则不会造成风格混乱。 如果项目要做整体风格迁移那就先把规则定好然后让AI逐个文件迁移迁移完的文件自然符合新规则。 ### 5.5 规则配置的常见误区速查 | 误区 | 后果 | 正确做法 | |------|------|----------| | 所有规则都用Always | 上下文被占满AI记不住 | 核心用Always其余用Auto Attached | | 规则写得太抽象 | AI理解不了不遵守 | 写成具体可执行的指令 | | 规则文件太大 | AI只读前面部分 | 拆分成多个聚焦的小文件 | | 规则里全是“建议” | AI选择性忽略 | 明确区分“必须”和“建议” | | 规则写完不迭代 | 效果越来越差 | 每周review一次持续优化 | | 团队规则不共享 | 各人配置不同代码风格混乱 | 规则文件进Git统一管理 | ## 6. 进阶玩法让规则系统发挥更大价值 ### 6.1 用规则实现代码审查自动化 规则不仅能约束AI生成代码还能让AI帮你审查代码。我配置了一条Manual规则叫code-review.mdc内容是一份审查清单 markdown --- description: 代码审查清单审查代码时加载 alwaysApply: false --- # 代码审查要点 审查代码时按以下清单逐项检查 1. 类型安全是否有any、类型断言是否必要 2. 错误处理异步操作是否有try-catch边界情况是否处理 3. 性能是否有不必要的重渲染、是否有N1查询 4. 安全是否有XSS风险、敏感信息是否硬编码 5. 可维护性函数是否过长、命名是否清晰、是否有重复代码 6. 测试核心逻辑是否有测试覆盖 输出格式按严重程度分级阻塞/建议/提示每条给出具体位置和修改建议。需要审查代码时code-review引用这条规则AI就会按清单逐项检查。这比让AI“随便看看”有效得多因为它有了明确的检查框架。6.2 规则与项目文档的联动规则文件本身可以成为项目文档的一部分。我在规则里会引用项目的README、架构文档、API文档让AI在需要时去读这些文档获取更详细的上下文。比如API规则里写“详细的接口定义见docs/api.md生成API调用代码前先阅读该文档”。这样AI生成的请求代码就能和实际接口对齐不会出现字段名写错、参数遗漏的问题。6.3 针对不同任务类型的规则切换不同的开发任务需要不同的规则侧重。我配置了几套规则组合按任务类型切换写新功能加载核心规则 技术栈规则 测试规则修bug加载核心规则 调试规则强调最小改动、加日志、写复现步骤重构加载核心规则 重构规则强调保持行为不变、小步提交、充分测试写文档加载文档规则强调结构清晰、示例完整、面向读者这种按需加载的方式让AI在每个场景下都能获得最相关的约束而不是被一堆无关规则干扰。6.4 规则系统的持续演进规则系统不是配一次就完事的它应该随着项目演进持续更新。我的做法是每次Code Review发现AI生成的代码有共性问题就往规则里加一条。每次技术栈升级就更新对应的规则文件。每个季度做一次规则清理删掉过时的、合并重复的、补充缺失的。这样坚持下来规则系统会越来越贴合项目实际AI的表现也会越来越稳定。我现在的新项目基本配置好规则后AI生成的代码有八成以上能直接用剩下的两成也只需要小改。这个效率提升是单纯换模型或者调参数达不到的。说到底AI编程工具的能力上限取决于模型但你能用出多少取决于你给它的规则有多好。花一个下午把规则配好后面几个月都受益这笔账怎么算都划算。
