WorkBuddy 实战手册
WorkBuddy 实战手册

Appearance

Skill 创建、测试、版本与发布 ​

本章目标 ​

安装一个 Skill 只是把它放进可使用范围。真正可复用的 Skill，还要能说明解决什么任务、接受什么输入、产出什么结果，能够在异常和权限不足时停下来，并且可以在修改后回到上一个已知可用版本。本章给出一条从需求到发布的可回退路径。

产品事实与实施方法：当前公开资料能够支持 Skill、专家、连接器和知识资产的概念边界，但具体创建入口、字段名称、团队可见性和分享按钮会随 WorkBuddy 版本、租户策略和账号权限变化。下文把“产品当前提供的能力”和“为了稳定交付而建议的管理方法”分开写，不把人工台账或验收清单当成平台原生功能。

先判断：这件事值得做成 Skill 吗？ ​

Skill 不是一条更长的 Prompt。Prompt 通常描述一次任务；Skill 则把一类重复任务的触发条件、输入、步骤、规则、输出和边界固化下来。Expert 更强调角色视角和领域判断，Agent 或多 Agent 更强调任务执行、工具调用、状态和协作。它们可以组合，但不是同一个对象。

方式适合的问题不适合的信号交付前要看什么
普通 Prompt一次性、目标清楚、无需重复的任务同类任务已经反复出现这次结果是否满足要求
Skill输入输出相对稳定、步骤可以复用的任务每次目标、资料和判断标准都完全不同触发是否准确、输出是否稳定、权限是否可控
Expert需要固定的岗位视角、方法和判断框架只是想让一次任务“看起来更专业”角色边界、适用范围和人工责任
Agent / 多 Agent需要执行、长链路、工具或多个工作包的任务单个小任务就能可靠完成状态、交接、失败处理和最终验收

如果任务仍然没有稳定输入，或者成功标准只能靠临场感觉判断，先保留为普通任务或任务卡，不急着创建 Skill。先把最小可用任务跑通，比先写一套宽泛规则更容易发现真实边界。

一、先写 Skill 需求卡 ​

创建前先填写一张最小需求卡。它是实施方法，不代表 WorkBuddy 一定有同名的配置字段，但没有这些信息就不应把 Skill 交给其他人或接入自动化。

维度需要写清楚例子
输入文件、文本、表格、链接、字段和最小样本一份脱敏的月度销售表
输出格式、结构、长度、命名和保存位置异常清单与一页复核摘要
使用者谁能调用、谁负责检查、谁不能使用运营分析员调用，业务负责人复核
触发方式什么问题或条件下适用收到同一模板的月度数据时
依赖需要的资料、模型、连接器或外部服务规则表、测试目录、只读数据源
权限可读、可写、可发送和可删除的范围只读输入目录，不得覆盖原表
失败条件空输入、字段变化、超时、权限拒绝和事实冲突缺少日期列时暂停并报告
验收标准怎样算完成，谁来批准数字可回溯、格式通过、原文件未变更

把“成功”写成可观察结果，不写成“效果很好”“尽量准确”这类无法复核的形容词。需要专业判断的任务，还要把待确认项单独列出，不能让 Skill 用猜测补齐缺失事实。

二、创建：只配置已确认的能力 ​

如果当前 WorkBuddy 版本提供 Skill 创建或导入入口，先从产品实际显示的入口进入。公开资料和现有内容支持的配置核对维度包括：名称与描述、Instructions、允许使用的文件或知识资料、需要的 Tools / Connector、参数、输出约束和适用边界。这里的字段清单是创建前的核对框架，不是对每个租户 UI 的保证。

创建时按下面顺序写，避免把所有想法堆进一段长指令：

  1. 名称和描述。 名称说任务，不说夸张结果；描述说明适用、不适用和需要人工确认的地方。
  2. Instructions。 写目标、步骤、判断规则、停止条件和输出格式。把“不得猜测”“不得覆盖原文件”等硬边界写成明确规则。
  3. Files / Knowledge。 只挂载有权使用的资料和最小必要范围。资料可能过期时记录版本或核对日期，不能把个人临时笔记当作组织事实源。
  4. Tools / Connector。 只有任务确实需要时才启用；先用只读能力完成验证，写入、发送、发布和删除动作单独设置人工门禁。连接器的实际可用项以当前版本和租户权限为准。
  5. 参数和输出。 把必须输入的字段、可选字段、缺失时的处理和输出模板写清。若当前入口没有参数化字段，就用需求卡和模板人工管理，不杜撰平台功能。
  6. 示例与反例。 准备一个通过样例、一个边界样例和一个不应触发的诱饵样例，帮助后续测试判断误触发。

