我用 TRAE Work 做了一个 C盘清理工具

本文作者：阿呆，TRAE 核心用户

作者背景介绍：

个人身份： 全栈工程师，TRAE 深度用户

日常高频工作： 开发、调试、同时开多个 IDE 和开发工具

本次使用功能： TRAE Work 桌面端 + 移动端协同开发

项目地址： github.com/niuhai/skil...

前言

C 盘又红了？别急着删文件。

让 AI 帮你先诊断，再决策，最后安全执行。

过去我每次 C 盘爆满，都要经历一套重复流程：

打开清理工具 → 扫描 5 分钟 → 看到一堆"可以删除"的项 → 不敢乱点 → 手动百度每个项是什么 → 浪费 1 小时。

最痛苦的是 Docker、npm、WSL 这些开发工具的缓存，传统工具要么不敢删，要么删错了导致环境损坏。

这篇文章想聊的不是"怎么用清理工具"，而是记录一次具体经验：我是怎么用 TRAE Work 桌面端 + 移动端，在 49 天里把一个简单的 PowerShell 扫描脚本，逐步打磨成一个 AI 磁盘健康决策顾问（CleanSight）的。

看完本篇文章你可以了解到：

为什么"清理工具"不够用，需要的是"AI 决策层"
CleanSight 如何为 TRAE 生态量身打造
从 v1.0 到 v6.4 的 49 天进化历程
清理引擎性能优化的真实踩坑与解法
真实测试数据：C 盘从 91.7% 降至 74.4%

一、痛点：C 盘爆满之痛

作为开发者，我的 C 盘长期处于"高危"状态。

最典型的一次：开着 2-3 个 TRAE 实例，系统卡得要死。打开资源管理器一看，C 盘飘红，剩余空间不到 12 GB。但我不敢随便删，谁知道哪个缓存正在被 TRAE 用着？

传统清理工具给我的是这样的体验：

信息不对称：工具告诉我"可以删除 2.3GB 临时文件"，但不解释这 2.3GB 是什么、删了会不会影响我的工作。我不知道哪些是安全的、哪些有风险、哪些应该迁移而不是删除。
一刀切的扫描策略：不管我是 256GB 小硬盘紧急状态（只剩 8GB），还是 1TB 大硬盘日常维护（用了 60%），都是同样的全量扫描。小磁盘等不起 5 分钟，大磁盘不需要那么详细的信息。
开发者特有的痛点 ：Docker 镜像占了 45GB，但我不敢随便 docker system prune 因为怕删掉正在用的镜像；npm 缓存清了下次 npm install 又会重新下载，而且可能影响项目编译；WSL2 的。vhdx 文件只增不减，Windows 自带工具根本不识别。
每次都从零开始：上周刚问过"Docker 怎么清理"，今天又要重新问一遍。AI 不记得我的偏好、我的习惯、我关注什么。

核心矛盾在于：传统工具回答"能不能删"，但开发者真正需要回答的是"该不该删、为什么、有没有更好的方法、如何从根本上解决"。

二、核心定位：从"执行层"到"决策层"

这个矛盾决定了 CleanSight 的核心定位：它不是一个"更好的 CCleaner"，而是一个全新的产品形态。

Plain 复制代码

传统工具 = 执行层：帮你删文件（但不懂你）
CleanSight = 决策层：理解你 → 分析数据 → 智能建议 → 教你安全执行

差异化公式 ：迁移 > 删除 > 忽略

传统工具只会删，CleanSight 教你迁移保留功能的同时释放空间。这不是文字游戏，而是完全不同的产品设计逻辑。

一个真实场景的对比

发现 10GB 的 node_modules：

传统工具：

Plain 复制代码

显示: "node_modules - 10GB - 可删除"
用户: "删不删？不知道，万一以后要用呢？"
结果: 犹豫不决，或者误删

CleanSight（AI 决策层）：

Plain 复制代码

显示: "检测到 node_modules 10GB，位于项目 X"
分析: "该项目最后编译时间是 30 天前"
推理: "你最近主要在做 Python 项目，这个 Node.js 项目近期不太可能活跃"
建议: "可以安全删除。如果未来需要，npm install 即可恢复。
      另外，建议设置 .gitignore 忽略 node_modules，
      或使用 pnpm 的全局存储功能（附配置方法）"
