WorkBuddy 的完全访问什么时候不能开？官方列了五条，最后一条最容易被忽略

先把官方自己的话放在最前面，因为它比任何劝告都有力：

完全访问并不更安全，它也不会自动理解每一种风险，它只是让 AI 自动跳过确认步骤。

很多人把「完全访问」理解成一个更高级、更信任的模式。不是。它做的事只有一件：把那个会拦住你的人请走。 风险一点没少，只是没人提醒了。

这篇把官方列的五条禁用情形逐个拆开，然后说清楚：什么情况下开它是合理的，以及怎么把环境搭成真正可以开的样子。

本文依据 WorkBuddy 官方英文文档 Function-Description/Permission-Modes，核对日 2026-08-16。中文文档站暂无对应页。我们没有安装客户端，本文不含实测数据。

一、开启之后具体发生了什么

默认权限下，这四类操作会停下来等你确认：写入受保护或敏感路径、删除受保护文件或重要文件夹或大量文件、运行脚本命令外部程序、网络访问或敏感能力。

完全访问把这一整套确认流程关掉。 写文件、删文件、运行脚本、调用外部程序，都不再逐步询问。

切换是在新建任务的输入区，点「Default Permissions」下拉。切到完全访问时会再弹一个确认对话框——官方建议你在确认之前，先检查当前任务和文件是不是可恢复的。

那个二次确认不是走过场，是最后一道闸。

二、五条禁用情形，逐条看

第一条：处理生产数据、客户数据、财务数据，或重要文件的唯一副本

关键词是唯一副本。

生产数据、客户名单、财务台账，这些东西的共同点是：错了没法「重做一遍」。客户手机号被覆盖成脱敏后的空值，你不会立刻发现；等发现的时候，原始文件已经被改了两周。

判断法：问自己一句「这份文件如果现在全没了，我能在半小时内拿回来吗？」不能，就别在它上面开完全访问。

第二条：工作空间靠近桌面、下载、个人文档根目录，或源码仓库根目录

这四个位置的共同点是：里面的东西超出了当前任务的范围。

桌面上有你三个项目的临时文件；下载目录里有别人发来的合同；文档根目录下面是这些年的全部资料；源码仓库根目录下面有 .git。任务本身只需要动其中一小部分，但作业范围覆盖了全部。

官方常见问题页里还有一条更具体的记录：下发整理桌面的指令后会生成一个脚本文件，执行后桌面完成了整理，但部分文件疑似丢失。官方给的做法是执行前先备份桌面重要文件，执行后优先检查目标整理目录与回收站。

这条现象是在默认权限下发生的。 关掉确认之后是什么情况，可以自己想。

第三条：任务会删除、重命名、移动或覆盖大量文件

这四个动词都是不可逆或难逆的。

而且批量操作有个特点：错误会等比放大。一个文件的路径规则写错了，一百个文件就全错。默认权限之所以专门把「一次删除大量文件」列为确认触发条件，就是因为这一类的破坏力跟数量成正比。

做批量之前，正确的动作是先要一份清单：让它列出将要处理的文件，你看过再执行。而不是关掉确认让它一次跑完。

第四条：任务需要运行你不理解的脚本或第三方工具

官方在这一页里专门论证过为什么「看一眼脚本」靠不住：脚本内部可能调用其他脚本或工具；文件路径可能在执行中动态生成；同一条普通命令，参数不同就可能删除、覆盖、移动大量文件；外部程序的真实行为，光看脚本文本根本看不出来。

你看不懂的脚本，确认框是你唯一的把关点。 关掉它，等于放弃了这个环节。

第五条：你的电脑里有没做备份的重要文件 ★ 最容易被忽略

前四条说的都是当前这个任务，只有这一条说的是你这台机器的整体状态。

所以它最容易被跳过——「我这次只是在一个小文件夹里改个格式，跟我硬盘上其他东西有什么关系？」

