WorkBuddy Skill：把重复 SOP 打成可调用的手册包

image.png

烦。更烦的是，它有时记得有时忘，你还得翻聊天记录找「上次我是怎么叮嘱的」。

Skill 解决的就是这个：把一次讲清楚的做法，打包成可反复调用的 SOP/手册包。不是每次从零教，而是「这类活，按我们家的规矩来」。

Skill 和一次性 Prompt 有啥不同

image.png

Prompt（一次 Task） 像临时派活：「把这份表汇总一下，注意合计行。」干完就散，下次还得重说。

Skill（可复用做法包） 像版本化的 runbook：里面有步骤说明（SKILL.md）、可选脚本、模板、样例。WorkBuddy 接到相关任务时，先翻这本手册，再动手。

技术相对照：

• 聊天框 = 通用模型，没有你们公司的习惯。
• 普通 Task = 每次把参数和约束写进命令行。
• Skill = 固化的 playbook，执行前自动加载，不用你重复讲第三遍。

Skill 通常包含：名称和简短描述（让你知道啥时候该用）、详细规则正文（用到才加载）、以及可选的脚本或模板文件。这叫渐进披露——列表里先看标题和简介，真用到再展开全文，不占无谓上下文。

纸质岗位手册教人怎么做；WorkBuddy 的 Skill 是手册 + 执行者。手册里写「汇总表保留两位小数」，它读 Skill 后生成 Excel 时会真的按两位小数来——不是只看一遍文档然后自由发挥。但手册里写不清楚的，它也会卡。Skill 质量决定输出质量：步骤模糊、样例缺失、边界没写，照样返工。维护 Skill 跟维护内部文档一样，要有人偶尔更新。

Skill 能帮你干什么

• 补公司流程知识。 报销附件命名规则、品牌用词表、内部文档标题格式——写进 Skill，比每次粘贴一段「注意事项」稳。
• 固定工作流。 「收齐发票 → 核对金额 → 生成汇总表 → 输出待审清单」这种重复链路，Skill 把顺序和检查点钉死。
• 减少重复叮嘱。 你说过一次的话，沉淀成 Skill，团队其他人用斜杠命令也能调用同一套标准。
• 经验资产化。 老员工脑子里的「我们以前怎么做」，变成可 diff、可版本管理的文件，新人不用靠口头传承。

怎么用：市场、上传、斜杠调用

image.png

WorkBuddy 支持从 Skill 市场安装现成的（通用写作、表格处理之类），也支持把自己或团队的做法打包成 zip 上传。上传前按规范组织：根目录放 SKILL.md，说明名称、描述、适用场景；需要的话附上模板和脚本。

调用方式一般是输入斜杠命令，比如 /weekly-report，后面再跟本次具体材料或微调说明。Skill 提供「怎么做的规矩」，你仍然要提供「这一次的具体输入」。

用不上的 Skill 可以关闭或卸载，避免列表太长找错。常用的留几个就够起步，不用的收起来。

渐进披露：为什么列表里只见标题

Skill 市场或本地列表里，通常只显示名称和一行描述——像书架上的书脊，让你判断「是不是这本」。真正执行任务、匹配到某个 Skill 时，才加载 SKILL.md 全文和相关脚本。

这样设计是为了省上下文、降干扰。几十个 Skill 全展开，反而找不到重点。挑 Skill 时看描述是否命中场景；命中了再调用，细节交给运行时加载。

团队里谁该维护 Skill

个人 Skill：自己用自己改。团队 Skill：建议指定 owner，跟内部文档 owner 一样——模板变了、品牌色改了、财务要求改了，owner 更新 SKILL.md，版本在文件名或文内记一笔。

没有 owner 的 Skill，半年后就跟旧版 PPT 模板一样，用着用着全员怀疑「是不是工具不行」，其实是手册过期。

写一个 Skill 从哪开始

不必一次完美。推荐路径：

