《WorkBuddy Skill 机制拆解|从 How 到 Why,万字干货》

作者: 智见AI-大鹏 @zjp1997720

格式: 专栏文章
阅读时间预估: 5 分钟
作者: 智见AI-大鹏 @zjp1997720•发布日期: 2026-08-31•WorkBuddy 架构机制拆解
WorkBuddy Skill 机制拆解|从How到Why,万字干货

最近我组了个小团队来帮我分担交付压力。作为一个 AI native 团队,我让团队的小伙伴都用上了 WorkBuddy(全员上 Codex 暂时还用不起),也教他们怎么在里面自己设计 Skill。

创建这件事本身不难。WorkBuddy 内置了一个叫 skill-creator 的技能——对,用 Skill 来创建 Skill。只要能把需求说清楚,就能创建出一个不错的 Skill。这一步,大家很快就都过了。

但创建完之后,问题才真正开始:

「我创建的 Skill 存在哪了?」
「为什么新建了一个项目,之前的 Skill 就不见了?」
「Skill 管理里『我安装的』这一长串,都是哪来的?」
「这些 Skill 要怎么维护?会自动更新吗?改过的会被覆盖吗?」

这些问题不是一个人问的。团队里几个小伙伴,前后撞的是同一批墙。

我后来想明白了:他们不是不会用。创建会用,安装会用,调用也会用——What 和 How 都有了,缺的是 Why。Skill 在这个软件里怎么存在、怎么被找到、怎么被加载、怎么被管理,这套机制没人讲过。

💡 核心洞察:

把一件事从「会用」做到「做精」,差的从来就是 Why。 这篇文章把这些问题一次讲透——Skill 是什么、放在哪、从哪来、怎么维护。四个问题,四个机制层面的底层答案。看完这篇,你再打开 WorkBuddy 的技能列表,看到的东西会完全不一样。

WorkBuddy 架构图解

一、Skill 到底是什么:一个文件夹,一份 AI 自己会去读的文档

先校准概念。这一节不解决具体问题,但后面三个答案都建立在它上面。

打开你磁盘上的技能目录(用户级的在 ~/.workbuddy/skills/,怎么找到它下一节讲),随便挑一个技能进去看。你不会看到代码。你会看到一个文件夹,里面躺着一到几个 Markdown 文档:

skill-name/
├── SKILL.md          ← 必需,技能本体
├── scripts/          ← 可选,可执行脚本
├── references/       ← 可选,参考文档
└── assets/           ← 可选,模板等资产文件
Skill 目录结构图解

SKILL.md 是技能的本体,分两段:

  • 开头一段 YAML 元数据:只有两样东西是必需的:name(叫什么)和 description(什么时候用我)。
  • 正文是方法论:写清楚「这类任务怎么做」。

所以 Skill 主文件的准确定义是:一份写给 AI 读的方法论文档。它不运行,不编译,不需要你会任何编程。工作过程是:模型在对话中判断当前任务匹配了某个技能的 description,就去读这份文档,然后按照文档里的方法做事。

SKILL.md 规范拆解

两段结构里,description 值得单独停一下。

系统每次对话只会把所有技能的「名字+描述」放进上下文,正文要等真正用到时才读取。这是按需加载。这带来一个直接推论:模型是凭 description 决定要不要唤醒这个技能的。

🚪 门牌效应:

写技能的功力,一半花在这段描述上。写清触发词,比如「当用户要求写周报时使用」;也划清边界,比如「不用于日记、月报」。有的技能装了从来不触发,问题九成出在这段描述没写好,而不是技能正文不行。

还有一层背景值得知道:SKILL.md 不是 WorkBuddy 的私有格式,它是一个开放标准(agentskills.io 规范)。Claude、Codex、Cursor 这些工具的技能,用的都是同一套格式。WorkBuddy 的技能格式和腾讯的开发者工具 CodeBuddy 完全同源。你会在文件层不断看到这个血脉痕迹——比如它的技能创建脚本里,默认路径还写着 .codebuddy/。

一个文件夹,一份文档,一个开放标准。这就是 Skill 的全部物质基础。


