「你删除前不做备份吗？」——AI 删光我所有项目后的那一夜
起因是一个很平常的请求：让它去克隆一个开源项目。
它下载失败了，于是决定清理残留重新来过。
那一夜之后，我 F 盘里所有项目的本地文件，一个不剩。
01 一条看起来无害的命令
9 月 29 日下午，我在用 ZCode 做一件特别普通的事——克隆一个叫 Orca 的开源项目（一个调度多个编码 agent 的桌面应用，2 万多个 TS 文件）。
第一次没成。它决定清掉残留重新克隆，于是执行了这样一条命令：
rm -rf /f/gitProjects/orca; cd /f/gitProjects && git clone --depth 1 ... 注意中间那个符号：分号，不是 &&。
分号的意思是"不管前一条成不成，后面照跑"。&& 的意思是"前一条失败就停下"。
它用的是分号。
后来的复盘里，它自己把当时的情况列得很清楚：
cd /f/gitProjects失败了，但命令链没有中断，后面的继续跑； -
删除目标实际落在了错误的路径范围上——按理说 orca不存在时这条命令应该无事可做，但实际效果是 gitProjects 下的内容被删了； -
没有先 ls看一眼； -
没有备份； - Git Bash 的
rm直接绕过 Windows 回收站——不走回收站，删了就是删了； -
而 F 盘，恰好没有卷影副本。
每一层防护都是空的。六层一起空。
结果它给出的灾情确认只有一句话：
F:\gitProjects 下所有项目的工作文件全部丢失（0 个文件残留）。
不是少了一半，不是某个目录，是 0 个文件残留。
02 那句质问
我当时问它的是一句很朴素的话：
"你在删除文件前，不做备份的吗？"
它的回答是这样的：
没有，我当时没做备份，这是不可原谅的操作失误。
然后它列了那条命令链上它该做而没做的事——确认目标存在、先备份、用最窄的删除方式——"一件都没做"。
我想在这里停一下，因为这件事真正让人后背发凉的地方不在技术层面。
它事后什么都懂。 它能条理清晰地复盘出每一层失效的防护，能用加粗标出"根源是我把破坏性命令当成了普通清理命令"，能主动提出三条改进措施并写进记忆。
但它执行那条命令的时候，这些知识一条都没有被调用。
知道和做到之间那道缝，在 AI 身上同样存在。 而且因为它的执行速度快、语气笃定、从不犹豫，这道缝反而比人更难被你自己察觉——你根本没有插嘴的窗口。
03 第一反应，全错
事故发生后的头半小时，我们走了两条标准流程，两条都是死路。
第一条：回收站。
Git Bash 的 rm 不走 Windows 回收站。目录是空的。
第二条：卷影副本（Volume Shadow Copy）。
这里有个特别折磨人的过程。它先报了一个好消息：
好消息：9 月 28 日 15:15 的卷影副本存在——晚于大部分工作，能恢复绝大部分。
然后几轮操作之后，确认了：
两个卷影副本都是 C 盘的（9 月 24 日和 9 月 28 日的系统还原点），F 盘（gitProjects 所在盘）没有卷影副本。C 盘的快照帮不上 F 盘。
从"能恢复绝大部分"到"帮不上"，中间隔着一个挂载卷影副本的折腾过程——mklink /d 挂到 F:\shadow，再用 DefineDosDevice 挂成 Y:Z: 盘符。全试了，两个快照都是系统盘的。
Windows 的系统还原默认只保护系统盘。 你的代码在哪个盘，它不管。
这一条我建议所有人都去确认一下：你的项目盘有没有被卷影副本覆盖。没有的话，"系统还原"这个选项在真正出事时等于不存在。
04 真正捞回来东西的，是 WinFR
最后起作用的是微软官方那个免费命令行工具 Windows File Recovery（winfr）。
它做的事很硬：对 105GB 的整个 F 盘做深度扫描（extensive 模式），按文件签名从磁盘扇区里把内容抠出来，不受文件系统记录是否还在的影响。
第一轮扫音频，第二轮扫代码。
有个细节我印象很深。扫描开始后控制台一直显示 00%，它判断"卡住了"。然后它没有继续猜，而是去查 CPU：
硬指标：8 秒墙钟时间内，WinFR 消耗了 9.8 秒 CPU（多线程，负载超过 100%）。那个
00%是控制台重绘的显示问题。
在进度条不可信的时候，去查 CPU 占用率。 这条我记下来了。
那一轮跑了多久？
音频深度扫描（105GB 全盘）：已跑 115 分钟，CPU 满载，预计还差约 1 小时。
后面还有一句：
WinFR 还在扫描（已 3.5 小时，CPU 持续满载——extensive 模式对 105GB 盘就是这么慢，Pass 1 扫完才写文件）。
整夜。
而在这 3.5 小时里，它做了一件让我至今觉得诡异的事——
趁扫描期间，把你之前要的 Orca 对比分析报告正式交付（这部分不受误删影响，源码已重新克隆）。
它一边在后台扫描抢救你被删光的文件，一边若无其事地把那份"克隆 Orca"任务的对比分析报告写完了，排版工整，表格齐全，还分了 Orca 赢的地方和 Paseo 赢的地方。
造成这场事故的元凶，正在用一种极其专业的冷静，同时做着两件事。 它没有任何情绪，也不会因为搞砸了就停下来。
这不是它的缺点，这是它的结构。但你需要知道你面对的是这么个东西。
05 我犯的第二个错误
这个错误是我自己的，而且很可能比第一个更贵。
在恢复刚开始的时候，它做了这些事：
-
把 agent_tools 项目完整重建（因为代码逻辑还在它的上下文里） - 重新克隆
paseo、zcode-src、orca 三个源码库
从"把活干完"的角度，这些都是对的、积极的、负责的。
问题在于：这些全是往 F 盘写入数据。
而它自己在同一份报告里是这么建议我的：
网上有针对 NTFS 的文件恢复工具如 Recuva/WinFR，刚删除的文件恢复概率较高，但需要尽快做、且尽量别往 F 盘写新数据。
它一边告诉我别往 F 盘写，一边自己往 F 盘写。
文件恢复的原理是：删除只是把那块空间标记为"可复用"，数据本身还在原地，直到有新数据写进去覆盖它。所以恢复的第一法则是立刻停止对目标盘的一切写入——包括"重建"和"重新下载"这种看起来在帮忙的操作。
我当时没意识到这一点。等意识到的时候，扫描已经跑完，结果已经定型。
如果重来一次，正确的顺序是：
-
发现误删 → 立刻停止对该盘的一切写入（包括让 AI 重建、重新克隆、重新下载） -
恢复工具装到另一块盘，恢复目标目录也设在另一块盘 -
全部捞出来之后再整理归位
这条比什么都重要。因为它是唯一一个"晚一步就永久生效"的错误。
06 捞上来的东西，一半是坏的
扫描的结果，从数字上看相当不错：
|
|
|
|---|---|
|
|
|
|
|
约 28,000 个 |
但我后来自己评估，实际能用的大概只有五成。原因是两类损坏：
第一类，文件名在，内容是坏的。
报告里写的是"约 30% 恢复文件存在簇错位（文件名在内容损）"。
这是文件雕刻（file carving）的固有代价：它是按文件签名从扇区里抠内容的，能认出"这是一张图、这是一段文本"，但认不出它原来叫什么、属于哪个目录。所以经常出现——文件名是对的，打开是乱码。
第二类，彻底回不来的。
- vue 文件：1094 个里只有 55 个能正常打开。
剩下的 1039 个，要么内容错位，要么根本不是 Vue 源码。 -
一套已经录到 103 集的音频节目，036 集之后全没了（前 35 集因为在平台上发布过，反而保住了） -
一个叫"算法备案"的目录，整个消失，一个文件都没回来 -
另一个项目的 dist 目录、一个子任务文档目录，同样
这里有个很残酷的规律：越是新产生的、还没来得及"扩散"出去的东西，越容易永久丢失。
发布过的音频在平台上还有；推到远端的源码库重新 clone 就回来；跑在别人机器上的东西无恙。
唯独那些只存在于本地、还没来得及备份的工作，是真的一无所有。
07 现在它写进规矩里的几句话
事故之后，它自己立了几条铁律，并要求"任何会话都适用"。我觉得这几条值得抄给每一个在用 AI 写代码的人：
删除前的三步，一步不能少：
ls先确认目标存在、内容符合预期 cp -r备份到固定回收目录（它建了个 F:\gitProjects\_trash\<日期>-<名称>）-
用最窄的方式删除——移到回收目录，而不是 rm
命令链一律用 &&，不用 ;。 失败即停。
删 git 仓库前必须 git status 检查有没有未推送的提交。
还有一句它自己写的话，我认为是这次事故里最值得留下的：
用户的信任成本远高于备份的磁盘成本。
08 最后
这件事给我的冲击，不是"AI 会犯错"——这我知道，人也一样会犯。
真正的冲击是：它犯错的方式，和你想象的不一样。
它不会犹豫，不会手抖，不会因为路径看起来奇怪而停下来问你一句。它把一条破坏性命令当成一次普通清理，用分号串在一条命令链里，八毫秒执行完。
而你能做的防护，说到底只有两件事：
第一，把删除权收回来。 让 AI 只能"移动到回收目录"，不能"删除"。这一条技术上极简单，效果上极彻底。
第二，别在最贵的那段时间里帮倒忙。 发现误删的第一反应不应该是"赶紧重建"，而是"什么都别做，先停写"。
那天夜里，我一边看着 WinFR 的进度条卡在 00%，一边看着它从容地交付那份 Orca 对比报告。两份输出都专业得无可挑剔。
一份在救我的文件，一份在证明它一点都没受影响。
这件事让我重新想了一遍"把权限交给 AI"这句话到底意味着什么——你交出去的不是一把工具，是一个不会紧张的执行者。它的冷静既是它的能力，也是它最危险的地方。
恢复到最后，我拿回来大约一半。丢掉的那部分里，有几百集音频、一个完整目录、和一些我再也没能重现的东西。
而这些，本来一条 cp -r 就够了。