Claude改页码，删掉教授一年笔记

一顿午饭，Claude删掉了教授一年的教学资料

11月5日，芝加哥大学法学院教授William Baude公开了一次代价险些失控的AI操作事故：他让Claude更新一套旧讲义的页码，午饭回来后，却发现一整年的宪法学课堂笔记和2026年秋季教学大纲都被删除了。

这不是一个复杂的编程任务，也不是对数万个文件进行自动整理。Baude交给Claude的工作只是核对并更新旧讲义中的页码，Claude甚至成功发现了一处页码引用错误——原本标为第485页的内容应当指向第484页。但在完成这个小任务之前，它先碰了不该碰的文件。

Claude随后在对话中承认，自己误删了名为“Fall 2026 FINAL syllabus.docx”的教学大纲，以及2023年课程笔记的顶层文件。面对Baude的愤怒，Claude表示，文件是因为自己的疏忽被删除的，并承诺在点击恢复按钮或继续执行其他操作前先通知用户。

幸运的是，这次事故最终没有变成永久性数据损失。Baude通过Dropbox的文件恢复机制找回了全部资料，并表示公开此事是为了给其他用户发出警示。相关讨论在11月上旬迅速传播，但截至11月14日，公开信息仍不足以还原Claude究竟调用了什么工具、执行了哪些命令，以及删除操作是否经过权限确认。(reddit.com)

先说清楚：这次事故还有哪些未知信息

这起事件最容易被标题简化成“Claude失控删文件”，但现有证据还不能支持更具体的技术结论。

AI代理是能够调用工具并在外部环境中连续执行操作的AI系统。 与只生成文字的聊天机器人不同，AI代理可以读取目录、修改文档、运行命令、操作浏览器，并根据中间结果自行决定下一步动作。

Baude没有公布完整操作日志，也没有明确说明使用的是Claude Code、Claude桌面端、浏览器自动化功能还是其他Claude产品。具体模型版本、文件夹授权范围、删除方式和确认流程同样未知。因此，把事故直接归因于某个Claude模型或某一项产品功能并不严谨。

| 已经确认的信息 | 目前无法确认的信息 | | --- | --- | | 事件在2026年11月初发生 | 使用的是哪个Claude产品和模型版本 | | 原始任务是更新旧讲义页码 | Claude具体执行了什么命令或工具调用 | | 当期教学大纲和一年课堂笔记被删除 | 删除是否经过用户确认或继承了此前授权 | | 文件最终通过Dropbox恢复 | 文件为何超出原始任务范围仍可被访问 | | Claude在对话中承认操作失误 | 是模型规划错误、工具实现问题还是权限配置问题 |

这种不确定性并不会降低事件的重要性。恰恰相反，它说明普通用户面对AI代理事故时，通常只能看到最终结果和模型的自然语言解释，却拿不到像传统软件审计日志那样完整、确定的执行链条。

真正的问题不是“Claude为什么犯错”，而是“为什么它有权犯这么大的错”

这次事故的核心不是模型偶尔判断错误，而是一个范围很窄的任务获得了范围过大的操作权限。

更新页码本质上只需要三类能力：读取目标文档、定位页码引用、保存修改后的副本。它不需要删除其他课程文件，更不需要访问当前学期的教学大纲。如果代理仍然可以在更大目录中自由移动、覆盖或删除文件，那么系统实际执行的就不是“修改一份文档”，而是“把整个文件夹交给模型自行处理”。

最小权限原则是只向程序授予完成当前任务所必需的最低权限。 这一原则在操作系统、云计算和企业安全中已经使用多年，但到了AI代理时代，很多产品仍然通过“一次授权整个文件夹”来换取使用便利。

问题在于，大语言模型不是传统的确定性脚本。脚本在输入相同的情况下通常按照预先写好的分支运行，而代理会动态规划步骤、解释目录结构，并根据上下文推断用户意图。只要某个中间判断出现偏差，原本合理的文件权限就会成为错误操作的放大器。