创建完成后先保存草稿或测试副本。不要在第一次创建时连接真实客户资料、生产密钥、群聊外发权限或唯一原件。

三、测试：从正常路径开始，也要测试“不能做什么” ​

最小测试集至少包括下表。每个用例记录输入版本、Skill 版本、运行时间、结果、文件变化、权限和人工结论。

测试项要验证的问题通过标准
Happy path标准输入能否按预期完成输出完整，结构和规则符合需求卡
空输入没有文件、字段或文本时会怎样明确提示缺口并停止，不生成假结果
异常输入错误格式、缺列、乱码或重复记录是否可识别标记异常，保留证据，不静默跳过
文件变化是否读写了预期目录和文件原文件不被覆盖，变更可列出
权限不足无权访问或调用时是否安全失败不绕过权限，不泄露资料或凭证
外部服务失败超时、断网、限流和服务错误如何处理保留错误和部分结果，按规则重试或转人工
输出格式文档、表格、JSON 或命名是否符合约定下游可以打开、读取和复核
事实核对是否把推断写成事实，引用能否回溯事实、推断和待确认项分开
边界测试相似但不适用的任务会不会误触发明确拒绝或要求人工确认

测试时一次只改一个主要变量。若同时更换资料、Instructions、模型和连接器，失败后就无法知道是哪一处造成变化。对会写文件或调用外部系统的 Skill，先把输出改成草稿、预览或差异清单，再开放真实动作。

四、版本：把“可用”变成可追溯 ​

版本管理是实施方法。除非当前产品入口明确提供原生版本、发布和回滚能力，否则不要把人工编号写成 WorkBuddy 的系统字段。

建议为每个测试或正式版本留下：

  • 版本号、更新时间、负责人和变更原因；
  • Instructions、资料、Tools / Connector、参数和输出约束的变化；
  • 通过、失败和未覆盖的测试用例；
  • 兼容的输入格式、依赖和已知限制；
  • 旧版本副本、回退位置和恢复负责人。

修改前先复制已通过版本，修改后在隔离数据上重新跑完整测试集。出现结果漂移、越权、格式破坏或无法解释的错误时，先停用测试版本并回到上一个通过版本，不要用“再试一次”覆盖证据。

五、发布与共享：先小范围，再扩大可见性 ​

发布前核对当前产品是否提供相应的保存、安装、更新、分享、团队可见性或卸载入口。不同版本可能使用不同名称，也可能只提供个人使用范围；页面不能把内部伙伴渠道、培训包或人工分发流程包装成公开功能。

推荐的发布顺序是：

  1. 测试负责人确认测试记录和已知限制；
  2. 业务负责人确认输出真的解决任务，而不是只通过格式检查；
  3. 安全或管理员确认资料、连接器、Secret、API Key 和写操作边界；
  4. 先给一组已知用户或测试空间使用，收集失败样本；
  5. 再按当前产品可用的分享或安装机制扩大范围；
  6. 更新时保留旧版本和变更说明，停用时通知使用者并撤回依赖。

如果没有原生版本或回滚入口，就用组织批准的目录、台账和发布记录补足治理，但要明确这是企业实施方法。

六、安全与上线检查清单 ​

上线前逐项回答“是 / 否 / 不适用”，不能用“应该没问题”代替证据：

  • [ ] Skill 的任务、使用者、触发条件、输入、输出和失败条件已写清；
  • [ ] Files / Knowledge 只包含有权使用、范围最小且版本可识别的资料；
  • [ ] Secret、API Key、Token 没有写进 Prompt、Instructions、截图、日志或公开文档；
  • [ ] Tools / Connector 采用最小权限，读、写、发送、删除和发布动作已分开验证；
  • [ ] 测试覆盖正常、空输入、异常输入、权限不足、外部失败、输出格式和误触发；
  • [ ] 原文件、测试副本、草稿和正式产物可以区分，未覆盖唯一原件；
  • [ ] 事实、推断、来源和待确认项已经分开，专业结论由人复核；
  • [ ] 版本、变更记录、已知限制、旧版本和回退负责人已经登记；
  • [ ] 分享或安装范围符合组织策略，使用者知道如何停用或报告问题；
  • [ ] 发布负责人、维护负责人和停用负责人已明确。

任何一项无法回答时，状态应保持“测试中”或“待人工确认”，不要把草稿当成正式 Skill。

相关内容 ​

来源引用 ​

内容版本与核对日期 ​

  • 内容版本：0.1.0
  • 最后核对日期：2026-09-26
  • 适用版本状态：Skill 创建入口、字段、分享和版本能力以当前 WorkBuddy 版本、租户策略和实际权限为准。
  • 来源提交版本：6b5e2403f0f2ad5d3f7ab7a67e9c4d4113583ff3

章节导航 ​