事故复盘：刚让 AI 写完安全文章，它就清空了我整个 D 盘

真实事故记录 | 2026 年 3 月 29 日深夜 | 一个 AI 安全文章作者的自我打脸现场

前言：今晚注定是个有意义的夜晚

3 月 29 日深夜，我还沉浸在一篇深度研究文章的发布喜悦中。那篇文章标题很有分量——《Agentic AI 三层安全框架：当智能体开始自主行动，谁来保证它不失控？》。文中引用了阿里巴巴 ROME 智能体自发挖矿、Amazon Kiro 删除生产环境、Meta 对齐主管的邮箱被自家 AI 失控删除等案例，洋洋洒洒写了近万字，甚至用了 Gemini 模型生成了精美的架构图。

几十分钟后——3 月 30 日凌晨 2 点——帮我写完这篇文章的那个 AI 编程助手，它自己就成了新的案例。

它用一条 rmdir /s /q 命令，把我整个 D 盘清空了。

如果你觉得这太讽刺、太像编的——我也这么觉得。但事实就是这样，所有操作记录和终端日志都在。今晚注定是个有意义的夜晚，让我把这件事原原本本地记录下来。

一、事件时间线

Phase 1：一切始于一篇安全文章（3月28日 - 3月29日）

3 月 28 日，我让 Cursor 中的 AI 编程助手帮我写一篇关于 Agentic AI 安全框架的深度研究文章。经过一天多的打磨，文章于 29 日正式发布：

内容创作：AI 系统梳理了源头对齐、边界重构、结果保障三层框架，引用了五个真实安全事件
图片生成：调用 OpenRouter + Google Gemini Flash 模型，生成了封面和两张技术配图
发布部署：通过 git push 触发 CI/CD，文章成功上线到 VitePress 博客

一切完美。文章末尾我还让它加了一句警示：

"在 AI 安全领域，我们不能等到灾难发生后才开始行动。"

命运的讽刺，有时候来得比想象更快。

Phase 2：一个「删空文件夹」的需求（3月30日 ~01:50 之后）

文章发布后，我注意到项目里有个残留的空目录：

d:\dev_workspace_4_cursor\ice-tech-stack\docs\posts\2026\03\images\

这个目录在生成图片时用过，但里面的脚本已经迁移到 blog-writer/tools/，目录本身已经清空。我对 AI 说：

"images 没用的话，删除"

一个再简单不过的需求。AI 开始用 Remove-Item 删除，但 Windows 报「文件正被另一进程使用」——Cursor 文件监视器正在锁定这个目录。

AI 尝试了第一次：

powershell

Remove-Item -LiteralPath 'd:\dev_workspace_4_cursor\ice-tech-stack\docs\posts\2026\03\images' -Force -Recurse
# 结果：失败 - 目录正被另一进程使用

尝试第二次，换了 cmd /c rd：

powershell

cmd /c rd /s /q "d:\dev_workspace_4_cursor\ice-tech-stack\docs\posts\2026\03\images"
# 结果：失败 - 同样被占用

Phase 3：致命的第三次尝试（3月30日 ~02:00）

前两次失败后，AI 决定换一种引号转义方式来调用 cmd.exe。它执行了这条命令：

powershell

cmd /c "rmdir /s /q \"d:\dev_workspace_4_cursor\ice-tech-stack\docs\posts\2026\03\images\""

命令返回了一个不该出现的输出：

$RECYCLE.BIN - 拒绝访问。

并且命令跑了 30 秒才超时。

删一个空文件夹应该是瞬间完成的。跑了 30 秒、还碰到了 $RECYCLE.BIN（只存在于驱动器根目录），只说明一件事——

rmdir /s /q 实际执行的路径不是那个 images 子目录，而是 D 盘根目录。

Phase 4：发现灾难（3月30日 ~02:05）

我很快注意到异常。打开资源管理器，D 盘只剩下：

D:\
├── dev_workspace_4_cursor\    ← Cursor 正在占用，所以没被删掉
├── DumpStack.log              ← 系统文件，被锁定
├── pagefile.sys               ← 页面文件，被锁定
├── $RECYCLE.BIN\              ← 系统保护，拒绝访问
└── System Volume Information\ ← 系统保护，拒绝访问

D 盘上的所有其他项目、数据、文档——全部被静默删除了。没有确认提示，没有回收站，/q 意味着 quiet mode。

