TRAE Work制作C盘清理工具实战分享

前言

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”，而是一个全新的产品形态。

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

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

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

一个真实场景的对比

发现 10GB 的 node_modules：

传统工具：

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

CleanSight（AI 决策层）：

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

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

三大核心优势

三、为 TRAE 生态量身打造

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

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

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

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

TRAE 进程感知清理

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

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

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

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

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

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

 复制代码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 磁盘健康决策顾问”。

 复制代码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 分钟

 复制代码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 倍。

效果

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

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

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

测试环境

清理前后对比

C 盘最大占用源 TOP 3

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

 复制代码 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 的文件结构：

 复制代码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 的替代品，而是互补品。

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

两者结合，效果最佳。

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

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

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

你是一名 AI 行业编辑，请围绕下面这条热点输出一份资讯解读：
热点：TRAE Work制作C盘清理工具实战分享要求：
1. 先用一句话解释这条热点在讲什么
2. 再总结它为什么重要
3. 说明会影响哪些 AI 产品或内容方向
4. 最后给出 3 个适合资讯站使用的标题