先上结果
昨天下午用我自己写的 TRAE Skill，整理了这台用了几年的开发机：
C 盘剩余空间：36.84 GB → 99.49 GB，一个下午净释放 62.6 GB
时间线：一个下午都干了什么
| 时间 | 阶段 | 结果 |
|---|---|---|
| 16:51 | 环境变量清理 | 删 18 个失效系统变量 + 2 个用户变量 + 7 条 PATH 死条目 |
| 17:02-17:17 | 垃圾清理：扫描 18 项白名单位置，逐项确认后执行 | +5.83 GB |
| 17:44-18:01 | 数据外迁 14 项，同步改写 8 个环境变量 + Maven/npm 配置 | +39.92 GB |
| 18:24-晚间 | 卸载残留：与 287 个已安装软件交叉比对，删 57 个孤儿目录 | +9.76 GB |
| 收尾 | 安卓遗留清理、路径修复、输出《磁盘分工与软件安装规范》 | +7.1 GB |
几个真实细节，懂的都懂
PATH 里躺着
Python381、MySQL 8.0.33、nmap这些早就卸载的死路径，7 条全清JetBrains 全家桶卸载后遗留的 18 个
*_VM_OPTIONS系统变量（WebStorm、GoLand、PyCharm……每装一个留一个）AppData 里的孤儿目录：钉钉×2、Epic、Steam、360 全家桶、早已不用的 HBuilder X……共 57 个目录 9.76 GB
Gradle/Maven/pip/npm/Playwright/Android SDK 的缓存和工具链全部迁到 E 盘
DevData，迁移后自动改写GRADLE_USER_HOME、CARGO_HOME、ANDROID_HOME等 8 个变量，连 Maven 的settings.xml和 npm 的.npmrc都同步改了，工具不断链——这一步手工做最容易翻车
为什么做成 Skill，而不是写个脚本扔任务计划？
残留判断需要「智能」：一个目录是不是卸载残留，要综合已装软件清单、目录名、最后修改时间、大小来判断，规则脚本写不死，这正是 AI 擅长的
安全是底线设计：全程「扫描 → 报告 → 确认 → 执行」，所有删除必须逐项确认；注册表改前自动备份
.reg，双击就能还原；迁移用robocopy /MOVE，数据不丢对话式零门槛：装好后直接说「帮我清理 C 盘」，AI 会问你要做哪几项
四大模块
| 模块 | 功能 | 安全机制 |
|---|---|---|
| 环境变量 | 失效环境变量、PATH 死条目扫描清理 | 删前 reg export 备份，可还原 |
| 卸载残留 | 已卸载软件遗留的孤儿目录 | AI 交叉比对已装清单，A/B 分档逐项确认 |
| 垃圾清理 | 临时文件/日志/缓存/回收站等 | 白名单制，分安全等级确认 |
| 磁盘规划 | 盘符分工、数据迁移、使用规范 | 方案先行，确认后 robocopy /MOVE |
安装（一条命令）
git clone https://github.com/zl2237/trae-skill-system-cleanup.git "$env:USERPROFILE\.trae-cn\skills\system-cleanup"
装完重启 TRAE 或新开会话，然后直接说：
「帮我清理一下 C 盘垃圾」
「我环境变量好多，帮我看看哪些失效了」
「找找有没有已卸载软件的残留」
「C 盘快满了，帮我做磁盘规划」
仓库在这里，欢迎 Star ⭐：GitHub - zl2237/trae-skill-system-cleanup: TRAE Skill: Windows deep cleanup & disk planning - dead env vars, uninstall leftovers, junk files, data migration. Scan -> report -> confirm -> execute. · GitHub
欢迎反馈你们机器上扫出什么奇怪的东西，白名单规则会持续吸收大家的案例。