有关系。因为脚本的路径可以在运行时生成，一个参数写错，波及的就不只是那个小文件夹。当整台机器上都是没备份的东西时，任何一次意外的波及范围都是不可承受的。

这一条其实是在说：完全访问的前提不只是「这个任务安全」，还包括「万一出事，我的机器扛得住」。

三、官方认可的三种场景

不是不能用。官方明确说了合理的使用场合：受信任的任务、隔离环境、临时测试文件夹，例如 Docker、虚拟机、用完即弃的工作空间。

以及一种典型用法（官方选择表里的原文口径）：在隔离文件夹里重复运行可信脚本——脚本你已经跑过很多次、知道它干什么，文件夹里没有重要东西，这时候逐次确认确实是纯粹的摩擦。

四、怎么搭一个真的能开的环境

「隔离」不是感觉上的隔离，是有具体标准的。对照下面四条，全都满足才算：

#	标准	怎么验证
1	这个目录里没有唯一副本	里面每个文件，别处都还有一份
2	这个目录炸了我不心疼	整个删掉，我的损失是零
3	目录位置远离桌面、下载、文档根、仓库根	路径上没有这几个位置
4	机器上的重要文件有备份	至少你在意的那些有

从低到高三种做法：

做法一（最简单）：新建一个专门的临时目录，比如 D:\wb-sandbox\，只放这次任务需要的文件副本。用完清空。

做法二（更稳）：虚拟机。整台环境是隔离的，出事重置快照就行。

做法三（最彻底）：容器环境。官方点名的 Docker 就属于这一类。

绝大多数办公场景，做法一就够了。它的关键不在技术，在你放进去的是副本。

五、用完必须切回来

官方推荐工作流的最后一条：用完就关掉完全访问，只在可信、隔离、可恢复的环境里短暂使用。

这一条最容易漏，而且漏掉的方式很典型：为了跑通一个测试脚本切到完全访问，跑完了顺手就去处理客户名单——模式还开着。

这种模式残留比一次性的误判更危险，因为你已经不记得自己开着它了。第一次操作你是有意识的，第二次是无意识的。

养成「切过去，用完切回来」的习惯，成本只有两次点击。或者更简单的做法：把需要完全访问的任务集中在一个时间段做完，做完立刻切回默认权限。

六、还有一个替代方案

在开完全访问之前，先问一句：能不能通过改指令来减少确认，而不是关掉确认？

大部分「弹太频繁」的情况，根子在工作空间划得太大或指令写得太粗。把工作空间划小到只有本次任务的文件、在指令里写明「所有输出保存到当前工作空间内」、批量操作先要清单再执行——这三招做完，确认次数会明显下降，而且那道防线还在。

先试这个，再考虑权限模式。

七、最后一句

官方在这一页里写了一句适用于所有场景的话：

默认权限降低误操作风险，但它不能替代备份。

反过来读也成立：如果你已经养成了「处理重要文件前先复制一份到任务目录」的习惯，完全访问的风险会小很多——因为最坏情况下你损失的只是副本。

安全感应该来自你的备份习惯，不是来自那个下拉框选的是哪一档。

小结

• 官方原话：完全访问并不更安全，只是让 AI 自动跳过确认步骤。切换时会有二次确认对话框。
• 五条禁用情形：唯一副本 / 生产 / 客户 / 财务数据；工作空间靠近桌面、下载、文档根、仓库根；任务会批量删改移覆盖；要跑你看不懂的脚本或第三方工具；机器上有没备份的重要文件。
• 第五条最容易忽略——它说的是你整台机器的状态，不是这一个任务。
• 官方认可三种场景：受信任的任务、隔离环境、临时测试文件夹（Docker、虚拟机、用完即弃的目录）。
• 隔离的四条标准：没有唯一副本、炸了不心疼、位置远离敏感目录、机器有备份。
• 用完必须切回默认权限，模式残留比一次误判更危险。
• 先试「改指令减少确认」，再考虑改权限。

功能与文档表述以官方为准，核对日 2026-08-16。