ARTICLE · 1297763
AI Agent 实践案例:一句话清理 C 盘,从 12.8 GB 回到 44 GB 并沉淀为技能
2026 年 10 月 30 日，周五。锅头打开“此电脑”，C 盘那根容量条已经快填满了：199 GB 的盘用了 187 GB，只剩 12.7 GB。又顺手把截图发给 WorkBuddy，只提了一个要求：先看看这些空间都被什么占用了。接下来三个多小时，AI 做了三轮只读审计、四轮分级清理，可用空间从 12.84 GB 回到 44.21 GB，占用率从 93.6% 降到 77.9%。中间遇到五个问题，其中一个——删了 15 GB、可用空间却没有变化——前后排查了将近四十分钟。收尾时让 AI 把整套流程写成技能，下次清理 C 盘，一句话就够了。
锅头这台是华为笔记本，一块 199 GB 的 C 盘、一块 322 GB 的 D 盘、一块 410 GB 的 E 盘。日常写稿、剪视频、跑各种 AI 工具，浏览器常年开着几十个标签页，C 盘就这样一点点涨到 187 GB。E 盘还很空，但很多软件默认往 C 盘的用户目录里写东西，时间一长就把它撑满了。
下面这张是当时的状态截图，C 盘和 D 盘的容量条都已经接近满格：
清理前的磁盘状态：C 盘 12.7 GB 可用 / 共 199 GB
只看数字，感觉只是“剩得不多”；实际用起来，问题就很具体了：系统更新装不上，剪视频时缓存写不进去，偶尔弹出磁盘空间不足的提示。
清理 C 盘这件事，大部分人都做过。常见的做法有两种：一种是打开文件夹，看见不熟悉的就删；另一种是装一个清理软件，点一下一键优化。这两条路都会遇到同样的三个难题。
第三个问题最容易被忽略，也最消耗耐心。这次就在它上面停了很久，3.4 和 4.4 两节会完整复盘。
能删的和该删的，中间隔着的不是技术，是那一次确认：
动手之前，先把目标写清楚了，一共四条，每条都能用数字衡量：
整套方法可以概括成五步：先看清、再定位、然后分级清理、接着复核结果、最后沉淀成技能。思路本身不复杂，真正花心思的是第二步。清理 C 盘最常见的做法是打开就删，而更省时间的做法，是先认识那几类“看起来不像垃圾、其实一直在增长”的东西。把这几个位置认全了，后面基本就是执行。
C 盘治理五步法：先看清、再定位、分级清理、复核结果、沉淀技能
这五步里有一句话，是整场实践最先想通的，也是后面所有反常现象的答案：
想通这一点，后面很多看起来互相矛盾的现象，就都能解释得通了。
这次没有安装任何第三方清理软件，用到的都是 Windows 自带的能力，再由 AI 负责编排：磁盘接口读取真实剩余空间、目录遍历统计体积、清空回收站、系统组件清理、电源方案查询。用系统原生工具的好处很直接：不会因为装一个清理软件反而多占几个 G，也不会有不透明的操作动到不该动的地方。具体分工如下。
工具清单：六项能力都来自 Windows 系统自带，未安装第三方清理软件
表格里每一行背后都对应一个具体问题。比如“限制递归层数会把上百 G 算成几个 G”这一条，就是第一轮扫描时暴露出来的：脚本只统计了目录第一层的文件，把 106 GB 的用户目录算成了 3 GB。
从机器的视角看，AI 收到“清理 C 盘”这句话之后，内部实际走的是八步：接收意图、读取基线、全盘遍历、比对清单、生成方案、执行删除，最后复核差额并输出报告。
Agent 内部八步工作流：从接收意图，到差额归因输出报告
其中第四步“比对四类隐形黑洞清单”是整个流程的核心。这份清单是这次实践换来的：临时文件、系统组件存储、回收站、休眠文件。少看任何一类，最后都可能出现“删了却没释放”的情况。
交付之前，定了五条验收线，缺一条都不算完成。这五条同时也是第 4 章检验时的依据：空间有没有真正回收、数据有没有丢、系统是否正常、结果能不能解释清楚、下次能不能复用。
五条验收线：空间、数据、系统、可解释、可复用
“结果可解释”这一条看着不像技术指标，其实是给自己定的规矩：释放了多少、到手多少、差额去了哪里，都要能一句一句讲清楚，不用“大概释放了”含糊过去。
给 AI 划的边界一共五条，每一条都是不许越的线：
整场下来，实际只动手七次，其余时间都是 AI 在跑。节奏大致是这样：
人的视角：七次动作串起整个过程
下面按其中几个关键节点展开，都是当时真实遇到的情况。
第一件事是把截图发过去，写了一句需求：“C 盘空间满了，请分析磁盘空间占用情况，并给出清理建议”。这里只说分析和建议，没有直接要求删除。
AI 先做了一遍只读扫描，没有删除任何东西。第一轮扫描出了问题：脚本限制了递归层数，只统计目录第一层的文件，把 106 GB 的用户目录算成了 3 GB。AI 自己发现数字对不上，当场重写了扫描逻辑。修正之后，占用排名变得很清楚：
只读扫描后的第一份分析：C 盘已用 187 GB、仅剩 12.8 GB，用户目录 106.1 GB 居首
截图里可以看到当时的判断：C 盘共 199 GB，已用 187 GB，仅剩 12.8 GB，占用 93.6%；用户目录 C:\Users 占 106.1 GB，是最大的一块；C:\Windows 占 38.5 GB，其中系统组件存储 WinSxS 就有 24 GB；C:\Program Files 占 8.3 GB。再往下拆，用户目录里的 AppData 一个文件夹就占了 86 GB。
拿到这份清单才意识到：C 盘不是被“垃圾文件”撑满的，是被一批看不见、却合法的文件占满的。
这也是后来反复跟同事讲的一句：
看完清单，先选最保守的一组：临时文件、回收站、系统组件清理，三项预估能释放 30 GB 左右。
临时文件清得很快，20.84 GB 降到 0.16 GB。中间有个插曲：清完之后再查，临时目录又回到了 9.12 GB。追下去发现是编辑器自己的更新缓存——每次会话生成一个临时目录，用完不清理，积了 255 个历史目录，光这一项就 8.97 GB。AI 只删了当天中午之前的历史会话，保留正在运行的那个，避免影响程序。
到这一步，C 盘可用空间从 12.84 GB 涨到 35.12 GB，第一个目标达成。
系统组件清理必须管理员权限。AI 试了三种自动提权的方式，都被安全策略拒绝了：启动外部进程被拦、换到非隔离环境仍是普通权限、计划任务工具在禁止名单里。AI 没有绕过去，而是说明这一步需要人工确认，然后做了一个双击就能提权的启动器。
双击之后，UAC 弹窗点“是”，得到的就是下面这个窗口——从第一秒到第二十分钟，除了最上面一行提示，没有任何新输出。
提权后运行系统组件清理的窗口：只有首行提示，长时间没有新输出
当时截图问 AI 是不是卡住了。AI 没有直接安慰，而是去查了三样东西：后台进程还在不在、组件服务的内存有没有在涨（两秒内从 820 MB 涨到 825 MB）、系统组件日志的最新时间戳（还在刷新）。三样都对得上，判断是在正常工作，只是输出被暂存了，跑完才会一次性打印。
十二分半钟后，日志里出现“操作成功完成”，退出码 0。系统组件存储从 24.09 GB 降到 12.24 GB，可用空间到了 43.97 GB。
这一次留下的经验，后来直接写进了技能的排查说明里：
到这里本来可以收尾。想再挤一点，于是清理了剪映、Chrome、Edge、豆包的缓存。删除明细显示合计约 15.2 GB，每个目录都从几个 G 变成了 0。
结果 C 盘可用空间从 43.84 GB 变成 43.82 GB，几乎没有变化。
接下来的排查是一层层排除。先怀疑目录其实是链接，一查都是普通文件夹；再怀疑进程占用，把浏览器都关掉之后数字仍然不动；又怀疑系统还原点，查了两遍，一个卷影副本都没有。最后用系统底层接口读了一次，才发现两个同时出现的变化：
两项加起来，刚好把清出来的空间抵消掉。把这份账目列成表格，一眼就能看懂：
第三轮清理的空间账本：释放 15.2 GB，被回收站与休眠文件各抵消一块
这件事留下一句话：
当场要求保留休眠功能——这台是笔记本，合盖休眠用得上。AI 把已经做好的关闭休眠脚本撤掉了，休眠文件 12.69 GB 原样保留。回收站里那 15.19 GB 也没有立刻清空，因为里面可能混着以前手动删过的旧文件，需要先确认一遍。
事情到这里其实可以结束。但 C 盘还会再满，而这套判断逻辑靠记忆留不住。于是提了一个要求：为了下次清理做准备，把这套流程做成 skill。
AI 把整场经验固化成一个用户级技能，包含 6 个脚本（只读审计、秒级快照、临时文件清理、缓存白名单清理、系统组件清理、提权启动器）、一份主文档和一份问题库。为了让脚本真的可用，它自己跑了三轮全盘扫描、两轮空跑测试，改掉了五个 bug——包括路径拼接多一个斜杠导致关键目录显示 0 GB、递归限制导致体积严重低估、程序盘符大小写比对失效等。
这套东西现在放在用户技能目录里。下次 C 盘再满，只要说一句“清理一下 C 盘”，它会自动走审计、给方案、等确认、分级执行、复核对账的完整流程。
这次不是实验室环境，就是日常在用的这台机器：199 GB 的 C 盘、91.5 万个文件、26.3 万个文件夹，都处于真实使用状态。方法有三条：
全程一共做了三轮清理，覆盖五类对象。每一轮的预估与实测都记在下面这张表里，差额一栏也是最开始那轮排查的线索：
三轮清理数据：预估释放与实际释放对照
表面上看，合计删除约 54.8 GB，最终到手 31.4 GB，相差 23 GB。这个差额不是误差，而是被四部分分走了：停在回收站的 15.19 GB、重建的休眠文件 12.69 GB、被进程占用暂时没有归还的部分，以及清理之后又重新长回来的一部分缓存。一项项对上，账才是平的。这也是这次实践里最有价值的一个发现。
所以后来给自己加了一条规矩：
最终结果以系统权威口径为准，清理前 12.84 GB，清理后 44.21 GB：
最终结果：可用空间净增 31.37 GB，占用率下降 15.7 个百分点
表格里最后一行看着反常——回收站占用反而从 0.79 GB 涨到 15.19 GB。这恰好是排查的成果，它正是“删了但没真正释放”的直接证据。把这 15.19 GB 清掉，C 盘还能再上一个台阶。
单看表格不够直观，把几个主要项目的前后数值画成条形图，变化的形状就很清楚了（浅灰是清理前，黑色是清理后）：
前后对比：五行里只有回收站这一项是往上长的
只有“回收站”这一行是往上长的，因为它装的正是那些以为已经删掉的东西。这张图看明白了，C 盘清理基本不会再走弯路。
五条验收线都通过了：可用空间净增 31.37 GB、占用率降到 77.9%、个人文件零丢失、重启之后系统与常用软件一切正常、释放量与到手空间能够逐项对上。
这一段值得单独写，因为它推翻了一个很自然的直觉：只要目录清空了、文件数归零了，空间就应该回来了。事实是有将近四十分钟停在这个坎上。
排查顺序如下，每一步被排除之后，才接近答案：
前三步走完的时候，常见解释已经用尽，数字还是不动。真正解开问题的其实是一个很朴素的动作：把所有可能藏东西的位置挨个称一遍重量，看哪个体积突然变大。称完就清楚了——回收站从 0.79 GB 涨到 15.19 GB，一进一出正好对上。
这个案例后来成了技能里的第一条问题记录，排在休眠文件之前，标题就叫“先查回收站”。在所有“删了却没释放”的情况里，它出现得最多，也最容易被忽略。
四条目标都已达成，而且都落在预期线以内。先看最终的状态截图，C 盘可用 43.7 GB，D 盘 30.7 GB，E 盘 141 GB（这张图拍于清理刚结束时，之后又陆续释放了一部分，最终权威口径是 44.21 GB）：
清理后的磁盘状态：C 盘从 12.7 GB 回到 43.7 GB 可用
对照开工前定下的四条：
时间上，全盘审计一次约 6.5 分钟（91.5 万个文件），一半以上的等待时间花在扫描和系统组件清理上，人手实际操作的时长不到十分钟。
换到别的场景，这套方法同样适用。归结成四条：
如果只带走一句话：
五个问题都是现场遇到的，现在都写进了技能的问题库，按参考价值排序：
五个坑：从回收站吞掉释放量到提权被拦，每个都有对应的解法
如果只保留一条，建议记住第一条。它花的时间最长，道理却最简单：空间不是删出来的，是删完再确认一次，才落进口袋的。
这台机器从 12.84 GB 回到 44.21 GB，用了三个多小时。真正留下来的，是那套以后还能接着用的方法。
