你有没有遇到过这样的尴尬让Cursor帮你写一个团队的React组件结果它完全按自己的习惯来跟你们项目的命名规范、路由风格、注释习惯全对不上或者让它帮你排一份LaTeX论文它每次都从零开始问你格式要求答完这次下次又忘。过去我的解决办法很粗暴——把规范写进全局Rules里或者每次手动贴一大段“工作手册”进提示词。规则越攒越多之后整个上下文都被这些固定内容占着真正重要的代码反而没空间了。后来我把目光转向了Cursor里的Skills机制用了一段时间之后最大的感受是这东西本质上就是给AI配了一本“按需翻开的SOP手册”。比起把所有规则一股脑塞给模型Skills是在你真正处理某类任务时才把对应内容加载进来。这篇文章我会从Skills在Cursor里的定位讲起依次聊到现成技能包的获取安装、触发机制、自己怎么写一个可用的Skill以及我实测中踩过的那些坑。无论你只是想把别人做好的技能直接用起来还是打算给团队沉淀一套内部规范这篇文章都适合你。1. Skills在Cursor里解决的是什么问题先说清楚一个基本问题Skills在Cursor里到底是什么。Cursor中的Skills形式上是一个带SKILL.md描述文件的文件夹里面装着某个领域任务的“操作手册”——包括工作流程、代码规范、输出格式、检查清单甚至配套的脚本和参考文档。当你在对话里让Cursor处理某类任务时模型会根据技能描述判断要不要加载这份手册并按照手册里的步骤去执行。听起来好像只是“多了一个文件”但真正用过之后你会发现它解决的问题比想象中要大。1.1 没有Skills时我们在怎么“重复造轮子”在Skills出现之前我身边大多数人的做法分三类。第一类是把规范写进全局Rules。这个做法的好处是每次对话都生效但坏处也明显——无论你在写Python还是改配置文件所有规则都压在上下文里。全局规则一多不仅浪费token还容易让模型在无关任务上也“过度守规矩”反而影响灵活性。第二类是每次手动粘贴规范。这个方式看似精准实际上很累。你需要在对话前整理一份“临时手册”一旦忘了贴模型就按默认习惯来产出的代码风格立刻打回原形。而且不同项目有不同规范每次都要从收藏夹里找对应文本麻烦程度不亚于复制粘贴一段长代码。第三类是依赖模型“自己记住”。靠对话记忆显然不靠谱——换个新会话就断片了团队里换了同事也接不上。Skills的解决思路其实很朴素把规范做成独立的、可复用的文件夹每个文件夹专门管一类任务。写React组件时自动加载React规范做LaTeX排版时自动加载排版规范谁也不耽误谁。需要的时候才翻开手册不需要的时候完全不影响对话。这个“按需加载”的思路就是它和Rules最大的区别。1.2 Skills、Rules与MCP三者的分工别搞混刚接触Cursor生态的人经常会问一个问题我有Rules了也有MCP为什么还要一个Skills这三者的边界不少人是模糊的。我用一张表说明白。维度SkillsRulesMCP核心定位按需加载的任务手册全局行为准则外部工具与数据连接加载方式匹配任务描述时触发每次对话都生效调用具体工具时生效典型场景前端开发、LaTeX排版、论文写作语言偏好、通用禁止项查数据库、读网页、跑浏览器内容形态Markdown手册脚本参考文档简短规则文本服务端工具接口这三者并不互斥实际项目中往往是组合使用。比如你可以用Rules规定“所有代码必须写注释”用Skills规定“React项目里组件怎么拆分、Hooks怎么命名”再用MCP让Cursor能直接查询你们公司的接口文档。Rules管底线Skills管专业能力MCP管外部连接各司其职。理解这个分工之后再看Skills就很清晰了它解决的是“专业工作流标准化”的问题。你不需要在每次对话里重复告诉Cursor该怎么干活它只需要在合适的时机自己翻开那本手册。2. 先跑通现成的开源Skills的获取与安装很多人的第一反应是“我不会写Skill直接用别人做好的行不行”。当然行而且我强烈建议你先从现成的开始跑通一遍再考虑自己写。这个领域的生态已经比较热闹了虽然早期高质量技能包不多但找一些通用场景的完全够用。2.1 从哪些地方能找到靠谱的Skills源目前找现成Skills最主流的两条路一是GitHub上的聚合仓库二是一些社区维护的技能集市网站。GitHub上直接搜“awesome-claude-skills”“cursor skills”这类关键词能找到不少人整理的技能列表。除了综合仓库还有一些特定方向的合集也值得关注比如前端开发技能包、LaTeX排版技能包、图片生成技能包、AI漫剧分镜脚本技能包甚至连全国大学生数学建模比赛用的论文排版技能都有现成的。这些技能包的质量参差不齐下载前我习惯先看两点一看Star数和最近更新时间二看SKILL.md里写的描述是否具体。描述写得含糊的往往触发效果也不好。另外一个很实用的途径是直接在Cursor的对话框里问AI“你了解有哪些常用的Skills源网站吗”让模型帮你梳理一遍社区里的知名项目再去GitHub核对。这比自己在搜索引擎里翻半天高效得多尤其是对刚上手的人。2.2 安装到全局目录还是项目目录找到技能包之后安装本身没什么技术含量核心就是选对目录。Cursor的技能包位置分为两种。全局目录在用户主目录下macOS / Linux~/.cursor/skillsWindows%USERPROFILE%\.cursor\skills全局目录里的技能包对所有项目生效适合放那些“通用型”技能比如代码审查规范、通用写作规范、LaTeX排版规范。项目级目录在项目根目录下.cursor/skills。这个目录里的技能包只对这个仓库生效而且因为文件夹会随代码一起提交团队里的人clone下来之后能力是共享的。适合放跟业务强绑定的规范比如你们公司自己的后端代码结构、特定框架的组件写法、数据表命名规则。实际操作时只需要把下载下来的技能包文件夹注意是整个包含SKILL.md的文件夹放到对应目录里就行。比如你想让所有项目都能用一个“前端开发规范”技能就把那个文件夹复制到~/.cursor/skills下面。装完建议执行一次“Reload Window”让Cursor重新扫描技能目录再开始测试。2.3 装完之后怎么确认Cursor真的读到了这一步是很多人忽略的。装完技能包就直接开聊结果发现模型根本没调用于是开始怀疑自己哪里装错了。我建议用两个方法来验证。方法一直接问。在Cursor的输入框里问一句“你现在有哪些可用的skills”正常情况下模型会把它能看到的技能包名称和描述列出来。如果列出来的技能跟你放进去的对不上说明扫描路径有问题或者格式不对。方法二制造一个必须触发技能的请求。比如你装了一个“LaTeX排版”技能包就让它“帮我用LaTeX写一份学术论文的模板”。如果技能真的被加载了模型会按照技能里的格式要求一步步输出如果没有你就得回头检查目录结构和SKILL.md格式。这里还想提醒一句不同版本的Cursor对Skills的入口位置有差异。新版里有的桌面端在Settings里增加了SKills路径的管理入口最稳妥的方式是直接以文件管理器的方式打开上面说的目录路径手动确认文件夹确实在那。别只依赖设置界面文件路径才是最终的判断标准。3. 让技能真正被调用Agent触发机制与使用细节安装只是第一步真正让Skills发挥价值的是“触发”这个环节。不少人在这一步卡住——技能明明装好了模型就是不调用。这背后其实涉及Cursor对Agent模式、模型能力、上下文管理的一整套逻辑。3.1 自动触发和手动引用的配合方式Skills的触发方式主要有两种。自动触发是指当用户描述的任务和技能包description高度匹配时模型会自动决定加载该技能。比如技能描述里写着“当用户需要编写或审查React组件时使用”那么你只要说“帮我写一个带筛选功能的用户列表组件”模型就会尝试加载这个技能包。这种机制的最大好处是自然——你不需要记得自己装了什么技能正常说话即可。手动引用则适合那些场景特别明确的时刻。在Cursor的输入框里你可以通过引用的方式把技能包路径贴进对话比如你的技能包文件夹路径让模型明确知道你要用这个技能。这种方式适合一张对话里有多个技能候选、你不想靠模型猜的场景。两者怎么配合我的习惯是通用任务靠自动触发重要且复杂的任务靠手动引用。比如平时写点小代码让模型自己判断就好了一旦要输出正式的团队代码评审或者论文排版我一定手动引用对应技能包确保它跑不了。3.2 为什么有时候Agent就是不调用Skills如果模型就是不调用你装的技能先别急着怪技能包。逐个排查下面几个因素。第一模型模式不对。只有Agent模式下模型才具备“主动决定加载技能”的能力。如果你用的是普通的快速问答模式尤其是一些轻量模型它可能根本不会去看技能目录。在Cursor里执行复杂任务前先把模式切到Agent否则装再好的技能也白搭。第二技能描述写得不好。这其实是最大概率的原因。描述太笼统——比如只写“前端开发技能”——模型遇到具体任务时很难判断“这件事属于前端开发技能的范围吗”。描述里应该包含明确的触发场景和任务类型越具体召回率越高。第三上下文太长模型“忘”了还有技能可用。在长对话里早期加载的内容会逐渐被挤出上下文。如果聊了很久才提到要写React组件模型可能不再记得自己有哪些技能包。遇到这种情况直接手动引用技能包路径最省事。第四版本兼容问题。老版本的Cursor可能根本还没支持Skills或者支持的目录格式不同。如果验证了目录、模式、描述都没问题还是不生效优先检查Cursor版本把它升级到最新版再试。3.3 模型选择与上下文预算的平衡用Skills时很多人忽略了模型选择对效果的影响。需要主动调用技能包里的流程、并严格按照手册执行任务的场景建议选择Agent能力强的模型比如Claude系列更靠后的版本或者各家最新旗舰模型。轻量模型不是不能用Skills但可能“读”了手册却不认真执行效果会打折扣。上下文预算同样重要。Skill被触发后SKILL.md的内容会被注入对话上下文。如果你把整个操作手册写成一个几千行的大文件光加载它就会吃掉大量上下文空间留给真正代码和对话的空间就少了。这也是为什么我后面第四节会专门讲“渐进式披露”的写法——主文件只保留摘要和触发条件细节放进references子文件里按需加载。这不仅是写给别人看的技巧更是为了省token。4. 从零写一个Skill以前端开发规范为例现成技能包用熟练之后很多人会萌生一个念头我也写一个属于自己的Skill。这个门槛其实不高照着固定结构来就行。这一节我拿一个“前端React开发规范”技能包举例从目录结构到SKILL.md内容一步一步讲清楚。4.1 一个Skill的标准目录结构Skills的能力来自一套约定的目录结构。一个最小的技能包长这样my-react-skill/ ├── SKILL.md └── references/ └── react-code-review.md外层文件夹的名字比如my-react-skill可以随便起方便识别就行。但里面那个SKILL.md是固定的文件名不能改也不能改成小写skill.md否则Cursor可能压根不认。references目录是可选的用来放那些“用得着但没必要一上来就全文加载”的详细资料比如代码审查细则、组件拆分策略、命名对照表。如果技能包里带脚本还可以加scripts/目录。比如写一个自动检查组件命名是否符合规则的Python脚本放在scripts/check_component_name.py。Agent在执行到对应步骤时可能会调用它不过是否执行脚本、执行时要不要授权取决于Cursor的权限策略。4.2 SKILL.md怎么写才不会被Agent无视SKILL.md是整个技能包的核心控制着它“会不会被触发”以及“触发后怎么干活”。头部是YAML格式的元信息用---包裹起来至少需要name和description两个字段。name用来标记技能名description的作用则大得多——前面反复提到模型判断“要不要用这个技能”就是靠读description。所以description写得越具体越好。不要只写“用于前端开发”而要写成“当用户需要编写、审查或重构React函数组件时使用。包括组件目录结构、Hooks命名规范、props设计原则、代码审查清单等”。这样模型才能在你提出相关需求时产生匹配。正文部分不要上来就堆细节。SKILL.md的主体应该写清楚几个内容这个技能适合什么场景、不适合什么场景、标准工作流程是什么、输出什么格式、有哪些硬性规则。比如写React组件规范可以规定组件文件必须放到src/components/[功能名]/目录每个组件带一个index.ts导出Hooks命名必须以use开头并遵循驼峰式禁止在组件内部直接写行内样式等等。一个非常好用的写法是“显式指出触发条件”。在描述或正文开头顶格写一句“当用户提到以下关键词或需求时必须使用本技能React组件、前端组件、组件审查……”。这句话相当于给模型一个强指令能明显提高召回率。4.3 一套可直接改用的React组件Skill示例下面我给一个简化但完整的SKILL.md示例你可以直接抄走改成自己团队的版本。--- name: react-component-standard description: 当用户需要编写、审查或重构React函数组件时使用。覆盖组件目录结构、Hooks命名、props设计、代码审查清单。适合前端开发场景也适合要求输出团队规范的场景。 --- # React组件开发规范 ## 使用场景 - 用户要求创建新的React组件 - 用户要求审查已有组件代码 - 用户要求重构组件并保持团队规范 ## 不适用场景 - 后端接口设计 - 数据库表结构设计 - 非React的前端页面开发 ## 工作流程 1. 确认组件功能与使用场景 2. 参考references/react-code-review.md中的目录结构和命名规则 3. 输出组件代码包含必要的类型定义 4. 附上checklist逐项说明是否符合规范 ## 硬性规则 - 组件使用function声明不使用class组件 - props通过interface定义统一放在组件文件底部导出 - 所有Hooks以use前缀开头语义化命名 - 禁止行内样式统一使用CSS Modules - 组件文件放在src/components/[功能名]/目录下 - 默认导出组件同时导出类型定义 ## 输出格式 代码块输出组件完整代码代码块之后给出Checklist列表 - [ ] 目录结构是否合规 - [ ] Hooks命名是否合规 - [ ] props是否有类型定义 - [ ] 是否有行内样式这个示例麻雀虽小五脏俱全。它明确了触发场景给出了工作流程并且把“输出检查清单”也写进技能里——这样模型每次写完组件都会附带一个自检清单团队评审的时候就很省事。4.4 细节放进references按需加载你可能会发现上面的SKILL.md正文里详细规则只写了6条。真正团队的规范肯定不止这些什么组件注释怎么写、样式命名用BEM还是别的、目录下要不要额外放storybook文件……这些全写进主文件上下文空间就浪费了。正确做法是把详细规则拆分到references子文件里。SKILL.md里只留一句话“组件结构、样式命名、注释规则的详细说明见references/react-code-review.md”。当Agent需要深挖时它会自己去读那个子文件。这就是前文说的渐进式披露——主文件负责“告诉模型有这个技能、以及大概的执行框架”子文件承载“具体怎么做”的全部细节。这套思路跟写技术文档时“摘要正文”的结构如出一辙只是服务对象变成了模型而已。5. 实测中踩过的坑路径、缓存与兼容性技能包用了一段时间之后我确实踩过一些不大不小的坑。这些问题单看都不难解决但第一次遇到时多少会让人愣一下。这一节把几个典型的坑记录下来希望你能绕开。5.1 目录命名和YAML格式第一道翻车点最容易翻车的其实不是概念性问题而是最基础的格式问题。首先技能包的内部必须有SKILL.md这个文件名是全大写固定名称一旦写成skill.md或者SKILL.MDCursor很可能直接忽略。其次YAML头部里冒号后面一定要有空格name: react-component-standard是合法的name:react-component-standard就会解析失败。再次YAML头部里的字段不要用Tab缩进统一用空格解析更稳定。文件夹的名称反而没那么多讲究中英文都可以但建议还是用英文小写加横线命名一是避免编码问题二是团队协作时更通用。我最初把一个技能包文件夹命名为“前端规范”虽然也能用但在命令行和配置里进出目录时并不方便后来统一改成了英文命名。5.2 改了不生效加载与缓存机制的真相这个问题几乎每次更新技能内容时都会遇到。你改了SKILL.md里的某个规则回到Cursor里重新提需求发现模型还在按旧规则输出完全无视你的修改。原因通常不是写错了而是Cursor没有重新扫描技能文件。对于大多数修改执行一次“Developer: Reload Window”就能解决。如果是在项目级技能目录里改的注意确认当前打开的工作区确实是这个项目。还有个细节容易被忽略技能包内容的加载时机可能在你发起请求的瞬间才确定。所以如果你改了文件但上一轮对话已经处于激活状态最好新开一个会话再测试避免旧会话粘着旧技能的状态。5.3 同一套Skills在Cursor与Claude Code的差异因为Skills的概念在其他AI编程工具里也存在比如Claude Code。同一个技能包文件夹在Cursor和Claude Code之间有时可以互通但有几个地方需要注意。首先目录位置不一样。Cursor读的是~/.cursor/skills或项目里的.cursor/skillsClaude Code读的是~/.claude/skills或项目里的.claude/skills。要让两边共用最简单的办法是把技能包复制到两边各自的目录里而不是试图让某一方“跨界”读取。其次YAML里的元信息字段在两个工具之间不完全通用。比如有的技能包会带allowed-tools字段声明技能执行时可以调用哪些工具这类字段在Cursor里未必生效甚至可能在解析时报出警告。跨工具使用前建议把这类工具相关的字段清掉或按目标工具的文档重新配置。最后模型的执行风格不同。Claude Code更倾向于严格按照技能里的Workflow一条条走而Cursor的Agent在步骤控制上更灵活一点。如果技能里写了“必须按顺序执行1、2、3、4”在Cursor里最好再叠加一句“未完成上一步之前不要跳到下一步”否则模型可能合并步骤跑。这也算是我迁移技能包时发现的一个小经验。5.4 脚本执行与权限安全第一有些技能包会附带可执行脚本比如检查代码规范、批量生成文件等。这类脚本在Cursor里执行时通常会触发权限确认。如果你为了省事在Agent设置里把自动接受权限全部打开风险就来了——技能包来自第三方你根本不知道它内部脚本会不会做超出预期的事情。我的建议是技能包里的脚本先人工打开看一遍确认没有可疑操作再允许执行尤其是那些从GitHub上下载、来源不明、却要求联网或写文件到系统目录的脚本更要留个心眼。Cursor本质上是把执行权交给了模型而模型会忠实地执行技能包里的指令——包括你不希望它执行的指令。所以审查技能包内容跟你审查第三方依赖库一样重要不能省。最后再分享一点我的个人体会把Skills用成习惯之后我最大的感受是它逼着我把“怎样算做得好”这件事想清楚了。以前我口头告诉Cursor“写规范一点”它永远无法理解我们团队到底要怎么个规范法。现在我可以把规范拆成技能包用SKILL.md一条条写清楚再把检查清单塞进去让它自查。这样做的好处不只是代码风格统一了更重要的是新人接手项目时不用翻团队文档也能让AI按团队规范干活。一个小技巧分享给大家给技能包取description的时候我习惯用“当用户提到……时使用覆盖……适合……不适合……”的句式把触发条件、能力范围、边界都写清楚。实测下来这样写的技能包召回率比只写一句话的明显高。你们也可以试试把自己手头反复贴给别人看的那些规范文档先挑一个整理成技能包用一次就知道这套机制有多顺手了。
