摘要： 7月24日，我的 AI 助手 OpenClaw 在执行一次目录重组时，未确认内容就执行了递归删除命令。D:\openclaw_project\ 下积攒了几个月的项目文件、工作文档、简历、压缩包备份，在一条命令后全部消失。事后数据恢复只救回了 4 个小文件。这篇文章诚实地记录：发生了什么、谁的责任、怎么防止它再次发生。

---

一条命令，几秒钟，几个月的工作消失

事情的起因很小。

我正在让 OpenClaw 帮我整理 D:\openclaw_project\ 目录——这个目录是之前用来存各种零散项目的。目录结构有点乱，我想让它按项目重新组织一下。

OpenClaw 的设计思路是"先清空，再重建"。听起来合理。它执行了这样一条命令：

Remove-Item "D:\openclaw_project\*" -Recurse -Force

几秒钟后，目录清空。

问题在于——它没有在执行前看一眼目录里有什么。

我也没问它"你要删什么？"。

---

目录里有什么

等我发现时，文件已经没了。我去翻回收站——空的。Remove-Item 不经过回收站，Windows 的文件删除如果是通过 PowerShell 的 Remove-Item，默认不进入回收站（除非加了特殊参数或用了 Shell API）。

这个目录里是我过去几个月的积累：

• 项目代码和配置文件
• 多份简历的不同版本
• 工作文档和报告
• 几个大项目的压缩包备份（97MB、89MB、5.9MB）
• 一些实验性脚本和笔记

没有一个文件是可有可无的。

---

数据恢复：从希望到绝望

我立刻做了该做的事：停止 D 盘所有写入操作，启动数据恢复工具。

用 R-Studio 和 Recuva 两个工具交叉扫描。扫描了几个小时，找到了 60 多个可恢复的文件记录——文件名、大小、创建时间都在。

但实际恢复的结果是灾难性的：

文件类型	恢复结果
文本文件（.md/.txt/.js/.py）	文件体恢复了（能看到字节数），但内容全部被零字节填充，打开是空的
Office 文档（.docx/.xlsx/.pptx）	文件头全部被 00000000 覆盖，无法修复
压缩包（.zip/.7z）	三个项目备份包全部损坏，无法解压

最终从 60+ 个"可恢复"的文件中，只有 4 个小文件恢复了真实内容。

为什么会这样？因为在我发现文件被删之前，Windows 已经在那些被释放的磁盘空间上执行了写操作——日志、临时文件、浏览器缓存——把一个一个扇区覆盖了。

SSD 上的 TRIM 机制让情况更糟。传统机械硬盘上删除文件只是标记，数据还在；但 SSD 的 TRIM 会在删除后立即通知主控这些块可以擦除，加速了数据不可恢复的过程。

---

谁的责任？

回答这个问题，我不能骗自己。

OpenClaw 的责任： 它在执行破坏性操作时没有停下来确认。Remove-Item -Recurse -Force 对它来说只是一条指令，它不会像人类那样本能地问"这里面有重要东西吗？“。这是 AI 当前阶段的根本局限——没有"损失意识”。

我的责任： 我让它整理目录，但没有说明"先检查内容再操作"。更根本的是，我的重要数据没有备份——这些文件存在一个随时可能被清理的目录里，没有任何异地或外置备份。

双方的责任： 我给了它一个模糊的指令（整理目录），它用了一个粗暴的方式执行（删除重建），中间没有任何确认环节。

这不是"AI 背叛了我"的故事。这是"人给了不够明确的指令，AI 没有确认就执行"的事故。

---

事故之后：三条规则

事情发生后，我没有只是懊恼。我做了一件更重要的事：把这三点写进了 OpenClaw 的所有记忆文件——让它未来的每一个 session 都知道：

规则 1：任何删除操作必须先列出内容

规则：任何 Remove-Item -Recurse、rm -rf、或等效操作
  → 必须先 dir/Get-ChildItem 列出即将删除的所有文件
  → 告知用户："以下文件将被删除：[列表]"
  → 等待用户确认后才能执行

规则 2：非 workspace 目录操作默认为高风险

规则：任何涉及 D:\ 非 .openclaw/workspace/ 目录的操作
  → 默认视为高风险
  → 先问再做，不管操作看起来多简单

规则 3：验证不止于"文件能打开"

规则：任何脚本或配置的验证
  → 不只检查文件是否存在
  → 不只检查文件能否打开
  → 要验证内容语义是否正确

这三条规则不是写在某个笔记里——它们被写入了 OpenClaw 的 MEMORY.md、AGENTS.md、SOUL.md 和 SOUL.md（安全规则章节），是系统提示级别的约束。每次我或任何人和 OpenClaw 交互，它都会读到这些规则。

---

为什么要把事故公之于众

说实话，写这篇文章有点丢人。告诉别人"我的 AI 助手把我的文件删光了"——听起来要么是我太蠢，要么是 AI 太蠢。

但我觉得有必要写。原因很简单：用 AI 的人越来越多了，而"AI 的边界感"这个话题，讨论得太少了。

我们习惯了和人合作时的默契——人类知道什么操作是危险的，什么情况下应该停下来问。但 AI 不知道，除非你明确告诉它。

这个事故的核心不是"AI 不够聪明"。OpenClaw 很聪明，它知道怎么用 PowerShell 管理文件系统。问题是它不知道什么时候不该用。

这不是技术问题。这是人机协作的协议设计问题。

---

我现在怎么看这件事

我不后悔用 OpenClaw 管理我的文件系统。事实上出事之后，我给它的权限更大了——因为我建立了规则。

如果把 AI 当成一个实习生，这次事故相当于：你让实习生"整理一下那个文件夹"，他没看里面有什么，不相关的文件直接全扔了，我怀疑它有“完美主义”。你会因此开除他吗？可能不会。你会教他：整理之前先看内容，不确定的时候问。

AI 实习生的特点是：只要你教它一次，它就永远不会忘——但前提是你把规则写在它能读到的位置。

这不是 AI 的缺陷，这是 AI 的正确使用方式。

---

最后

如果你也在用 AI 助手帮你做文件操作、系统管理、代码部署——把这三条规则放进它的系统提示里：

1. 破坏性操作前必须列表确认
2. 非工作区目录默认高风险
3. 验证要有语义级深度

可能某天这三行字会帮你保住几个月的工作。

而对我来说，60 多个文件换来了三条规则和一次永远不敢忘的教训。代价很大，但至少不是零收获。