现在用 Cursor 和 Claude Code 的人越来越多了但我发现大多数人的用法还停留在“开个对话框把问题丢进去等答案”。这其实是非常低效的因为每次对话你都在重复描述同样的上下文、同样的规范、同样的处理流程AI 每次都在“重新认识你”质量自然忽高忽低。Skills技能包就是为终结这种重复劳动而生的。它本质上是给 AI 助手装的一份“可复用操作手册”你把某个任务的前置条件、执行步骤、判断标准和输出格式都写清楚存成 Skill。之后只要在 Cursor 或 Claude Code 里触发它AI 就会按这份手册自动干活既不需要你反复交代背景也不会每次都自由发挥。这篇文章会分四块展开先讲清楚 Skills 的运行原理和价值再整理 8 类我实际用过、确实能提效的 Skills 推荐然后把 Cursor 和 Claude Code 的接入全流程走一遍包括目录结构、SKILL.md 写法、验证方法最后记录一些容易踩的坑和排查思路。适合每天重度使用 AI 写代码、想把手头重复工作固化下来的开发者也适合想在团队里推广统一编码规范和评审流程的工程负责人。1. 先搞懂 Skills 的核心价值它到底解决了什么问题1.1 从“一问一答”到“一劳永逸”先举个例子。假设你每周都要做代码审查。以前的做法是把代码贴给 Cursor然后写一大段提示词比如“请重点检查性能问题、安全漏洞、边界条件、命名规范最后按严重程度给结论”。每次贴不同的代码但提示词几乎一模一样效率很低而且每次 AI 的侧重点还不一样有时候抓了一堆无关紧要的格式问题真正致命的逻辑漏洞反而没提。有了 Skill 之后你只需要把代码丢过去说一句“用 code-review 检查一下”。AI 自动加载那份写好的审查流程知道要看哪几个维度、参考什么标准、按什么格式输出。这个变化的本质是你不再跟 AI“商量”任务怎么做而是直接给它派一个定义好的活。Prompt 写一次之后所有项目、所有成员都能复用AI 的输出质量也从“看当天状态”变成“看手册标准”。我实测下来同一个审查任务用 Skill 跑出来的规则覆盖度明显更全输出也更规整很少出现漏检或偏题。再往深一层说Skill 在工程上其实就是普通文件和目录核心是一个 SKILL.md。文件头是 YAML 格式的元信息包含技能名称、场景描述、版本号等正文则是给 AI 看的行为说明告诉它这个任务要分几步做、每一步注意什么、最终产出什么样子。当用户的说法命中 description 里描述的场景Agent 就会把这个文件当成参考手册按里面的步骤一步步执行。这个机制说白了就是两个词触发 执行。所以后面你会发现写 Skill 的功夫一大半都花在 description 和步骤设计上这一步做好了才能“一劳永逸”。1.2 Skills 与 Rules、Commands 的区别很多人会把 Skills 和 Cursor 里的 Rules、Commands 搞混。这三样东西都能影响 AI 行为但定位完全不一样我整理了一张对比表。类型典型位置核心作用适用场景Rules.cursor/rules、.claude/rules定义行为边界持续生效全局约束比如“所有代码必须有类型定义”Commands.cursor/commands、斜杠命令预置快捷指令手动触发固定动作比如 /review 调用一段 PromptSkills.cursor/skills、.claude/skills带完整流程的技能包自动触发完整任务比如代码审查、测试生成、架构方案按我自己的使用习惯三者分工通常是Rules 管“不能做什么”Commands 管“一键发起什么”Skills 管“拿到任务后按什么流程做”。只要搭配得当AI 的行为既不会跑偏又不用每次手动启动。这里尤其要提醒一点Skills 和 Commands 最容易被混淆。很多人装完 Skill非要手动敲个命令去调用发现没反应就以为没装好。实际上 Skills 的定位是“让 AI 自己判断什么时候用”触发靠的是 agent 对自然语言的理解不需要你显式点名。只有当描述写得不清楚、AI 识别不到场景时才需要你手动提示一下。理解了这一点后面调试 Skills 会省掉很多力气。2. 8 类值得装的 Skills按场景选别贪多GitHub 上已经有很多 Skills 集合项目了像 awesome-claude-skills、superpower skills 这类动辄收录上百个技能。但我建议别一口气全装技能太多反而让模型“选择困难”还会拖慢响应。下面这 8 类是我在不同项目里实际用下来、价值最明显的方向你可以结合自己的技术栈挑着配。2.1 代码审查与质量检查类性价比最高的一类没有之一。把审查维度前置写死比如“优先检查空指针、注入风险、未捕获异常、资源泄漏、过度复杂函数”AI 就会按统一标准去看代码而不是随机发挥。我还会要求它按“严重 / 中等 / 建议”三档输出严重级别给出明确的修改示例方便直接抄作业。这类 Skill 最合适的应用节点有两个。一个是提交代码前让 AI 快速过一遍 diff挡住低级错误另一个是 PR 阶段配合 Agent 自动审查让人工 Review 聚焦在更难的设计问题上。坚持跑一段时间后你会发现团队代码风格会肉眼可见地变稳定因为标准统一了不会因为今天审查人心情好就多写几句、心情差就一笔带过。我还见过有团队把“安全审查”单独拆成一个 Skill专门看依赖版本、密钥硬编码、权限配置效果也不错。2.2 前端还原与 UI 实现类前端应该是受 AI 编程影响最大的方向。给一张设计稿截图让 AI 直接生成可运行的 React 或 Vue 组件已经不算新鲜事。但如果没有 Skill生成结果经常是“看起来像细节全崩”因为 AI 不了解你项目里用的是什么组件库、样式方案是什么、响应式断点怎么切。这类 Skill 的核心价值不是让 AI 会写前端而是让它知道“怎么写才符合当前项目的规范”。我会在 SKILL.md 里写清楚项目用的是 Element 还是 Ant Design样式用 Tailwind 还是 CSS Modules颜色从设计 token 的哪个变量取间距走几倍栅格图标怎么引入移动端断点到多少像素开始堆叠。把这些写进 Skill 后AI 生成的前端代码基本能达到“可提交评审”的质量你只需要在交互细节上把把关。补充一个技巧在 Skill 里附上一两份“优秀示例组件”的代码片段AI 会模仿示例的写法比单纯用文字描述规范有效得多。2.3 数据库与查询优化类写过几年后端的人都知道SQL 优化是最考经验的工作。Skill 在这里的作用是把一名老手的排查流程固化下来。我见过一个团队把“慢查询分析”做成 Skill第一步收集 EXPLAIN 输出第二步识别全表扫描、索引失效、临时排序等问题第三步根据表结构和数据量给索引建议第四步用 EXPLAIN 验证优化效果。整个链路非常清晰。这类 Skill 还有个隐藏价值它能让新人直接上手。以前团队成员遇到 SQL 慢只能截图找老同事看现在只要把 EXPLAIN 结果贴给 AI按 Skill 流程走一遍至少能拿到一个靠谱的初步结论再找人工确认就轻松多了。说白了这就是把“老师傅的肚子里的经验”变成团队资产。配合数据库模型文件一起放进 Skill 目录AI 就能结合实际的表结构给出更有针对性的建议而不是泛泛而谈“建议加索引”。2.4 测试用例生成类写单测对很多人来说是件枯燥活但 AI 恰恰擅长。测试生成 Skill 需要写清楚的内容包括测试框架是什么Jest、Vitest、pytest 等、断言风格偏好、Mock 规则、覆盖率要求以及哪些东西不要测比如不要重复测第三方库的行为。把这几条写清楚AI 生成的测试代码才符合团队风格而不是每次都得手工重写。我个人很推荐一个变体把“根据 bug 描述生成回归测试”做成 Skill。开发者在修复 issue 以后直接让 AI 按这个模式生成对应的回归用例确认这个问题不会再冒出来。这个用法对长期维护的项目特别有价值相当于每次修 bug 的成果都自动沉淀成保护网。实测下来配合定时执行能明显降低重复 bug 率。2.5 文档与注释维护类文档是很多人的痛点但偏偏不得不做。文档类 Skill 能干的事不少生成 README、维护 CHANGELOG、写 API 注释、生成 Swagger 描述。这类 Skill 最关键的设计点是明确“给程序员看的文档”和“给用户看的文档”的差异不能让 AI 写出来的东西两头不靠。我自己的做法是在 Skill 里规定 README 必须有项目简介、安装方式、快速开始、常见问题四部分Swagger 描述则必须覆盖请求参数类型、响应示例、错误码说明。这样一来AI 生成的文档不会光顾着堆术语而是真的可读、可维护。另外如果你维护的开源项目在 GitHub 上还可以在 Skill 里附上贡献指南模板让 AI 帮新贡献者生成 issue 模板、PR 模板也算是一种“隐形文档”。2.6 技术方案与架构设计类写技术方案是 AI 能帮上大忙的场景。架构设计类 Skill 的核心是让 AI 按固定模板来思考和输出背景与目标、需求分析、技术选型对比、架构图描述文字版、数据模型设计、接口设计、风险与备选方案、上线与回滚计划。这类 Skill 的效果上限取决于你塞进去的“强制检查项”。比如我会要求 AI 在方案里必须回答“这个设计能应对未来半年的增长吗”“如果这个模块挂了影响范围有多大”这类问题。有了这些硬性约束AI 出方案的质量会明显提升而不是写一堆正确的废话。刚开始可以看一些优秀的 RFC 文档把它们的结构提炼成一个模板再做成本项目的规范 Skill比自己凭空定义要靠谱得多。2.7 图片生成与视觉素材类可能有人疑惑图片生成也能做成 Skills现在确实可以了。在一些编辑器工具链里通过调用外部图片生成接口Skill 可以帮助快速出组件预览图、项目封面、占位素材甚至可以封装成一个“图片生成技能包”用在文档配图自动化的场景里。这类 Skill 的设计要点是提前统一画布尺寸、风格关键词和输出路径。比如我见过有人把“产品功能示意图生成”做成 Skill规定图片尺寸 16:9、风格简洁插画、输出到 docs/images 目录。这样一来项目的配图风格保持一致不会今天一个样明天一个样。如果有版权风险或者出图质量不稳定的情况也建议在 Skill 里加一步“生成后人工确认”的流程避免直接进产线。2.8 代码迁移与重构类最后一个分类但使用频率可能最高。代码迁移类 Skill 适合处理“Python 2 迁移到 Python 3”“JavaScript 改造成 TypeScript”“旧框架升级到新框架”这类大工程。这类任务最大的风险是“改着改着把原行为改没了”所以 Skill 里必须明确强调“保持行为不变”的原则。具体操作上我会让 AI 先梳理现有代码的输入输出契约再生成迁移清单接着分模块迁移并对比结果每完成一块输出变更说明。把流程写进 Skill 之后这类耗时工程就能交给 AI 一步步执行开发者在关键节点做 Review 就够了。再配合一份迁移前后的测试用例集效果会好很多毕竟迁移最大的痛点就是改完不自知地埋了雷。3. Cursor 与 Claude Code 接入全流程从零到一落地先说明一点Cursor 和 Claude Code 的 Skills 机制都在快速迭代不同版本在配置入口和参数上可能会略有差异。下面这套流程是基于当前主流版本里兼容性最好的做法近期版本基本都能跑通如果你的版本界面有差异找 Settings 里带“Skills”或“Agent”字样的位置即可。3.1 先搞懂 Skills 的标准格式SKILL.md不管是 Cursor 还是 Claude CodeSkill 的核心文件都叫 SKILL.md。它分两部分头部 YAML 元信息和正文 Markdown 说明。头部一般包含这几个字段。字段作用注意事项name技能名称习惯用动词短语如 code-review、test-gendescription技能描述写清楚触发场景是 Agent 判断调用的核心依据version版本号方便迭代追踪例如 0.1.0正文部分可以自由发挥但建议要有这几块适用场景、执行步骤、输出格式、质量标准、参考资源。下面是一个可以直接抄的简化模板。--- name: code-review description: 当用户要求审查代码、检查代码质量或提交前验证时使用。适用于代码审查场景。 version: 0.1.0 --- # Code Review Skill ## 适用场景 - 提交 merge request 前快速检查 - 团队 Code Review 时辅助发现问题 ## 执行步骤 1. 阅读目标代码梳理核心逻辑和数据流。 2. 按下列维度逐项检查空指针与异常处理、安全漏洞、资源泄漏、边界条件、命名与可读性。 3. 对问题分类严重可能导致崩溃或安全风险、中等影响正确性或性能、建议代码风格与可维护性。 4. 输出问题清单每个问题包含位置、原因、修改建议和简短的修改示例。 ## 输出格式 - 严重 / 中等 / 建议 三档标题 - 每个问题按文件位置 - 问题描述 - 修改建议 - 示例代码 组织写完后把这个文件放到对应的 skills 目录里目录名最好和技能名一致。一个 Skill 目录里还可以放参考资料、模板文件、示例代码建议都用相对路径引用避免 Agent 找不到资源。3.2 在 Cursor 里接入 Skills 五步走第一步确认版本支持。打开 Cursor 的 Settings搜一下“Skills”或“Agent”如果能找到相关开关说明版本支持 Skills。找不到就先把 Cursor 升级到最新版旧版本是装不了的。第二步建目录。在项目根目录创建 .cursor/skills 文件夹。如果你希望 Skills 在多个项目里全局生效再看 Cursor 的全局配置目录一般都在用户主目录下的 .cursor 里。我的习惯是团队规范类的技能放项目级随 Git 走个人提效类的放全局换项目也能用。第三步写 SKILL.md。按 3.1 的模板做第一个 Skill。个人建议从“生成 README”这种简单任务开始跑通流程再去碰复杂的不然第一个就遇到各种调试问题容易劝退。第四步让 Agent 启用。在 Cursor 里切到 Agent 模式在上下文面板或输入框附近找到 Skills 的开关打开它。这个开关本质上是允许 Agent 在回答时主动读取技能文件。不开的话你写好也不会被自动触发。第五步联动测试。用一个自然语言问题测试比如“帮我 review 一下当前文件”。看它有没有按 SKILL.md 里的步骤和格式来执行。如果输出格式跟 Skill 里定义的一致说明已经生效如果 AI 自己乱答说明没读到文件回头检查目录和开关。3.3 在 Claude Code 里接入 Skills 五步走第一步安装 Claude Code。如果还没装在终端执行下面这条命令然后按提示完成登录授权。npm install -g anthropic-ai/claude-code第二步建目录。Claude Code 同样支持两个层面的 Skills 目录。项目级是 .claude/skills跟着代码仓库走适合团队共享用户级是 ~/.claude/skills适合个人通用技能。团队规范类的建议放项目级新成员克隆仓库后自动就带上。第三步写 SKILL.md。目录建好后把写好的 Skill 放进去。这里注意Claude Code 对目录命名建议用英文小写加短横线比如 skills/code-review/SKILL.md不要带空格或大写。第四步检查加载。在 claude 交互界面里输入 /skills 或 /agents不同版本命令可能不同能列出技能列表的就行看到刚才创建的技能名称就说明加载成功。看不到就先检查目录层级和文件命名。第五步真实场景验证。故意给一段有问题的代码手动触发一次审查类 Skill。在 Claude Code 的日志输出里通常能看到读取 SKILL.md 的记录这个细节能帮你快速定位问题出在加载环节还是触发环节。3.4 让 Skill 真正“好用”的三个设计经验装好 Skill 只是万里长征第一步真正好用还差三件事。第一description 一定要写“触发场景”而不是“功能定义”。比如不要写“代码审查工具”而要写“当用户要求审查代码、检查代码质量或提交前验证时使用”。因为 Agent 是用你的自然语言去匹配 description 的场景描述越贴近真实说法触发就越准。你写在 description 里的每一个关键词都可能成为触发条件多用用户真正会说的词。第二一个 Skill 只做一件事。别想做“万能助手”那只会让 Agent 读完手册还是不知道具体该怎么办。我见过有人把几十条指令塞进一个 Skill结果 AI 输出越来越平庸。与其搞一个“大而全”不如拆成 code-review、test-gen、doc-gen 三个小 Skill互不干扰质量都能保证。第三执行步骤要能被验证。步骤里一定要有明确的“产出物”比如“最后输出一个 Markdown 表格”或“每个问题至少要有一行修改示例”。这样你一眼就能确认 AI 有没有照做。如果步骤写得过于开放AI 自由发挥的空间大Skill 的约束力就形同虚设了。补充一点Skill 里可以引用示例代码作为风格基准。AI 是强模仿模型给它几个“优秀参考”往往比十条规则更有效。3.5 快速验证与自测方法装完 Skill 别急着投入生产按下面的思路自测一遍能省下后面一大堆麻烦事。测试一触发测试。用一个明确命中 description 的问题去问比如“帮我审查这段代码”看 AI 是否按 Skill 的流程走。如果不触发优先考虑 description 和用户问法是否对得上。测试二边界测试。问一个偏离主题但沾点边的问题比如“给我讲讲代码审查的意义”正常情况不应该加载审查流程。如果误触发检查 description 是不是写得范围过大。测试三格式稳定性测试。准备两段质量差异很大的代码分别让 AI 审查看它是否都严格按照 Skill 里定义的输出格式来给结果。格式稳定才说明 Skill 的约束真正生效了。三关都过了这个 Skill 基本就可以正式启用。以后维护流程就是在仓库里维护这些 Skill 文件改模板、加规则都能通过更新文件来完成比在每次对话里反复叮嘱 AI 要可靠得多。4. 踩坑实录不生效、迁移与中文环境问题排查4.1 为什么 Skill 不触发或没生效这是新手最容易碰到的问题。明明按格式写了 SKILL.md目录也建好了AI 就是不理。我从项目现场整理了四个最常见的原因现象原因解决办法AI 完全没反应目录或文件名错误检查是否在 .cursor/skills 或 .claude/skills 下不按步骤执行description 匹配不上把 description 改成贴近用户表达的触发场景部分生效部分不生效SKILL.md 语法有问题检查 YAML 头部冒号后要有空格其他项目能用本项目不行项目级配置覆盖检查项目根目录是否有更高优先级的配置目录排查的时候有个小技巧Cursor 和 Claude Code 都能在输出日志里看到 Skill 的加载记录。如果日志里有加载记录但还是不触发那就重写 description如果连加载记录都没有优先查路径和文件命名。很多时候就是目录大小写、横线写成了下划线这种低级问题。4.2 跨工具迁移与团队协作问题Cursor 和 Claude Code 的 Skills 都基于 SKILL.md 约定所以同一个 Skill 包在这两个工具之间迁移基本就是复制粘贴的活。但要注意两个工具对 Skill 里扩展字段和可执行脚本的支持度并不完全一样直接搬过去有时候会“水土不服”。我在迁移时发现最稳妥的做法是让 Skill 只用 Markdown 描述流程不把可执行脚本写死在里面。如果确实需要脚本把脚本放在 Skill 目录里并在步骤中明确告诉 AI“脚本在 scripts/xxx.py运行前先查看注释”。这样不管在哪个工具里Agent 都知道先去读脚本再执行而不是瞎猜。团队协作方面我强烈建议把项目级 Skills 目录纳入 Git 管理并在 README 里写清楚每个 Skill 的用途和维护人。换电脑、加新人、改标准都不会丢失这套技能资产。另外如果要同步到 Cursor 和 Claude Code 两套工具可以在项目里分别建 .cursor/skills 和 .claude/skills然后把同一份 SKILL.md 放进去。虽然看起来有点重复但能保证两边行为一致。4.3 写 Skills 时最容易踩的三个坑第一个坑把 Skill 当成角色设定。有些人喜欢在 SKILL.md 里写一堆“你是一名资深架构师”“你精通所有语言”实际上这对执行帮助不大。Skill 的核心是流程和标准角色设定一两句带过就够了写太多反而稀释重点。第二个坑description 范围控制不好。我在 3.4 里提过场景化描述的重要性这里再补充一个反面例子。如果描述写的是“帮助开发者提高代码质量”那很多问题都可能命中触发率反而下降正确写法是“当用户要求审查代码、检查代码质量或提交前验证时使用”。把命中范围缩到最优触发才能精准。第三个坑资源文件路径写错。Skill 目录里引用示例文件或模板时相对路径很容易出错。因为 Agent 执行任务时的工作目录不一定是 Skill 所在目录所以最好在正文里明确写一句“所有相对路径都基于本 SKILL.md 所在目录”。这句话看着不起眼却能省下不少排查时间。4.4 中文环境设置与常用路径整理最后回应两个大家问得比较多的小事在 Cursor 里看中文界面以及 Claude Code 里的中文交互。Cursor 的界面语言可以在设置里直接调整。打开 Cursor 的 Settings找到 Language 这一项选择“中文简体”重启编辑器就生效了。这个设置不会影响代码编辑和调试能力只是把菜单和界面提示变成中文对中文用户更友好。Claude Code 本身是命令行工具主界面目前基本是全英文但完全可以用中文交互。你可以在 Skill 的 description 和执行步骤里写中文比如“当用户要求对代码进行审查时使用”。你用中文提问Agent 也能识别并触发对应 Skill输出也可以是中文格式。常用路径整理如下建议收藏Cursor 项目级 Skills项目根目录 /.cursor/skills/Cursor 全局 Skills用户主目录 /.cursor/skills/Claude Code 项目级 Skills项目根目录 /.claude/skills/Claude Code 用户级 Skills用户主目录 /.claude/skills/典型 Skill 结构skills/ /SKILL.md结尾先跑通一个再复制出去我自己玩 Skills 差不多两个月最明显的感觉是没配 Skills 之前AI 像一个“不懂就问”的新人我需要把话讲得非常细它才能干对活配好 Skills 之后AI 更像一个带说明书的同事我只需要派活它自己会按流程执行。这种转变带来的提效是全方位的不只是少打几个字而是产出质量更稳定、团队成员之间的协作也更统一了。如果你还没上手我的建议非常简单从你平时最常做、最烦做的那件事开始比如代码审查或者 README 生成照着 3.1 的模板写一个最少可用的 Skill跑通一遍完整流程。等你体会到“一次配置、到处复用”带来的快感之后你会自然地去想还有什么重复劳动能这样固化下来到那时候你大概就理解为什么我说 Skills 是 AI 编程时代最值得花时间研究的东西了。 
长河君 · 2026/10/18 20:52:45 · 阅读 1.2k Cursor与Claude Code Skills技能包实战：从重复劳动到一劳永逸
现在用 Cursor 和 Claude Code 的人越来越多了但我发现大多数人的用法还停留在“开个对话框把问题丢进去等答案”。这其实是非常低效的因为每次对话你都在重复描述同样的上下文、同样的规范、同样的处理流程AI 每次都在“重新认识你”质量自然忽高忽低。Skills技能包就是为终结这种重复劳动而生的。它本质上是给 AI 助手装的一份“可复用操作手册”你把某个任务的前置条件、执行步骤、判断标准和输出格式都写清楚存成 Skill。之后只要在 Cursor 或 Claude Code 里触发它AI 就会按这份手册自动干活既不需要你反复交代背景也不会每次都自由发挥。这篇文章会分四块展开先讲清楚 Skills 的运行原理和价值再整理 8 类我实际用过、确实能提效的 Skills 推荐然后把 Cursor 和 Claude Code 的接入全流程走一遍包括目录结构、SKILL.md 写法、验证方法最后记录一些容易踩的坑和排查思路。适合每天重度使用 AI 写代码、想把手头重复工作固化下来的开发者也适合想在团队里推广统一编码规范和评审流程的工程负责人。1. 先搞懂 Skills 的核心价值它到底解决了什么问题1.1 从“一问一答”到“一劳永逸”先举个例子。假设你每周都要做代码审查。以前的做法是把代码贴给 Cursor然后写一大段提示词比如“请重点检查性能问题、安全漏洞、边界条件、命名规范最后按严重程度给结论”。每次贴不同的代码但提示词几乎一模一样效率很低而且每次 AI 的侧重点还不一样有时候抓了一堆无关紧要的格式问题真正致命的逻辑漏洞反而没提。有了 Skill 之后你只需要把代码丢过去说一句“用 code-review 检查一下”。AI 自动加载那份写好的审查流程知道要看哪几个维度、参考什么标准、按什么格式输出。这个变化的本质是你不再跟 AI“商量”任务怎么做而是直接给它派一个定义好的活。Prompt 写一次之后所有项目、所有成员都能复用AI 的输出质量也从“看当天状态”变成“看手册标准”。我实测下来同一个审查任务用 Skill 跑出来的规则覆盖度明显更全输出也更规整很少出现漏检或偏题。再往深一层说Skill 在工程上其实就是普通文件和目录核心是一个 SKILL.md。文件头是 YAML 格式的元信息包含技能名称、场景描述、版本号等正文则是给 AI 看的行为说明告诉它这个任务要分几步做、每一步注意什么、最终产出什么样子。当用户的说法命中 description 里描述的场景Agent 就会把这个文件当成参考手册按里面的步骤一步步执行。这个机制说白了就是两个词触发 执行。所以后面你会发现写 Skill 的功夫一大半都花在 description 和步骤设计上这一步做好了才能“一劳永逸”。1.2 Skills 与 Rules、Commands 的区别很多人会把 Skills 和 Cursor 里的 Rules、Commands 搞混。这三样东西都能影响 AI 行为但定位完全不一样我整理了一张对比表。类型典型位置核心作用适用场景Rules.cursor/rules、.claude/rules定义行为边界持续生效全局约束比如“所有代码必须有类型定义”Commands.cursor/commands、斜杠命令预置快捷指令手动触发固定动作比如 /review 调用一段 PromptSkills.cursor/skills、.claude/skills带完整流程的技能包自动触发完整任务比如代码审查、测试生成、架构方案按我自己的使用习惯三者分工通常是Rules 管“不能做什么”Commands 管“一键发起什么”Skills 管“拿到任务后按什么流程做”。只要搭配得当AI 的行为既不会跑偏又不用每次手动启动。这里尤其要提醒一点Skills 和 Commands 最容易被混淆。很多人装完 Skill非要手动敲个命令去调用发现没反应就以为没装好。实际上 Skills 的定位是“让 AI 自己判断什么时候用”触发靠的是 agent 对自然语言的理解不需要你显式点名。只有当描述写得不清楚、AI 识别不到场景时才需要你手动提示一下。理解了这一点后面调试 Skills 会省掉很多力气。2. 8 类值得装的 Skills按场景选别贪多GitHub 上已经有很多 Skills 集合项目了像 awesome-claude-skills、superpower skills 这类动辄收录上百个技能。但我建议别一口气全装技能太多反而让模型“选择困难”还会拖慢响应。下面这 8 类是我在不同项目里实际用下来、价值最明显的方向你可以结合自己的技术栈挑着配。2.1 代码审查与质量检查类性价比最高的一类没有之一。把审查维度前置写死比如“优先检查空指针、注入风险、未捕获异常、资源泄漏、过度复杂函数”AI 就会按统一标准去看代码而不是随机发挥。我还会要求它按“严重 / 中等 / 建议”三档输出严重级别给出明确的修改示例方便直接抄作业。这类 Skill 最合适的应用节点有两个。一个是提交代码前让 AI 快速过一遍 diff挡住低级错误另一个是 PR 阶段配合 Agent 自动审查让人工 Review 聚焦在更难的设计问题上。坚持跑一段时间后你会发现团队代码风格会肉眼可见地变稳定因为标准统一了不会因为今天审查人心情好就多写几句、心情差就一笔带过。我还见过有团队把“安全审查”单独拆成一个 Skill专门看依赖版本、密钥硬编码、权限配置效果也不错。2.2 前端还原与 UI 实现类前端应该是受 AI 编程影响最大的方向。给一张设计稿截图让 AI 直接生成可运行的 React 或 Vue 组件已经不算新鲜事。但如果没有 Skill生成结果经常是“看起来像细节全崩”因为 AI 不了解你项目里用的是什么组件库、样式方案是什么、响应式断点怎么切。这类 Skill 的核心价值不是让 AI 会写前端而是让它知道“怎么写才符合当前项目的规范”。我会在 SKILL.md 里写清楚项目用的是 Element 还是 Ant Design样式用 Tailwind 还是 CSS Modules颜色从设计 token 的哪个变量取间距走几倍栅格图标怎么引入移动端断点到多少像素开始堆叠。把这些写进 Skill 后AI 生成的前端代码基本能达到“可提交评审”的质量你只需要在交互细节上把把关。补充一个技巧在 Skill 里附上一两份“优秀示例组件”的代码片段AI 会模仿示例的写法比单纯用文字描述规范有效得多。2.3 数据库与查询优化类写过几年后端的人都知道SQL 优化是最考经验的工作。Skill 在这里的作用是把一名老手的排查流程固化下来。我见过一个团队把“慢查询分析”做成 Skill第一步收集 EXPLAIN 输出第二步识别全表扫描、索引失效、临时排序等问题第三步根据表结构和数据量给索引建议第四步用 EXPLAIN 验证优化效果。整个链路非常清晰。这类 Skill 还有个隐藏价值它能让新人直接上手。以前团队成员遇到 SQL 慢只能截图找老同事看现在只要把 EXPLAIN 结果贴给 AI按 Skill 流程走一遍至少能拿到一个靠谱的初步结论再找人工确认就轻松多了。说白了这就是把“老师傅的肚子里的经验”变成团队资产。配合数据库模型文件一起放进 Skill 目录AI 就能结合实际的表结构给出更有针对性的建议而不是泛泛而谈“建议加索引”。2.4 测试用例生成类写单测对很多人来说是件枯燥活但 AI 恰恰擅长。测试生成 Skill 需要写清楚的内容包括测试框架是什么Jest、Vitest、pytest 等、断言风格偏好、Mock 规则、覆盖率要求以及哪些东西不要测比如不要重复测第三方库的行为。把这几条写清楚AI 生成的测试代码才符合团队风格而不是每次都得手工重写。我个人很推荐一个变体把“根据 bug 描述生成回归测试”做成 Skill。开发者在修复 issue 以后直接让 AI 按这个模式生成对应的回归用例确认这个问题不会再冒出来。这个用法对长期维护的项目特别有价值相当于每次修 bug 的成果都自动沉淀成保护网。实测下来配合定时执行能明显降低重复 bug 率。2.5 文档与注释维护类文档是很多人的痛点但偏偏不得不做。文档类 Skill 能干的事不少生成 README、维护 CHANGELOG、写 API 注释、生成 Swagger 描述。这类 Skill 最关键的设计点是明确“给程序员看的文档”和“给用户看的文档”的差异不能让 AI 写出来的东西两头不靠。我自己的做法是在 Skill 里规定 README 必须有项目简介、安装方式、快速开始、常见问题四部分Swagger 描述则必须覆盖请求参数类型、响应示例、错误码说明。这样一来AI 生成的文档不会光顾着堆术语而是真的可读、可维护。另外如果你维护的开源项目在 GitHub 上还可以在 Skill 里附上贡献指南模板让 AI 帮新贡献者生成 issue 模板、PR 模板也算是一种“隐形文档”。2.6 技术方案与架构设计类写技术方案是 AI 能帮上大忙的场景。架构设计类 Skill 的核心是让 AI 按固定模板来思考和输出背景与目标、需求分析、技术选型对比、架构图描述文字版、数据模型设计、接口设计、风险与备选方案、上线与回滚计划。这类 Skill 的效果上限取决于你塞进去的“强制检查项”。比如我会要求 AI 在方案里必须回答“这个设计能应对未来半年的增长吗”“如果这个模块挂了影响范围有多大”这类问题。有了这些硬性约束AI 出方案的质量会明显提升而不是写一堆正确的废话。刚开始可以看一些优秀的 RFC 文档把它们的结构提炼成一个模板再做成本项目的规范 Skill比自己凭空定义要靠谱得多。2.7 图片生成与视觉素材类可能有人疑惑图片生成也能做成 Skills现在确实可以了。在一些编辑器工具链里通过调用外部图片生成接口Skill 可以帮助快速出组件预览图、项目封面、占位素材甚至可以封装成一个“图片生成技能包”用在文档配图自动化的场景里。这类 Skill 的设计要点是提前统一画布尺寸、风格关键词和输出路径。比如我见过有人把“产品功能示意图生成”做成 Skill规定图片尺寸 16:9、风格简洁插画、输出到 docs/images 目录。这样一来项目的配图风格保持一致不会今天一个样明天一个样。如果有版权风险或者出图质量不稳定的情况也建议在 Skill 里加一步“生成后人工确认”的流程避免直接进产线。2.8 代码迁移与重构类最后一个分类但使用频率可能最高。代码迁移类 Skill 适合处理“Python 2 迁移到 Python 3”“JavaScript 改造成 TypeScript”“旧框架升级到新框架”这类大工程。这类任务最大的风险是“改着改着把原行为改没了”所以 Skill 里必须明确强调“保持行为不变”的原则。具体操作上我会让 AI 先梳理现有代码的输入输出契约再生成迁移清单接着分模块迁移并对比结果每完成一块输出变更说明。把流程写进 Skill 之后这类耗时工程就能交给 AI 一步步执行开发者在关键节点做 Review 就够了。再配合一份迁移前后的测试用例集效果会好很多毕竟迁移最大的痛点就是改完不自知地埋了雷。3. Cursor 与 Claude Code 接入全流程从零到一落地先说明一点Cursor 和 Claude Code 的 Skills 机制都在快速迭代不同版本在配置入口和参数上可能会略有差异。下面这套流程是基于当前主流版本里兼容性最好的做法近期版本基本都能跑通如果你的版本界面有差异找 Settings 里带“Skills”或“Agent”字样的位置即可。3.1 先搞懂 Skills 的标准格式SKILL.md不管是 Cursor 还是 Claude CodeSkill 的核心文件都叫 SKILL.md。它分两部分头部 YAML 元信息和正文 Markdown 说明。头部一般包含这几个字段。字段作用注意事项name技能名称习惯用动词短语如 code-review、test-gendescription技能描述写清楚触发场景是 Agent 判断调用的核心依据version版本号方便迭代追踪例如 0.1.0正文部分可以自由发挥但建议要有这几块适用场景、执行步骤、输出格式、质量标准、参考资源。下面是一个可以直接抄的简化模板。--- name: code-review description: 当用户要求审查代码、检查代码质量或提交前验证时使用。适用于代码审查场景。 version: 0.1.0 --- # Code Review Skill ## 适用场景 - 提交 merge request 前快速检查 - 团队 Code Review 时辅助发现问题 ## 执行步骤 1. 阅读目标代码梳理核心逻辑和数据流。 2. 按下列维度逐项检查空指针与异常处理、安全漏洞、资源泄漏、边界条件、命名与可读性。 3. 对问题分类严重可能导致崩溃或安全风险、中等影响正确性或性能、建议代码风格与可维护性。 4. 输出问题清单每个问题包含位置、原因、修改建议和简短的修改示例。 ## 输出格式 - 严重 / 中等 / 建议 三档标题 - 每个问题按文件位置 - 问题描述 - 修改建议 - 示例代码 组织写完后把这个文件放到对应的 skills 目录里目录名最好和技能名一致。一个 Skill 目录里还可以放参考资料、模板文件、示例代码建议都用相对路径引用避免 Agent 找不到资源。3.2 在 Cursor 里接入 Skills 五步走第一步确认版本支持。打开 Cursor 的 Settings搜一下“Skills”或“Agent”如果能找到相关开关说明版本支持 Skills。找不到就先把 Cursor 升级到最新版旧版本是装不了的。第二步建目录。在项目根目录创建 .cursor/skills 文件夹。如果你希望 Skills 在多个项目里全局生效再看 Cursor 的全局配置目录一般都在用户主目录下的 .cursor 里。我的习惯是团队规范类的技能放项目级随 Git 走个人提效类的放全局换项目也能用。第三步写 SKILL.md。按 3.1 的模板做第一个 Skill。个人建议从“生成 README”这种简单任务开始跑通流程再去碰复杂的不然第一个就遇到各种调试问题容易劝退。第四步让 Agent 启用。在 Cursor 里切到 Agent 模式在上下文面板或输入框附近找到 Skills 的开关打开它。这个开关本质上是允许 Agent 在回答时主动读取技能文件。不开的话你写好也不会被自动触发。第五步联动测试。用一个自然语言问题测试比如“帮我 review 一下当前文件”。看它有没有按 SKILL.md 里的步骤和格式来执行。如果输出格式跟 Skill 里定义的一致说明已经生效如果 AI 自己乱答说明没读到文件回头检查目录和开关。3.3 在 Claude Code 里接入 Skills 五步走第一步安装 Claude Code。如果还没装在终端执行下面这条命令然后按提示完成登录授权。npm install -g anthropic-ai/claude-code第二步建目录。Claude Code 同样支持两个层面的 Skills 目录。项目级是 .claude/skills跟着代码仓库走适合团队共享用户级是 ~/.claude/skills适合个人通用技能。团队规范类的建议放项目级新成员克隆仓库后自动就带上。第三步写 SKILL.md。目录建好后把写好的 Skill 放进去。这里注意Claude Code 对目录命名建议用英文小写加短横线比如 skills/code-review/SKILL.md不要带空格或大写。第四步检查加载。在 claude 交互界面里输入 /skills 或 /agents不同版本命令可能不同能列出技能列表的就行看到刚才创建的技能名称就说明加载成功。看不到就先检查目录层级和文件命名。第五步真实场景验证。故意给一段有问题的代码手动触发一次审查类 Skill。在 Claude Code 的日志输出里通常能看到读取 SKILL.md 的记录这个细节能帮你快速定位问题出在加载环节还是触发环节。3.4 让 Skill 真正“好用”的三个设计经验装好 Skill 只是万里长征第一步真正好用还差三件事。第一description 一定要写“触发场景”而不是“功能定义”。比如不要写“代码审查工具”而要写“当用户要求审查代码、检查代码质量或提交前验证时使用”。因为 Agent 是用你的自然语言去匹配 description 的场景描述越贴近真实说法触发就越准。你写在 description 里的每一个关键词都可能成为触发条件多用用户真正会说的词。第二一个 Skill 只做一件事。别想做“万能助手”那只会让 Agent 读完手册还是不知道具体该怎么办。我见过有人把几十条指令塞进一个 Skill结果 AI 输出越来越平庸。与其搞一个“大而全”不如拆成 code-review、test-gen、doc-gen 三个小 Skill互不干扰质量都能保证。第三执行步骤要能被验证。步骤里一定要有明确的“产出物”比如“最后输出一个 Markdown 表格”或“每个问题至少要有一行修改示例”。这样你一眼就能确认 AI 有没有照做。如果步骤写得过于开放AI 自由发挥的空间大Skill 的约束力就形同虚设了。补充一点Skill 里可以引用示例代码作为风格基准。AI 是强模仿模型给它几个“优秀参考”往往比十条规则更有效。3.5 快速验证与自测方法装完 Skill 别急着投入生产按下面的思路自测一遍能省下后面一大堆麻烦事。测试一触发测试。用一个明确命中 description 的问题去问比如“帮我审查这段代码”看 AI 是否按 Skill 的流程走。如果不触发优先考虑 description 和用户问法是否对得上。测试二边界测试。问一个偏离主题但沾点边的问题比如“给我讲讲代码审查的意义”正常情况不应该加载审查流程。如果误触发检查 description 是不是写得范围过大。测试三格式稳定性测试。准备两段质量差异很大的代码分别让 AI 审查看它是否都严格按照 Skill 里定义的输出格式来给结果。格式稳定才说明 Skill 的约束真正生效了。三关都过了这个 Skill 基本就可以正式启用。以后维护流程就是在仓库里维护这些 Skill 文件改模板、加规则都能通过更新文件来完成比在每次对话里反复叮嘱 AI 要可靠得多。4. 踩坑实录不生效、迁移与中文环境问题排查4.1 为什么 Skill 不触发或没生效这是新手最容易碰到的问题。明明按格式写了 SKILL.md目录也建好了AI 就是不理。我从项目现场整理了四个最常见的原因现象原因解决办法AI 完全没反应目录或文件名错误检查是否在 .cursor/skills 或 .claude/skills 下不按步骤执行description 匹配不上把 description 改成贴近用户表达的触发场景部分生效部分不生效SKILL.md 语法有问题检查 YAML 头部冒号后要有空格其他项目能用本项目不行项目级配置覆盖检查项目根目录是否有更高优先级的配置目录排查的时候有个小技巧Cursor 和 Claude Code 都能在输出日志里看到 Skill 的加载记录。如果日志里有加载记录但还是不触发那就重写 description如果连加载记录都没有优先查路径和文件命名。很多时候就是目录大小写、横线写成了下划线这种低级问题。4.2 跨工具迁移与团队协作问题Cursor 和 Claude Code 的 Skills 都基于 SKILL.md 约定所以同一个 Skill 包在这两个工具之间迁移基本就是复制粘贴的活。但要注意两个工具对 Skill 里扩展字段和可执行脚本的支持度并不完全一样直接搬过去有时候会“水土不服”。我在迁移时发现最稳妥的做法是让 Skill 只用 Markdown 描述流程不把可执行脚本写死在里面。如果确实需要脚本把脚本放在 Skill 目录里并在步骤中明确告诉 AI“脚本在 scripts/xxx.py运行前先查看注释”。这样不管在哪个工具里Agent 都知道先去读脚本再执行而不是瞎猜。团队协作方面我强烈建议把项目级 Skills 目录纳入 Git 管理并在 README 里写清楚每个 Skill 的用途和维护人。换电脑、加新人、改标准都不会丢失这套技能资产。另外如果要同步到 Cursor 和 Claude Code 两套工具可以在项目里分别建 .cursor/skills 和 .claude/skills然后把同一份 SKILL.md 放进去。虽然看起来有点重复但能保证两边行为一致。4.3 写 Skills 时最容易踩的三个坑第一个坑把 Skill 当成角色设定。有些人喜欢在 SKILL.md 里写一堆“你是一名资深架构师”“你精通所有语言”实际上这对执行帮助不大。Skill 的核心是流程和标准角色设定一两句带过就够了写太多反而稀释重点。第二个坑description 范围控制不好。我在 3.4 里提过场景化描述的重要性这里再补充一个反面例子。如果描述写的是“帮助开发者提高代码质量”那很多问题都可能命中触发率反而下降正确写法是“当用户要求审查代码、检查代码质量或提交前验证时使用”。把命中范围缩到最优触发才能精准。第三个坑资源文件路径写错。Skill 目录里引用示例文件或模板时相对路径很容易出错。因为 Agent 执行任务时的工作目录不一定是 Skill 所在目录所以最好在正文里明确写一句“所有相对路径都基于本 SKILL.md 所在目录”。这句话看着不起眼却能省下不少排查时间。4.4 中文环境设置与常用路径整理最后回应两个大家问得比较多的小事在 Cursor 里看中文界面以及 Claude Code 里的中文交互。Cursor 的界面语言可以在设置里直接调整。打开 Cursor 的 Settings找到 Language 这一项选择“中文简体”重启编辑器就生效了。这个设置不会影响代码编辑和调试能力只是把菜单和界面提示变成中文对中文用户更友好。Claude Code 本身是命令行工具主界面目前基本是全英文但完全可以用中文交互。你可以在 Skill 的 description 和执行步骤里写中文比如“当用户要求对代码进行审查时使用”。你用中文提问Agent 也能识别并触发对应 Skill输出也可以是中文格式。常用路径整理如下建议收藏Cursor 项目级 Skills项目根目录 /.cursor/skills/Cursor 全局 Skills用户主目录 /.cursor/skills/Claude Code 项目级 Skills项目根目录 /.claude/skills/Claude Code 用户级 Skills用户主目录 /.claude/skills/典型 Skill 结构skills/ /SKILL.md结尾先跑通一个再复制出去我自己玩 Skills 差不多两个月最明显的感觉是没配 Skills 之前AI 像一个“不懂就问”的新人我需要把话讲得非常细它才能干对活配好 Skills 之后AI 更像一个带说明书的同事我只需要派活它自己会按流程执行。这种转变带来的提效是全方位的不只是少打几个字而是产出质量更稳定、团队成员之间的协作也更统一了。如果你还没上手我的建议非常简单从你平时最常做、最烦做的那件事开始比如代码审查或者 README 生成照着 3.1 的模板写一个最少可用的 Skill跑通一遍完整流程。等你体会到“一次配置、到处复用”带来的快感之后你会自然地去想还有什么重复劳动能这样固化下来到那时候你大概就理解为什么我说 Skills 是 AI 编程时代最值得花时间研究的东西了。