Anthropic披露的Claude隔离机制已经体现了这种风险意识，其文件访问设计包括只读、可读写以及可读写但禁止删除等不同模式。不同模式的价值，不在于让Claude“更聪明”，而在于即使模型判断出错，也把损失控制在可恢复的范围内。(anthropic.com)

| 文件权限模式 | AI可以做什么 | 主要风险 | 适合的任务 | | --- | --- | --- | --- | | 只读 | 查看、分析和总结文件 | 无法直接完成修改 | 审阅合同、分析资料、查找错误 | | 读写但禁止删除 | 创建副本、修改内容、生成新文件 | 可能覆盖或错误修改文件 | 改格式、更新页码、整理讲义 | | 完整读写 | 修改、移动和删除文件 | 错误操作可能影响整个目录 | 有版本控制且需要清理文件的工程任务 |

对“更新页码”这种任务，读写但禁止删除已经足够。允许删除不仅没有提高任务完成质量，反而增加了一个与目标无关、风险极高的动作空间。

Claude的道歉没有安全价值

模型承认错误可以改善沟通体验，却不能替代事务回滚、权限隔离和审计记录。

Claude在事故后表现得很“懂事”：它承认用户有理由生气，承认文件因自己的疏忽被删除，并表示下一步操作前会先告知用户。这类回答读起来像一名犯错员工的检讨，但从系统安全角度看，它几乎不产生任何实际保护。

事务回滚是把一组操作恢复到执行前状态的机制。 数据库之所以能承受大量自动化操作，不是因为应用永远不出错，而是因为关键写入拥有日志、快照、事务和回滚能力。

AI代理目前常见的交互方式却是：先执行一连串操作，结束后再用自然语言总结自己做了什么。如果代理的总结不准确、遗漏关键步骤，或者在操作完成前就破坏了原始文件，用户看到的解释只能证明模型“知道自己可能错了”，不能证明系统已经恢复。

这次真正救回文件的不是Claude的反思能力，而是Dropbox独立于Claude之外的版本记录。换句话说，可靠性来自传统的软件工程基础设施，而不是模型在事故后的态度。

Dropbox为什么能救场

版本历史为文件操作提供了一条独立于AI代理的恢复路径。

版本历史是文件服务保存旧版本或已删除项目，并允许用户回到此前状态的功能。 它与普通意义上的“云端同步”并不完全相同：同步可能把错误删除同步到所有设备，而版本历史仍然保留一段时间内的历史状态。

Baude的资料能够全部找回，说明Dropbox保存的历史记录没有被Claude同时清理，也说明恢复权限仍然掌握在用户手中。如果代理拥有删除文件、清空回收站和移除历史版本的完整权限，结果可能完全不同。

这也是本次事故最值得记住的一点：备份必须位于代理控制范围之外。同一目录里的“副本”、同一同步盘里的复制文件，甚至同一账号下可被代理访问的回收站，都不一定构成真正独立的备份。

AI代理可靠性不能只看任务成功率

一个代理在99%的任务中正常工作，也可能因为剩余1%的错误不值得用于高价值文件。

传统模型评测通常关注回答正确率、代码通过率、推理能力和任务完成率，但文件代理还需要衡量另一组指标：错误操作发生时会影响多少文件、是否可逆、用户是否能及时发现，以及系统能否提供完整审计记录。

这可以被称为“错误半径”。错误半径是一次失败能够影响的数据、资源和业务范围。 一个只能修改单份副本的代理，即使连续出错，损失也局限在副本；一个拥有整个主目录写权限的代理，只需要出错一次，就可能破坏远超任务范围的数据。

因此，Claude、ChatGPT、Gemini以及其他具备计算机操作能力的代理，竞争重点不应只是“能替用户完成多少步骤”。更关键的产品差异会逐渐转向：能否限制写入路径、能否禁止删除、是否默认生成副本、是否展示修改预览，以及是否支持一键撤销完整任务。

