把 WorkBuddy 装上之后头几天我其实是有点失望的——充其量是个聪明点的聊天框嘛问一句答一句效率没见翻倍好奇心倒先翻倍了。直到我认真研究了一下技能Skills、插件Plugins、连接器Connectors这三个东西的差异才意识到我一直在用最原始的方式跟它相处。这篇文章想分享的就是我从把 WorkBuddy 当聊天框到把它当一个能自动干活的团队实习生的过程中真正落地且长期在用的 10 个技能。适合刚装好 WorkBuddy 还在到处摸索的人也适合那些装了挺久但总觉得差点意思的老用户。先说明一点我这里讲的技能是 WorkBuddy 体系里的 Skills不是技能树那种游戏化东西。它本质上是一套你可以反复触发、有明确步骤和输出格式的工作流定义。你不需要懂很深的编程只要会写 Markdown就能自己造技能。1. 先搞清楚技能、插件、连接器是三种什么角色很多人的第一个困惑是这三个东西名字听着很像到底什么关系我自己踩过的坑是装了一堆插件连了一堆连接器结果还是不会用。后来我用一个不太严谨但非常好记的方式来理解它们。1.1 连接器给 WorkBuddy 接上外部世界的插座连接器解决的是数据怎么进来的问题。WorkBuddy 默认只能看到你当前对话里给它的东西但有了连接器它能直接访问 GitHub、Jira、飞书文档、数据库、本地文件目录等等外部系统。打个比方连接器就是充电器的插头它决定了你能插在哪个插座上。GitHub 连接器能拉取分支和提交记录Jira 连接器能读取任务状态数据库连接器能直接执行查询并返回结果。这些东西本身不改变 AI 的聪明程度但它们极大扩展了 AI 的信息来源。我见过不少团队把连接器权限全都打开以为这样 AI 就能自动干活了。实际上连接器只是接入真正决定 AI 怎么用这些数据的是技能。1.2 插件给 WorkBuddy 新增能力的外挂模块插件则是能力层——它让 WorkBuddy 能做一些原本做不到的动作。比如执行终端命令、操作本地文件、抓取网页内容、调用代码搜索索引这些都需要插件来提供。还是用电动工具类比连接器是电源线插件是电钻头。电源决定你能不能通电钻头决定你能钻出什么效果。常见的插件有 Shell 执行器、文件读写器、代码语义搜索这些插件能让你在对话里直接说帮我把这个仓库里所有 TODO 统计一遍然后它真的去做了。1.3 技能告诉 AI 怎么干活的操作手册技能是三者里最核心、也最容易被忽略的一层。如果说连接器是数据来源、插件是执行能力那技能就是作业指导书——它规定了 AI 在一个具体任务里该按什么顺序、用什么标准、输出什么格式。一个技能通常是一个目录里面有一个核心的 SKILL.md 文件内容大致是# 周报生成器 ## 触发方式 用户说生成周报时启用 ## 目标 根据本周 Git 提交、任务卡片、会议记录生成结构化周报 ## 步骤 1. 汇总连接器提供的提交记录、任务状态和会议摘要 2. 按已完成/进行中/阻塞/风险四类归类 3. 成果描述必须附带可验证的数据证据如提交数、需求单号 4. 按模板输出本周成果、下周计划、需要协助、风险提醒 ## 注意事项 - 不要把待办当成已完成 - 无法从数据源确认的信息一律标注待确认 - 相关数据不足时先询问用户而不是自行编造这个文件的存在让 WorkBuddy 在遇到生成周报这句话时不再自由发挥而是严格按照你定义的套路执行。三个角色的关系一句话概括连接器负责把东西拿进来插件负责把手伸出去技能负责让脑子按套路转。1.4 优先级与触发逻辑为什么技能经常不生效还有一个非常常见的问题我明明定义了技能为什么 WorkBuddy 还是不理我这通常涉及触发逻辑。技能一般通过 description 里的描述被模型识别当用户输入与描述相关时才会被激活。如果 description 写得含糊比如就写帮助用户那它大概率不知道什么时候该用。我的经验是每个技能的 description 里至少要包含三样东西这个技能解决什么问题、在什么场景下触发、不适用于什么场景。后一点尤其重要能避免很多误触发。2. 效率类技能先解决每天都要重复的琐事我最早落地的几个技能全都是针对每周/每天固定要做、但不想动脑的事情。这类技能见效最快也最容易让你建立信心。2.1 技能一周报生成器——让散落的记录自动收敛先说结论这是我使用频率最高的一个技能没有之一。以前写周报我要翻 Git 记录、看钉钉消息、回忆这周开了什么会一个下午就那么没了。后来我写了个周报生成器技能配合 GitHub 连接器和日历连接器。具体工作方式是这样的我会在周五下午说一句生成这周周报技能会自动拉取这一周的 commit、合并的 PR、关联的 Jira 任务以及日历上的会议纪要然后按我预先定义的四象限结构输出。你在定义这个技能时要特别注意两点。第一成果描述不能只写修复了登录问题而要让它带上证据比如修复了登录并发导致的 token 互踢问题commit 8f3a2d1这样周报才有说服力。第二一定要在注意事项里写明无法确认的信息标待确认否则 AI 会为了凑完整性而开始脑补这在周报场景里是很尴尬的。这个技能看起来简单但真正值钱的点是收敛。数据源越分散技能的节省效果越明显。如果你只用它来写一行本周正常推进那是对技能的浪费。2.2 技能二会议纪要整理器——把录音变成可执行清单很多团队的会议记录就是一段语音转文字长而且乱。我写了一个会议纪要整理器技能专门干这件事输入原始转写文本输出一张表。技能的步骤定义得很死第一步提取所有讨论主题第二步把每个主题下的结论单独列出并标注是谁提出的第三步把待办事项抽出来并且区分负责人、截止时间、优先级第四步识别风险点例如某模块排期有冲突之类。我踩过的一个小坑是AI 默认会把所有提到的事情都当成待办哪怕说话人只是在陈述一个事实。后来我在技能的注意事项里加了一句只有出现明确动作和负责人的内容才能算待办输出质量马上就不一样了。如果你能再给它配一个会议记录连接器甚至可以直接让它每天定时把前一天的会议整理好放指定目录这周都不用碰。2.3 技能三技术方案草稿机——从零散备注到方案初稿写技术方案是个典型的写起来半天但其实 80% 内容都是套路的活。背景、现状、目标、方案对比、风险、上线计划每节都有固定的写法和要求。我自己写的时候经常卡在从哪开头但让 WorkBuddy 直接生成又怕太空。所以我设计了一个技术方案草稿机技能专门接受零散的思考片段作为输入。比如我把几段话丢给它用户反馈导入大文件时卡死怀疑是内存拷贝问题后端同学建议用流式处理但前端进度条依赖总大小需要两边协调。技能会按标准模板展开成方案草稿包括现状描述、问题根因分析、候选方案、选型理由、兼容性影响。值得提醒的是这个技能的价值在于把你脑中的碎片组织成连贯文本而不是替你判断技术对错。用它生成的方案你仍然要自己推演一遍关键决策。我遇到过一次它把技术选型理由写得头头是道但引用的性能数据明显是编的——所以技能模板里我强制加了一行所有数据指标必须标注来源找不到来源就写待实测。这相当于给 AI 上了一个紧箍咒。3. 工程类技能写码、评审、测试一条龙如果你是开发者WorkBuddy 最不亏的使用方式就是把它当能读代码的结对同事。这部分技能对代码仓库的阅读理解能力要求比较高建议先给它配置好代码搜索相关插件。3.1 技能四仓库体检报告——比静态检查多一层理解很多项目长期迭代后都会有一些不知道谁写的但没人敢删的代码。传统静态分析工具能给出一堆指标但不会告诉你为什么这段代码变成了这样。我写了个仓库体检报告技能让 WorkBuddy 在指定目录里做一次深度阅读然后输出一份带人类视角的报告。技能的执行步骤大致是先统计整体的文件规模与依赖关系接着找出明显不符合当前架构约定的模块然后定位高耦合、低内聚的热点类——就是那种很多人都在改、但谁也不敢大动的类最后按风险等级排序并给出一个建议优先处理的清单。这个技能跟 SonarQube 这类工具最大的区别在于它能结合提交历史去解释这段代码之前是为什么这么写的。有一次它发现一个支付模块里有一段看起来多余的状态机逻辑顺着提交历史挖掘后发现是当年为了兼容某支付渠道而留下的其他渠道已经下掉了——这种信息静态检查工具永远给不了你。需要注意的是仓库体检不要设置过大的扫描范围。我一开始让它扫整个 monorepo结果它跑来跑去分析了两小时输出的报告结构还挺乱。后来我把技能限定在单模块扫描,再针对重点模块跑一次效果反而好很多。3.2 技能五Code Review 助手——提交前先过一遍 AI 的眼睛这个技能我给团队推荐过多次。它的核心用途不是在代码合入后做审查而是在你提交 PR 之前充当第二双眼睛把明显的低级问题和边界漏洞先挡住。技能的输入很简单一个分支名或 commit 范围。技能会自动调用插件获取 diff然后按逻辑正确性、边界条件、资源释放、并发安全、可读性五类给出审查意见。每一条意见都必须附带文件位置与具体行号并且给出阻塞或建议的等级。我最喜欢的是它能抓只改了主线逻辑忘了改配套逻辑这类问题。比如有人给导出功能加了新字段但 Excel 模板列头没加AI 会通过跨文件上下文发现问题。这类问题在人工 review 时特别容易被忽略因为人总是顺着 diff 看看完就忘了去关联文件。当然AI review 会有噪音。我发现它有时会把风格偏好当成强问题提出来比如这个变量名可以更语义化——这种意见我一般都关掉。所以技能里我也写了抑制规则非功能性建议一律合并为风格备注不占主意见位。3.3 技能六遗留代码重构——小步走不炸锅重构是 WorkBuddy 最容易翻车的场景之一因为它天生倾向于给你一大坨新代码。我刚开始用的时候直接让它重构一个权限判断模块结果它一口气把所有函数的实现都改了——功能上没问题但 review 的人根本没法看而且埋了风险。后来我把这个教训写进了技能任何重构任务都必须先输出一份影响面分析列出所有调用方和可能的副作用然后拆成多个小步骤每步只做一件事。技能还强制要求生成最小改动方案优先于生成理想方案。用这个技能做典型重构流程是这样的先让它读一遍目标代码输出这个函数的真实调用场景分析然后让它给出一个兼容层方案让新旧接口并存最后再按步骤慢慢替换调用方。整个过程中你会发现 AI 真正擅长的是整理和标注而不是一次性重写——把它的能力限制在合理的节奏里反而能拿到稳定成果。设置这种做法的时候有耐心是最重要的。很多开发者让 AI 重构翻车之后就从此再也不让它碰重构了。但本质上不是 AI 不能做而是你没给它立规矩。3.4 技能七单测批量补齐——用例清单先行补单元测试这件事很多人对 AI 的使用方式是帮我给这个函数写测试——这其实很不高效。更好的方式是用一个技能去接管整个流程它先不急着写代码而是先输出一份测试用例清单。这个技能的执行逻辑是读取待测源文件提取它的公共 API、条件分支、错误处理路径生成一份用例矩阵每一行包括用例名、前置条件、输入、预期行为等到用户确认这份清单之后才开始生成具体的测试代码。为什么非得先确认清单因为 AI 生成的测试看起来全绿实际上经常有对着实现写测试的问题——就是说测试意图跟函数内部实现绑得太死后续只要重构一点代码测试就碎一地。先列用例清单至少能让你在动手前发现测试意图是否合理。这个技能落地之后的感受是写单测的心理负担大幅降低。以前想到要写测试就觉得很麻烦现在你只需要去检查 AI 输出的用例矩阵对不对至于 Jest 的 mock 怎么写、怎么构造环境已经不需要自己来一行行硬写了。4. 数据与排查类技能让 AI 当你的分析员这类技能不一定只有开发者能用。只要是经常要跟日志、数据表格、业务报表打交道的人都值得给自己配一个。4.1 技能八日志根因分析——从时间线里找凶手线上出了问题最累的不是修而是定位。从几十万行日志里翻出异常发生的链条是非常消耗心力的工作。我的日志根因分析技能专门干这事。技能通过日志连接器或者本地文件插件读取日志内容然后按时间线做事件聚合先找出第一个异常时间点再回看它之前的告警和痕迹把前因后果拼接成一条完整链路。输出时必须有时间戳、服务名、traceId 引用不能只写看起来是数据库问题这种模糊结论。去年有一次线上 502我们查了大半天没头绪。后来把相关日志喂给这个技能它很快发现每次 502 之前都会先出现一大批 Redis 连接超时时间点跟发布窗口高度吻合——之后查证确实是新发布版本改动了一个连接池参数。这类跨模块的关联线索人肉翻日志很难看到但 AI 读起来很快就串起来了。不过我必须提醒你日志分析技能的输出是线索不是实锤。任何根因结论你都要重新验证一遍。我在技能里强制它输出证据级别确定、可疑、排除。这样就不会出现 AI 拍脑袋给结论而你把结论直接丢给同事的尴尬情况。4.2 技能九数据报表解读——把 SQL 结果转成业务结论这个技能是我给非技术同事推荐最多的一个。做法很简单把 CSV、数据库查询结果或 Excel 表格粘贴给 WorkBuddy技能会按固定的分析框架生成解读报告。框架包括数据结构概览、关键指标、异常波动点、可解释原因、建议动作。比如给一份近 3 个月的用户活跃数据它会发现6 月中旬活跃显著下降并且结合你提供的业务背景那个时间段做了改版推测原因再给出下一步要验证的假设。这种技能最忌讳的是让 AI 自由发挥。如果不加约束它会写出建议优化用户体验这种正确的废话。所以我强制它在每条结论后面标注数据支撑或假设需验证。这样一来输出就变成一份可以放进周报的分析素材。对不会 SQL 的同事这个技能还有一个衍生玩法直接让它根据问题生成 SQL再交给数据团队跑。虽然生成出来的 SQL 偶尔要调整但比从零开始写效率高太多了。5. 底座技能全局规则、记忆与自定义技能库当你把前面的技能都跑顺了之后你会发现一个更大的诉求我不只想用别人定义的技能我想让 WorkBuddy 变成越来越像我的工具。这就轮到第十个技能也是我认为最值得长期投入的技能——自定义底座。5.1 技能十全局规则与记忆——给 WorkBuddy 立人设WorkBuddy 本身支持设置几条全局规则对所有后续任务生效。这个功能一定不要浪费因为它是你所有技能的地基。我自己的全局规则大致有四条所有回答使用中文但代码注释和提交信息保持英文禁止编造不存在的文件、接口、数据不确定的事实必须说明不确定涉及删除、覆盖、重构等破坏性操作先给出影响范围并等待确认代码输出必须附带最小可运行示例不能只给片段这四条规则看着朴素但它们给我的所有技能都兜了底。比如审计这个技能存在日志分析技能就不会因为只顾着找线索而顺手编造一个错误结论有了破坏性操作先确认这条仓库体检技能在提议删除无用代码时也会更谨慎。全局规则是对所有任务生效而更高的自定义技能则是对特定任务生效。两者配合的正确姿势是全局规则解决底线问题自定义技能解决效率问题。5.2 怎样写一个合格的自定义技能文件自力更生写技能其实门槛很低。你只需要建立一个目录里面放一个 SKILL.md然后用 Markdown 写清楚这个技能的触发条件、执行步骤、输出格式和注意事项。我用得顺手的一个模板是--- name: 论文摘要助手 description: 当用户提供论文 PDF 或章节文本时使用。用于生成结构化摘要。不适用于代码库分析。 --- # 论文摘要助手 ## 执行流程 1. 提取文章的研究问题、方法、实验设置、结论 2. 检查摘要是否覆盖了四个部分 3. 输出 300 字以内的中文摘要并保留原文关键术语 ## 输出格式 - 研究问题: - 方法: - 实验/验证: - 结论: - 一句话总结: ## 注意事项 - 不得添加原文没有的结论 - 术语翻译拿不准时保留英文原文写技能文件最大的心得是不要把它写成给 AI 看的提示词而要把它当成给新人同事看的交接文档。新人同事需要知道什么场景用、什么步骤、什么不做AI 也一样需要。写完后放在 WorkBuddy 的技能目录下它的加载器会自动识别。不同版本的导入路径可能有差异但核心都是放进去就能识别这件事。5.3 从抄作业到写作业的进阶路径一开始不知道怎么设计技能就先用别人分享的技能库这一点都不丢人。我自己最开始也用了三四个社区里现成的高质量技能用熟之后才慢慢改造成自己的版本。我建议的进阶路径是这样的第一步挑一个你每天都在做的重复性任务比如写周报、读书笔记、代码 review先用现成技能顶着第二步把现成技能里不顺手的输出格式改掉改成你真正需要的格式第三步基于你已经改过的版本反推它哪部分设计得好、哪部分是为了通用性做的妥协第四步开始给自己的工作场景写第一个全新技能。从用技能到写技能的临界点是当你开始觉得如果它能再多知道一点我的习惯就好了的时候。顺着这个需求走下去你会慢慢沉淀出一个真正属于你的技能库——这个库才是 WorkBuddy 效率翻倍的真正来源。6. 落地过程中踩过的坑与最终建议技能设计得好不好要用了才知道。但有些坑是可以在动手之前就避开的。这部分是我几个月的实战教训写出来给大家做参考。6.1 连接器与插件的权限陷阱连接器默认是全量授权很多人的第一个错误就是全都连上、全都允许。我见过有人给 WorkBuddy 配了生产数据库连接器然后让 AI 做数据分析。AI 确实很乖地执行了但问题是你根本无法保证它在分析过程中不会突发奇想执行一条影响生产的操作。连接器和插件的权限一定要遵循最小化原则。数据分析只连只读实例文件写入只开放白名单目录GitHub 连接器只授予目标仓库权限。如果是团队共用 WorkBuddy还要设好操作确认机制尤其是删除和变更类操作。6.2 敏感信息管理的三条红线第一不要把 API Key、数据库密码、云厂商密钥这些敏感信息直接写进技能文件的示例里。技能文件是会被反复读取的泄露面很大。第二环境变量和敏感变量的管理要用 WorkBuddy 的变量机制来存不要图省事写死在配置里。第三如果技能本身需要访问某些敏感数据应该在技能里注明访问前需经过用户确认而不是静默获取。有一次我为了省事把一个内部系统的 token 直接写在技能文件里后来那份技能文件被分享给同事时token 就这么曝光了。为此我改成了变量引用并加上了如未设置变量则提示用户配置的兜底逻辑才算把坑填上。6.3 技能失效的常见原因与排查路线技能偶尔会失灵比如明明定义了却怎么都不触发。我的排查顺序是这样的先确认技能文件是否被正确加载目录结构和命名是否符合版本文档再检查触发描述的准确性看看它是不是被其他技能或者全局规则抢答了接着检查上下文长度如果技能内容太长可能超出模型可关注的范围最后看一下版本升级后有没有兼容性变化。很多人的直觉是一遇到失效就重装插件这其实是最没有效率的做法。按上面顺序一步步来一般都能快速定位到问题。尤其要注意描述里的适用/不适用场景部分我就遇到过两个技能描述相似、互相抢触发的情况改完描述就好了。最后再分享一个小经验别想着一次性把十个技能全配好再开始用。我的建议是本周先配一个最痛的点下周再加一个。技能这东西用得越久你对它的感知越准写出来的下一版就越趁手。WorkBuddy 的价值不在于你装了多少个技能而在于你有没有把那些真正重复、真正耗时的工作交给它让自己腾出手去做那些 AI 做不了的事。