安装Skill不是点一下按钮：先把任务说清，再查找候选、审查权限、用脱敏小样测试，最后才决定是否长期启用。

上一篇整理了电商人值得关注的10个Skill，很多人接下来最容易犯的错是：看到名字不错，点一下安装，然后把所有Skill长期打开。

结果往往是三种情况：该调用时没有调用、不该调用时反而介入，或者装了一个权限很大的第三方Skill，却根本不知道它读了哪些文件、向哪里发送了数据。

所以这一篇只解决一个问题：怎样把一个候选Skill，从“看起来有用”，安全地变成“可以进入真实工作的能力”。

完整流程不是“搜索—安装”两步，而是：

定义任务 → 查找候选 → 比较来源 → 安全审查 → 小样测试 → 结果验收 → 按需启用

一、先记住：不是所有Skill都值得安装

判断一个Skill值不值得进入工作台，先看四件事：

• 任务够不够高频：
  偶尔做一次的事情，没有必要长期占用能力位；
• 输入能不能稳定：
  文件、链接、字段和路径最好相对固定；
• 输出能不能验收：
  必须说得清最终要Excel、PPT、截图还是清单；
• 风险能不能控制：
  涉及账号、凭证、客户资料、批量修改或数据外发时，必须提高审查等级。

如果任务本身都说不清，先不要急着找Skill。AI找得再快，也只会把模糊需求放大。

二、第一步：把“想装个Skill”改成一张任务卡

以电商运营常见的“经营周报”为例，不要这样说：

帮我找一个做周报的Skill。

改成下面这张任务卡：

任务：每周合并6家店铺的经营报表并输出周报。 输入：6个XLSX文件，字段可能不完全一致；另有活动记录和异常说明。 关键动作：统一商品编码与日期口径，计算流量、转化率、客单价、退款率和毛利变化。 输出：一份保留公式的汇总Excel、一页经营结论、异常商品清单。 边界：缺失数据留空；不得推测补全；原始文件不覆盖。 验收：公式可追溯，数字与原表核对一致，所有结论有数据证据。

这一步看似多写了几行，实际会大幅减少后面的无效搜索。

三、第二步：用Find Skills查候选，不要直接安装

WorkBuddy支持从技能市场按需安装，也可以通过“查找技能”根据任务描述筛选候选Skill；如果没有合适的现成能力，还可以上传本地技能包或创建技能。

查找时不要只要求“推荐最好用的”，而要让它比较：

• 能否处理你的文件类型；
• 是否真的完成关键动作；
• 来源和更新时间；
• 需要什么权限；
• 是否调用第三方服务；
• 有没有可验证的使用示例。

可直接使用这段指令：

我需要完成下面这项任务，请先查找合适的Skill，不要直接安装。  【粘贴任务卡】  请输出候选清单，逐个说明： 1. Skill名称与来源； 2. 能解决哪些步骤，不能解决哪些步骤； 3. 所需权限和数据外发风险； 4. 最近更新时间与使用示例； 5. 推荐顺序与推荐理由。 如果没有一个Skill能完整覆盖，请给出组合方案。

四、第三步：先看来源，再看功能

候选结果出来后，先分三类：

不要被“下载量高”“功能很多”直接说服。对电商团队来说，权限过大可能接触销售数据、供应商报价、消费者信息、账号凭证和投放数据。

五、第四步：用Skill Scanner做安装前安检

WorkBuddy官方把Skill Scanner列为安装第三方Skill前的安全审查工具。它可以帮助检查可疑依赖、硬编码配置和潜在风险。

审查时，至少看六项：

• 来源：
  仓库、发布者和维护记录是否清楚；
• 依赖：
  是否会额外安装不明软件包；
• 脚本：
  是否包含删除、批量写入或系统配置动作；
• 文件：
  会读取、修改哪些目录；
• 网络：
  会访问哪些域名、把什么数据发出去；
• 凭证：
  是否需要账号、Token、Cookie或API Key。

请先审查这个候选Skill，不要安装、不要执行。  重点检查：来源可信度、依赖包、脚本行为、文件读写范围、 外部网络请求、凭证使用、数据外发和删除/覆盖风险。  请输出：风险等级、证据、需要人工确认的项目、 建议允许的最小权限，以及是否建议进入小样测试。

需要强调：扫描结果只是辅助判断，不是“绝对安全证明”。涉及高权限操作时，仍然要人工确认。

六、第五步：建立一张最小权限表

安装前，把Skill要做的动作和实际权限对齐：

权限原则只有一句话：完成任务需要多少，就先给多少。

七、第六步：不要拿真实全量数据做第一次测试

第一次测试建议准备一个“最小可验证样本”：

• 10—30行脱敏数据；
• 2—3个文件，而不是整个历史目录；
• 人为放入1个缺失值、1个重复值和1个异常值；
• 使用单独的测试输入和输出文件夹；
• 原始文件保留备份并设置为只读。

测试指令可以这样写：

这是脱敏测试数据。只允许读取“测试输入”文件夹， 只允许把结果写入“测试输出”文件夹，不得覆盖原文件。  先列出执行计划、将要读取的文件、将要创建或修改的文件， 等我确认后再执行。  执行后输出：处理日志、异常记录、结果文件和验收说明。

不要依赖某个固定入口。直接在任务要求中明确“先检查、先列计划、确认后再执行”即可。

八、第七步：用结果验收，不用“任务完成”四个字验收

经营周报类Skill至少要过八项：

• 输入文件是否读全；
• 原始文件是否保持不变；
• 字段映射和日期口径是否正确；
• 公式是否保留、能否追溯；
• 缺失值是否按规则处理；
• 异常数据是否单独列出；
• 输出路径和命名是否正确；
• 关闭Skill后，是否不再参与其他任务。

只有测试通过，才把它标记为“可用”；失败时记录失败原因，修正后重新测试，而不是带着问题直接进入真实业务。

九、什么时候安装，什么时候自建？

可以用这张判断表：

• 通用动作已有成熟能力：
  优先找现成Skill，例如PDF、XLSX、PPTX；
• 现成Skill覆盖80%，差异只是输入和输出：
  先组合现有Skill；
• 涉及团队独有口径、审批和验收规则：
  更适合创建自己的Skill；
• 低频、一次性、风险高：
  不要为了“自动化”强行安装。

真正成熟的Skill管理，不是装得多，而是每一个启用的Skill都有明确任务、明确权限、测试记录和停用机制。