结果: 用户放心删除 + 学到最佳实践

差别不在于"能不能删"，而在于 AI 给了上下文、推理过程、替代方案和知识赋能。

三大核心优势

能力	传统工具	CleanSight
上下文感知	固定规则，一刀切	基于你的使用习惯动态分析
动态风险评估	只说"能删/不能删"	告诉你为什么 + 替代方案 + 迁移指导
知识赋能	删完就结束	教你根本解决方法，一劳永逸

三、为 TRAE 生态量身打造

CleanSight 不是通用清理工具，它在设计之初就深度适配了 TRAE 生态。这是我最想分享的部分：一个 Skill 如何理解它所服务的平台。

原生识别 3 个 TRAE IDE 应用签名

在 extensions/app-signatures.json 中内置了完整的 TRAE 产品家族识别：

应用	检测路径	可清理缓存类型	典型大小
Trae	`%APPDATA%\Trae`	Cache， Code Cache， GPUCache， DawnWebGPUCache， WebStorage 等	3-5 GB
Trae CN	`%APPDATA%\Trae CN`	Cache， Code Cache， GPUCache， WebStorage， Session Storage 等	~10.3 GB
TRAE SOLO CN	`%APPDATA%\TRAE SOLO CN`	GPUCache 等	1-2 GB

实际测试发现：Trae / Trae CN / TRAE Work CN 三者的缓存合计可达～15 GB，是 C 盘最大的单项占用源之一。

TRAE 进程感知清理

清理脚本内置了 Test-AppRunning 函数，在执行前自动检测 TRAE 进程是否在运行：

Plain 复制代码

检测到 Trae/TraeCN 正在运行（进程 ID: 12345）
⚠️ 建议关闭 TRAE 后再清理，以获得更好的效果（释放更多缓存）
是否继续？[Y/N]

如果未关闭 TRAE，脚本会智能跳过被锁定缓存，只清理可安全释放的部分，绝不会因为清理导致 TRAE 崩溃或数据丢失。

这个细节看起来简单，但它是用一次"翻车"换来的：早期版本清理时没有检测进程，直接清了正在运行的 TRAE 的 GPUCache，导致界面闪烁了几秒。虽然没崩，但用户体验不好。加了进程检测后，这个问题再没出现过。

附带 TRAE IDE 性能优化测试方案

项目中专门提供了 TRAE-Optimization-Test-Plan.md，一套完整的 TRAE 开发环境性能调优方案：

Plain 复制代码

Phase 1 - 基准测试: 记录C盘空间、内存、TRAE启动时间、SearchHost CPU
Phase 2 - 优化实施:
 ├─ Part 1: 虚拟内存配置（C盘释放 + 性能提升）
 ├─ Part 2: Search索引排除开发目录
 ├─ Part 3: TRAE设置优化
 └─ Part 6: TRAE智能缓存清理（安全清理 Cache/Code Cache/GPUCache 等）
Phase 3 - 效果验证: 量化对比优化前后的TRAE性能指标

这不是一个"清理脚本"，而是一套面向 TRAE 开发者的系统调优方案。

四、AI 决策层的产品哲学

在做 CleanSight 的过程中，我逐渐想清楚了一件事：涉及系统文件操作的工具，安全性是底线，但安全不等于保守。

五大设计原则

只读优先（Read-First）：信任是逐步建立的，让用户先看到 AI 的分析质量，再决定是否执行。所有扫描脚本都是只读的，不自动删除任何文件。
教育赋能（Empowerment Over Automation）：不是"我帮你删了"，而是"我分析了，建议这样做，理由是...". AI 的价值不只是告诉你"怎么做"，更是解释"为什么"。
个性化适配（Personalization）：识别用户类型（开发者/设计师/普通用户），拒绝一刀切。开发者看到的是 npm / Docker 缓存分析，普通用户看到的是浏览器和社交应用缓存。
透明可解释（Explainable AI）：每个建议都有明确理由，这是建立信任的关键。不只是说"可以删"，而是说"为什么可以删、删了有什么影响、有没有更好的方案"。
渐进式信任（Progressive Trust Building） ：尊重用户的掌控权，始终保留人工确认环节。清理脚本支持 -WhatIf 预览模式，危险操作需要 -ReallyDelete 明确确认。

安全红线

有些操作永远不自动执行：

