把 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 做不了的事。
