WorkBuddy Skill 实战指南：从零编写真正用得上的 SKILL.md

1. 为什么大多数人的 WorkBuddy Skill 装了等于没装我见过太多人兴冲冲地打开 WorkBuddy翻到 Skill 市场看到一堆名字花哨的 Skill点进去、装上、然后……就没有然后了。问起来就说“装了但好像没啥用”或者“感觉跟直接问它差不多”。这个现象太普遍了普遍到我觉得有必要专门写一篇东西把“加载一个真正用得上的 Skill”这件事从头到尾讲透。先说结论Skill 的价值不在于它本身多复杂而在于它能不能把你的重复性工作流固化下来让你不用每次都重新描述需求。如果你装了一个 Skill用的时候还得反复解释“帮我做这个、注意那个、格式要这样”那这个 Skill 就是失败的。真正用得上的 Skill是你打开 WorkBuddy、选中它、丢进去原料它就能按你预期的样子产出结果——中间不需要你再补一句废话。这篇内容适合三类人第一类是完全没接触过 WorkBuddy Skill、想搞清楚它到底是什么的新手第二类是装过几个 Skill 但觉得鸡肋、想弄明白问题出在哪的用户第三类是想自己动手写一个 SKILL.md、把自己的工作流封装成 Skill 的进阶玩家。不管你在哪一层接下来的内容都会给你一套可复现的方法。我自己的经历是这样的最开始用 WorkBuddy 的时候我也觉得 Skill 是个噱头不就是预设了一段 Prompt 吗后来有一次我要批量处理几十份结构类似的文档每次都要重复交代格式要求、输出结构、注意事项烦得不行。我就想能不能把这套东西固化下来于是写了第一个 SKILL.md从那以后这个 Skill 帮我省掉了至少几百次重复输入。从那之后我才真正理解 Skill 的设计意图——它不是给你一个“万能工具”而是让你把“你自己的做事方式”变成可复用的资产。2. Skill、Prompt、Agent 到底谁管谁2.1 三者不是替代关系是嵌套关系很多人搞不清楚 Skill、Prompt、Agent 这三个词的区别网上也有各种说法有的说 Skill 就是高级 Prompt有的说 Skill 是 Agent 的子集。我尽量用大白话把这事说清楚。Prompt 是你对模型说的一句话。比如“帮我写一段产品介绍”这就是一个 Prompt。它是最轻量的交互方式用完即走不留痕迹。Skill 是一组被封装好的 Prompt 加上执行逻辑。它不只是“一段话”而是一个有结构的文件通常是 SKILL.md里面定义了这个 Skill 是干什么的、需要什么输入、按什么步骤处理、输出什么格式、有哪些注意事项。你可以把它理解成一份“操作手册”WorkBuddy 读到这份手册后就知道该怎么干活了。Agent 是一个能自主决策、调用工具、多步执行的智能体。Agent 可以调用 Skill也可以自己规划步骤。Skill 是 Agent 的能力模块之一。用一个生活化的类比Prompt 是你跟厨师说“来个蛋炒饭”Skill 是你给厨师一本菜谱上面写了蛋炒饭的完整做法Agent 是那个厨师本人他看了菜谱之后自己决定先打蛋还是先热锅、火候大了怎么调。所以三者的关系是Agent 调用 SkillSkill 包含 Prompt。你写 Skill 的时候本质上是在写一套结构化的 Prompt 组合让 Agent 能稳定地按你的意图执行。2.2 为什么“渐进式披露”是 Skill 设计的核心热词里有一个词叫“渐进式披露”这是 Skill 设计中非常关键的一个概念但很多人没注意到。所谓渐进式披露意思是Skill 不应该一次性把所有信息都塞给模型而是分阶段、按需地把信息暴露出来。为什么因为模型的上下文窗口是有限的如果你在 SKILL.md 里写了三千字模型每次加载都要把这三千字全部读一遍既浪费 token又容易让模型“抓不住重点”。好的 Skill 设计是这样的第一层是元信息名称、描述、触发条件让 WorkBuddy 知道“这个 Skill 是干什么的、什么时候该用它”第二层是执行步骤核心流程告诉模型“按什么顺序做”第三层是细节补充边界情况、格式规范、示例只在需要的时候才展开。这就像你给新同事交接工作你不会第一天就把所有细节全倒给他而是先告诉他“这个岗位负责什么”等他上手了再逐步补充“遇到 A 情况这样处理、遇到 B 情况那样处理”。渐进式披露的本质是让信息在正确的时机出现在正确的位置。2.3 一个 Skill 的生命周期理解 Skill 的生命周期能帮你判断什么时候该写 Skill、什么时候不该写。阶段做什么判断标准识别发现重复性任务同一类任务每周至少做 3 次抽象提炼固定流程每次的步骤基本一致只有输入不同编写写 SKILL.md能用清晰的步骤描述完整流程测试用真实输入验证连续 5 次输出都符合预期迭代根据边界情况补充遇到新情况就更新 Skill如果你的任务是一次性的、每次流程都不一样那就不适合写成 Skill直接用 Prompt 就行。Skill 的核心价值在于“重复”没有重复就没有封装的意义。3. 拆解一个能打的 SKILL.md 长什么样3.1 文件结构从元信息到执行细节一个标准的 SKILL.md 通常包含以下几个部分。我拿一个实际例子来讲——假设你要做一个“文档结构化摘要”的 Skill输入是一篇长文输出是固定格式的摘要卡片。--- name: doc-summary description: 将长文档压缩为结构化摘要卡片包含核心观点、关键数据和行动建议 trigger: 当用户需要快速理解一篇长文的核心内容时 --- # 文档结构化摘要 ## 输入要求 - 一篇完整的文档Markdown 或纯文本 - 可选摘要长度偏好短/中/长 ## 执行步骤 1. 通读全文识别文档的主题和结构 2. 提取 3-5 个核心观点 3. 提取所有关键数据数字、日期、比例 4. 生成 1-3 条行动建议 5. 按下方模板输出 ## 输出模板 ### 核心观点 - 观点1 - 观点2 ### 关键数据 | 数据项 | 数值 | 出处 | |--------|------|------| ### 行动建议 1. ... ## 注意事项 - 不要添加原文没有的信息 - 数据必须标注出处段落 - 如果原文少于 500 字直接返回原文要点即可这个结构看起来简单但每一部分都有讲究。元信息frontmatter是给 WorkBuddy 看的让它知道什么时候该调用这个 Skill执行步骤是给模型看的告诉它按什么顺序做输出模板是给结果看的保证每次输出格式一致注意事项是给边界情况看的防止模型自由发挥。3.2 触发条件写不好Skill 就永远不会被调用我见过最常见的问题就是触发条件写得太模糊。比如有人写trigger: 当用户需要处理文档时——这等于没写。什么叫“处理文档”总结是处理、翻译是处理、格式转换也是处理WorkBuddy 根本不知道该不该调用你的 Skill。好的触发条件应该是具体的、可判断的。比如差当用户需要摘要时好当用户提供一篇超过 500 字的文档并要求提炼核心内容时差当用户需要写代码时好当用户要求生成 Python 数据处理脚本且输入为 CSV 文件时触发条件越具体Skill 被正确调用的概率越高。这就像你给朋友指路“往东走”和“看到红绿灯左转、走到第三个路口右转”的区别。3.3 执行步骤的颗粒度怎么把握执行步骤写多细这是很多人纠结的问题。写太粗模型自由发挥输出不稳定写太细模型变成提线木偶遇到稍微不同的输入就卡住。我的经验是步骤写到“一个刚入职的实习生看了能执行”的程度就够了。你不需要告诉他“打开电脑、双击图标”这种程度但你需要告诉他“先做什么、再做什么、遇到什么情况怎么处理”。具体来说每个步骤应该包含三个要素动作做什么、输入用什么做、输出产出什么。比如“提取 3-5 个核心观点”这个步骤动作是提取输入是全文输出是 3-5 个观点。如果某个步骤的输出是下一个步骤的输入那顺序就不能乱。还有一个技巧在步骤中嵌入判断逻辑。比如“如果原文少于 500 字跳转到简化流程”这样模型遇到短文本时就不会硬套完整流程。3.4 输出模板让每次结果都长一个样输出模板是 Skill 稳定性的最后一道防线。没有输出模板的 Skill每次产出格式都不一样用起来很痛苦。输出模板不需要很复杂但必须固定结构。比如上面例子里的“核心观点 关键数据 行动建议”三段式不管输入什么文档输出永远是这三块。这样你拿到结果之后可以直接复制到你的笔记系统、周报模板或者任何下游流程里不需要再手动调整格式。如果你需要更灵活的输出可以用“条件模板”比如“如果文档是技术类输出包含代码示例如果是管理类输出包含决策建议”。但即使条件不同每个分支的内部结构也应该是固定的。4. 从零写一个“真正用得上”的 Skill完整实操4.1 选一个你每周至少做三次的任务写 Skill 的第一步不是打开编辑器而是找到值得封装的任务。判断标准很简单这个任务你每周至少做三次而且每次的流程基本一样只是输入内容不同。我拿一个真实场景来演示假设你是一个运营每周需要从多个渠道收集用户反馈整理成一份结构化报告。这个任务的特点是输入是零散的反馈文本输出是固定格式的报告流程是“分类 → 归纳 → 提炼 → 输出”。这就是一个典型的适合封装成 Skill 的任务。反例如果你只是偶尔写一篇创意文案每次风格都不一样那就不适合写 Skill。Skill 是为重复性工作服务的不是为创意性工作服务的。4.2 把流程拆成“输入-处理-输出”三段选好任务之后把它拆成三段输入是什么、处理步骤有哪些、输出长什么样。以“用户反馈整理”为例输入一段或多段用户反馈文本可能来自不同渠道格式不统一处理步骤逐条阅读反馈判断每条反馈的类型功能建议 / Bug 反馈 / 体验吐槽 / 表扬将同类反馈归并找出高频问题对每个高频问题提炼一句话概括按优先级排序影响面 × 严重程度生成结构化报告输出一份包含“反馈概览、高频问题、优先级排序、原始反馈索引”的报告拆解的时候要注意处理步骤必须是可执行的、无歧义的。“判断反馈类型”是可执行的“理解用户意图”就太模糊了。如果你发现某个步骤没法用一句话说清楚那说明你还没想清楚这个流程需要再细化。4.3 写 SKILL.md 时最容易犯的三个错误错误一把 Skill 写成 Prompt。有些人写 SKILL.md 的时候直接写了一大段“你是一个专业的运营助手请帮我整理用户反馈……”——这是 Prompt不是 Skill。Skill 需要结构化的元信息、步骤和模板不是一段自然语言描述。错误二步骤之间没有逻辑衔接。比如写了“第一步分类、第二步归纳、第三步输出”但没说分类的结果怎么传给归纳、归纳的结果怎么传给输出。模型执行的时候就会跳步或者乱序。正确的做法是在步骤中明确“上一步的输出作为下一步的输入”。错误三忽略异常情况。比如输入为空怎么办输入格式完全不对怎么办输入内容超出预期长度怎么办这些边界情况如果不写清楚模型遇到的时候就会自由发挥输出不可控。好的 Skill 不是只处理正常情况而是能优雅地处理异常情况。4.4 测试与迭代连续五次输出都稳定才算过关写完 SKILL.md 之后不要急着说“完成了”。你需要用真实输入测试至少五次而且这五次的输入要有差异——有的长、有的短、有的格式规范、有的格式混乱。如果五次输出都符合你的预期那这个 Skill 才算过关。如果某次输出不对不要改模型改 Skill。Skill 的问题永远出在 Skill 本身而不是模型不行。模型只是一个执行者你的 SKILL.md 是它的操作手册。手册写得不清楚执行者当然会做错。迭代的时候把每次遇到的问题记录下来补充到“注意事项”或者“边界情况”里。一个成熟的 Skill 通常需要经过 3-5 轮迭代才能稳定。5. 让 Skill 从“能用”变成“好用”的进阶技巧5.1 用“示例输入输出”锚定模型行为在 SKILL.md 里放一组示例输入和示例输出是提升稳定性的最有效手段之一。模型看到示例之后会更容易理解你想要的格式和风格。示例不需要很长但必须典型。比如## 示例 ### 输入 用户反馈你们这个搜索功能太慢了每次都要等好几秒。另外希望能加一个按时间筛选的功能。 ### 输出 **反馈类型**功能建议 体验吐槽 **核心问题**搜索响应速度慢缺少时间筛选功能 **优先级**高影响核心体验 **建议**优先优化搜索性能评估时间筛选的开发成本有了这个示例模型就知道“反馈类型”要写什么、“核心问题”要怎么写、“优先级”怎么判断。示例的作用是把抽象的要求变成具体的参照。5.2 用“条件分支”处理不同输入类型如果你的 Skill 需要处理多种类型的输入可以用条件分支来组织步骤。比如## 执行步骤 ### 如果输入是单条反馈 1. 直接分类并提炼 2. 输出单条反馈卡片 ### 如果输入是多条反馈 1. 逐条分类 2. 归并同类项 3. 按优先级排序 4. 输出汇总报告 ### 如果输入为空或无法识别 1. 返回提示信息说明需要提供有效的反馈文本条件分支的好处是模型不需要自己判断该走哪条路你已经在 Skill 里帮它判断好了。这样输出的一致性会大幅提升。5.3 控制输出长度别让模型写论文很多人写 Skill 的时候不控制输出长度结果模型每次都给出一大篇内容用起来反而累。好的 Skill 应该控制输出的信息密度而不是信息总量。控制长度的方法有两种一是在输出模板里限定每个部分的最大长度比如“核心观点不超过 3 条每条不超过 20 字”二是在注意事项里明确“如果原文信息量不足不要强行扩充”。我自己的习惯是输出模板里的每个字段都有明确的字数上限。这样不管输入多长输出永远是紧凑的、可快速浏览的。5.4 版本管理Skill 也需要迭代记录Skill 不是写完就扔那儿的它需要持续迭代。建议在 SKILL.md 的末尾加一个简单的版本记录## 版本记录 - v1.0初始版本支持单条和多条反馈整理 - v1.1增加优先级排序逻辑补充空输入处理 - v1.2优化输出模板限制每条观点字数这样做的好处是当你发现某个版本出了问题可以快速回滚当你分享给别人的时候对方也能看到这个 Skill 的演进过程。Skill 是你工作方式的沉淀它值得被认真对待。6. 那些我踩过的坑和后来想明白的事6.1 不要试图写一个“万能 Skill”我最初写 Skill 的时候总想写一个能处理所有情况的“万能 Skill”结果就是每个情况都处理不好。后来我想明白了Skill 的价值在于专精不在于通用。一个只处理“用户反馈整理”的 Skill比一个号称能处理“所有运营文案”的 Skill 有用得多。如果你有多个不同类型的任务就写多个 Skill。WorkBuddy 支持加载多个 Skill每个 Skill 负责一个具体的场景这样反而更清晰。6.2 Skill 的维护成本比你想象的低很多人觉得写 Skill 很麻烦要维护、要迭代。但实际上一个稳定的 Skill 写完之后可能几个月都不需要改。因为你的工作流程本身是稳定的只要流程不变Skill 就不用变。真正需要频繁修改的 Skill往往是因为你一开始就没想清楚流程。所以写 Skill 之前先花时间把流程理清楚比急着写文件更重要。6.3 从“用别人的 Skill”到“写自己的 Skill”如果你刚开始接触 WorkBuddy Skill我的建议是先用几个别人写好的 Skill感受一下什么样的 Skill 是好用的、什么样的不好用。然后找一个你自己每周都在做的重复性任务试着把它写成 Skill。第一个 Skill 不需要完美能跑通就行。我写的第一个 Skill 只有十几行输出格式也很粗糙但它帮我省掉了每次重复描述需求的时间。后来我不断迭代它才变成现在这个稳定的版本。6.4 一个 Skill 好不好用看你是不是“闭着眼睛都敢用”最后分享一个我自己的判断标准如果一个 Skill你闭着眼睛丢进去输入都不担心输出会跑偏那它就是一个真正用得上的 Skill。反过来如果你每次用之前都要想“这次它会不会又乱来”那说明这个 Skill 还需要继续打磨。Skill 的终极目标是让你忘记它的存在——你只需要知道“这个任务找这个 Skill”然后就不用管了。它就像你工具箱里的一把顺手的螺丝刀你不会天天想着它但每次需要的时候拿起来就能用。写到这儿我想起一个朋友问我的问题“写 Skill 到底值不值”我的回答是如果你有一个每周做三次以上的重复任务那写 Skill 绝对值。因为一次投入长期受益。而且随着你写的 Skill 越来越多你会发现自己的工作方式也在变得越来越清晰——因为你被迫把那些“凭感觉做”的事情变成了“有步骤可循”的流程。这本身就是一种收获。