删除系统还原点 / 关闭休眠 / 移动页面文件
清理 WinSxS /ResetBase
删除 Program Files / 用户文档/桌面/下载
触碰企业安全软件（EDR/NAC/杀毒）
vssadmin / diskpart 操作

这些红线不是"建议"，是代码层面的硬性约束。

五、开发历程：49 天 7 个大版本

整个项目从构思、编码、调试到发布，全程使用 TRAE Work 桌面端 + 移动端协同开发。桌面端写核心脚本和 PowerShell 引擎，移动端蹲坑时写文档、调交互逻辑，真正做到了"随时随地用 AI 开发 AI"。

v1.0 --- 最初只是一个脚本（2026-04-01）

一个简单的 PowerShell 扫描脚本，输出文本报告，覆盖 3 个基础类别：临时文件、浏览器缓存、少数开发缓存。

当时想法很天真："能扫出来就行了，用户自己会判断"。

教训：只告诉用户"有什么"是远远不够的，更要告诉他"该怎么办"。

v4.0 --- 从单文件到专业架构（2026-05-12）

一次彻底的重构：897 行的单文件 SKILL.md 变成了完整的文件组架构，14 个扫描脚本 + 3 个清理脚本 + 3 个迁移脚本 + 完整安全机制。

新增 5 个扫描类别，覆盖安全软件、多版本残留、Electron 重复运行时、输入法、即时通讯。同时增加了快照备份、注册表备份、回滚指南等安全机制。

教训：涉及系统文件操作，安全性是底线。宁可功能少，不能出事。

v6.0 --- AI 决策层（2026-05-13）

这是最大的转折点。CleanSight 从一个"清理工具集"正式升级为"AI 磁盘健康决策顾问"。

Plain 复制代码

v5.0 之前: "帮你扫描C盘" → 执行层
v6.0 之后: "理解你 → 分析数据 → 智能建议 → 教你安全执行" → 决策层

新增能力包括：用户画像自动识别（开发者/普通用户/DevOps）、智能决策算法（多维加权评分）、风险动态评估（基于使用场景而非固定规则）、9 大模块 AI 决策报告系统。

v6.1 --- 生产级重构：品牌升级为 CleanSight（2026-05-16）

正式品牌命名：CleanSight （AI Disk Health Advisor）。健康评分算法落地，5 种扫描模式（极速/快速/标准/自定义/智能），3 阶段交互流程（预检 → 推荐 → 执行），创建完整测试评测体系。

v6.3 --- 清理引擎深度优化（2026-05-18）

两个紧急版本解决性能 bug，这是整个开发过程中最"惊心动魄"的部分。

六、难题与解法：清理引擎性能优化

v6.1 发布后，有些朋友反馈了一个致命问题：清理大目录时脚本会卡死。

问题：飞书目录清理卡死 30 分钟

Plain 复制代码

Bug: 删除 4.81 GB 飞书目录时，脚本卡死 30 分钟无响应
后果: 飞书卡死后，Trae CN（10.3 GB）等更大的项根本没机会清理
原因: Remove-Item "$Path\*" -Recurse -Force 在大目录下比 cmd /c rmdir 慢 10-100 倍

这个问题让我意识到：PowerShell 的 Remove-Item -Recurse 在处理大量小文件时性能极差，因为它需要先枚举所有文件再逐个删除。

解法：三层删除策略

第一层 ：System.Diagnostics.Process.Start() + WaitForExit(120s) 调用 cmd /c rmdir /s /q，带 120 秒超时控制。如果超时，自动 kill 进程进入回退方案。
第二层 ：robocopy $emptyDir $Path /MIR 清空内容，再用 rmdir 删除空目录。robocopy 是 Windows 原生复制引擎，跳过被锁文件，速度比。NET Delete 快数倍。
第三层 ：.NET [System.IO.Directory]::Delete() 作为最后手段保留。

同时，清理前扫描也从 Get-ChildItem -Recurse 替换为 Get-FolderSizeFast（基于 robocopy /L /S /BYTES），快 10-100 倍。

效果

操作	修复前	修复后	提升
删除 4.81 GB 飞书目录	卡死 30 分钟	～30 秒	60x+
删除 10.3 GB Trae CN	没机会跑	～60 秒	∞
清理 3 项共 15.8 GB	飞书卡死后全崩	～3 分钟	∞