二、放在哪、为什么换项目就找不到:作用域,不是丢件

现在回答团队里被问得最多的问题:我创建的 Skill 存哪了?为什么换个项目就不见了?

WorkBuddy 给自建技能留了两个作用域,这是系统提示词模板里明文写的:

层级物理存储路径生效范围与生命周期
用户级~/.workbuddy/skills/你这台电脑上的所有项目通用,跨工作区可见
项目级<项目目录>/.workbuddy/skills/只有当前项目生效,随项目文件夹与 Git 仓库走
用户级路径
项目级路径

「为什么新建项目后技能不见了」的答案就在这张表里:那个技能当时被创建到了项目级目录。它没有丢,就躺在旧项目的 .workbuddy/skills/ 文件夹里,只是作用域不覆盖新项目。

终端两行只读命令,一分钟查穿技能住在哪
ls ~/.workbuddy/skills/ | head -20        # 查看你的用户级技能库
ls <项目目录>/.workbuddy/skills/ 2>/dev/null   # 查看当前项目的专属技能

那创建的时候,技能会被放进哪一层?WorkBuddy 内置的 skill-creator 给了明确的判断原则:拿不准就放用户级。

这个原则反过来读,就是团队分发的正确姿势:把需要全员一致的技能放进项目级目录,让它随代码仓库走。新人 clone 项目、打开 WorkBuddy,老员工沉淀的方法论自动就在了。

第三层目录:.agents/skills/ 跨 Agent 互操作

这是行业里正在形成的跨 Agent 互操作约定。Codex 把它作为原生主目录,Cursor、GitHub Copilot、VS Code 都官方支持读取它。社区名言:「The spec unified us. The paths divided us.」(规范统一了我们,路径分裂了我们)。

重度用户的做法:一份技能库放在一处,用软链接 (Symlink) 打通到各家目录(如 ~/.workbuddy/skills/ 软链接指向 Vault 里的 .claude/skills/)。目录是入口,文件可以在别处,入口负责让当前 Agent 看得见它。

跨 Agent 互操作软链接图解

🎮 趣味交互体验:Skill 作用域与存储路径决策模拟器

点击切换场景查看推荐落点
🎯 场景:个人跨项目通用技能(如周报生成器、论文润色、日常翻译)
推荐作用域:用户级 (User Level)
推荐物理路径:~/.workbuddy/skills/<skill-name>/

存放在你的个人主目录下,本台电脑上的所有工作区和新建项目都能直接加载调用。

更新策略: 完全由你自己控制,绝不会被任何项目切换或市场更新静默覆盖。

三、「我安装的」那一长串从哪来:分清入口、来源和落点

第三个问题最普遍也最隐蔽。打开 Skill 管理的「我安装的」列表,里面几十个技能(我这台机器显示 94 个),很多你压根没印象装过。

「我安装的」是一个聚合视图:只要当前能被 WorkBuddy 调用,界面就把它列进来。它的磁盘来源至少有五类:

插件缓存路径
市场安装路径
1. 自建与同步导入

落点在 ~/.workbuddy/skills/ 或项目目录。包含 AI 帮你创建的、手工导入的与软链接同步的。

2. 内置插件携带(18 个 skill-* 内置插件)

落点在 ~/.workbuddy/plugins/cache/workbuddy-builtin/<plugin>/<version>/。如 skill-creator, skill-marketplace-skill-installer, skill-expert-manager 等。

3. 技能市场主动安装

落点在 ~/.workbuddy/skills/<skill-name>/,附带来源标记文件(_skillhub_meta.json 或 _knot_meta.json)。

4. 外部插件捎带的嵌套技能

落点在 ~/.workbuddy/plugins/cache/<marketplace>/<plugin>/<version>/skills/。你装插件是为了某个功能,附带收到了几个技能。

5. 连接器携带的技能

落点在 ~/.workbuddy/connectors/skills/(如 fbs-connector)。

