先说清边界：这一页讲项目目录里怎么恢复。桌面、下载、文档这类个人目录的批量删除，不在「直接执行」范围内，那类操作要先扫描、先报告、先确认。
恢复的前提是「有东西可恢复」。所以真正该做的是把可恢复性变成日常事实，而不是出事时想办法。
三层可恢复性，成本递增
| 层 | 怎么做 | 恢复耗时 | 覆盖场景 |
|---|---|---|---|
| 版本控制 | git仓库 + 及时提交 | 秒级（git checkout / git restore） | 已提交的一切 |
| 快照 | 跑任务前tar一份目录 | 分钟级 | 未提交的改动 |
| 不做 | 靠记忆重建 | 不可估计 | —— |
实测一个最小的快照流程：
tar -czf /tmp/ws-$(date +%H%M%S).tgz -C . --exclude='./.git' . # 出事之后 tar -xzf /tmp/ws-113045.tgz -C .
被 git 删掉的文件怎么救
git status看是不是暂存区还没提交的删除：git restore <文件>直接回来。- 已提交的删除：
git checkout HEAD~1 -- <文件>从上一个提交取回。 - 连提交都找不到了：
git log --diff-filter=D --name-only找是哪次删的。
被 rm 掉且没有 git
- 先看回收站——不少工具删文件是进回收站而不是真删。
- 看有没有编辑器或系统留下的临时文件、备份文件（
*.bak、~$*、swap文件）。 - 都找不到就承认找不回来。这时候不要尝试「数据恢复软件」往同一块盘上写东西——会覆盖掉本来还能救的数据。
把这次教训固化成规则
- 凡是清理动作，先
find列出清单，再删。列清单和删之间不要合并在一条命令里。 - 批量删除一次不超过十份，删完核对一次。
- 让AI清理残留时，明确要求「先列清单等我确认」，不要给「清理干净」这种开放式指令。