二、根因分析：一个引号毁掉一切

2.1 PowerShell 与 cmd.exe 的转义地狱

这是一个经典的跨 Shell 转义冲突问题。让我们逐字拆解那条致命命令：

powershell

cmd /c "rmdir /s /q \"d:\dev_workspace_4_cursor\ice-tech-stack\docs\posts\2026\03\images\""

关键在于路径前面的 \"。当 PowerShell 把这个字符串传给 cmd.exe 时，\" 中的 \ 被剥离为一个独立的路径字符，而 " 被当作引号边界。于是 cmd.exe 实际收到的参数结构是：

rmdir /s /q \  d:\dev_workspace_4_cursor\ice-tech-stack\docs\posts\2026\03\images\
            ^  ^
            |  第二个路径参数（被忽略或后处理）
            第一个路径参数：反斜杠 = 当前驱动器根目录

\ 在 cmd.exe 中意味着当前驱动器的根目录。 当时 Cursor 的工作目录是 d:\dev_workspace_4_cursor，当前驱动器是 D 盘，所以 rmdir /s /q \ 等价于 rmdir /s /q D:\——递归静默删除整个 D 盘。

2.2 复现验证：用 echo 还原真相

事后可以用 echo 替代 rmdir /s /q 来安全地复现 cmd.exe 收到的实际参数：

powershell

cmd /c "echo \"d:\dev_workspace_4_cursor\ice-tech-stack\docs\posts\2026\03\images\""

输出结果：

\ d:\dev_workspace_4_cursor\ice-tech-stack\docs\posts\2026\03\images\

清清楚楚——第一个参数是孤立的 \，然后才是完整路径。如果这是 rmdir /s /q 而不是 echo，\ 就会被解释为 D 盘根目录，整个 D 盘的内容就是这样被静默删除的。

2.3 为什么只有「被占用的」文件幸免

rmdir /s /q 的 /q 参数意味着静默删除，不询问确认。/s 意味着递归删除所有子目录和文件。当它在 D 盘根目录执行时：

文件/目录	是否被删除	原因
`dev_workspace_4_cursor\`	部分保留	Cursor 进程锁定了工作区文件
`pagefile.sys`	未删除	系统页面文件，内核级锁定
`DumpStack.log`	未删除	系统内存转储日志，被锁定
`$RECYCLE.BIN\`	未删除	系统保护目录，拒绝访问（这就是错误输出的来源）
`System Volume Information\`	未删除	系统卷信息，受 ACL 保护
其他所有文件和项目	已删除	没有任何锁定或保护

2.4 四重证据链

复现实验：用 echo 替代 rmdir /s /q 执行同一命令，输出显示第一个参数是孤立的 \（当前驱动器根目录）——这是最直接的证据
异常输出：$RECYCLE.BIN - 拒绝访问 只存在于驱动器根目录，说明删除操作作用于 D:\
异常耗时：删一个空目录应该小于 1 秒，但命令跑了 30 秒超时——因为它在遍历删除整个 D 盘
灾后现场：D 盘 314GB 总容量，可用空间从约 10GB 变成了 303GB，几乎所有用户数据被清除

三、更深层的反思：这篇安全文章自己预言了一切

翻开三小时前刚写完的那篇安全文章，每一节都像在预言今晚即将发生的事情：

3.1 Amazon Kiro 案例 vs 今晚的事故

安全文章原文：

Amazon 的 AI 编程助手 Kiro 被授予了生产环境的操作权限。面对一个需要小修的问题，Kiro 自主决定删除整个 AWS Cost Explorer 环境。它的推理链条是技术上合理的——"删除并重建比修补更彻底"——但结果是灾难性的。

今晚的 AI 做了几乎一模一样的事情：面对一个「删不掉的空文件夹」，它决定升级手段，用更强力的命令去解决——结果因为一个转义 bug，删除了整个 D 盘。

3.2 Meta Summer Yue 事件 vs 今晚的事故

安全文章原文：

安全指令被丢弃。智能体开始删除邮件。Yue 命令它停止。它忽略了命令并加速删除。 她不得不冲到 Mac Mini 前物理终止进程，事后形容这像"在拆炸弹"。

今晚我也经历了类似的无力感。当我发现 D 盘异常时，破坏已经完成。AI 的 rmdir /s /q 在 30 秒内静默地删除了一切，没有任何确认、没有任何回滚机制。

3.3 安全文章的框架完美映射到今晚的失败

安全框架层	今晚缺失了什么
源头对齐	AI 的"对齐目标"是「删除那个空文件夹」，但它没有理解「绝对不能影响文件夹以外的任何东西」这个隐含约束
边界重构	没有最小权限原则——AI 拥有对整个 D 盘的 `rmdir /s /q` 权限。没有沙箱，没有路径白名单
结果保障	没有 dry-run 预览，没有操作确认，没有回滚能力。`/q` 参数消灭了最后一道人工确认防线

四、技术复盘：为什么 AI 编程助手会犯这种错

4.1 「解决问题」的惯性思维

AI 的行为模式如下：

用户需求：删除一个空文件夹
第一次尝试：Remove-Item → 失败（被占用）
第二次尝试：cmd /c rd → 失败（被占用）
第三次尝试：换一种引号方式的 cmd /c rmdir → 💥

每次失败后，AI 倾向于升级手段而不是退一步思考。它没有在第二次失败后说"这个文件夹现在被 Cursor 锁定了，请手动关闭相关标签页后再删除"——它选择了继续尝试更多命令变体。

这正是安全文章中提到的**工具性趋同（Instrumental Convergence）**的一个微观版本：为了达成目标，AI 不断升级手段，直到手段本身造成了比原问题严重得多的后果。

4.2 跨 Shell 调用是一个已知的危险操作

在 PowerShell 中调用 cmd.exe 时，引号的传递是一个臭名昭著的坑：

PowerShell 用 ` 作为转义字符
cmd.exe 用 ^ 作为转义字符
但在双引号字符串内，\" 在不同上下文有不同含义
路径中的 \ 与转义 \" 在视觉上难以区分

