最近把 WorkBuddy 里的「中国移动云盘 Skill」装上用了一段时间。作为一个平时也写点自动化脚本的人我对它更有兴趣的不是能干什么而是它凭什么敢让一个 AI 去动我的文件——授权怎么走、权限卡在哪、为什么是这个设计。一、为什么智能体需要 Skill 这一层大模型本身没有访问任何外部系统的能力它能做的只有生成文本。要让它操作云盘中间必须有能力接入层——把外部系统的 API 包装成模型可调用的工具tool / function calling模型负责决定调用哪个、传什么参数实际请求由这一层执行。Skill 就是这个接入层的打包形态一套工具定义 认证方式 能力边界装一次长期可用。所以装 Skill本质上是给智能体注册一批它可以调用的函数顺带把凭据管理也一并交给它。没装之前助手不认识你的云盘——不是它不想是它根本没有对应的工具可用。这个边界值得记住模型的能力上限由注册的工具集决定跟模型本身强不强关系不大。二、授权链路为什么是扫码安装完成后第一次使用需要扫码授权这个设计不是随手做的。桌面客户端有个天然难题没有浏览器回调地址标准 OAuth 的授权码流程需要 redirect_uri 接住 code在纯桌面环境下不好落地。所以这类场景通常会走设备授权流程的变体客户端向授权服务申请一个设备码把登录链接和码展示给用户用户用手机已登录态的设备完成身份确认客户端轮询授权服务拿凭据。客户端 → 授权服务: 申请设备码 用户 → 手机端 : 扫码 确认身份 客户端 → 授权服务: 轮询换取 access_token 客户端 → 云盘 API: 携带 token 调用这个模式的好处是安全的密码从不出现在客户端凭据是设备级、可单独吊销的。用户丢了设备撤销授权即可不用改密码。顺带说凭据的绑定锚点通常是手机号——云盘账号本身就是手机号跨端串联天然有主键。三、权限边界写操作逐次确认而不是权限位这是我觉得最值得看的一点。装完之后新建、删除、移动这类写操作都需要用户逐次确认AI 不能自己一路动到底。它新建的文件默认落在专属的AI空间 / 智能体云盘助手目录下方便和你原有的资料区分开——但可操作的并不限于这个目录。从工程角度看这是一套写操作二次确认 独立默认工作目录的组合而不是细粒度的权限位控制读/写/删分别授权。为什么这样选实现成本读写分离的权限位意味着每个 API 都要做权限校验链路而按关键分支写、删、移动拦截只需在工具调用层做一次判断——同样的安全收益复杂度低得多。用户理解成本给普通用户展示允许读取但不允许删除这种权限矩阵大多数人不知道怎么选改动之前它会问你一声一句话能说清。风险兜底AI 的失败模式通常是理解偏了而不是恶意。读操作放开、改动必确认即使判断出错也不会造成静默的破坏。代价也很明确——牺牲的是无人值守。批量整理、递归归档这类活它能做但每一步都要用户点一下头不适合挂在无人看管的流程里跑。这是设计取舍不是缺陷。四、写操作确认为什么不能全自动写操作逐次确认会牺牲无人值守的体验但这一步不能省。原因在于模型的意图识别不是确定性的。同一个指令在不同上下文里可能导致不同调用。把这份报告传上去——传哪个目录、覆盖不覆盖同名文件、是不是要连带附件这些都需要人确认。全自动的风险不是必然出错而是出错时你无法预知哪里错了。成熟一点的做法是把确认做在关键分支上写、删、移动读操作放开。这也是这套方案实际的选择查和看随便用改和删必须点头。五、开发者视角什么场景值得接如果你的工作里有这些需求把云盘作为数据源接进自动化流程是划算的非结构化资料的检索入口合同、扫描件、发票这类按文件名回忆不起来的东西用自然语言检索比写文件名匹配规则省事跨设备取文件省掉提前搬到本地这一步对经常换机器的人价值明显轻量归档让 AI 生成的内容直接落到云盘指定空间不用再手动搬一遍要注意的边界批量文件治理能做但每条写操作都要确认不适合放进无人值守的流程需要稳定吞吐的批处理任务不要挂在这条链路上工具调用多了延迟会累积涉及敏感数据的场景先确认数据流向与留存策略六、几个常见问题Q装了 Skill 等于把云盘账号密码交出去了吗不等于。走的是设备授权换取凭据密码不落地到客户端且凭据可以单独吊销。Q能不能让 AI 帮我删云盘里的重复文件能。删除属于写操作需要你确认后才执行批量清理同理只是确认次数会多一些。Q为什么有时候它理解得不准自然语言到工具调用的映射本身有歧义指令里把哪个目录、哪个文件、做什么动作说清楚成功率会明显提高。Q这套机制和 MCP 是什么关系思路一致——都是把外部能力标准化成模型可调用的工具集。Skill 可以理解为面向具体产品的封装形态。