1. 先有一次成功的 Task。 演练目录里跑通，验收过了，说明你的六要素描述本身是对的。
2. 把「每次都一样的部分」抽出来。 格式、禁忌、步骤顺序、输出文件名规则——这些是 Skill 正文。
3. 把「每次会变的部分」留在 Prompt。 具体文件名、日期、客户名——调用 Skill 时再填。
4. 试调用并迭代。 故意用边界 case 测：缺字段、空文件、负责人未知，看 Skill 里有没有写「这时怎么办」。没有就补一条。

团队共用时，约定 Skill 命名和描述，避免三个人三个 /report 不知道选哪个。

调用时 Prompt 和 Skill 怎么分工

image.png

记住一句：Skill 管规矩，Prompt 管这次。 Skill 里写「周报四段：本周完成、下周计划、风险、需协调」；Prompt 里写「本周数据在 week12.xlsx，风险重点写供应链延迟」。规矩不必每次重复，材料每次不同。

斜杠命令后面跟的那几句，就是本次 Prompt。别在 Skill 里硬编码会变的日期和客户名；别在 Prompt 里重复 Skill 已有的格式说明——两边分清，描述又短又稳。

从市场安装 vs 自己上传

市场里的 Skill 适合通用场景：Markdown 整理、表格清洗、常见文档转换。拿不准时先装一个轻量的试跑，看 SKILL.md 是否符合你习惯。

公司特有流程——内部模板、审批用语、字段命名——几乎一定要自己写或改再上传 zip。直接拿市场 Skill 硬套内部规范，往往要大量口头补丁，不如一开始就把补丁写进 SKILL.md。

常见坑

• Skill 写太长像论文 → 执行时加载慢、抓重点难。核心规则放前面，细节放附录或分节。
• 该进 Skill 的还在口头说 → 没沉淀，下次还是重复。固定规矩进 Skill，一次性例外留 Prompt。
• 从不更新 → 公司改了模板，Skill 还是旧版，产物集体跑偏。手册要有 owner。
• 装太多从不卸载 → 斜杠列表一长，误调用概率上去。常用的留三五个就够起步。
• 把 Skill 当万能 → 它管「怎么做」，不管「做不做」。涉密、涉合规的决策仍在你。
• Skill 之间打架 → 同时启用两个风格冲突的 Skill，产物可能四不像。一次 Task 聚焦一个主 Skill，必要时在 Prompt 里声明「以某某 Skill 为准」。

人工闸门：Skill 替不了的部分

Skill 固化的是流程和格式，不是业务判断。例：Skill 写「待办标注负责人」，但原文没有名字——它应标 @待定，你补全后再发。Skill 写「对外邮件经主管确认」，系统不会自动替主管点头，要你或主管真的确认。

上传团队 Skill 前，自己先跑几遍；涉及脚本自动改文件的，脚本逻辑也要人看过。Skill 是放大器：规矩写对了放大效率，写错了放大错误。

从市场安装的第三方 Skill，敏感任务前先看 SKILL.md 里会读哪些路径、会不会外传——跟装任何办公插件同一个谨慎度。

复杂任务有时需要多个专长一起会诊（后续能力）；Skill 是事先写好的单份手册，日常重复活用 Skill 即可。别第一天就把所有活都塞进一个巨型 Skill。

Skill 用得顺的团队，共同点是：先有个人练熟的六要素，再把六要素里不变的部分抽成手册。 跳步直接写 Skill，往往反复改 SKILL.md，不如先跑通两三次 Task 来得实在。

小结：Skill = 可复用的 SOP 包：SKILL.md 讲规矩，可选脚本模板帮执行；用斜杠调用，一次沉淀、反复少废话。Prompt 管这一次，Skill 管这一类。如果你发现自己跟 WorkBuddy 重复第三遍同样叮嘱，停一下，把那句话写进 Skill。先从一个小 Skill 开始——比如「自家周报格式」或「文件名命名规范」——比一口气建十个半成品实用得多。也可以问：这段话我是不是已经复制粘贴给 AI 超过两次了？是的话，它就该进 Skill 了。手册不必一次完美，但要有人记得更新；跟团队共享前，自己在演练目录试几遍，比上线后集体返工体面。