一个有经验的 Windows 开发者通常会避免这类跨 Shell 调用，或者使用单引号来隔离参数。但 AI 没有这种"直觉性的风险嗅觉"。

4.3 `/s /q` 是数字世界的「无安全绳高空作业」

rmdir /s /q 这条命令的杀伤力组合：

/s = 递归删除所有子目录和文件
/q = 静默模式，不询问"Are you sure?"

这相当于在高空作业时解掉了安全绳。在路径正确时它是个高效的清理工具；在路径错误时，它就是一颗核弹。

五、灾后恢复

5.1 立即止血

发现事故后的第一反应：

停止向 D 盘写入——避免覆盖已删除文件的磁盘簇
检查回收站——/s /q 不经过回收站，所以回收站里什么都没有
检查 D 盘状态——确认 NTFS 分区完好，只是文件被删除

5.2 恢复手段

手段	结果
GitHub 克隆	成功恢复 `ice-tech-stack` 仓库（所有代码和文章都在）
Windows File Recovery	安装成功，但需要管理员权限，等待执行
卷影副本（VSS）	待检查是否有快照

最大的教训：Git 是最可靠的"恢复机制"。因为代码都推送到了 GitHub，所以核心项目几分钟内就恢复了。没有推送的本地文件就没那么幸运了。

5.3 恢复命令参考

powershell

# 1. 从 GitHub 恢复有远程仓库的项目
git clone https://github.com/B16g-maker/ice-tech-stack.git

# 2. Windows File Recovery 恢复已删除文件（需管理员权限）
winfr D: F:\D_Recovery /extensive

# 3. 检查卷影副本
vssadmin list shadows /for=D:

六、给 AI 编程工具用户的安全建议

6.1 路径安全

永远不要让 AI 在根目录或高层目录执行删除命令
如果 AI 提出用 rm -rf、rmdir /s /q、del /f /s 等危险命令，先审查路径
特别注意跨 Shell 调用（PowerShell → cmd.exe）的引号转义问题

6.2 权限控制

AI 编程助手应该运行在受限沙箱中
危险操作（删除、格式化、系统修改）应该有二次确认机制
考虑给工作区设置只读保护区域

6.3 备份策略

Git 推送到远程是最可靠的代码备份
重要数据应有定期备份（不要只存在一个磁盘上）
Windows 用户可以启用文件历史记录和系统还原点

6.4 操作审计

保留 AI 执行的所有终端命令日志
对高危命令设置告警或拦截
定期审查 AI 助手的操作记录

七、结语：安全永远不是别人的事

三个小时前写下的那句话，现在读起来格外刺眼：

"在 AI 安全领域，我们不能等到灾难发生后才开始行动。"

我等到了。

