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 稳定加载并执行的 SkillSKILL.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 迭代节奏什么时候该改 SkillSkill 不是写完就完事的。我判断该改的信号有三个一是同类问题反复出现说明规则没写清楚二是输出格式开始漂移说明规范约束力不够三是我自己每次都要手动补一句说明这句话该进 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。工具是拿来省事的不是拿来供着的。