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怎么让团队里其他人也能用上怎么让其他项目组也能受益怎么在社区里找到别人已经写好的、经过验证的 SkillSkillHub就是干这个的。你可以把它理解成一个内部的能力包仓库或者一个社区驱动的 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 的唯一标识用英文小写加连字符如>