12.4 D 产品操作（5 问）

这组是学员回到岗位后最先卡住的地方——不是方法论不懂，是手上跑不动。以下五问对应第 3~5 章的实操内容，遇到时可以直接回来查。

Q13：技能（Skill）和专家（Expert），什么时候该用哪个？

技能是「一套做事的方法」，专家是「一个有身份的角色」。 判断方法很简单：如果你想固化的是一个流程或规范（例如「周报怎么写」「数据表怎么清洗」「合同要检查哪 12 项」），做成技能；如果你想固化的是一个能被反复找上门的岗位人设（例如「招生咨询顾问」「财务合规审核员」），做成专家。

两者是嵌套关系：专家 = 人设提示词 + 若干附属技能 + 展示信息。所以实践顺序通常是先沉淀出两三个技能，跑顺了，再包装成一个专家对外发布。

一个判断偷懒的信号：如果你的专家里没有挂任何技能，只有一段人设提示词，那它大概率还只是「换了个语气的通用对话」，还没到资产层面。

Q14：我写的技能，为什么 WorkBuddy 从来不自动用？

八成问题出在 description 上。自动匹配靠的是 description 与用户提问的语义相关度，正文写得再详细，description 含糊也不会被调起。

对比一下：

• ✕ description: 数据处理技能 ——太抽象，匹配不到任何具体提问

• ✓ description: 清洗招生咨询记录表，去重、补全缺失字段、按渠道汇总转化率。当用户提到招生数据、咨询表、渠道转化时使用。

关键写法：把「什么情况下该用我」直接写进 description，包含业务名词和触发场景。

如果还是不触发，先用手动方式验证技能本身有没有问题：用「用 <技能名> 帮我处理这份表格」。手动能跑通说明逻辑没问题，纯属 description 问题；手动也跑不通，回去检查工作流步骤是否可执行。

Q15：技能写完之后想让 WorkBuddy 帮我改，它说改不了？

检查 SKILL.md 的元信息里有没有 agent_created: true。缺这一行，WorkBuddy 会把该技能视为不可修改，后续迭代只能靠你手工编辑文件。

这条很容易漏，代价是后面每次调整都要自己动手，失去了「让 AI 帮你改 AI」的效率。建议做成习惯：新建技能第一件事就是写全元信息（名称、description、agent_created: true）。

技能文件存放位置：~/.workbuddy/skills/，可以直接 ls 查看已装技能列表。

Q16：企业后台给部门配了白名单，为什么有人还是看不到那个专家？

按这三条依次排查，绝大多数问题在第一条：

① 黑名单优先级高于白名单。 如果同一个人既在白名单也命中黑名单，结果是不可见。企业规模一大，两份名单往往由不同人维护，冲突很常见。

② 启用状态与下发策略是两回事。 专家如果还处于「仅保存」的草稿状态，配了白名单也不会下发。需要确认已「保存并启用」。

③ 内置市场专家不受企业下发策略约束。 如果你想限制的是市场专家，白名单／黑名单都管不住它。

排查完仍不确定时，用后台的**「权限查询」**直接查某个成员对某个专家的最终权限，比逐份名单比对快得多。

顺带一个不可逆的坑：专家标识（如 frontend-expert）发布后不可修改，且全局唯一。命名前先想清楚，别用 test、demo1 这种临时名字发布。

Q17：在客户现场，MCP 老是连不上（红色状态），怎么排查？

按从外到内的顺序查，别一上来就怀疑配置文件（第 3 章的排查顺序）：

① 网络出口。 客户内网常见屏蔽公网 443 出站，导致 npx 拉包直接失败。表现是安装阶段就卡住，而非连接阶段。进场前先问清出网策略，必要时提前在本地准备好离线包。

② 配置层级选错。 用户级配置在 ~/.workbuddy/mcp.json（全项目生效），项目级在 <项目>/.workbuddy/mcp.json（仅当前项目）。写在项目级却在别的项目里用，自然连不上。客户现场的通用系统建议放用户级。

③ 凭据与权限。 Token 过期、权限范围不够、企业应用未授权给当前成员，都会表现为红色。

练手建议：官方推荐先用企业微信机器人跑通一次——配置最简单，成功后显示绿色状态，能帮你确认「问题在环境还是在配置」这个分界点。

这不只是技术问题。第 5 章讲过，客户数据能不能出内网决定了部署形态（旗舰版／专享版／私有化企业版）。MCP 连不上，很多时候是合规边界没谈清的技术表现。