Skill：让经验可复用，让 AI 懂流程
一、Skill 是什么
1.1 一句话定义
Skill 是一个打包好的"能力包"——本质上是一个文件夹,里面装着教 Claude 如何完成某一类特定任务的指令、脚本和参考资料。你可以把它理解为"给 AI 的 SOP(标准作业程序)",不同的是这份 SOP 是可执行、可复用、可被 Claude 自动识别并调用的。
1.2 和普通 Prompt 的区别
| 普通 Prompt | Skill | |
|---|---|---|
| 生命周期 | 单次对话内有效 | 长期沉淀,跨会话、跨用户复用 |
| 触发方式 | 需要你每次手动描述 | Claude 根据任务自动判断是否调用 |
| 内容承载 | 纯文字指令 | 指令 + 可执行脚本 + 参考文档 + 模板素材 |
| 迭代方式 | 改一次用一次 | 可以用真实案例反复测试、评估、优化 |
| 价值沉淀 | 经验留在聊天记录里,容易丢失 | 经验变成结构化资产,团队可共享 |
1.3 一个 Skill 长什么样
skill-name/
├── SKILL.md (必需)
│ ├── YAML frontmatter: name(名称)、description(描述)
│ └── Markdown 正文: 具体的操作指令
└── 可选的配套资源
├── scripts/ 可执行代码,用来处理确定性、重复性的操作
├── references/ 供按需查阅的详细文档
└── assets/ 输出中要用到的模板、图标、字体等文件
1.4 三层"按需加载"机制
Skill 的设计核心是渐进式加载(Progressive Disclosure),目的是既能让 Claude "知道有这个工具",又不会把上下文塞满:
- 元数据层(name + description):始终在 Claude 的"技能清单"里,只占很小的篇幅
- SKILL.md 正文:只有在任务命中这个 skill 时才会被读入,建议控制在 500 行以内
- 配套资源:体积不限,按需读取,脚本甚至可以在不占用上下文的情况下直接执行
这意味着你可以做"轻量的技能"(只有一份说明书),也可以做"重量级的技能"(说明书 + 大量参考文档 + 现成脚本),Claude 会自己判断该往下读多少。
1.5 Skill 的触发机制
Claude 是否使用一个 skill,取决于当前任务的描述是否匹配 skill 的 description 字段。有一个重要规律:
越简单的、一步能搞定的任务,越不容易触发 skill;越是复杂、多步骤、需要专业知识的任务,越容易也越应该触发 skill。
这也直接决定了下一节要讲的:什么样的工作内容值得做成 skill。
1.6 生态位置
- 官方内置 skill:比如处理 Word / PPT / Excel / PDF 的技能,开箱即用
- 个人自定义 skill:你根据自己的工作流程写的技能,只在你的账号下生效
- 团队/组织共享 skill:被沉淀下来、其他同事也能"一键安装"复用的技能
- skill-creator:一个特殊的"元技能",专门用来帮你创建和迭代其他 skill
二、如何从工作中挖掘"适合做成 Skill"的点
不是所有重复劳动都值得做成 skill。判断的关键不是"这件事我做了很多次",而是"这件事有没有可以被沉淀下来的结构"。可以从以下几个信号入手排查:
2.1 信号一:同一套多步骤流程反复出现
如果你发现自己经常对 Claude(或对自己)重复类似的一整套操作步骤——比如"先做 A,再检查 B 有没有问题,再按格式 C 输出"——这就是候选。
例子:每周整理销售数据,先清洗字段,再按固定口径计算指标,再套用同一份周报模板。
2.2 信号二:踩过坑、有隐性经验需要沉淀
有些任务表面简单,但实际操作中有很多"新手会踩的坑"——环境限制、格式陷阱、容易出错的边界情况。这些经验如果只存在于你脑子里或某次对话记录里,下次还会重新踩一遍。
例子:生成的 PDF 表格经常错位,你摸索出了一套修正方法;某类财务模型必须先转换某个单位否则会算错。
2.3 信号三:有明确、固定的输出规范
如果输出有清晰的格式要求(公司模板、行业规范、固定的报告结构),这种"规则明确、可验证对错"的任务非常适合做 skill,而且效果容易评估。
例子:所有对外发布的报告必须用统一的封面、目录结构和字体规范。
2.4 信号四:需要专业领域知识或特定工具链
任务涉及某个专业领域的术语、行业惯例,或者需要串联多个特定工具/API 才能完成,这类"专业壁垒"适合封装成 skill,让不熟悉该领域的同事也能借助 skill 产出合格结果。
例子:合规审查有一套特定的检查清单和话术规范,不是每个同事都熟悉。
2.5 信号五:任务足够"重",不是一句话能答完的
结合前面提到的触发机制,如果一个任务本来就是一步问答能解决的(比如"帮我查一下这个词的意思"),做成 skill 意义不大,也很难被触发。真正值得投入的,是那些多步骤、有中间产物、容易出错的工作。
2.6 一个简单的自查清单
可以问自己以下几个问题,命中越多,越值得做成 skill:
- 这件事我(或团队)一个月内做了 3 次以上,而且步骤基本相同?
- 每次做的时候都要重新想一遍"哪里容易出错"?
- 有明确的输入/输出格式,可以写出"什么样才算做对了"?
- 团队里不止我一个人需要做这件事?
- 这件事需要多个步骤或跨多个工具才能完成?
三、如何动手做一个 Skill
3.1 第一步:想清楚三件事
在动笔之前先回答:
- 这个 skill 要让 Claude 具备什么能力?(做什么)
- 什么情况下应该触发它?(用户会怎么问、在什么场景下需要)
- 期望的输出格式是什么样的?(有没有模板、有没有硬性规范)
如果你已经和 Claude 有过一段对话、摸索出了一套可行流程,直接跟 Claude 说"把这个流程做成一个 skill",让它从对话历史里提取步骤、工具使用顺序、你做过的修正——这比从零开始描述要高效得多。
3.2 第二步:撰写 SKILL.md
Frontmatter(元数据)部分:
---
name: skill-name
description: 描述这个skill做什么、什么时候应该被触发
---
description 是决定 skill 会不会被正确调用的关键字段,写作时要注意:
- 同时写清楚"做什么"和"什么场景下用"两部分信息,所有"何时使用"的判断依据都应该写在这里,而不是藏在正文里
- 措辞可以稍微"主动"一点,明确列出多种可能的触发场景(哪怕用户没有用到 skill 名称里的关键词),避免 Claude 该用的时候没用上
正文部分:
- 用祈使句/指令式的语气写步骤,而不是描述性的陈述句
- 尽量解释"为什么"要这么做,而不是堆砌生硬的"必须""禁止"式规则——现在的模型理解力足够好,给出原因往往比给命令更有效
- 明确定义输出格式(如果有固定模板,直接把模板结构写进去)
- 如果涉及多个子领域/多个分支场景,按场景拆分成独立的参考文件,正文只负责"引导去哪个文件",避免 SKILL.md 本身过长
- SKILL.md 正文建议控制在 500 行以内;如果发现内容变多,把细节挪到
references/目录,正文里留清晰的"什么时候去读哪个文件"的指引
关于配套脚本:
如果发现每次执行这个 skill 时,都要重新写一遍类似的代码(比如生成同一种格式的图表、跑同一套数据清洗逻辑),这是一个强信号——应该把这段代码写成脚本放进 scripts/ 目录,并在 SKILL.md 里告诉 Claude 直接调用它,而不是每次重新生成一遍。
3.3 第三步:写测试用例并试跑
写完草稿后,不要急着定稿,而是:
- 设计 2-3 个贴近真实场景的测试问法(而不是抽象的"帮我格式化数据"这种)
- 用这些测试问法分别跑一遍"有 skill 帮助" vs "没有 skill"的效果,直观对比差异
- 检查产出是否符合预期,记录哪里不对劲
3.4 第四步:根据反馈迭代
拿到测试结果后:
- 优先看反馈里明确吐槽的问题,针对性修改,而不是漫无目的地大改
- 警惕"过拟合":你和自己反复用同一两个例子调优,容易调出一个只对这几个例子好用、换个场景就失灵的 skill。如果某个问题总是解决不好,试着换个角度重新表述指令,而不是不断加更严格的规则
- 保持精简:定期检查正文里有没有"食之无味、弃之可惜"的冗余内容,删掉不产生实际效果的部分
- 重复"改进 → 重新测试 → 收集反馈"这个循环,直到结果稳定满意
3.5 第五步:打磨触发准确率(可选,进阶)
如果发现 skill 该触发时没触发、或者不该触发时乱触发,可以专门优化 description 字段:
- 准备一批"应该触发"和"不应该触发"的真实问法样本(后者尤其要选容易混淆的边界案例,而不是明显不相关的问题)
- 对比不同版本的 description 在这批样本上的表现,选出效果最好的版本
3.6 第六步:打包与分享
Skill 写好后可以打包成独立文件,分享给同事或团队直接安装使用,让沉淀下来的经验真正流通起来,而不是只停留在你一个人的对话记录里。
四、小结
把工作沉淀成 Skill,本质上是在做一件事:把"只有我知道的经验"变成"任何人都能复用的结构化能力"。
判断一件工作值不值得做成 skill,核心看它是否满足:重复发生 + 有踩坑经验 + 有明确规范 + 步骤足够多。而制作 skill 的过程,其实就是把这些隐性经验显性化、结构化,并通过真实案例不断验证、迭代,直到它足够稳定可靠。
Skill 作为一个技能工具，他不局限于在任何智能体框架上使用哈比如openclaw hermes codex claude qorder 等国产或国外智能体
