我的 D 盘是个什么都有的大杂烩：JDK、Node、Python、各种依赖缓存、Docker、WSL、VMware 的虚拟磁盘、项目代码、下载的安装包、个人数据……全堆一块儿。

想清理，但动哪都怕炸：

• 把装好的软件目录挪一下？快捷方式、注册表、卸载入口、文件关联，全指着原路径。
• 把「看起来没用」的大文件删了？那可能是 WSL 的 VHDX、Docker 的 Volume，删了直接回到解放前。
• 「先把根目录变好看」？这是最危险的动机——为了好看，弄坏能用。

后来学乖了：清理这事，难点从来不在「删文件」，在「删完之后东西还能用」。而「能用」得靠你自己真点开软件来验，不是靠 AI 说一句「进程能启动」。

clean + template，一个管操作一个管档案

clean 是一份 Skill，管「怎么安全地动手」。主线 8 步：

复制

定义目标 → 只读盘点 → 风险分级 → 备份+清单 → 分阶段执行 → 真实入口验证 → 管理员验收 → 写回档案

几个关键点：

只读盘点先行。Get-DriveInventory.ps1 先扫一遍输出 JSON：磁盘、顶层目录、快捷方式目标、PATH、环境变量（值自动脱敏，只留名字和「是否存在」）、已装应用、VHDX。没摸清之前，一个字节都不许动。

分阶段、按风险执行：

• Stage A（低风险）：建目录、挪松散的安装包和报告，先查重不删。
• Stage B（可配置缓存）：npm / pnpm / pip / uv / Maven / Gradle 缓存迁移，全走工具自带配置项，不用文件系统硬搬。
• Stage C（已装应用）：优先应用原生迁移 → 重装保数据 → 便携版 → 兼容 junction → 最后才手动修注册表。
• Stage D（虚拟化/数据库）：只走产品原生 export/import 或迁移，永远不把大 VHDX 当普通文件。

验收用「真实入口」。规则写死了：进程能启动 ≠ 通过。得验快捷方式能不能点开、文件关联 / Open With 对不对、卸载和更新入口指的路还活不活、项目能不能正常 build、虚拟磁盘长度对不对。自验（客观证据）和管理员/用户验收（真点开用）是两回事，后者才作数。

template 是配套的档案模板，管「这台机器记什么」：00–07 目录，从现状、软件路径、开发环境、虚拟化，到维护日志、备份恢复，一条龙。它和 clean 分开分发、搭配用——clean 干完活，产物落进 template 的档案；template 的 AGENTS.md 反过来要求先读 clean/SKILL.md。

一句话

clean 管「怎么安全地动」，template 管「动了之后怎么记得住」。核心还是同一套老规矩：先证据、分阶段、用真实入口验收、动刀前单独确认。

仓库和参与

GitHub - 1263-ux/real-ai-engineering: Real problems become reusable AI engineering assets: skills, adapters, cases · GitHub

和 dev-loop 同一个仓库。目前 clean 只在 Codex 上真实验证过（Windows + PowerShell），没验证的我不吹。你要是在别的工具上跑得通，或者又发现了新坑，Issue / PR 都欢迎，尤其是边界反馈。