外部插件目录
连接器技能目录
来源常见落点识别特征维护与升级规则
自建/手工导入~/.workbuddy/skills/本地目录,AI 创建带 agent_created: true自己完全可控,改完即时生效
跨 Agent 同步上述目录里的软链接readlink 能看到真实源路径改源目录,多端全局生效
内置插件技能.../workbuddy-builtin/.../version/workbuddySeedManaged: true随产品更新覆盖,复制出来再改
市场技能~/.workbuddy/skills/<name>/_skillhub_meta.json / _knot_meta.json自动更新;修改后有 userModified 保护
外部插件技能.../plugins/cache/.../skills/跟随插件清单分发跟插件版本更新走
系统提示词模板里的死命令:find-skills 自动补给线

WorkBuddy 的系统提示词模板(位于应用包内 workbuddy-prompt.tpl)明文规定:「当你遇到做不了的事(操作邮件/日历/备忘录或系统自动化),第一个动作必须是调用 find-skills 去技能市场搜一圈;确认没有合适技能才允许说做不了。」

你的技能列表会自己生长:一半是你主动装的,另一半是 AI 在干活途中发现能力缺口自己去市场上找回来补上的。
find-skills 提示词模板
按需加载机制

四、怎么维护:一套生命周期标记体系与复盘闭环

技能多了之后的维护——改了会不会被覆盖、AI 创建的和市场装的能不能混着管、团队怎么统一升级——答案藏在文件层的一套标记体系里。

agent_created 标记
userModified 保护机制

AI 创建的技能:agent_created 标记

由 Agent 创建的技能自带 agent_created: true。代表「AI 生成的资产自带可被 AI 安全管理修改的出生证明」。

市场技能:userModified 防覆盖保护

一旦你在 WorkBuddy 中编辑了市场技能,系统写入 userModified: true。后续市场自动更新绝不静默覆盖,先弹窗征求你的同意。

维护的高级形态:系统提示词常驻复盘法则
“端到端使用 Skill 后必须复盘,检查是否有可由 Skill 修正的问题;存在明确优化项时说明建议,并询问是否修改。”

这段话把「复盘」从人工记忆变成了 AI 的刚性义务。每一次使用,都变成了一次免费的技能审计。

复盘机制
技能沉淀开关

⚖️ 技能与规则的分工界限:

技能按需进场,规则常驻在场。 永远适用的(如复盘准则、交付格式)写进系统规则;特定场景适用的(如写周报、清洗数据)做成 Skill。

自我进化与闭环机制

五、从 Why 回到 How:一条被机制校准过的四步工作流

1

带着 AI 把任务从头到尾真刀真枪做一遍

不是先写技能再干活,而是在实战中收集「一手证据」:哪步易错、标准是什么。跳过这步写出来的只是凭空想象的文档。

2

做成之后,让 AI 固化最短成功路径

把成功过程交给 AI 提炼,砍掉试错弯路,只固化被验证过能稳定走通的确定性步骤。

3

认真回答 AI 的对齐提问(打磨 description 门牌)

明确回答「什么时候用、什么时候坚决不用」。划清边界是唯一不能外包的环节。

4

选对作用域,并亲自打开 SKILL.md 亲眼看一遍

个人进用户级,团队约定进项目级。亲眼扫一眼门牌与正文,快速建立对好技能的直觉判断力。

工作流实践总结

六、收个尾:工具会换,机制认知跟着你走

回到开头。团队小伙伴的四个问题,现在都有了机制层的答案:

  • Skill 是什么:一份给 AI 读的方法论文档;
  • 存放在哪:两层作用域和多个插件缓存,入口决定在何处出现;
  • 从哪来:多个来源的聚合,还会被 find-skills 悄悄在干活时自动补齐;
  • 怎么维护:一套标记体系,高级形态是在使用中强制复盘、由人决定进化。

💡 团队资产复利:把个人技巧变成团队的数字资产

对团队来说,这笔账更清楚:每个成员在工作中被固化的经验,都落在项目级目录里。随仓库沉淀、随版本演进、随新人自动就位。人员的流动带不走它,因为它早就不是某个人的技巧,而是团队的资产。

作者:智见AI-大鹏 (@zjp1997720) —— 原文详述了 WorkBuddy 的系统提示词拼装、技能目录加载机制与插件分发链路。