教训：不要假设 PowerShell 的内置 cmdlet 总是最优的。在处理大量文件时，Windows 原生工具（robocopy、rmdir）往往比。NET API 快一个数量级。

七、效果展示：真实测试数据

以下数据基于 2026-05-16 对 148.91 GB NVMe SSD 的真实标准模式全量扫描。

测试环境

项目	配置
操作系统	Windows 11 Pro 23H2
C 盘容量	148.91 GB NVMe SSD
初始使用率	91.7% （136.54 GB 已用）
用户类型	全栈开发者
安装的 dev tools	Node.js， Python， Docker， VS Code， TRAE 全家桶

清理前后对比

指标	清理前（5/16）	清理后（5/18）	变化
健康评分	17/100	50/100	+33
使用率	91.7%	74.4%	↓ 17.3%
剩余空间	12.37 GB	38.17 GB	+25.8 GB

C 盘最大占用源 TOP 3

在 148.91 GB 的真实 C 盘扫描中：

Plain 复制代码

🥇 Trae / Trae CN / TRAE Work CN 缓存合计: ~15 GB（C盘最大单项）
🥈 Electron 重复运行时（含 TRAE 依赖的 Chromium）: 13.02 GB
🥉 微信 + 飞书: 9.62 GB

清理后：C 盘使用率从 91.7% 降至 74.4%，释放 25.8 GB，TRAE 运行更流畅更稳定。

优化前，开 2-3 个 TRAE 就卡得要死；优化后，开五个都可以。

数据一致性验证

四次扫描结果完全一致（偏差 <0.5%），第四次因实际清理后数据变化合理：

第一次（14:05，清理前）：17/100，91.6%，28.3 GB 可释放
第二次（15:09，清理前）：17/100，91.6%，28.3 GB 可释放
第三次（16:08，清理前）：17/100，91.7%，28.39 GB 可释放
第四次（5/18，清理后）：50/100，74.4%，清理释放 25.8 GB

这说明扫描结果是稳定可靠的，不是随机数。

八、项目架构速览

整个 Skill 的文件结构：

Plain 复制代码

c-drive-cleaner/
├── SKILL.md                    ← 核心文档（完整使用指南）
├── analyze.ps1                 ← 一键入口
├── _common.ps1                 ← 公共模块（高性能函数库）
│
├── scanners/   (12个只读扫描)
├── cleaners/   (3个清理: safe/deep/dev-caches)
├── migrators/  (3个迁移: appdata/dev-caches/wsl-docker)
├── extensions/
│   ├── app-signatures.json     ← 100+ 应用签名（含TRAE全家桶）
│   └── strategy-config.json    ← 5种扫描模式配置
├── safety/     (备份+快照+回滚)
├── memory/     (v6.2 个性化系统)
├── examples/   (案例库：4正面 + 2反面)
├── tests/      (测试评测体系)
└── scheduled/  (定期自动化)

扩展性 ：新软件签名只需一行 JSON，无需修改代码。编辑 extensions/user-custom.json 保存即生效。

写在最后

这次实践让我感受最深的是：AI 编程真正有价值的地方，不只是帮我多写了几百行代码，而是帮助我把一个模糊的痛点，逐步变成了一个有清晰定位、有安全底线、有真实效果的产品。

从 v1.0 的一个简单脚本，到 v6.4 的 AI 磁盘健康决策顾问，49 天 7 个大版本的进化，每一步都是在解决真实问题：

v1.0 解决"能不能扫出来"
v4.0 解决"覆盖够不够全"
v6.0 解决"该不该删、为什么"
v6.3 解决"能不能又快又安全地执行"

CleanSight 不是 CCleaner 的替代品，而是互补品。

Plain 复制代码

AI（本 Skill）= 建筑师（设计蓝图、规划方案）
BleachBit/WizTree = 施工队（按蓝图执行）

两者结合，效果最佳。

人的工作没有消失，只是换了位置。以前人站在每个细节里，一点点手工判断该不该删。

现在更像站在流程上面：先讲清楚要什么，看 AI 的分析对不对，最后判断能不能执行。

对我来说，这才是用 TRAE 做 Skill 最值得沉淀的地方：它不是让人少思考，而是让人把思考放在更前面，也放在更关键的位置。