很多人用Cursor其实还停留在“把聊天框当百度用”的阶段——问一句答一句代码能用就复制走。真正让Cursor脱胎换骨的是另外三样东西注记、Rules、Skills。这三个词单独拆开都不难理解但把它们组合到位才算是把Cursor从“会写代码的插件”升级成“真正懂你这个项目的协作者”。今天不聊基础操作聊进阶。这篇文章会逐一拆解注记的引用链路、Rules的规则体系、Skills的技能封装再给一套可以直接抄的组合打法。适合已经用Cursor写过一段时间代码、但总觉得AI“不够听话”或“记不住项目规范”的人。看完你会发现过去那些“AI写得不对”“AI又改了我不让它改的东西”的烦恼大部分根本不用忍。1. 为什么是这三件套注记、Rules、Skills的分工逻辑1.1 三个功能各管一段上下文、约束、流程先说个我常用的类比。你把AI想象成一个新来的程序员工位已经给他准备好了。注记是“递材料”。你不是跟他说“帮我改一下登录页”而是把登录页对应的文件、依赖的组件、后端接口文档直接甩到他桌上。AI看到的就不再是想象里的登录页而是你项目里真实的登录页。Rules是“员工手册”。里面写清楚这个团队怎么命名变量、怎么处理错误、用什么状态管理库、代码提交前要过哪些检查。AI每次干活前先翻这本手册产出的代码天然贴合你的团队规范。Skills是“标准作业流程”。比如“新增一个API端点”这件事在你们项目里是有固定套路的建路由、加校验、写服务层、补Swagger注释、跑测试。Skill就是把这套动作固化成一份可执行的清单AI按部就班走完不会漏步骤。这三件事的分工极其清晰上下文靠注记供给行为边界靠Rules框定重复任务靠Skills自动化。三者合起来才是一个完整的“AI协作系统”。1.2 为什么这是“进阶”的分水岭大部分用户只用到了Cursor最浅的一层对话窗口里描述需求AI生成代码。这层用法的问题是AI每一次回答都是“从零开始”的——它不知道你的项目结构、不知道你的编码习惯、也不知道“上一次已经处理过这个问题”。进阶用法和基础用法的差异本质上是一个公式AI产出质量 模型能力 上下文质量 约束清晰度 执行流程完整度这四项里模型能力是Cursor定死的你没法改但后面三项恰好就是注记、Rules、Skills分别补上的。当你的上下文更精确、约束更明确、流程更完整时AI的产出会从“能跑”跃迁到“不用改就能合进主干”这个差距是肉眼可见的。1.3 这套玩法不是Cursor独有但Cursor把它做进了编辑器Claude Code里有SkillsCodex里也有类似的文件分组和指令机制。但Cursor的优势在于这些东西不是命令行里的一次性配置而是长在编辑器里的日常交互。你在写代码时随手一个文件、在项目目录里放一份规则后续所有AI交互都会自动带上这些信息不需要来回切换工具。而且更重要的是Cursor正在兼容社区里通用的Skills格式。这意味着你从Claude Code或Codex社区里淘来的优秀技能包很多可以直接拿过来用不用重写。这一点后面第2章会专门展开。2. 核心细节与实操要点拆解2.1 注记把“AI猜”变成“AI看”注记At Mentions是Cursor里操作成本最低、但提升效果最明显的功能。在对话输入框里输入会弹出当前项目的文件、文件夹列表以及一系列快捷引用项。选中的内容会作为上下文附加到你的提问里。实战中我主要用这么几种按使用频率排引用方式解决的问题使用建议File文件针对单个文件提问、修改改bug、重构单文件时必用Folder文件夹让AI理解一个模块的完整结构跨文件改动、新增功能时优先Codebase代码库让AI检索整个仓库适合“这个项目里XXX是怎么实现的”这类问题Docs文档引入第三方库官方文档用不熟悉的库、查API时非常香Web网页检索最新网络信息库版本迭代快、文档过期时用Git代码变更查看提交记录、Diff复盘线上问题、写commit message时用先说Codebase。很多人一上来就喜欢用这个因为它看起来最“AI”。但我实测下来它是最容易被滥用的——Codebase会触发一次跨全仓库的向量检索耗时几秒到几十秒消耗的token也不小。如果你的问题其实只涉及某一个模块直接用Folder把它按进去精度更高、速度更快。我的习惯是小改动用File模块级改动用Folder只有完全不确定代码在哪的时候才用Codebase。再说Docs。这个是隐藏神器。Cursor里可以提前配置一批文档源Settings - Docs把项目依赖的框架、组件库、后端API文档都挂上去。之后在对话里Docs就能直接引用。我见过很多人在用三方库时让AI“猜”参数配置AI一本正经地编了一堆不存在的API最后全踩坑。挂上官方文档之后这种情况基本绝迹。使用注记有个容易忽略的坑如果选中了多个文件AI会把它们当作并列上下文但不会自动理解文件之间的依赖关系。比如你同时了一个组件文件和一个工具函数文件最好在提问里补充一句“这个组件使用了utils里的xxx函数请注意两者的类型关系”。不然AI可能忽略你给的部分上下文自己另起炉灶。2.2 Rules让AI遵守“这个项目自己的规矩”Rules在Cursor里承担的是“长期记忆行为约束”的角色而且和注记不一样Rules不需要每次对话都手动带上——它是自动生效的。先说存放位置。目前Cursor里有两类规则Project Rules项目级放在项目根目录下的.cursor/rules/文件夹里支持.mdc格式。这是官方推荐的方式。User Rules全局级在Cursor的设置里配置对所有项目生效。适合放你自己的通用偏好比如“回答用中文”“代码里不要用console.log”。老版本还有一个.cursorrules文件放在项目根目录的玩法现在官方建议往.cursor/rules/迁移。如果你的项目里同时存在.cursorrules和.cursor/rules/新规则优先但为了长远考虑我建议都统一到.cursor/rules/里。.mdc文件有一个很核心的机制frontmatter glob匹配。文件头部用两段---包起来的信息叫frontmatter里面可以写description和globs。globs是用来控制这条规则作用于哪些文件的。比如--- description: 所有 TS 组件文件必须遵守的规范 globs: src/**/*.tsx, src/**/*.ts --- - 组件命名必须使用 PascalCase - 禁止使用 any 类型 - 组件必须有明确的 props 接口定义 - 文件末尾留一个空行这个机制的意义非常大。你可以把规则拆成好几份文件一份管TS类型、一份管React组件、一份管样式写法。Cursor会根据当前对话涉及的文件路径自动匹配合适的规则注入。规则太多太杂反而会稀释AI的注意力拆开按需生效才是正道。再强调一遍规则要写“要什么”而不是“不要什么”。AI对负面指令的理解和执行远不如正面指令稳定。你说“不要用any”它可能还是会偶尔漏但你说“所有类型必须显式定义禁止隐式推断为any”执行率会高很多。2.3 Skills把“问一句答一句”变成“交给AI执行”Skills是三者里最新、也最被低估的能力。通俗理解它就是把一条完整的任务流程打包成一个“技能包”。AI识别到你的需求匹配某个技能后会自动加载这个技能的步骤说明、代码模板、注意事项然后一步步执行。Cursor的Skills目录结构一般长这样.cursor/ ├── skills/ │ ├── create-api/ │ │ ├── SKILL.md │ │ └── templates/ │ │ └── api-handler.template.ts │ └── review-code/ │ └── SKILL.md每个技能文件夹里至少要有一个SKILL.md文件它是技能的“说明书”。文件头部同样有frontmatter包含name、description、allowed-tools等字段。真正重要的是description——Cursor会读取它来决定“什么情况下自动触发这个技能”。写清楚触发场景技能才会被精准命中。下面是一个简化的SKILL.md示例--- name: create-react-component description: 当用户要求创建新的 React 组件时使用。适合带有 props 接口、样式文件和默认导出的组件创建流程。 allowed-tools: write, read, edit --- 1. 读取项目根目录下的 components 目录理解现有组件的文件组织方式 2. 根据用户提供的组件名创建同名文件夹 3. 新建 index.tsx导出组件主体新建 types.ts定义 Props 接口 4. 样式文件使用项目已有的 CSS 方案默认 CSS Modules 5. 创建完成后检查是否存在同名 .stories.tsx 规范若有则补充 Storybook 文件你看这个Skill把“创建React组件”这件原本需要AI自由发挥的事编码成了一个流程。AI不会再问你“要不要单独建文件夹”而是照着流程走完。Skills与Rules、注记最大的区别也在这里Rules告诉你“什么能做、什么不能做”它是静态的Skills告诉你“这件事具体分几步做”它是动态的、流程化的。而当Skill里要读取具体文件时它内部仍然会用到注记的底层能力这三者不是替代关系是嵌套关系。另外提一个非常实用的事Claude Code和Codex的Skills目录结构和Cursor高度相似。我试过直接把Claude Code社区的某个代码审查Skill放进.cursor/skills/稍微改一下frontmatter的字段名就能跑起来。这意味着你不用从零开始造轮子去社区里找那几个星标高的skills仓库下载后做微调就能用。3. 实操从0到1搭一套“规则技能”组合3.1 场景设计我以一个实际项目为例——React TypeScript Vite的B端管理后台团队风格比较偏保守组件全用函数组件、样式用CSS Modules、类名遵循BEM、数据请求封装在独立的hooks/useRequest.ts里。过去让AI直接写代码经常写出带class组件、样式内联、没有复用useRequest的东西。现在我要做三件事在项目里配置一套Rules告诉AI我们团队到底怎么“说话”。写一个封装新页面的Skill把从“创建组件”到“接入路由”再到“联调接口”的标准流程固化下来。用一个实际对话演示“注记 Rules Skills”三者怎么共同干活。3.2 第一步配置项目级Rules在项目根目录创建.cursor/rules/放两份文件。第一份frontend-rules.mdc管理通用的前端风格--- description: 前端代码通用规范适用于所有 TS/TSX 文件 globs: src/**/*.{ts,tsx} --- 1. 函数组件为主禁止使用 class 组件 2. 样式必须使用 CSS Modules禁止使用内联 style 属性 3. 类名采用 BEM 命名规范block__element--modifier 4. 数据请求统一走 src/hooks/useRequest.ts 封装禁止直接在组件内 fetch 5. TypeScript 类型定义放在与组件同级的 types.ts 文件中 6. 组件默认导出必须使用 export default具名导出仅用于工具函数第二份page-creation.mdc专门约束页面创建流程--- description: 新建页面时需要遵守的目录规范 globs: src/pages/**/* --- 1. 每个页面目录下必须包含 index.tsx、types.ts、styles.module.css 三个文件 2. 页面级状态管理使用 zustand禁止使用 redux 3. 新页面必须在 src/router/routes.ts 中手动注册路由 4. 页面文案统一放在 src/locales/zh-CN.ts 中禁止硬编码中文文本这两份Rule生效后AI生成代码就强制被拉回团队的既定轨道上。我实测下来最明显的改善是以前AI喜欢把所有样式怼在style{{}}里现在自动生成styles.module.css类名也老老实实按BEM走。3.3 第二步编写页面生成的Skill在.cursor/skills/create-page/下创建SKILL.md--- name: create-page description: 创建后台管理系统的页面。当用户要求新增页面、新建业务模块或创建CRUD界面时使用。触发关键词包括“创建页面”、“新增模块”、“做一个列表页”等。 allowed-tools: read, write, edit, grep --- # 页面创建流程 ## 1. 环境确认 - 读取 src/pages 目录确认现有页面结构 - 读取 src/router/routes.ts理解路由注册方式 ## 2. 创建页面骨架 - 在 src/pages/新建页面名/ 下创建 index.tsx、types.ts、styles.module.css - index.tsx 中导出默认组件组件名使用 PascalCase - types.ts 中定义页面所需的所有接口类型 ## 3. 接入路由 - 在 src/router/routes.ts 中注册新路由路径与菜单配置遵循现有格式 ## 4. 对接数据 - 使用 src/hooks/useRequest.ts 进行数据请求 - 所有交互状态用 zustand 管理store 文件放在 src/store/ 下 ## 5. 自查清单 - [ ] index.tsx / types.ts / styles.module.css 三个文件都已创建 - [ ] 路由已注册且路径无重复 - [ ] 没有硬编码中文字符 - [ ] 没有使用任何 any 类型这个Skill的核心价值在于它把“做一个页面”的隐性知识路由注册、store管理、文案抽取显性化了。AI执行时相当于照着清单逐项打勾不会因为忘了注册路由导致页面白屏。3.4 第三步用注记启动对话现在模拟一个真实操作我打开Cursor的对话窗口先输入Folder选中src/pages目录让AI看到现有页面的组织方式再引用src/services目录让AI知道后端接口大概长什么样。然后输入Folder src/pages Folder src/services 请按照 create-page 这个技能帮我新增一个“用户管理”页面。功能包括用户列表展示、状态切换、搜索过滤。AI会怎么反应它会先识别到create-page这个Skill按SKILL.md里面写的步骤走读pages目录看结构 - 创建三个文件 - 注册路由 - 联调useRequest。因为Rules注入了frontend-rules.mdc它生成代码时会自动采用CSS Modules和BEM命名因为Skill规定了自查清单它最后会逐项检查有没有漏掉路由、有没有硬编码。整个过程中我几乎不需要重复说“记得用CSS Modules”“记得注册路由”这些话。上下文由注记提供行为边界由Rules约束执行步骤由Skills接管。3.5 效果验证与微调第一次执行完我习惯做两件事检查路由文件确认AI确实在routes.ts里新增了路由而不是只创建了页面组件。跑一遍CtrlClick跳转看页面文件里的import路径有没有拼错。如果某一步AI漏了我不会只说“你漏了注册路由”而是打开对应的Rule或Skill文件把漏掉的步骤补进去。这样下次它就记住了。这个“反馈-沉淀-固化”的循环才是Rules和Skills真正越用越顺的原因。4. 常见问题与排查技巧实录我把过去几个月攒下来的坑整理成了一份速查表遇到问题先对着查一遍比自己瞎折腾快得多。现象可能原因解决办法Rules完全不生效文件位置放错确认放在项目根目录的.cursor/rules/下文件名后缀为.mdc规则时灵时不灵globs写得太宽或太窄检查globs是否覆盖了对话涉及的文件路径不确定时先去掉globs试试Skill没有被触发description写得像“功能描述”而非“触发场景”改成包含触发关键词的说明比如“当用户要求创建列表页时使用”Skill被误触发description太宽泛增加限定语比如“仅适用于xxx后台项目”Codebase引用的内容太杂检索范围过大把Codebase换成Folder或FileAI不遵守“禁止xxx”规则本身是负面表达把负面指令改写成正面要求例如“禁止硬编码”改为“文案必须放在locales文件”从Claude Code迁移的Skill报错frontmatter字段不兼容检查allowed-tools、model字段Cursor版本可能不支持移除即可这里单独说一个我掉过最深的坑规则写在.mdc文件里但AI每次启动对话后仍然置若罔闻。后来排查发现是因为我在规则里用了“必须”“禁止”这类命令式表达但整份规则没有description字段。Cursor依赖description判断“这条规则该不该在当前对话注入”没有它规则可能被当作普通文件内容处理而不是规则。所以每个.mdc文件务必写好description这不仅是给AI看的也是给规则加“触发开关”。还有一个关于Skills的细节不要一开始就写非常复杂的Skill。我见过有人把“全流程部署”塞进一个Skill里结果AI执行到第三步就开始乱后面全崩了。Skill的粒度最好控制在“单次任务5-10步以内”。宁可拆成“build-feature”和“deploy”两个Skill也不要硬塞一个巨型流程。流程越长AI的注意力就越容易漂移这一步没法完全靠提示词弥补。另外如果你遇到AI明明在按Skill执行但中途还是“发散”了大概率是因为Skill description里没有说明“执行范围”。比如“创建页面”的SkillAI可能在第四步“对接数据”时擅自重构了你的useRequest.ts因为它觉得“顺手优化一下”。要压住这种行为可以在SKILL.md最后加一行本流程只包含页面创建相关操作不得修改既有工具函数、hooks或其他页面文件。规则越有边界AI越不容易跑偏。这跟带新人是一个道理——你只让他收拾桌子他就不该顺便把别人抽屉也翻一遍。5. 关于使用这套组合的几点心得最后分享一些碎片化的个人经验不算系统教学但都是我实际踩过之后觉得值得记住的东西。第一个心得是Rules和Skills是“越写越准”的资产不是一次性配置。第一版写的规则肯定有漏洞AI不按规矩走的时候不要急着骂它而是反思规则本身写没写清楚。把每次“AI跑偏”都当成一次规则迭代的机会你的规则库会越来越像一份真正反映团队文化的员工手册。第二个心得是注记不要滥用也不要不用。我见过两类极端用户一类永远只用对话框打字AI全靠猜产出自然拉胯另一类每次把全项目都进去token烧得飞快回答反而被无关代码干扰。最舒服的用法是先想清楚“这个问题到底依赖哪些上下文”再精准地那两三处。第三个心得是Skills可以跟别人的项目共用但一定要“本地化”。从社区下到一个不错的React组件检查Skill先读一遍SKILL.md把你的项目路径、团队规范、目录结构同步进去。直接搬来就用的人十有八九会卡在路径不一致上。第四个心得是这套组合不只在代码生成场景有效。我用它来“让AI做代码审查”效果也很好——写一个review-code的Skill规则里规定审查要检查的几个维度类型安全、边界情况、依赖引入、命名异味再用Codebase让它扫整个模块AI能像有经验的老手一样给出非常具体的审查意见甚至帮你找出测试覆盖不到的隐藏分支。Cursor的进阶玩法没有想象中那么玄乎。核心就是把“你希望AI怎么做”这件事从你的脑子里搬到配置文件里。一旦搬完了它就不再依赖你每次对话时反复叮嘱。注记解决的是“AI看不看得见”Rules解决的是“AI守不守规矩”Skills解决的是“AI会不会干活”。三件事各归其位Cursor才真正从编辑器变成了你的结对编程搭档。 Cursor进阶三件套：@注记、Rules、Skills的实战组合
很多人用Cursor其实还停留在“把聊天框当百度用”的阶段——问一句答一句代码能用就复制走。真正让Cursor脱胎换骨的是另外三样东西注记、Rules、Skills。这三个词单独拆开都不难理解但把它们组合到位才算是把Cursor从“会写代码的插件”升级成“真正懂你这个项目的协作者”。今天不聊基础操作聊进阶。这篇文章会逐一拆解注记的引用链路、Rules的规则体系、Skills的技能封装再给一套可以直接抄的组合打法。适合已经用Cursor写过一段时间代码、但总觉得AI“不够听话”或“记不住项目规范”的人。看完你会发现过去那些“AI写得不对”“AI又改了我不让它改的东西”的烦恼大部分根本不用忍。1. 为什么是这三件套注记、Rules、Skills的分工逻辑1.1 三个功能各管一段上下文、约束、流程先说个我常用的类比。你把AI想象成一个新来的程序员工位已经给他准备好了。注记是“递材料”。你不是跟他说“帮我改一下登录页”而是把登录页对应的文件、依赖的组件、后端接口文档直接甩到他桌上。AI看到的就不再是想象里的登录页而是你项目里真实的登录页。Rules是“员工手册”。里面写清楚这个团队怎么命名变量、怎么处理错误、用什么状态管理库、代码提交前要过哪些检查。AI每次干活前先翻这本手册产出的代码天然贴合你的团队规范。Skills是“标准作业流程”。比如“新增一个API端点”这件事在你们项目里是有固定套路的建路由、加校验、写服务层、补Swagger注释、跑测试。Skill就是把这套动作固化成一份可执行的清单AI按部就班走完不会漏步骤。这三件事的分工极其清晰上下文靠注记供给行为边界靠Rules框定重复任务靠Skills自动化。三者合起来才是一个完整的“AI协作系统”。1.2 为什么这是“进阶”的分水岭大部分用户只用到了Cursor最浅的一层对话窗口里描述需求AI生成代码。这层用法的问题是AI每一次回答都是“从零开始”的——它不知道你的项目结构、不知道你的编码习惯、也不知道“上一次已经处理过这个问题”。进阶用法和基础用法的差异本质上是一个公式AI产出质量 模型能力 上下文质量 约束清晰度 执行流程完整度这四项里模型能力是Cursor定死的你没法改但后面三项恰好就是注记、Rules、Skills分别补上的。当你的上下文更精确、约束更明确、流程更完整时AI的产出会从“能跑”跃迁到“不用改就能合进主干”这个差距是肉眼可见的。1.3 这套玩法不是Cursor独有但Cursor把它做进了编辑器Claude Code里有SkillsCodex里也有类似的文件分组和指令机制。但Cursor的优势在于这些东西不是命令行里的一次性配置而是长在编辑器里的日常交互。你在写代码时随手一个文件、在项目目录里放一份规则后续所有AI交互都会自动带上这些信息不需要来回切换工具。而且更重要的是Cursor正在兼容社区里通用的Skills格式。这意味着你从Claude Code或Codex社区里淘来的优秀技能包很多可以直接拿过来用不用重写。这一点后面第2章会专门展开。2. 核心细节与实操要点拆解2.1 注记把“AI猜”变成“AI看”注记At Mentions是Cursor里操作成本最低、但提升效果最明显的功能。在对话输入框里输入会弹出当前项目的文件、文件夹列表以及一系列快捷引用项。选中的内容会作为上下文附加到你的提问里。实战中我主要用这么几种按使用频率排引用方式解决的问题使用建议File文件针对单个文件提问、修改改bug、重构单文件时必用Folder文件夹让AI理解一个模块的完整结构跨文件改动、新增功能时优先Codebase代码库让AI检索整个仓库适合“这个项目里XXX是怎么实现的”这类问题Docs文档引入第三方库官方文档用不熟悉的库、查API时非常香Web网页检索最新网络信息库版本迭代快、文档过期时用Git代码变更查看提交记录、Diff复盘线上问题、写commit message时用先说Codebase。很多人一上来就喜欢用这个因为它看起来最“AI”。但我实测下来它是最容易被滥用的——Codebase会触发一次跨全仓库的向量检索耗时几秒到几十秒消耗的token也不小。如果你的问题其实只涉及某一个模块直接用Folder把它按进去精度更高、速度更快。我的习惯是小改动用File模块级改动用Folder只有完全不确定代码在哪的时候才用Codebase。再说Docs。这个是隐藏神器。Cursor里可以提前配置一批文档源Settings - Docs把项目依赖的框架、组件库、后端API文档都挂上去。之后在对话里Docs就能直接引用。我见过很多人在用三方库时让AI“猜”参数配置AI一本正经地编了一堆不存在的API最后全踩坑。挂上官方文档之后这种情况基本绝迹。使用注记有个容易忽略的坑如果选中了多个文件AI会把它们当作并列上下文但不会自动理解文件之间的依赖关系。比如你同时了一个组件文件和一个工具函数文件最好在提问里补充一句“这个组件使用了utils里的xxx函数请注意两者的类型关系”。不然AI可能忽略你给的部分上下文自己另起炉灶。2.2 Rules让AI遵守“这个项目自己的规矩”Rules在Cursor里承担的是“长期记忆行为约束”的角色而且和注记不一样Rules不需要每次对话都手动带上——它是自动生效的。先说存放位置。目前Cursor里有两类规则Project Rules项目级放在项目根目录下的.cursor/rules/文件夹里支持.mdc格式。这是官方推荐的方式。User Rules全局级在Cursor的设置里配置对所有项目生效。适合放你自己的通用偏好比如“回答用中文”“代码里不要用console.log”。老版本还有一个.cursorrules文件放在项目根目录的玩法现在官方建议往.cursor/rules/迁移。如果你的项目里同时存在.cursorrules和.cursor/rules/新规则优先但为了长远考虑我建议都统一到.cursor/rules/里。.mdc文件有一个很核心的机制frontmatter glob匹配。文件头部用两段---包起来的信息叫frontmatter里面可以写description和globs。globs是用来控制这条规则作用于哪些文件的。比如--- description: 所有 TS 组件文件必须遵守的规范 globs: src/**/*.tsx, src/**/*.ts --- - 组件命名必须使用 PascalCase - 禁止使用 any 类型 - 组件必须有明确的 props 接口定义 - 文件末尾留一个空行这个机制的意义非常大。你可以把规则拆成好几份文件一份管TS类型、一份管React组件、一份管样式写法。Cursor会根据当前对话涉及的文件路径自动匹配合适的规则注入。规则太多太杂反而会稀释AI的注意力拆开按需生效才是正道。再强调一遍规则要写“要什么”而不是“不要什么”。AI对负面指令的理解和执行远不如正面指令稳定。你说“不要用any”它可能还是会偶尔漏但你说“所有类型必须显式定义禁止隐式推断为any”执行率会高很多。2.3 Skills把“问一句答一句”变成“交给AI执行”Skills是三者里最新、也最被低估的能力。通俗理解它就是把一条完整的任务流程打包成一个“技能包”。AI识别到你的需求匹配某个技能后会自动加载这个技能的步骤说明、代码模板、注意事项然后一步步执行。Cursor的Skills目录结构一般长这样.cursor/ ├── skills/ │ ├── create-api/ │ │ ├── SKILL.md │ │ └── templates/ │ │ └── api-handler.template.ts │ └── review-code/ │ └── SKILL.md每个技能文件夹里至少要有一个SKILL.md文件它是技能的“说明书”。文件头部同样有frontmatter包含name、description、allowed-tools等字段。真正重要的是description——Cursor会读取它来决定“什么情况下自动触发这个技能”。写清楚触发场景技能才会被精准命中。下面是一个简化的SKILL.md示例--- name: create-react-component description: 当用户要求创建新的 React 组件时使用。适合带有 props 接口、样式文件和默认导出的组件创建流程。 allowed-tools: write, read, edit --- 1. 读取项目根目录下的 components 目录理解现有组件的文件组织方式 2. 根据用户提供的组件名创建同名文件夹 3. 新建 index.tsx导出组件主体新建 types.ts定义 Props 接口 4. 样式文件使用项目已有的 CSS 方案默认 CSS Modules 5. 创建完成后检查是否存在同名 .stories.tsx 规范若有则补充 Storybook 文件你看这个Skill把“创建React组件”这件原本需要AI自由发挥的事编码成了一个流程。AI不会再问你“要不要单独建文件夹”而是照着流程走完。Skills与Rules、注记最大的区别也在这里Rules告诉你“什么能做、什么不能做”它是静态的Skills告诉你“这件事具体分几步做”它是动态的、流程化的。而当Skill里要读取具体文件时它内部仍然会用到注记的底层能力这三者不是替代关系是嵌套关系。另外提一个非常实用的事Claude Code和Codex的Skills目录结构和Cursor高度相似。我试过直接把Claude Code社区的某个代码审查Skill放进.cursor/skills/稍微改一下frontmatter的字段名就能跑起来。这意味着你不用从零开始造轮子去社区里找那几个星标高的skills仓库下载后做微调就能用。3. 实操从0到1搭一套“规则技能”组合3.1 场景设计我以一个实际项目为例——React TypeScript Vite的B端管理后台团队风格比较偏保守组件全用函数组件、样式用CSS Modules、类名遵循BEM、数据请求封装在独立的hooks/useRequest.ts里。过去让AI直接写代码经常写出带class组件、样式内联、没有复用useRequest的东西。现在我要做三件事在项目里配置一套Rules告诉AI我们团队到底怎么“说话”。写一个封装新页面的Skill把从“创建组件”到“接入路由”再到“联调接口”的标准流程固化下来。用一个实际对话演示“注记 Rules Skills”三者怎么共同干活。3.2 第一步配置项目级Rules在项目根目录创建.cursor/rules/放两份文件。第一份frontend-rules.mdc管理通用的前端风格--- description: 前端代码通用规范适用于所有 TS/TSX 文件 globs: src/**/*.{ts,tsx} --- 1. 函数组件为主禁止使用 class 组件 2. 样式必须使用 CSS Modules禁止使用内联 style 属性 3. 类名采用 BEM 命名规范block__element--modifier 4. 数据请求统一走 src/hooks/useRequest.ts 封装禁止直接在组件内 fetch 5. TypeScript 类型定义放在与组件同级的 types.ts 文件中 6. 组件默认导出必须使用 export default具名导出仅用于工具函数第二份page-creation.mdc专门约束页面创建流程--- description: 新建页面时需要遵守的目录规范 globs: src/pages/**/* --- 1. 每个页面目录下必须包含 index.tsx、types.ts、styles.module.css 三个文件 2. 页面级状态管理使用 zustand禁止使用 redux 3. 新页面必须在 src/router/routes.ts 中手动注册路由 4. 页面文案统一放在 src/locales/zh-CN.ts 中禁止硬编码中文文本这两份Rule生效后AI生成代码就强制被拉回团队的既定轨道上。我实测下来最明显的改善是以前AI喜欢把所有样式怼在style{{}}里现在自动生成styles.module.css类名也老老实实按BEM走。3.3 第二步编写页面生成的Skill在.cursor/skills/create-page/下创建SKILL.md--- name: create-page description: 创建后台管理系统的页面。当用户要求新增页面、新建业务模块或创建CRUD界面时使用。触发关键词包括“创建页面”、“新增模块”、“做一个列表页”等。 allowed-tools: read, write, edit, grep --- # 页面创建流程 ## 1. 环境确认 - 读取 src/pages 目录确认现有页面结构 - 读取 src/router/routes.ts理解路由注册方式 ## 2. 创建页面骨架 - 在 src/pages/新建页面名/ 下创建 index.tsx、types.ts、styles.module.css - index.tsx 中导出默认组件组件名使用 PascalCase - types.ts 中定义页面所需的所有接口类型 ## 3. 接入路由 - 在 src/router/routes.ts 中注册新路由路径与菜单配置遵循现有格式 ## 4. 对接数据 - 使用 src/hooks/useRequest.ts 进行数据请求 - 所有交互状态用 zustand 管理store 文件放在 src/store/ 下 ## 5. 自查清单 - [ ] index.tsx / types.ts / styles.module.css 三个文件都已创建 - [ ] 路由已注册且路径无重复 - [ ] 没有硬编码中文字符 - [ ] 没有使用任何 any 类型这个Skill的核心价值在于它把“做一个页面”的隐性知识路由注册、store管理、文案抽取显性化了。AI执行时相当于照着清单逐项打勾不会因为忘了注册路由导致页面白屏。3.4 第三步用注记启动对话现在模拟一个真实操作我打开Cursor的对话窗口先输入Folder选中src/pages目录让AI看到现有页面的组织方式再引用src/services目录让AI知道后端接口大概长什么样。然后输入Folder src/pages Folder src/services 请按照 create-page 这个技能帮我新增一个“用户管理”页面。功能包括用户列表展示、状态切换、搜索过滤。AI会怎么反应它会先识别到create-page这个Skill按SKILL.md里面写的步骤走读pages目录看结构 - 创建三个文件 - 注册路由 - 联调useRequest。因为Rules注入了frontend-rules.mdc它生成代码时会自动采用CSS Modules和BEM命名因为Skill规定了自查清单它最后会逐项检查有没有漏掉路由、有没有硬编码。整个过程中我几乎不需要重复说“记得用CSS Modules”“记得注册路由”这些话。上下文由注记提供行为边界由Rules约束执行步骤由Skills接管。3.5 效果验证与微调第一次执行完我习惯做两件事检查路由文件确认AI确实在routes.ts里新增了路由而不是只创建了页面组件。跑一遍CtrlClick跳转看页面文件里的import路径有没有拼错。如果某一步AI漏了我不会只说“你漏了注册路由”而是打开对应的Rule或Skill文件把漏掉的步骤补进去。这样下次它就记住了。这个“反馈-沉淀-固化”的循环才是Rules和Skills真正越用越顺的原因。4. 常见问题与排查技巧实录我把过去几个月攒下来的坑整理成了一份速查表遇到问题先对着查一遍比自己瞎折腾快得多。现象可能原因解决办法Rules完全不生效文件位置放错确认放在项目根目录的.cursor/rules/下文件名后缀为.mdc规则时灵时不灵globs写得太宽或太窄检查globs是否覆盖了对话涉及的文件路径不确定时先去掉globs试试Skill没有被触发description写得像“功能描述”而非“触发场景”改成包含触发关键词的说明比如“当用户要求创建列表页时使用”Skill被误触发description太宽泛增加限定语比如“仅适用于xxx后台项目”Codebase引用的内容太杂检索范围过大把Codebase换成Folder或FileAI不遵守“禁止xxx”规则本身是负面表达把负面指令改写成正面要求例如“禁止硬编码”改为“文案必须放在locales文件”从Claude Code迁移的Skill报错frontmatter字段不兼容检查allowed-tools、model字段Cursor版本可能不支持移除即可这里单独说一个我掉过最深的坑规则写在.mdc文件里但AI每次启动对话后仍然置若罔闻。后来排查发现是因为我在规则里用了“必须”“禁止”这类命令式表达但整份规则没有description字段。Cursor依赖description判断“这条规则该不该在当前对话注入”没有它规则可能被当作普通文件内容处理而不是规则。所以每个.mdc文件务必写好description这不仅是给AI看的也是给规则加“触发开关”。还有一个关于Skills的细节不要一开始就写非常复杂的Skill。我见过有人把“全流程部署”塞进一个Skill里结果AI执行到第三步就开始乱后面全崩了。Skill的粒度最好控制在“单次任务5-10步以内”。宁可拆成“build-feature”和“deploy”两个Skill也不要硬塞一个巨型流程。流程越长AI的注意力就越容易漂移这一步没法完全靠提示词弥补。另外如果你遇到AI明明在按Skill执行但中途还是“发散”了大概率是因为Skill description里没有说明“执行范围”。比如“创建页面”的SkillAI可能在第四步“对接数据”时擅自重构了你的useRequest.ts因为它觉得“顺手优化一下”。要压住这种行为可以在SKILL.md最后加一行本流程只包含页面创建相关操作不得修改既有工具函数、hooks或其他页面文件。规则越有边界AI越不容易跑偏。这跟带新人是一个道理——你只让他收拾桌子他就不该顺便把别人抽屉也翻一遍。5. 关于使用这套组合的几点心得最后分享一些碎片化的个人经验不算系统教学但都是我实际踩过之后觉得值得记住的东西。第一个心得是Rules和Skills是“越写越准”的资产不是一次性配置。第一版写的规则肯定有漏洞AI不按规矩走的时候不要急着骂它而是反思规则本身写没写清楚。把每次“AI跑偏”都当成一次规则迭代的机会你的规则库会越来越像一份真正反映团队文化的员工手册。第二个心得是注记不要滥用也不要不用。我见过两类极端用户一类永远只用对话框打字AI全靠猜产出自然拉胯另一类每次把全项目都进去token烧得飞快回答反而被无关代码干扰。最舒服的用法是先想清楚“这个问题到底依赖哪些上下文”再精准地那两三处。第三个心得是Skills可以跟别人的项目共用但一定要“本地化”。从社区下到一个不错的React组件检查Skill先读一遍SKILL.md把你的项目路径、团队规范、目录结构同步进去。直接搬来就用的人十有八九会卡在路径不一致上。第四个心得是这套组合不只在代码生成场景有效。我用它来“让AI做代码审查”效果也很好——写一个review-code的Skill规则里规定审查要检查的几个维度类型安全、边界情况、依赖引入、命名异味再用Codebase让它扫整个模块AI能像有经验的老手一样给出非常具体的审查意见甚至帮你找出测试覆盖不到的隐藏分支。Cursor的进阶玩法没有想象中那么玄乎。核心就是把“你希望AI怎么做”这件事从你的脑子里搬到配置文件里。一旦搬完了它就不再依赖你每次对话时反复叮嘱。注记解决的是“AI看不看得见”Rules解决的是“AI守不守规矩”Skills解决的是“AI会不会干活”。三件事各归其位Cursor才真正从编辑器变成了你的结对编程搭档。