1. 装完 WorkBuddy 先别急着上手这 5 个技能决定了你的使用上限WorkBuddy 这类工具最近在圈子里讨论度很高尤其是围绕 Skill 体系的玩法从 find-skills 到 skill-creator再到 humanizer-zh 这种去 AI 味的专项技能已经形成了一套相当完整的生态。但很多人装完之后的第一反应就是直接开干结果用不了几天就发现输出内容一股机器味、找不到合适的技能、想定制又不知道从哪下手、项目迁移过来一堆缓存问题。说白了WorkBuddy 本身只是一个壳真正决定它好不好用的是你往里装了什么 Skill。我前后折腾了大概三周时间从最初的“装完就用”到后来逐步补齐几个关键技能体验差距非常明显。这篇文章就是把我踩过的坑和验证过的方案整理出来重点讲清楚五件事怎么找到靠谱的 Skill、怎么让输出内容去掉 AI 味、怎么自己动手写 Skill、怎么管理 Skill 的版本和依赖、以及怎么把 WorkBuddy 真正嵌入到日常工作流里。不管你是刚装完还在摸索阶段还是已经用了一段时间但觉得效果一般这几个技能补上之后使用体验会有质的提升。文章里涉及的操作步骤和参数配置都是我实际跑过一遍的有些地方会给出具体的命令和文件结构有些地方会解释为什么这么选而不是那么选。你不需要全部照搬但至少能少走一些弯路。2. 先搞清楚 WorkBuddy 的 Skill 体系到底是怎么回事2.1 Skill 不是插件它更像是一套“行为说明书”很多人第一次接触 WorkBuddy 的 Skill 概念时会下意识把它理解成浏览器插件或者 IDE 扩展。这个理解偏差会导致后续很多操作走弯路。Skill 的本质是一组结构化的指令和上下文描述它告诉 WorkBuddy 在特定场景下应该怎么思考、怎么组织输出、遵循什么规则。你可以把它想象成给一个新员工写的岗位操作手册——手册本身不干活但决定了干活的人用什么方式干。从文件结构上看一个典型的 Skill 通常包含几个核心部分元信息描述这个 Skill 是干什么的、什么时候触发、行为指令具体怎么执行、以及可选的示例和约束条件。WorkBuddy 在运行时会根据当前任务匹配对应的 Skill然后按照 Skill 里定义的规则来生成输出。这就解释了为什么同一个 WorkBuddy装了不同的 Skill 之后表现差异会那么大。注意Skill 的触发是有优先级的。如果你同时装了两个功能重叠的 Skill可能会出现行为冲突表现为输出风格忽左忽右。建议同类 Skill 只保留一个。2.2 为什么“装完就用”大概率会失望默认状态下的 WorkBuddy 只有基础能力它的输出风格偏向通用和安全这在很多场景下反而成了缺点。比如你要写一篇行业分析默认输出往往四平八稳、面面俱到但缺少锐度和个人观点你要处理一个具体的技术问题它可能会给你一堆“可以考虑”“建议评估”之类的废话而不是直接告诉你选哪个、为什么。这不是 WorkBuddy 本身的问题而是缺少针对性 Skill 导致的。通用模型为了保证不出错会倾向于选择最保守的表达方式。而 Skill 的作用就是给它“松绑”或者“上规矩”——告诉它在什么场景下可以大胆输出、在什么场景下必须严格遵循格式。find-skills 这个技能之所以被频繁提及就是因为它解决了“不知道装什么”的问题相当于给你一个技能市场的导航。2.3 五个必补技能的整体定位我整理了一下装完 WorkBuddy 之后最值得优先补齐的五个技能分别是find-skills技能发现与筛选、humanizer-zh中文去 AI 味、skill-creator自定义技能创建、skill 版本管理依赖与更新、以及工作流集成把 WorkBuddy 嵌入日常工具链。这五个技能覆盖了从“找到好技能”到“自己造技能”再到“让技能真正干活”的完整链路。下面这张表可以帮你快速判断自己当前最缺哪个当前状态优先补的技能预期效果刚装完不知道装什么 Skillfind-skills快速定位高质量技能输出内容一眼 AI 味humanizer-zh中文表达自然化找不到满足需求的现成 Skillskill-creator自己动手定制Skill 装多了互相冲突版本与依赖管理环境稳定可控用了一段时间但没融入工作流工作流集成效率实质提升3. find-skills解决“不知道装什么”的第一步3.1 find-skills 的核心逻辑find-skills 这个技能做的事情说起来简单帮你找到适合当前需求的 Skill。但它的价值在于筛选逻辑。网上流传的 Skill 数量已经不少了质量参差不齐有些是认真打磨过的有些就是随手扔出来的半成品。find-skills 会根据你的描述去匹配技能库然后按照相关性、更新频率、使用反馈等维度给出推荐。我实际用下来的感受是它最大的作用是帮你省掉“大海捞针”的时间。比如你输入“我需要一个处理中文文本去 AI 味的技能”它会直接定位到 humanizer-zh 这类专项技能而不是让你在一堆通用技能里翻找。这个匹配过程背后其实有一套关键词映射和场景分类的逻辑用多了你会发现它对中文场景的理解比想象中好。3.2 实操用 find-skills 定位你需要的技能具体操作上你可以在 WorkBuddy 的对话界面直接描述需求比如“找一个能帮我写技术文档的 Skill”或者“有没有处理中文口语化输出的技能”。find-skills 会返回一个候选列表每个候选会附带简要说明和适用场景。这里有个小技巧描述需求的时候尽量具体。不要说“找个好用的 Skill”而是说“我需要一个能把正式中文改写成口语化风格的 Skill用于社交媒体内容”。描述越具体匹配精度越高。我试过用模糊描述和具体描述分别跑一遍返回结果的差异非常明显。提示find-skills 返回结果后不要急着全部装上。先看每个 Skill 的更新时间和适用场景说明优先选择最近有更新、说明写得清楚的。3.3 筛选 Skill 的三个硬标准用了这段时间我总结出筛选 Skill 的三个硬标准。第一看更新频率超过三个月没更新的 Skill 要谨慎因为 WorkBuddy 本身在迭代旧 Skill 可能不兼容。第二看说明文档的完整度一个连使用说明都写不清楚的 Skill很难指望它内部逻辑有多严谨。第三看是否有明确的适用边界好的 Skill 会告诉你“我适合什么场景、不适合什么场景”而不是宣称自己什么都能干。这三个标准看起来简单但能同时满足的 Skill 其实不多。find-skills 的推荐列表里我通常会先按更新时间排序然后再逐个看说明。这个过程花不了几分钟但能避免后面反复调试的麻烦。4. humanizer-zh让中文输出不再“一眼 AI”4.1 AI 味到底是怎么来的在讲 humanizer-zh 之前先说说 AI 味是怎么产生的。WorkBuddy 默认的输出风格有几个典型特征句式工整但缺乏变化、喜欢用“通过……可以……”“随着……的发展”这类模板化表达、段落结构过于对称、很少使用口语化词汇和语气词。这些特征单独看都不是问题但组合在一起就会让人一眼认出“这是机器写的”。humanizer-zh 这个技能做的事情就是针对中文场景对这些特征进行反向调整。它会在输出时引入句式变化、替换模板化表达、适当加入口语化连接词、打破过于对称的段落结构。我实测下来装上 humanizer-zh 之后同样的提示词输出内容的自然度提升非常明显尤其是写社交媒体文案和博客类内容时差别肉眼可见。4.2 humanizer-zh 的配置与调参humanizer-zh 本身有一些可调参数比如“口语化程度”“句式变化幅度”“是否允许使用网络流行语”等。这些参数没有绝对的最优值取决于你的使用场景。写正式报告时口语化程度调低写社交媒体内容时可以调高。我一般会准备两套配置一套用于正式输出口语化程度设为中等偏低句式变化适中另一套用于轻松场景口语化程度拉高允许使用常见的网络表达。切换配置的成本很低但效果差异很大。如果你经常在不同场景之间切换建议把这两套配置保存下来用的时候直接调用。注意humanizer-zh 的去 AI 味能力有边界。如果原始内容本身逻辑混乱光靠 humanizer-zh 是救不回来的。它的作用是优化表达不是重写内容。4.3 实测对比装与不装的差距我拿同一段提示词做了对比测试。提示词是“写一段关于远程办公效率的短文200 字左右”。不装 humanizer-zh 时输出是这样的“随着远程办公的普及如何提升工作效率成为许多人关注的问题。通过合理规划时间、建立清晰的工作边界可以有效提升远程办公的效率。”典型的 AI 模板句式读起来没有任何个人色彩。装上 humanizer-zh 之后同样的提示词输出变成了“远程办公这事儿效率高低其实跟在哪办公关系不大关键是你能不能把工作和生活的边界划清楚。我自己的经验是固定一个工作区域、每天列三件必须完成的事比什么时间管理方法都管用。”句式变了有了第一人称视角读起来像真人在说话。这个对比不是说 humanizer-zh 万能而是说明它在中文场景下的调整方向是对的。当然具体效果还取决于你的提示词质量和参数配置。5. skill-creator从“用别人的”到“造自己的”5.1 什么时候需要自己写 Skillfind-skills 能解决大部分通用需求但有些场景是找不到现成 Skill 的。比如你所在的行业有特殊的术语体系、你们团队有固定的文档格式要求、你个人有独特的工作流程偏好。这些情况下skill-creator 就派上用场了。skill-creator 的核心价值是降低自定义 Skill 的门槛。你不需要懂编程只需要用自然语言描述你想要的技能行为skill-creator 会帮你生成对应的 Skill 结构。我一开始以为这东西生成出来的 Skill 会很粗糙实际用下来发现只要描述得足够清楚生成的 Skill 质量相当可用。5.2 用 skill-creator 创建一个自定义 Skill 的完整流程创建自定义 Skill 的流程大致分四步。第一步是明确需求边界想清楚这个 Skill 要解决什么问题、在什么场景下触发、输出应该遵循什么规则。第二步是用自然语言写一段描述越具体越好。第三步是让 skill-creator 生成 Skill 草稿。第四步是实际测试并根据结果调整描述。我拿一个实际例子来说明。我需要一个“技术方案评审”Skill要求它在评审技术方案时按照可行性、成本、风险、可维护性四个维度给出结构化意见并且必须指出至少一个潜在问题。我把这个需求描述给 skill-creator它生成的 Skill 草稿基本符合要求我只需要微调一下输出格式的细节。提示skill-creator 生成的 Skill 建议先在小范围场景测试确认行为符合预期后再正式启用。直接上生产环境可能会遇到边界情况处理不当的问题。5.3 自定义 Skill 的调试与迭代自定义 Skill 不是一次成型的东西。我自己的做法是先跑几个典型场景记录下输出不符合预期的地方然后回到 Skill 描述里补充约束条件。比如我发现评审 Skill 有时候会漏掉风险维度就在描述里加一句“必须单独列出风险项不能合并到其他维度里”。这种迭代过程通常需要两三轮之后 Skill 就相对稳定了。另外skill-creator 支持导入示例。如果你能提供一两个“理想输出”的样例生成的 Skill 会更贴近你的预期。这个功能我强烈建议用上尤其是对输出格式有严格要求的时候。6. Skill 版本管理与依赖冲突排查6.1 为什么 Skill 装多了会出问题Skill 装到一定数量之后冲突几乎不可避免。最常见的冲突有两种功能重叠导致的触发混乱以及依赖版本不一致导致的运行异常。前者表现为同一个任务有时用 A Skill 处理、有时用 B Skill 处理输出风格不稳定后者表现为某个 Skill 突然不工作或者 WorkBuddy 启动时报错。我遇到过最典型的一次是同时装了两个都涉及“文本改写”的 Skill结果每次改写输出的风格都不一样排查了半天才发现是两个 Skill 的触发条件重叠了。后来把其中一个禁用问题立刻消失。6.2 版本管理的基本操作WorkBuddy 的 Skill 管理界面可以查看每个 Skill 的版本号和更新记录。我的习惯是每周花几分钟检查一下已装 Skill 的更新情况有更新就及时跟进。但要注意不是所有更新都值得立刻升级如果当前版本用着没问题而更新说明里只是改了一些无关紧要的细节可以先观望。对于依赖关系建议在装新 Skill 之前先看一下它是否依赖其他 Skill 或特定版本的 WorkBuddy。有些 Skill 的说明文档里会写清楚依赖要求没写的可以通过 find-skills 的详情页查看。问题类型典型表现排查方法功能重叠输出风格不稳定检查触发条件是否重叠版本不兼容Skill 突然失效查看更新记录和依赖说明依赖缺失启动报错检查依赖 Skill 是否已安装缓存冲突行为异常清理缓存后重启6.3 缓存目录与项目迁移的注意事项WorkBuddy 的缓存目录默认在用户目录下如果你需要更改缓存位置可以在设置里调整路径。项目迁移时缓存目录不会自动跟着走需要手动迁移或者重新生成。我建议在迁移项目之前先导出 Skill 配置迁移完成后再导入这样可以避免配置丢失。另外如果你在 Windows 和 Ubuntu 之间切换使用要注意路径分隔符的差异。有些 Skill 的配置文件里写死了路径跨平台时可能会出问题。遇到这种情况手动改一下路径配置就行不算复杂但容易忽略。7. 把 WorkBuddy 嵌入日常工作流7.1 工作流集成的三种模式WorkBuddy 跟日常工作流的结合方式我归纳为三种模式。第一种是“随用随开”需要的时候打开用一下用完就关适合低频场景。第二种是“常驻辅助”把 WorkBuddy 放在侧边栏或者第二个屏幕随时可以调用适合需要频繁切换任务的场景。第三种是“自动化触发”通过脚本或者快捷键在特定操作时自动调用 WorkBuddy适合流程固定的重复性任务。我目前用的是第二种加第三种混合模式。日常写作和资料整理用常驻辅助固定的周报生成和格式转换用自动化触发。这样既保持了灵活性又减少了重复操作。7.2 实操搭建一个最小可用的工作流搭建工作流不需要一步到位先从最小可用版本开始。我的建议是先选一个你每天都会做的重复性任务比如“把会议记录整理成结构化摘要”然后为这个任务配置一个专用 Skill再设置一个快捷键或者触发词。跑通这一个流程之后再逐步扩展到其他任务。具体操作上你可以在 WorkBuddy 的设置里找到“快捷指令”或者“触发词”相关的配置项把常用任务的提示词和对应 Skill 绑定起来。这样每次只需要输入一个简短的触发词就能自动调用对应的 Skill 和提示词组合。提示工作流搭建初期不要贪多先把一个场景跑顺再复制到其他场景。同时跑多个自动化流程容易出乱子排查起来也麻烦。7.3 从入门到精通的路径建议如果你想把 WorkBuddy 真正用出效果我的建议是分三个阶段推进。第一阶段是“熟悉基础”把 find-skills 和 humanizer-zh 用熟解决“找到技能”和“输出自然”两个基础问题。第二阶段是“定制扩展”用 skill-creator 创建两到三个自己高频使用的自定义 Skill。第三阶段是“流程固化”把常用操作固化成工作流减少重复劳动。每个阶段大概需要一到两周的适应时间不用着急。我见过不少人一上来就想搭一套全自动工作流结果因为基础没打牢后面反复返工。先把基础技能用顺手后面的扩展会顺利很多。8. 常见问题与排查技巧实录8.1 Skill 装了但不触发怎么办这是最常见的问题之一。排查思路分三步先确认 Skill 是否已启用有些 Skill 装完之后默认是禁用状态需要手动开启再检查触发条件是否匹配有些 Skill 对输入内容有特定要求不满足条件时不会触发最后看是否有其他 Skill 优先级更高导致目标 Skill 被覆盖。我遇到过一次一个文本处理 Skill 死活不触发查了半天发现是另一个通用 Skill 的触发范围太宽把所有文本处理请求都拦截了。把通用 Skill 的触发条件收窄之后问题解决。8.2 输出内容不符合预期怎么调输出不符合预期通常有三个原因Skill 本身的规则不够明确、提示词写得不够具体、或者多个 Skill 之间产生了冲突。排查顺序建议从提示词开始先确认自己的输入是否足够清晰然后再看 Skill 配置最后排查冲突。如果是 Skill 本身的问题可以用 skill-creator 打开对应的 Skill 进行修改。如果是提示词的问题试着把需求拆解得更细分步骤描述。我自己的经验是大部分“输出不对”的情况根源都在提示词太模糊。8.3 性能问题与资源占用Skill 装多了之后WorkBuddy 的启动速度和响应速度可能会下降。如果感觉到明显变慢可以先禁用一些不常用的 Skill观察是否有改善。另外缓存目录过大也会影响性能定期清理缓存是个好习惯。常见问题可能原因解决方向Skill 不触发未启用/条件不匹配/被覆盖检查启用状态和触发条件输出风格不稳定多个 Skill 冲突禁用重叠 Skill启动变慢Skill 过多/缓存过大精简 Skill、清理缓存迁移后配置丢失未导出配置迁移前导出 Skill 配置跨平台路径错误路径写死手动修改路径配置8.4 几个我踩过的坑第一个坑是装完 Skill 之后没有重启 WorkBuddy导致新 Skill 没有生效白白排查了半天。第二个坑是同时装了两个功能相似的 Skill输出风格来回跳后来养成习惯同类 Skill 只留一个。第三个坑是项目迁移时忘了导出 Skill 配置到了新环境重新配了一遍浪费了不少时间。这些坑说起来都不复杂但实际遇到的时候很容易懵。我的建议是每次装新 Skill 或者调整配置之后先跑一个简单测试确认行为符合预期再正式使用。这个习惯能帮你省掉很多排查时间。9. 一些个人体会和后续可以折腾的方向用 WorkBuddy 这段时间最大的感受是工具本身的能力上限取决于你给它装了什么 Skill。默认状态下的 WorkBuddy 就像一个刚入职的新人什么都能干一点但什么都不精。补上 find-skills、humanizer-zh、skill-creator 这几个核心技能之后它才真正变成一个能帮你干活的助手。后续我打算继续折腾的方向有两个一是把更多重复性工作流自动化比如周报生成、资料归档、格式转换这些二是尝试用 skill-creator 创建更复杂的组合技能把多个单一步骤串成一个完整流程。这两个方向都需要一定的调试时间但一旦跑通回报是很明显的。如果你也在用 WorkBuddy建议先从 find-skills 和 humanizer-zh 这两个技能开始补它们能解决最基础也最影响体验的两个问题。后面的 skill-creator 和工作流集成可以等基础用顺了再逐步推进。不用急这东西的投入产出比是随着使用深度增加而提升的。