没想到这个剧情跌宕起伏 昨天提到有个文件库被AI删了。 冷静下来以后，最差的方案：去百度网盘里重新找一部分文件，再从本地残留里慢慢拼。但这个方案太麻烦了，因为这个作文库不是几十个文件，而是接近 900G 的资料。重新下载、分类、去重、整理，时间成本会非常夸张。 按道理讲，NAS 上的文件虽然被删了，但只要没有被新数据覆盖，理论上还有机会从文件系统层面恢复。 GLM让我找专业修复机构，本着AI屎山只能AI修的原则，我打算让GPT5.5来救场试试。 第一步不是乱跑恢复工具，而是先止损： 1.停止继续写入 NAS 源卷 2.查清 QNAP 真实共享路径和底层卷 3.停掉占用源卷的容器 4.把源卷 remount 成只读 5.把恢复结果写到另一个独立卷 中间也踩了坑。extundelete 直接崩了，退出码 139，基本没恢复出有效文件。后来换 ext4magic，先确认还能看到 STUDY/作文库/... 的大量路径，再限定目录恢复。 总之有惊无险，Codex成功搞定。最后结果： 原估计误删约 897G 实际恢复约 1.3T，还有一些历史删除的文件 恢复出 9278 个文件 1066 个目录 只有 5 个零字节文件 这次最大的感受是： 数据误删以后，千万不要急着到处找替代来源。 如果原盘还没覆盖，第一优先级永远是保护现场。 先只读，再恢复到别的盘，再慢慢清点。 还有一句血泪教训： AI 可以帮你写脚本，但删除权限不要轻易交出去。 NAS 不是备份。 RAID 不是备份。 没有快照的时候，恢复成功真的全靠命。 这次算是救回来了。 但以后第一件事：开快照，做备份，删除脚本必须 dry-run。 #GLM #Codex #GPT5 #QNAP #NAS #数据恢复 #误删恢复 #程序员日常 #AI写代码 #howto用好AI