专家包管理器技能：从零做出可上架专家

把一个专家从需求到上架打包的整套流程，固化成可重复执行的步骤。

自己搓一个“专家”容易，让它能被 WorkBuddy 识别、能过审核、能上架，就不容易了：目录必须对、字段必须齐、头像规格、标签个数、能力描述字数都有硬要求。专家包管理器技能就是干这件事的——它按 WorkBuddy 专家开发规范 v2.0，把创建、校验、注册、打包串成一条流水线。

核心能力

1. 两种专家类型，不会搞错

技能把专家分成 agent 型（单角色）和 team 型（多角色协作），并明确要求根据实际结构判断，不可随意指定或变更。这个约束很必要：很多人把一套多角色流程硬塞进单个专家，结果提示词里塞满“你现在是产品经理兼开发兼测试”，效果直接崩。技能会在生成前先问清角色构成，再定类型。

2. 五种展示字段一一对应

它把“卡片上看到什么”与“文件里写哪个字段”列成了表：名字（职业）对应 profession，花名对应 displayName，类型对应 expertType，行业分类对应 categoryId，能力介绍对应 displayDescription（中文 40–50 字），擅长领域对应 tags（固定 3 个），试试这样问对应 quickPrompts（固定3 个，第一条兼作默认初始化提示）。写超字数、标签写到第 4 个，都会在校验环节被拦下。

3. 交互模式与资料转化模式

两种入口：你只有想法，就用交互模式，它提问收集信息后生成；你手上已经有文档、流程、提示词，就用资料转化模式，直接从材料里抽信息。后者对已有 SOP 的团队很实用——把手册丢进去，直接转成一个能用的专家，不用重写一遍提示词。

4. 目录强制，不允许自己改路径

技能里最硬的一条：专家必须生成到专家目录（由 WORKBUDDY_CONFIG_DIR 决定，默认 ~/.workbuddy/plugins/marketplaces/my-experts/plugins），禁止生成到其他目录，并要求在你要求换路径时拒绝并说明原因。这看着不近人情，但确实避免了“生成了但客户端检测不到”这类白忙活。

5. 从初始化到打包全链路脚本

它把流程拆成七步并各自对应脚本：收集信息 → init_expert.py 初始化 → 按 references 生成内容 → 生成头像（按 avatar-spec.md）→ validate_expert.py 校验 → register_expert.py 注册 → package_expert.py 打包。批量创建时则串行重复，参考 batch_create.py。

使用上手

1. 先想清楚：你要的是一个角色，还是一支协作团队。这决定了 expertType，也决定了后面提示词怎么写。
2. 在对话里说“用 expert-manager 创建一个专家”，然后一次性把三件事说清：做什么、给谁用、产出什么。
3. 如果手上有现成资料（手册、流程文档、旧提示词），直接上传走资料转化模式，比口述快得多。
4. 确认五个展示字段：职业定位、花名、能力介绍（40–50 字）、3 个领域标签、3 条示例提问。超了会被校验退回。
5. 让技能跑 validate_expert.py，按报错逐项修，不要跳过校验直接打包。
6. 校验通过后 register_expert.py 注册，再 package_expert.py 打包，然后在客户端里实际对话两三轮验收。

优点与不足

优点

• 把“字段规格”变成硬校验，不靠记忆与肉眼。
• 强制专家生成目录，避免产物白做。
• 支持从已有资料转化，存量资产能复用。
• 有批量创建脚本，适合一次做一整套专家。

不足

• 前置要求很硬：必须完整读 SKILL.md 全文，跳读容易漏规则。
• 流程步骤多，单次创建耗时不短。
• 头像规格、分类选择需要人工判断，自动化只能到一半。
• 偏向 WorkBuddy 生态，内置规则不能搬到别的平台。

适合谁

• 想把团队 SOP 变成可用 AI 专家的业务负责人。
• 一次要做多个专家、需要批量与统一规范的运营。
• 已有大量提示词资产、想系统化沉淀的团队。
• 需要对自己的专家包做合规检查与质量审查的人。

下载与访问

• 使用方式：WorkBuddy 对话中调用 expert-manager
• 技能目录：WorkBuddy 安装目录下 builtin/skills/expert-manager
• 专家产物目录：~/.workbuddy/plugins/marketplaces/my-experts/plugins

获取与授权

本文属于「技能」分类的 AI 资源专栏，更多评测见分类页。