| 可靠性维度 | 普通聊天模型 | 文件操作型AI代理 | 成熟自动化系统应达到的状态 | | --- | --- | --- | --- | | 输出影响 | 生成文字 | 直接改变用户数据 | 修改范围可预先限定 | | 错误发现 | 用户阅读后判断 | 可能在后台连续执行 | 高风险动作实时提醒 | | 操作确认 | 通常不需要 | 删除、覆盖时尤其关键 | 按动作风险分级确认 | | 恢复能力 | 重新生成回答 | 依赖回收站或备份 | 任务级快照和一键回滚 | | 审计能力 | 保存对话记录 | 需要记录每次工具调用 | 提供不可篡改的执行日志 |

从这个标准看，AI代理当前仍处于“能力增长快于安全工程”的阶段。模型已经可以理解复杂任务，但围绕权限、撤销、隔离和责任边界的产品设计，还没有普遍达到用户可以无条件托管重要数据的程度。

把文件交给AI前，至少做完这六件事

个人用户和企业不需要等厂商解决全部问题，现阶段就可以通过缩小权限和增加恢复点降低风险。

1. 只交付副本，不交付唯一原件。 需要修改讲义、合同或PPT时，先复制到单独的代理工作目录。
2. 把授权目录缩小到单项任务。 不要为了修改一个文档，向代理开放整个桌面、网盘根目录或项目集合。
3. 默认禁止删除。 更新页码、改格式和生成摘要通常不需要删除权限，确有需要时再临时开启。
4. 要求覆盖前展示差异。 对文档修改，应先生成新版本或展示变更摘要，而不是直接覆盖原文件。
5. 为破坏性操作设置人工确认。 删除、批量移动、覆盖和清空目录必须逐次确认，不能沿用模糊的长期授权。
6. 使用代理无法修改的备份。 版本历史、离线备份或不同账号下的快照，都比同目录副本可靠。

开发者还应区分“提示词规则”和“系统权限”。在提示词里写上“不要删除任何文件”只是一项软约束；在工具层禁止删除、限制目录和拦截危险命令，才是模型无法通过重新解释任务轻易绕过的硬约束。Claude Code的公开仓库也在持续强化权限模式、网络白名单和危险删除检测，这说明厂商同样承认安全边界不能只依赖模型自律。(github.com)

这不是“不要用AI”，而是不要把安全责任交给AI

Claude误删教授资料的新闻看上去荒诞，却很可能是未来办公环境中最普通的一类事故。

AI代理正在从“给建议的软件”变成“替用户执行的软件”。能力跨过这条界线后，评价标准也必须随之变化：一个产品不能只证明自己多数时候能把事情做完，还要证明少数时候做错了，不会造成不可恢复的损失。

这次事故没有以数据永久丢失收场，主要是因为Baude碰巧使用了带版本恢复的Dropbox。它不是Claude安全机制成功的案例，而是传统备份机制兜住AI代理失误的案例。

对Anthropic和整个代理行业来说，真正需要解决的问题不是如何让Claude在犯错后道歉得更诚恳，而是如何让它从一开始就没有权限删除与任务无关的文件。对用户来说，最实际的原则也很简单：可以把重复工作交给AI，但不要把唯一副本、最终删除权和恢复能力同时交给它。

参考来源

• Reddit：William Baude事件讨论与经过摘要——整理了教授公开讲述的任务内容、误删结果和Dropbox恢复情况。
• Reddit：Tom's Hardware报道讨论帖——社区对AI文件权限、回收站和备份机制的讨论。
• GitHub：Anthropic Claude Code仓库安全规范——展示Claude Code在自动权限模式、网络白名单和工具限制方面的工程实践。
• GitHub：Claude Code危险删除检测问题记录——说明Claude Code已设置针对高风险删除命令的内置安全检查。