1. 为什么“经验复用”这件事值得单独做成一个能力包
刚入行那几年，我最怕听到的一句话就是“这个需求上次不是做过类似的吗，你怎么又从头来一遍”。那时候我的工作方式很原始：每做完一个项目，把关键代码片段、踩坑记录、配置参数一股脑塞进一个叫“笔记”的文件夹里，下次遇到类似场景再去翻。结果就是翻半天找不到，找到了又发现当时的上下文早就忘了，参数为什么这么设、那个报错为什么这么解，全凭残存的记忆瞎猜。后来我意识到，问题不在于我记性差，而在于我把“经验”当成了“资料”来存，而不是当成“能力”来封装。
WorkBuddy 里的 Skill 这个概念，本质上就是在解决这件事。你可以把它理解成一个“能力包”：把你反复要用的一套流程、一套判断逻辑、一套操作规范，打包成一个可以被随时调用、可以被别人复用、可以跨项目迁移的独立单元。它不是一个简单的提示词模板，也不是一段死代码，而是一个带有明确输入输出、带有执行步骤、带有边界说明的完整能力描述。核心载体就是那个SKILL.md文件，配套的还有skill-creator这类辅助工具，以及SkillHub这种用来分发和共享能力包的集散地。
我第一次认真研究 Skill 是因为一个很具体的痛点：我手头有七八个不同项目，每个项目都要做数据清洗，但每个项目的数据格式、清洗规则、异常处理策略都不一样。如果我把清洗逻辑写成一个通用脚本，它就会变得无比臃肿，全是 if-else；如果我每个项目单独写一份，那重复劳动又太多。Skill 给我的启发是：把“数据清洗”这件事拆成“识别数据源类型”“应用对应清洗规则”“输出标准化结果”三个可组合的能力单元，每个单元用SKILL.md描述清楚它的适用范围、输入要求、执行步骤和输出格式。这样我在新项目里只需要组合调用，而不是重新造轮子。
这篇文章适合谁看？如果你是一个经常需要把重复性工作流程化的人，不管你是写代码的、做数据分析的、搞内容运营的，还是带团队做项目交付的，Skill 这套思路都能帮你把“个人经验”变成“团队资产”。如果你只是偶尔做一次性任务，那可能用不上，但了解一下这种“能力封装”的思维方式，对你以后做任何需要沉淀的事情都有好处。接下来我会从设计思路、核心细节、实操过程、常见问题四个层面，把 Skill 这件事讲透。
2. Skill 的整体设计思路与核心概念拆解
2.1 Skill 到底是什么：从“提示词”到“能力单元”的认知升级
很多人第一次接触 Skill 会把它和“自定义指令”或者“提示词模板”混为一谈。我一开始也这么想，直到我真正写了一个SKILL.md之后才发现，这两者的区别就像“菜谱”和“厨师”的区别。提示词模板是你告诉一个厨师“今天做红烧肉”，他凭自己的经验去做；而 Skill 是你把红烧肉这道菜从选肉、焯水、炒糖色到收汁的每一步都写清楚，还标注了“如果糖色炒糊了怎么办”“如果没有冰糖用白糖替代的比例是多少”，然后把这个菜谱交给任何一个厨师，他都能做出一模一样的味道。
从结构上看，一个完整的 Skill 通常包含几个核心部分。第一是元信息，包括这个 Skill 叫什么、版本号是多少、作者是谁、最后更新时间是什么时候。第二是适用场景描述，用自然语言说清楚“什么情况下该用这个 Skill，什么情况下不该用”。第三是输入输出定义，明确这个 Skill 需要什么参数、会产出什么结果。第四是执行步骤，这是最核心的部分，把整个流程拆成可操作的步骤，每一步都写清楚做什么、怎么做、注意什么。第五是边界与异常处理，说明遇到特殊情况时该怎么应对。
我实测下来，最容易被人忽略的是第二和第五部分。很多人写 Skill 只写“怎么做”，不写“什么时候用”和“出错了怎么办”，结果就是别人拿到你的 Skill 根本不敢用，因为不知道边界在哪里。一个好的 Skill 应该像一份严谨的作业指导书，而不是一份随意的备忘录。
2.2 为什么是 SKILL.md 这个格式：文件即能力，文本即接口
SKILL.md这个命名本身就很有讲究。.md是 Markdown 格式，意味着它是纯文本、人类可读、版本可控、diff 友好的。你不需要任何特殊工具就能打开它、编辑它、对比不同版本之间的差异。这一点在团队协作里极其重要，因为能力包是要被 review、被迭代、被继承的，如果它是一堆二进制文件或者某个平台专属的格式，那它的生命周期就会很短。
我试过把 Skill 的内容写进数据库、写进某个配置管理系统，最后都放弃了。原因很简单：那些地方的内容是“黑盒”的，你看不到全貌，也没法用 git 来管理变更历史。而SKILL.md放在代码仓库里，和你的项目代码一起版本控制，谁改了哪一行、为什么改，一目了然。这就像你把操作手册和机器放在同一个车间里，而不是锁在办公室的抽屉里。
另外，Markdown 的天然结构化特性让SKILL.md可以被程序解析。你可以用脚本读取它、提取关键字段、自动生成文档、甚至自动校验格式是否合规。skill-creator这类工具做的就是这件事：帮你按照规范生成SKILL.md的骨架，你只需要填空就行。我个人的习惯是先用skill-creator生成模板，然后手动调整内容，最后用脚本做一次格式校验，确保没有漏掉必填字段。
2.3 SkillHub 的定位：能力包的“应用商店”与“协作枢纽”
SkillHub这个概念解决的是“能力包怎么共享”的问题。你写了一个好用的 Skill，怎么让团队里其他人也能用上？怎么让其他项目组也能受益？怎么在社区里找到别人已经写好的、经过验证的 Skill？SkillHub就是干这个的。你可以把它理解成一个内部的能力包仓库，或者一个社区驱动的 Skill 集散地。
我在团队里推行 Skill 的时候，一开始是让大家把SKILL.md放在各自的项目仓库里，结果就是“我知道你写了一个数据清洗的 Skill，但我不知道它叫什么名字、放在哪个仓库、怎么调用”。后来我们建了一个统一的SkillHub目录，每个 Skill 一个子目录，目录名就是 Skill 的标识符，里面除了SKILL.md还有示例输入输出、测试用例、变更日志。这样一来，任何人想找某个能力，直接去SkillHub里搜就行了。
提示：
SkillHub的目录结构建议保持扁平，不要嵌套太深。我见过有人按“部门/项目/模块/版本”四层嵌套，结果找起来比翻笔记还慢。一般两层就够了：SkillHub/技能名称/。
2.4 和 Agent 的区别：Skill 是“能力”，Agent 是“执行者”
热词里有人问“skill 和 agent 的区别”，这个问题很关键。我的理解是：Agent 是一个能自主决策、能调用工具、能完成复杂任务的“执行者”，而 Skill 是 Agent 可以调用的“能力单元”。打个比方，Agent 是一个员工，Skill 是这个员工掌握的一项技能。员工可以有很多技能，也可以学习新技能；技能可以被多个员工共享，也可以被单独训练和考核。
这个区别决定了它们的编写方式不同。写 Agent 的时候你要考虑它的决策逻辑、任务规划、工具选择策略；写 Skill 的时候你只需要考虑“这件事怎么做才对、怎么做好”。所以 Skill 的粒度通常比 Agent 小，它更聚焦、更可复用、更容易测试。我个人的经验是：先把一个复杂流程拆成若干个 Skill，然后再用一个 Agent 去编排这些 Skill，这样比直接写一个大而全的 Agent 要容易维护得多。
3. 核心细节解析与实操要点
3.1 SKILL.md 的骨架结构：每个字段都有存在的理由
一个规范的SKILL.md通常包含以下字段，我逐个解释它们的作用和填写要点。
| 字段名 | 是否必填 | 作用 | 填写要点 |
|---|---|---|---|
name | 是 | Skill 的唯一标识 | 用英文小写加连字符，如>
|
