八月底电脑的存储问题又集中爆发了一次。一边是 C 盘空间紧张，希望尽量多释放空间；另一边是 E 盘状态不太好，担心真正重要的数据出问题。表面上都是“磁盘满了”，处理逻辑却完全不同：C 盘要判断什么可以删，E 盘首先要判断什么必须备份。

这次我给 AI 的限制一直很明确：先只读，扫描完整之后再决定。原因很简单，磁盘清理最危险的不是漏删几个缓存，而是把“看起来很大”误判成“可以删除”。尤其开发电脑里同时有 Git 工作区、Codex 历史目录、软件缓存、游戏资源、模型权重、构建产物和个人资料，单纯按体积排序几乎一定会犯错。

所以流程被拆成了几层。第一层只做容量和目录结构审计；第二层把内容分成可重建缓存、可迁移数据、需要进一步确认的数据和明确不能动的数据；第三层才生成执行清单；第四层需要人工批准后才真正删除或迁移；最后还要重新扫描，检查释放空间和失败项。

E 盘则更像一次备份优先级演练。Steam 游戏这类内容占空间很大，但重新下载就能恢复；真正应该优先抢救的是自己的文档、Vivado 工作区和其他不可再生工程资料。于是先把关键目录打包，再考虑后续修复和重建，而不是一上来就对疑似异常的盘做激进操作。

这几次操作之后，我把 C 盘治理总结成了一个独立 Skill。它强调“100% 安全删除”必须有证据，迁移也要保留可恢复路径；旧工作目录还要结合最后使用时间判断，而不是看到 Codex 或 worktree 就整批清掉。

存储治理其实和 Git 分支治理很像：目标不应该是界面看起来最干净，而是删除之后仍然能解释自己为什么敢删。AI 一旦拥有本机执行能力，这种证据链和审批边界反而比“能不能运行 rm”更重要。