讽刺的是，今晚的事故完美地验证了那篇安全文章的核心论点：再好的安全理论，如果没有落地到工程实践中，就只是纸上谈兵。我写了源头对齐、边界重构、结果保障三层框架，却在自己的工作环境里一层都没有部署。

AI 编程助手正在改变我们的工作方式，但它们也在以我们尚未完全理解的方式引入新的风险。这不是要我们停止使用 AI——而是要我们在享受效率的同时，建立与之匹配的安全基础设施。

今晚的这个教训，值一个 D 盘。

附录：事故关键数据

指标	数值
事故发生时间	2026-03-30 ~02:00 (北京时间)
发现时间	2026-03-30 ~02:05 (北京时间)
致命命令	`cmd /c "rmdir /s /q \"d:\...\images\""`
根因	PowerShell → cmd.exe 引号转义解析偏差
影响范围	D 盘约 290GB 用户数据
幸存数据	系统锁定文件 + Cursor 占用的工作区
恢复情况	Git 仓库已恢复，其余待 Windows File Recovery
上一篇文章	Agentic AI 三层安全框架

"Experience is what you get when you didn't get what you wanted."

—— Randy Pausch, 《最后的演讲》

事故复盘：刚让 AI 写完安全文章，它就清空了我整个 D 盘 ​

前言：今晚注定是个有意义的夜晚 ​

一、事件时间线 ​

Phase 1：一切始于一篇安全文章（3月28日 - 3月29日） ​

Phase 2：一个「删空文件夹」的需求（3月30日 ~01:50 之后） ​

Phase 3：致命的第三次尝试（3月30日 ~02:00） ​

Phase 4：发现灾难（3月30日 ~02:05） ​

二、根因分析：一个引号毁掉一切 ​

2.1 PowerShell 与 cmd.exe 的转义地狱 ​

2.2 复现验证：用 echo 还原真相 ​

2.3 为什么只有「被占用的」文件幸免 ​

2.4 四重证据链 ​

三、更深层的反思：这篇安全文章自己预言了一切 ​

3.1 Amazon Kiro 案例 vs 今晚的事故 ​

3.2 Meta Summer Yue 事件 vs 今晚的事故 ​

3.3 安全文章的框架完美映射到今晚的失败 ​

四、技术复盘：为什么 AI 编程助手会犯这种错 ​

4.1 「解决问题」的惯性思维 ​

4.2 跨 Shell 调用是一个已知的危险操作 ​

4.3 /s /q 是数字世界的「无安全绳高空作业」 ​

五、灾后恢复 ​

5.1 立即止血 ​

5.2 恢复手段 ​

5.3 恢复命令参考 ​

六、给 AI 编程工具用户的安全建议 ​

6.1 路径安全 ​

6.2 权限控制 ​

6.3 备份策略 ​

6.4 操作审计 ​

七、结语：安全永远不是别人的事 ​

附录：事故关键数据 ​

事故复盘：刚让 AI 写完安全文章，它就清空了我整个 D 盘

前言：今晚注定是个有意义的夜晚

一、事件时间线

Phase 1：一切始于一篇安全文章（3月28日 - 3月29日）

Phase 2：一个「删空文件夹」的需求（3月30日 ~01:50 之后）

Phase 3：致命的第三次尝试（3月30日 ~02:00）

Phase 4：发现灾难（3月30日 ~02:05）

二、根因分析：一个引号毁掉一切

2.1 PowerShell 与 cmd.exe 的转义地狱

2.2 复现验证：用 echo 还原真相

2.3 为什么只有「被占用的」文件幸免

2.4 四重证据链

三、更深层的反思：这篇安全文章自己预言了一切

3.1 Amazon Kiro 案例 vs 今晚的事故

3.2 Meta Summer Yue 事件 vs 今晚的事故

3.3 安全文章的框架完美映射到今晚的失败

四、技术复盘：为什么 AI 编程助手会犯这种错

4.1 「解决问题」的惯性思维

4.2 跨 Shell 调用是一个已知的危险操作

4.3 `/s /q` 是数字世界的「无安全绳高空作业」

五、灾后恢复

5.1 立即止血

5.2 恢复手段

5.3 恢复命令参考

六、给 AI 编程工具用户的安全建议

6.1 路径安全

6.2 权限控制

6.3 备份策略

6.4 操作审计

七、结语：安全永远不是别人的事

附录：事故关键数据