1. 为什么技能包正在取代提示词收藏夹过去两年我见过太多开发者电脑里躺着一个叫prompts.md的文件里面塞满了从各处抄来的提示词片段用的时候复制粘贴用完就忘。这种方式在单次对话里勉强够用但一旦涉及多步骤、跨文件、需要调用外部工具的任务就彻底崩了。原因很简单提示词是一次性的话术而 Skills 是可复用的能力单元。Skills 这个概念的核心是把一段结构化的指令、配套的脚本、参考文档打包成一个目录用一份SKILL.md作为入口描述。Agent 在需要的时候自动加载它不需要你每次手动粘贴。这就像从每次做菜现查菜谱升级成厨房里常备一套预制调料包——你依然掌控火候但基础工序已经被固化下来了。我最初接触 Skills 是在给一个前端项目做批量重构的时候。当时需要把几十个组件的 class 写法统一迁移到 hooks如果纯靠对话每处理一个文件都要重新解释一遍规则。后来我把迁移规则、边界条件、常见错误处理写成了一个 SkillAgent 就能连续处理多个文件而保持一致的行为。这个体验的差异是质变级别的。这篇文章面向的是已经用过 Cursor 或 Claude Code、但还没系统建立自己技能库的开发者。我会拆解 8 类真正值得装的 Skills讲清楚每一类解决什么问题、为什么这样设计然后给出接入 Cursor 和 Claude Code 的完整流程包括那些官方文档里不会写的坑。2. 拆解 SKILL.md一个技能包到底由什么构成2.1 目录结构不是随便定的一个标准的 Skill 目录长这样my-skill/ ├── SKILL.md # 必需技能入口 ├── scripts/ # 可选可执行脚本 ├── references/ # 可选参考文档 └── assets/ # 可选模板、图片等资源SKILL.md是唯一必需的文件。它的开头是一段 YAML frontmatter至少包含name和description两个字段。description的写法极其关键——Agent 就是靠这段描述来判断当前任务要不要加载这个技能。我踩过的第一个坑就在这里。最初我把 description 写成了用于处理前端代码重构结果 Agent 几乎从不主动加载它因为太模糊了。后来改成当需要将 React class 组件迁移为函数组件hooks 时使用适用于 .jsx/.tsx 文件包含生命周期映射和状态迁移规则命中率立刻上来了。提示description 要写成触发条件 适用范围 核心能力的组合而不是一句功能概括。这是决定技能能否被自动调用的第一道门槛。2.2 正文部分该写什么frontmatter 下面是 Markdown 正文这部分是 Agent 真正读取的指令内容。我的经验是分成三块来写何时使用列出具体的触发场景越具体越好执行步骤分步骤的操作流程每步说清楚输入和输出边界与禁忌明确哪些情况不要用这个技能避免误触发很多人会把正文写成一篇教程这是误区。Agent 不需要你教它背景知识它需要的是可执行的指令。所以正文应该像操作手册而不是科普文章。2.3 脚本和参考文档的加载时机scripts/目录里的脚本不会自动执行而是当 SKILL.md 正文里明确指示运行 scripts/xxx.py时才会被调用。references/里的文档同理需要正文引用才会被读取。这个设计的好处是节省上下文。一个技能包可以带很多参考资料但只有真正需要时才加载不会一上来就占满窗口。我有个做 API 文档生成的技能references 里放了十几种语言的模板实际使用时只加载对应语言那一份。3. 八类值得长期留在技能库里的 Skills3.1 代码迁移与重构类这是投入产出比最高的一类。典型场景包括框架版本升级、语言特性迁移、目录结构重组。这类技能的价值在于一致性——人工重构容易在不同文件里用不同写法而技能包能保证规则统一执行。我建议把迁移规则写成映射表的形式比如旧写法新写法备注componentWillMountuseEffect(() {}, [])注意依赖数组componentDidUpdateuseEffect(() {}, [deps])需手动比对 prevProps这种表格 Agent 读起来最省事执行也最准确。3.2 测试用例生成类写测试是很多人的痛点。一个测试生成技能应该包含项目使用的测试框架、断言风格、mock 策略、覆盖率要求。我自己的技能里还加了一条优先覆盖边界条件而非 happy path这样生成的测试才有真正的防护价值。需要注意的是测试生成技能一定要绑定具体的测试框架版本。Jest 和 Vitest 的 API 有差异如果不写清楚Agent 会混用导致报错。3.3 文档与注释补全类这类技能解决的是代码写完了但没人愿意写文档的问题。核心是定义清楚文档的粒度和风格是生成 JSDoc 还是 Markdown参数说明要写到什么程度是否包含示例代码我的做法是在技能里放一份文档模板让 Agent 照着填。这样输出的文档格式统一后续维护也方便。3.4 提交信息与变更日志类Git commit message 的规范执行是个老问题。一个提交信息技能可以做到读取暂存区的 diff、按 Conventional Commits 规范生成 message、自动关联 issue 编号。这类技能的关键是读取 diff这一步。要明确告诉 Agent 用git diff --staged而不是git diff否则会读到未暂存的改动生成的 message 和实际提交内容对不上。3.5 依赖管理与安全审计类定期检查依赖版本、识别已知问题、生成升级建议——这些重复劳动很适合做成技能。我通常会让技能输出一个分级报告必须升级的、建议升级的、可以观望的每项附上理由。3.6 数据格式转换类JSON 转 YAML、CSV 转 SQL、Protobuf 转 TypeScript 类型……这类转换规则明确、重复度高是技能包的理想场景。把转换规则和边界情况如嵌套结构、特殊字符转义写清楚基本可以一劳永逸。3.7 项目脚手架类新建项目时的一堆初始化操作——目录结构、配置文件、基础依赖、lint 规则——可以打包成一个技能。我有个技能专门用来初始化内部项目模板跑一次就能得到符合团队规范的项目骨架。3.8 领域知识注入类这类比较特殊是把特定业务领域的知识固化下来。比如我们公司的 API 错误码规范、这个项目的状态管理约定。新加入项目的开发者或者 Agent加载这个技能后就能按团队约定行事减少沟通成本。4. 接入 Cursor 的完整流程与实测细节4.1 技能文件的存放位置Cursor 对 Skills 的支持是通过项目根目录下的特定文件夹实现的。我实测下来把技能放在.cursor/skills/目录下最稳妥每个技能一个子目录里面放SKILL.md。如果你希望技能在所有项目里都能用可以放到用户级目录。但我的建议是项目相关的技能放项目里通用技能才放全局。否则全局技能太多Agent 的判断准确率会下降。4.2 让 Cursor 识别技能的配置要点Cursor 不会自动扫描所有目录。你需要在项目配置里明确声明技能路径。具体做法是在.cursor/下维护配置文件把技能目录加进去。这里有个容易忽略的点修改配置后需要重启 Cursor 或者重新加载窗口否则新技能不会被识别。我第一次配置时折腾了半小时最后发现只是没重启。4.3 验证技能是否生效配置完成后不要急着上真实任务。先做一个简单验证在对话里描述一个明确匹配某个技能触发条件的任务看 Agent 是否会主动提及使用了该技能。如果没反应按这个顺序排查检查SKILL.md的 frontmatter 格式是否正确YAML 对缩进敏感检查 description 是否足够具体检查配置文件路径是否写对重启编辑器4.4 Cursor 中文环境下的注意事项很多人在用中文界面的 Cursor。实测下来界面语言不影响技能加载但会影响 Agent 的回复语言。如果你希望技能执行过程中的输出也是中文需要在SKILL.md正文里明确写输出使用中文。另外中文路径偶尔会出问题。我建议技能目录和文件名都用英文避免不必要的麻烦。5. 接入 Claude Code 的完整流程与踩坑记录5.1 技能目录的约定Claude Code 对技能的识别有自己的约定。它会在特定目录下查找技能具体路径取决于你的安装方式。我建议先确认你的 Claude Code 版本然后查阅对应的目录约定。手动安装 GitHub 上的技能时流程是下载技能目录 → 放到约定的技能路径下 → 确认SKILL.md存在且格式正确。5.2 手动安装 GitHub 技能的完整步骤以安装一个社区技能为例# 1. 克隆或下载技能仓库 git clone 技能仓库地址 /tmp/skill-temp # 2. 查看技能结构确认 SKILL.md 存在 ls /tmp/skill-temp # 3. 复制到技能目录 cp -r /tmp/skill-temp/技能名 ~/.claude/skills/ # 4. 验证 ls ~/.claude/skills/技能名/SKILL.md复制完成后重启 Claude Code 让它重新扫描技能目录。5.3 技能不生效的排查链路我遇到过几次技能装了但用不了的情况排查下来主要有这几类原因第一类目录层级错误。技能目录被多套了一层导致SKILL.md不在预期位置。解决方法是确认路径结构是skills/技能名/SKILL.md而不是skills/技能名/技能名/SKILL.md。第二类frontmatter 格式错误。YAML 里用了 Tab 缩进、冒号后没空格、字符串没加引号都会导致解析失败。用在线 YAML 校验工具过一遍最保险。第三类description 触发不了。这个前面说过描述太泛会导致 Agent 不加载。解决方法是把 description 改得更具体加入明确的触发关键词。第四类权限问题。脚本文件没有执行权限。用chmod x加上即可。5.4 与 VS Code 配合使用的场景如果你在 VS Code 里用 Claude Code 扩展技能目录的路径可能和命令行版本不同。我建议统一用命令行版本验证技能是否生效确认没问题后再在编辑器里用。这样能排除编辑器扩展本身的干扰。VS Code 里还有个实用技巧把技能目录加到工作区这样可以直接在编辑器里编辑SKILL.md改完保存就能生效不用来回切换窗口。6. 技能库的维护从堆砌到精简6.1 技能不是越多越好我一开始很兴奋装了二十多个技能。结果发现 Agent 的判断准确率反而下降了——技能太多触发条件容易重叠Agent 不知道该用哪个。后来我做了一次大清理只留下真正高频使用的。判断标准很简单过去一个月里这个技能被自动触发过几次如果一次都没有要么是 description 写得不好要么是根本不需要。6.2 定期更新技能内容技能包不是一次写完就完事的。项目在演进规范在变化技能内容也要跟着更新。我养成的习惯是每次发现 Agent 执行技能时出错就回头改SKILL.md把这次的情况补充进去。比如我的代码迁移技能最初没考虑 TypeScript 的泛型场景后来遇到报错就补上了对应规则。技能包就是在这样一次次修补中变得可靠的。6.3 版本管理技能目录建议纳入 Git 管理。这样团队成员可以共享同一套技能也能追踪每次修改。我在团队里推行的是技能修改走正常的代码审查流程确保规则变更经过确认。6.4 技能之间的依赖处理有些技能会依赖其他技能的能力。比如生成 API 文档可能依赖读取代码结构这个基础技能。这种情况下我建议把公共能力抽成独立技能然后在具体技能的正文里说明先加载 xxx 技能。7. 那些官方文档不会告诉你的实操心得7.1 description 的写法有讲究我总结了一个 description 的模板当[具体场景]时使用适用于[文件类型/范围]包含[核心能力列表]不适用于[排除场景]。这个模板的好处是把触发条件、适用范围、能力边界都说清楚了。Agent 判断起来准确率明显更高。7.2 正文要短参考文档要长SKILL.md正文我控制在 200 行以内把详细内容放到references/里。原因是正文每次都会被加载太长会占用上下文参考文档按需加载可以写得很详细。7.3 脚本要幂等技能里的脚本尽量写成幂等的——重复执行不会产生副作用。因为 Agent 有时会重复调用如果脚本不幂等可能造成数据损坏。7.4 给技能加自检步骤在技能正文的最后加一步执行后自检让 Agent 确认输出是否符合预期。这一步能拦住不少低级错误。7.5 中文技能包的编码问题如果技能内容包含中文确保文件用 UTF-8 编码保存。我遇到过因为编码问题导致中文乱码、Agent 读取失败的情况。7.6 测试技能用最小案例验证一个新技能时不要直接上复杂任务。先构造一个最小的、边界清晰的案例确认技能能正确执行再逐步增加复杂度。8. 从零搭建第一个技能包的实操演示8.1 选定一个真实痛点假设你经常需要把接口返回的 JSON 数据转成 TypeScript 类型定义。这个任务规则明确、重复度高适合做成技能。8.2 编写 SKILL.md--- name: json-to-ts description: 当需要将 JSON 数据转换为 TypeScript 类型定义时使用适用于 .json 文件和内联 JSON 字符串包含嵌套对象、数组、可选字段处理不适用于需要运行时校验的场景。 --- ## 何时使用 - 用户提供了 JSON 样本要求生成对应的 TS 类型 - 需要为 API 响应定义类型 ## 执行步骤 1. 解析 JSON 结构识别所有字段和嵌套层级 2. 为每个对象生成 interface命名使用 PascalCase 3. 数组类型使用 T[] 形式 4. 值为 null 的字段标记为可选? 5. 输出到指定文件或直接展示 ## 边界与禁忌 - 不处理循环引用 - 不生成运行时校验代码 - 字段名含特殊字符时用引号包裹 ## 自检 - 确认所有嵌套层级都有对应类型 - 确认可选字段标记正确8.3 放入技能目录并验证把上面的内容保存为SKILL.md放到技能目录下重启编辑器然后给 Agent 一段 JSON 让它转换。如果输出符合预期技能就生效了。8.4 根据实际使用迭代第一次用可能会发现遗漏的场景比如日期字符串应该转成string还是Date。把这些决策补充到技能里下次就自动处理了。9. 技能生态的现状与选择建议9.1 社区技能的质量参差不齐现在社区里流传的技能包很多但质量差异很大。有些只是把一段提示词包装了一下没有真正的结构化设计。选择时我建议看三点description 是否具体、正文是否有明确的执行步骤、是否包含边界处理。9.2 优先自建核心技能通用技能可以借鉴社区的但涉及你项目特定规范的技能一定要自己写。因为只有你最清楚项目的约定和痛点社区技能不可能覆盖这些。9.3 技能的组合使用多个技能可以组合使用。比如代码迁移测试生成提交信息三个技能串起来就能完成一次完整的重构流程。组合使用时要注意技能之间的衔接确保前一个的输出格式是后一个能接受的输入。9.4 关注技能的加载顺序当多个技能同时匹配时Agent 会按某种顺序加载。我实测下来description 更具体的技能优先被加载。所以如果你有两个功能相近的技能把更常用的那个 description 写得更具体一些。10. 我个人的一些使用体会用了一段时间 Skills 之后最大的感受是它改变了我跟 AI 协作的方式。以前是我追着 AI 解释需求现在是 AI 主动调用我预设好的能力。这个转变的关键在于你把多少隐性知识显性化了。我现在的习惯是每当发现自己在重复解释同一件事就停下来想想能不能做成技能。这个习惯坚持下来技能库慢慢就充实了日常开发的效率提升是实实在在的。另外一点体会是技能包的质量比数量重要得多。一个精心设计的技能胜过十个粗糙的。与其到处收集技能不如把手上常用的那几个打磨好。最后分享一个小技巧给每个技能写一句一句话说明放在技能目录的 README 里。这样过一段时间回头看能快速想起这个技能是干什么的不用打开SKILL.md逐个读。这个习惯帮我省了不少时间。