1. 为什么“加载一个真正用得上的 Skill”值得单独拿出来讲
WorkBuddy 这类工具刚上手的时候，绝大多数人都会经历一个相同的阶段：装好、登录、随便丢几个问题进去，觉得“也就那样”。真正让体验发生质变的，往往不是模型本身换了多大，而是你有没有给它挂上一个真正用得上的 Skill。Skill 这个词最近被聊得很多，SKILL.md、agent skill、skill 和 agent 的区别、ponytail skill、数学建模 skill、book to skill……热搜词里一大半都跟它有关，说明大家已经意识到：光有一个能对话的壳子不够，得让它具备某个具体场景下的“手艺”。
我自己在 WorkBuddy 上折腾 Skill 有一段时间了，从最开始照抄别人的 SKILL.md，到后来自己写、自己调、自己踩坑，最大的感受是：Skill 不是插件，也不是简单的提示词模板，它更像是一份写给模型的“岗位说明书 + 作业规范 + 验收标准”三合一文档。你写得越像给一个刚入职的实习生交代工作，它执行起来就越稳。反过来，如果你只丢一句“帮我分析项目结构”，那它给你的东西大概率是泛泛而谈，因为你自己都没说清楚要什么。
这一章我想聊的不是“Skill 是什么”这种概念科普，而是怎么在 WorkBuddy 里加载一个真正能干活、能复用、能稳定出结果的 Skill。适合谁看？三类人：一是刚装好 WorkBuddy、还在摸索自定义指令的新手；二是已经会写 Prompt、但发现每次都要重复粘贴、想把它固化下来的进阶用户；三是想把团队里某套固定流程（比如周报生成、代码审查、竞品分析）沉淀成可复用资产的人。不管你是用 WorkBuddy 国际版还是 Linux 版本，核心逻辑是通的。
先说一个我踩过的坑：早期我以为 Skill 就是把一段长 Prompt 存起来，用的时候调用一下。结果发现完全不是。Prompt 是“这一次我要你做什么”，Skill 是“以后遇到这类事，你都按这套规矩来做”。前者是一次性指令，后者是长期契约。这个区别想明白了，你写出来的 SKILL.md 质量会直接上一个台阶。
2. Skill 和 Prompt 到底差在哪：先把概念理清楚再动手
2.1 从“一次性指令”到“可复用能力”的跨越
很多人搜“skill 和 agent 的区别”“agent skill”“ai skill”，其实是在找一个心理锚点：我到底在配置什么？我的理解是这样的——Prompt 是动词，Skill 是名词。你说“帮我写个周报”，这是 Prompt；你定义“周报生成器”这个能力，包含固定格式、数据来源、语气要求、禁忌事项，这是 Skill。Agent 则是把这些 Skill 组织起来、自己决定什么时候用哪个的“调度者”。三者是层层递进的关系，不是互相替代。
在 WorkBuddy 里，Skill 的载体通常就是一份 SKILL.md 文件。这个命名很直白：Markdown 格式，写清楚这个 Skill 叫什么、干什么、怎么干、干到什么程度算合格。为什么用 Markdown 而不是 JSON 或 YAML？因为 Markdown 对模型最友好，标题层级天然表达了结构，模型读起来不容易丢信息。你写 JSON 它也能读，但稍微复杂一点就容易在嵌套里迷路。
我实测下来，一个能被 WorkBuddy 稳定加载并执行的 Skill，SKILL.md 至少要包含四块内容：身份定义、输入约定、执行步骤、输出规范。缺任何一块，模型都会在某个环节开始“自由发挥”。尤其是输出规范，很多人不写，结果每次格式都不一样，根本没法复用。
2.2 渐进式披露：为什么 Skill 不能一次把所有信息倒给模型
热搜词里有个“渐进式披露”，这个词很关键。它的意思是：不要把 Skill 的所有细节一次性塞进上下文，而是分层、按需展开。为什么？因为模型的上下文窗口是有限的，你塞得越满，它注意力越分散，关键指令反而被淹没。
举个生活化的类比：你教一个新同事做事，不会第一天就把三年的操作手册全让他背下来。你会先告诉他“你是做什么的”，等他上手了再给“具体步骤”，遇到特殊情况再翻“异常处理”。Skill 的渐进式披露就是这个逻辑。SKILL.md 的主文件应该只放最核心的框架和索引，详细的参考文档、示例库、边界情况处理，放在附属文件里，等模型需要时再引用。
我在 WorkBuddy 上的做法是：主 SKILL.md 控制在 800 到 1500 字，只写“必须知道”的东西；把长示例、参数表、历史案例放到同目录的references/或examples/子文件里，在主文件里用一句话指路，比如“遇到格式问题时参考 examples/format-cases.md”。这样加载快、执行稳，改起来也方便。
2.3 一个 Skill 该有多“重”：颗粒度选择的经验法则
新手最容易犯的错是把 Skill 写得太宏大，比如“数据分析 Skill”，结果什么都想覆盖，什么都做不精。我的经验法则是：一个 Skill 只解决一类任务，且这类任务的输出格式是统一的。比如“把原始数据转成周报”“把 PR 描述转成审查意见”“把会议记录转成待办清单”，这些都是好的 Skill 边界。而“帮我处理所有文档工作”就是坏的边界。
颗粒度太粗，模型每次都要猜你的意图；颗粒度太细，你又得维护一大堆 Skill，调用时还得想用哪个。折中方案是：按“输出物”来划分 Skill。你最终要交付的东西是什么？一份报告、一段代码、一张表格、一封邮件？围绕这个交付物建 Skill，边界自然清晰。我目前维护的 Skill 大概七八个，每个都对应一种固定交付物，用起来很顺手。
3. 动手写一份能跑的 SKILL.md：结构拆解与逐段说明
3.1 身份定义段：让模型先“入戏”
SKILL.md 的第一段，我习惯写成身份定义。不是“你是一个 AI 助手”这种废话，而是具体到岗位。比如：
# 角色 你是一名有五年经验的 B 端产品竞品分析师，擅长从公开信息中提取产品功能差异，输出结构化对比结论。你的分析风格是：先给结论，再给证据，最后给建议。这段话看着简单，但它做了三件事：限定领域（B 端产品竞品分析）、限定风格（结论先行）、限定输出结构（结论-证据-建议）。模型读到这段，后面所有行为都会往这个方向靠。我试过不写身份定义直接写步骤，结果模型经常在“要不要给建议”这种问题上摇摆，加了身份定义之后就稳定多了。
注意：身份定义里不要写“你是一个乐于助人的助手”这类空话，要写具体的职业身份和风格偏好。越具体，模型的行为越可预测。
3.2 输入约定段：把“原料”说清楚
第二段我写输入约定。这一步很多人跳过，但它直接决定了 Skill 的鲁棒性。你要明确告诉模型：这个 Skill 期望收到什么格式的输入，如果输入不符合预期该怎么办。
比如竞品分析 Skill 的输入约定可以这样写：
# 输入 用户会提供 1 到 3 个竞品的名称，以及一份可选的关注维度列表。 如果用户只给了竞品名称没给维度，默认按“核心功能、定价策略、目标用户、差异化亮点”四个维度分析。 如果用户给的竞品超过 3 个，先询问是否分批处理，不要一次性硬做。这里的关键是默认值和异常处理。模型最怕的是“信息不全但又不让问”，你给了默认值，它就能自己往下走；你给了异常处理规则，它就不会在边界情况上翻车。我踩过的坑就是没写异常处理，结果用户丢进来五个竞品，模型硬着头皮分析，输出质量断崖式下跌。
3.3 执行步骤段：像写 SOP 一样写流程
这是 SKILL.md 的核心。我的写法是编号步骤 + 每步的意图说明。注意，不只是写“做什么”，还要写“为什么这么做”，因为模型理解了意图，遇到变体时才能灵活应对。
# 执行步骤 1. 先通读用户提供的所有信息，识别竞品名称和关注维度。这一步的目的是确认任务边界，不要急着分析。 2. 对每个竞品，按维度逐项收集信息。如果某个维度信息缺失，标注“信息不足”，不要编造。 3. 横向对比：把各竞品在同一维度下的表现并列，找出差异点。差异点优先于共同点。 4. 生成结论：每个维度给一句总结，最后给一段整体判断。 5. 自检：检查是否有编造信息、是否有维度遗漏、结论是否有证据支撑。第 5 步的“自检”是我后来加的，效果非常明显。模型在自检时会主动修正一些前面的疏漏。这就像让实习生交作业前自己先检查一遍，能挡掉不少低级错误。
3.4 输出规范段：格式定死，减少来回改
输出规范要具体到可以直接当模板用。我一般会给出一个 Markdown 骨架，让模型往里填：
# 输出格式 ## 结论摘要 （三句话以内，直接给判断） ## 维度对比 | 维度 | 竞品A | 竞品B | 差异点 | |------|-------|-------|--------| ## 详细分析 （每个维度一段，先结论后证据） ## 建议 （基于对比给出 2 到 3 条可执行建议）把格式定死的好处是：你拿到结果可以直接用，不用再排版。而且格式固定之后，你甚至可以把多个 Skill 的输出拼在一起做二次处理。我现在的周报 Skill 和数据分析 Skill 输出格式是统一的，拼起来毫无违和感。
4. 在 WorkBuddy 里加载 Skill 的完整实操流程
4.1 准备工作：文件放哪、怎么命名
WorkBuddy 加载 Skill 的方式，不同版本略有差异，但核心逻辑一致：把 SKILL.md 放到指定目录，然后在对话里引用它。我以常见的目录结构举例：
skills/ competitor-analysis/ SKILL.md examples/ sample-output.md references/ dimension-definitions.md目录名用英文小写加连字符，别用中文和空格，避免路径解析出问题。SKILL.md 必须大写，这是约定俗成的识别标志。附属文件按需建，不是必须的，但如果你有长示例或参数表，强烈建议拆出去，主文件保持精简。
提示：如果你用的是 WorkBuddy Linux 版本，注意文件权限。我遇到过 SKILL.md 权限不对导致加载失败的情况，
chmod 644 SKILL.md一下就好。
4.2 加载与调用：两种常见方式
第一种是自动加载：把 Skill 目录放到 WorkBuddy 的 skills 根目录下，重启或刷新后，它会在可用 Skill 列表里出现。这种方式适合长期使用的 Skill。
第二种是手动引用：在对话里直接说“使用 competitor-analysis 这个 Skill”，或者把 SKILL.md 的内容作为上下文贴进去。这种方式适合临时测试新写的 Skill。
我一般新写一个 Skill 会先手动引用测试几轮，确认稳定了再放到自动加载目录。因为自动加载的 Skill 如果写得有问题，可能会干扰其他对话。测试阶段用独立对话，别在正在干活的主对话里试。
4.3 首次运行后的验证清单
Skill 加载成功不等于能用。我每次新 Skill 上线前会跑一个验证清单：
| 检查项 | 验证方法 | 合格标准 |
|---|---|---|
| 身份是否生效 | 问一个边界问题 | 回答风格符合身份定义 |
| 输入约定是否生效 | 故意少给信息 | 模型按默认值处理或主动询问 |
| 步骤是否执行 | 给一个完整任务 | 输出能对应上每个步骤 |
| 格式是否遵守 | 看输出结构 | 与规范一致，无多余内容 |
| 异常处理是否生效 | 给超范围输入 | 模型按约定拒绝或分批 |
这个清单跑一遍，基本能发现 80% 的问题。剩下的 20% 靠实际使用中慢慢调。
4.4 参数与配置：那些容易忽略的细节
WorkBuddy 里跟 Skill 相关的配置项不多，但有几个值得注意。一是温度参数：分析类 Skill 建议调低（0.2 到 0.4），创意类可以调高（0.7 到 0.9）。二是上下文长度：如果 Skill 引用了大量附属文件，注意别超窗口。三是自定义指令的优先级：WorkBuddy 的自定义指令和 Skill 有时会冲突，我的做法是把通用规则放自定义指令，具体规则放 Skill，避免重复。
热搜里有人问“workbuddy 自定义指令推荐”，我的建议是：自定义指令只放跨 Skill 通用的偏好（比如“回答用中文”“不要用 emoji”），具体任务规则一律放 Skill。这样职责清晰，改起来不会互相影响。
5. 让 Skill 真正“用得上”的进阶技巧
5.1 用示例驱动：给模型看比给模型说更有效
SKILL.md 里写十句“要简洁”，不如给一个简洁的示例。我在每个 Skill 里都会放至少一个完整输入输出示例，放在 examples 目录里，主文件里指路。模型看到示例，对“简洁”的理解会具体很多。
示例的选择有讲究：要选有代表性的，不要选最完美的。我一般放一个标准案例加一个边界案例。标准案例展示正常流程，边界案例展示异常处理。这样模型遇到类似情况时，有参照物。
5.2 迭代节奏：什么时候该改 Skill
Skill 不是写完就完事的。我判断该改的信号有三个：一是同类问题反复出现，说明规则没写清楚；二是输出格式开始漂移，说明规范约束力不够；三是我自己每次都要手动补一句，说明这句话该进 Skill 了。
改的时候小步走，一次只改一个点，改完跑验证清单。别一次大改，否则出问题都不知道是哪改坏的。我有个 Skill 迭代了十几版，现在基本不用动了，因为该踩的坑都踩过了。
5.3 组合使用：多个 Skill 怎么协同
当你有了几个 Skill 之后，会自然想组合使用。比如先用“数据清洗 Skill”处理原始数据，再用“周报生成 Skill”出报告。组合的关键是输出格式要兼容。我在设计每个 Skill 的输出时，会预留一个“标准数据块”，方便下一个 Skill 直接吃。
组合调用时，在对话里明确说“先执行 A，把结果作为 B 的输入”。不要指望模型自己串起来，除非你写了一个专门的调度 Skill。我试过让模型自己判断该用哪个 Skill，结果它经常选错，还是明确指定更稳。
5.4 常见问题速查：我踩过的那些坑
| 问题现象 | 可能原因 | 解决办法 |
|---|---|---|
| Skill 加载后没反应 | 路径不对或文件名不对 | 检查 SKILL.md 大小写和目录层级 |
| 输出格式每次都不一样 | 输出规范写得太模糊 | 给出具体 Markdown 骨架 |
| 模型编造信息 | 没写“信息不足时标注” | 在步骤里加禁止编造的约束 |
| 长任务中途跑偏 | 上下文太长注意力分散 | 拆分任务，用渐进式披露 |
| 自定义指令和 Skill 冲突 | 规则重复或矛盾 | 通用规则上移，具体规则下放 |
| 中文输出夹杂英文 | 身份定义没限定语言 | 在身份段明确“用中文输出” |
这张表里的每一条都是我实际遇到过的。尤其是“编造信息”这条，早期特别头疼，后来在步骤里加了“信息不足时标注‘信息不足’，不要编造”，情况好了很多。模型不是故意骗你，它只是倾向于把空填满，你得明确告诉它“空着也行”。
6. 从“能用”到“好用”：我的个人体会
写到这里，其实核心的东西都讲完了。最后分享几个我自己的体会，不算总结，就是一些零散的经验。
第一个体会是：Skill 的质量上限取决于你对任务的理解深度。你自己都没想清楚这个任务该怎么干，写出来的 Skill 一定是模糊的。所以写 Skill 之前，先手动做几遍这个任务，把步骤记下来，再转化成 SKILL.md。我现在写新 Skill 之前，都会先手动跑三遍，边跑边记，记完再写。
第二个体会是：别追求一次写完美。我第一个 Skill 写得稀烂，但用起来之后才知道哪里烂。先写个能跑的版本，用起来，根据实际问题改。改着改着就顺了。那些热搜里问“workbuddy 从入门到精通”的人，其实缺的不是教程，是动手改的耐心。
第三个体会是：渐进式披露不只是技术手段，更是一种思维方式。它提醒你：信息要给在需要的时候，而不是一股脑倒出去。这个思路用在写文档、做汇报、带新人上，都一样管用。
第四个体会是关于“真正用得上”这五个字的。一个 Skill 用不用得上，标准很简单：你是不是每次遇到这类任务都会想到用它。如果用了两次就忘了，说明它没解决你的真实痛点，或者用起来太麻烦。这时候要么改 Skill，要么承认这个任务不值得做成 Skill。不是所有事都值得固化，挑那些高频、格式固定、你每次都要重复交代的任务来做 Skill，投入产出比最高。
我现在 WorkBuddy 里常驻的 Skill 就五个，不多，但每个都是高频使用的。剩下的任务，该手动就手动，该用 Prompt 就用 Prompt。工具是拿来省事的，不是拿来供着的。
