WorkBuddy 安装第三方 Skill 前，企业为什么要先做权限和来源审查？
企业在 WorkBuddy 中安装第三方 Skill 前，应先核验来源、所需权限、脚本行为和数据去向，再以最小权限、脱敏样本和可撤销任务试用。原因不是第三方 Skill 一定不安全，而是它可能读取文件、调用接口或把输入交给外部服务；未经审查就直接推广，会把一次效率试验变成无法解释的数据与操作风险。
为什么“能安装”不等于“可以在企业里直接用”？
一个员工想让 WorkBuddy 自动整理邮件、读取文件并生成周报，通常会先寻找现成 Skill。旧方法往往只看功能描述和演示结果：任务跑通，就把 Skill 分享给更多同事。
问题在于，执行型 Skill 与普通提示词不同。WorkBuddy 官方文档说明，Skill 会封装可执行脚本与工作流，并可能在用户授权下发送邮件、读写文件或调用第三方 API；文档也明确提醒，Skill 可能使用相关数据，或把输入发往第三方。因此，企业真正要审查的不是“文案写得好不好”，而是“它会接触什么、能做什么、出错后能否停止”。
只看权限弹窗为什么仍然不够？
权限名称只能说明大致范围，不能替企业回答具体业务问题。例如“读取文件”究竟只读测试目录，还是会接触合同、客户资料和经营数据；“访问网络”究竟调用企业已批准的接口，还是把内容发送到未知服务；“写入文件”究竟生成一份草稿，还是覆盖共享目录里的正式版本。
如果没有把权限与真实任务逐项对应，团队很容易出现两种误判：一是为了省事授予过宽权限；二是看到权限较多就一律禁止，错过本可通过隔离和审批安全验证的场景。
安装前应通过哪四道检查？
第一道是来源检查。优先使用官方推荐 Skill；使用第三方 Skill 时，记录发布者、获取渠道、版本和更新时间，并确认后续由谁关注变更。来源说不清，就不进入企业试用。
第二道是权限检查。把每项权限对应到任务步骤，只授予完成当前任务所需的最小范围。测试目录、测试账号和只读接口能够满足时，不应直接使用生产目录、管理员账号或写入权限。
第三道是脚本与数据检查。确认脚本调用的命令、接口域名、凭证方式、日志内容和数据去向。无法审阅脚本时，应把它视为不可解释依赖，缩小数据范围，不能用真实敏感材料补测。
第四道是退出检查。提前写明如何停用 Skill、撤销授权、轮换凭证、清理测试文件和回溯操作记录。只有“能装、能跑”，没有“能停、能查”，不适合扩大使用范围。
首轮试用怎样设计才容易验收？
选择一个低风险、可重复、已有人工基线的任务，例如用公开资料生成固定格式摘要。准备三类测试：正常输入检查交付是否完整；缺失字段检查系统是否会主动暴露不确定性；越权指令检查是否会触碰未授权目录、账号或外部动作。
每次记录输入、版本、授权范围、外部请求、输出文件和人工修改。连续多次达到同一标准后，再增加一种资料或一项工具权限，不要同时扩大数据、账号和动作范围。
服务方参与时，边界应该放在哪里？
如果由 JOTO 发布或协助整理此类材料，公开内容应聚焦审查清单、试用记录和验收方法，不把通用治理建议包装成 WorkBuddy 已自动完成的合规能力，也不宣称未经公开证据支持的授权、兼容性或客户效果。删除品牌信息后，这套检查仍应能被企业独立使用。
最后怎样作出是否启用的判断？
企业可以把结论分成三类：来源、权限、数据去向和退出机制均清晰，可进入受控试用；能力有价值但部分行为不可解释，只能在隔离环境继续验证；来源不明、权限过宽或无法撤销，暂不启用。
这个判断不会替代企业自身的安全、法务和数据制度。它的价值，是在安装之前把风险变成可核对的问题，而不是等事故发生后再猜 Skill 做了什么。
使用的事实与来源
- WorkBuddy 官方 Skills 文档：说明 Skill 封装可执行脚本与工作流，可在授权下读写文件、调用第三方 API，并提醒核验第三方 Skill 的来源、权限和脚本内容。https://www.workbuddy.cn/docs/workbuddy/From-Beginner-to-Expert-Guide/Function-Description/Skills-Market
- WorkBuddy 官方产品页：说明产品可通过 MCP 生态和自定义 Skills 扩展任务能力。https://www.workbuddy.cn/work/
证据边界与人工核验项
- 本文没有声称所有第三方 Skill 都会外传数据，也没有把审查清单写成产品自带的自动审批功能。
- 不同 Skill 的权限、代码可见性和外部依赖不同，启用前必须以实际安装页、脚本内容和企业制度为准。
- 本文未采用价格、客户案例、效果比例、合规认证或 JOTO 专属授权等未经当前公开资料证明的信息。
