夜雨聆风解析下 WorkBuddy 的Skill 体系
对着 AI 说"帮我写个小程序"时，它凭什么能拿出专业级的代码？答案藏在一套精心设计的技能体系里。
先聊一个问题：AI 的"专业感"从哪来？
同样是 AI 助手，有的聊起来像个"万事通但万事浅"的百科全书，有的却像请了一位真正的领域专家：它清楚项目里该用什么框架、组件怎么搭配、最佳实践有哪些……
差别在于背后携带了多少"专业技能包"，不在模型本身。
WorkBuddy 把这些技能包叫做 Skill。下面拆解一下，这套"技能树"是怎么组织的、怎么存储的、又是怎么让 AI 变专业的。
五层货架：Skill 存在哪？
想象一个五层书架，每层放着一类书：
前两层跟着 App 安装包走，路径在 /Applications/ 下，属于"出厂标配"。后三层在用户主目录下，属于"个性化装备"。
打个比方：前两层是手机出厂预装 App，第三层是从商店下载的专业工具，第四第五层是自行编写的脚本和模板。
从"市场"到"专家"：三层嵌套逛一遍
Skill 不是散乱放的文件，它有一套清晰的从"市场 → 专家 → 技能"的三层嵌套逻辑。
市场根目录 ~/.workbuddy/plugins/marketplaces/ └── 专家市场 experts/ ├── marketplace.json ← 市场清单（所有专家的"挂号单"） └── plugins/ ← 所有专家插件存放处 ├── gaokao-advisor/ ← 高考志愿专家 ├── ip-expert/ ← IP 专家 ├── strategy-backtest-expert/ ← 策略回测专家 └── we-chat-mini-program-developer/ ← 🌟 小程达（本文主角）
图 1：marketplaces 下的专家市场目录。
图 2：experts 市场内的专家插件列表。
marketplace.json 就像商场的楼层指引牌，列出了所有可用的专家插件。每条记录告诉系统："有个叫 we-chat-mini-program-developer 的专家，它的资料在哪个目录下。"
走进一位专家的"办公室"
点进小程达的目录，就像走进了一位资深小程序开发者的办公室：
we-chat-mini-program-developer/├── .codebuddy-plugin/│ └── plugin.json ← "工牌"（元数据：名字、版本、技能清单）├── agents/│ └── *.md ← "人设设定"（这位专家的性格和专业风格）├── avatars/│ └── expert.png ← "头像照片"├── README.md ← "个人简介"└── skills/ ← "技能工位"（核心区域） ├── brand-guidelines/ ← 品牌规范 ├── fullstack-dev/ ← 全栈开发 ├── impeccable/ ← 前端设计精进 ├── skyline/ ← Skyline 渲染引擎 ├── tdesign-miniprogram/ ← TDesign 组件库 └── wechat-miniprogram/ ← 小程序框架本身
图 3：小程达专家插件的目录结构与 6 个 Skill。
最关键的是 plugin.json 里的 skills 数组，它声明了激活这位专家时，要同时加载哪些技能包。
{ "name": "we-chat-mini-program-developer", "displayName": { "zh": "小程达", "en": "Cody" }, "profession": { "zh": "微信小程序开发者" }, "skills": [ "./skills/brand-guidelines", "./skills/fullstack-dev", "./skills/impeccable", "./skills/skyline", "./skills/tdesign-miniprogram", "./skills/wechat-miniprogram" ]}6 个技能包，一激活就全部就位。这就是为什么和专家对话时，AI 的回答格外专业：它手里有实打实的参考资料。
一个 Skill 的"内页结构"
打开任意一个 Skill 目录，总会看到一个主角：SKILL.md。
最简形态：一张卡
skills/brand-guidelines/├── SKILL.md ← 必须存在，是唯一入口└── LICENSE.txtSKILL.md 顶部是 YAML 元数据（"这张卡的标签"），正文是技能说明（"这张卡的内容"）：
---name: wechat-miniprogramdescription: "微信小程序开发框架..."description_zh: "微信小程序开发框架..."description_en: "WeChat Mini Program framework..."version: 1.0.0allowed-tools: Read,Write,Bash ← 这个技能能用哪些工具---正文通常包含：什么时候触发这个技能、常用代码模板、参考文档索引、核心概念讲解。
中等形态：一张卡 + 一叠附件
skills/wechat-miniprogram/├── SKILL.md└── references/ ← 参考文档目录 ├── getting_started.md ← 快速入门 ├── framework.md ← 框架详解 ├── components.md ← 内置组件 ├── api.md ← API 参考 ├── cloud.md ← 云开发 └── ...SKILL.md 是"目录页"，references 是"正文章节"。AI 需要深入某个主题时，会从 references 中找到具体文档。
丰富形态：一张卡 + 几十叠附件
fullstack-dev 有 8 个参考文件，覆盖技术选型、API 设计、认证流程、数据库、Django 最佳实践、环境管理、发布清单、测试策略，覆盖全栈开发全链路。
impeccable 更夸张：30 个参考文件，从排版到配色、从动效到交互、从认知负荷到无障碍设计，简直就是一本 UI 设计百科全书。
最复杂的形态：技能嵌套技能
skyline Skill 展示了 WorkBuddy Skill 体系中最精妙的设计：Skill 嵌套 Skill。
想象一棵树：顶层的 SKILL.md 是树干，references 下的每个子目录又是一棵小树（有自己的 SKILL.md），小树的 references 下再长出枝叶（具体文档），最多可达 3 层嵌套。
skyline/├── SKILL.md ← 总入口（树干）└── references/ ← 7 个子模块（大树分支） ├── overview/ ← 概览与迁移 │ ├── SKILL.md ← 子技能入口（小树树干） │ └── references/ ← 具体文档（枝叶） ├── components/ ← 组件体系 │ ├── SKILL.md │ └── references/ │ ├── scroll/ ← 滚动类组件 │ ├── form/ ← 表单类组件 │ ├── media/ ← 媒体类组件 │ └── special/ ← 特殊组件 ├── config/ ← 配置规范 ├── route/ ← 路由与转场 ├── scroll-api/ ← 滚动控制 API ├── worklet/ ← Worklet 动画 └── wxss/ ← WXSS 样式
图 4：Skyline Skill 通过多层 references 与 SKILL.md 组织子技能。
为什么嵌套？ 因为 Skyline 渲染引擎本身就是一个小宇宙。概览、组件、配置、路由、动画、样式，每个子领域都足够深，需要独立的技能入口。嵌套让系统可以在需要时只加载某个子模块，避免一口气吞下整座大山。
这是一种**"按需加载、分层展开"**的设计哲学，和前端里的懒加载异曲同工。
另一种组织流派：按功能域分目录
tdesign-miniprogram Skill 展示了不同的组织思路，references 按功能域分目录：
tdesign-miniprogram/├── SKILL.md└── references/ ├── miniprogram/ ← TDesign 小程序组件（60+ 组件文档） │ ├── getting-started.md │ ├── components/ │ │ ├── button.md │ │ ├── dialog.md │ │ ├── tabs.md │ │ └── ... ← 60 多个组件！ └── miniprogram-chat/ ← TDesign AI 聊天组件 ├── components/ ├── chat-message.md ├── chat-sender.md └── ...
图 5：TDesign MiniProgram Skill 按 miniprogram 与 miniprogram-chat 功能域组织文档。
60 多个组件文档按功能域整齐排列，像一个分类清晰的零件仓库。AI 要用哪个组件，直接去对应货架拿。
内置 Skill vs 专家 Skill：两种"装备"的区别
内置 Skill（比如金融数据查询 westock-data）住在 App 安装包内，多了两个"特殊装备"：
/Applications/WorkBuddy.app/.../builtin-skills/westock-data/├── SKILL.md ← 入口文件（格式相同）├── package.json ← npm 包配置（专家 Skill 没有）├── scripts/│ └── index.js ← 可执行脚本（专家 Skill 没有）└── references/ ├── commands.md └── ...关键差异：
内置 Skill 可能需要调用外部 API、执行复杂逻辑，带了代码引擎。专家插件 Skill 是纯知识型装备，通过 allowed-tools 声明"我需要用哪些工具"，AI 在运行时按声明调用。
七条约定：Skill 的"宪法"
总结一下 Skill 体系的组织约定：
1. SKILL.md 是唯一入口。每个 Skill 目录必须有，文件名不可更改 2. YAML Frontmatter 是元数据。name、description、version 等字段写在 ---之间3. references/ 存补充文档。按需创建，可以没有，也可以放几十个文件 4. references 可以嵌套。子目录有自己的 SKILL.md，形成子技能（如 skyline） 5. 路径用相对引用。plugin.json 中 ./skills/xxx，SKILL.md 中references/xxx.md6. allowed-tools 控权限。限制 Skill 加载时可用的工具集 7. 中英文双语支持。description 支持 _zh和_en后缀变体
一句话定位路径
以小程达为例，从用户目录到具体 Skill 入口文件，完整路径推导链：
~/.workbuddy/ ← WorkBuddy 用户目录 └── plugins/marketplaces/experts/ ← 专家市场 └── plugins/we-chat-mini-program-developer/ ← 专家插件 └── skills/wechat-miniprogram/ ← 具体 Skill └── SKILL.md ← 入口文件简写：~/.workbuddy/plugins/marketplaces/experts/plugins/we-chat-mini-program-developer/skills/wechat-miniprogram/SKILL.md
看起来很长？不需要手动找这个路径。系统会根据激活的专家，自动加载对应的技能包。这条路径是给想深入了解体系结构的开发者看的。
写在最后
WorkBuddy的Skill 体系设计哲学可以概括为三句话：
1. 知识是结构化的。有入口、有分层、有索引的知识体系，不是一锅粥式的文档堆 2. 加载是按需的。嵌套 Skill 可以只加载子模块，不浪费上下文窗口 3. 扩展是开放的。用户级和项目级 Skill 让任何人都能往"书架"上添加新书
和一位 WorkBuddy 专家的对话，实际是一整座精心搭建的技能图书馆在默默支撑。
速查表
