我最近花了一个周末折腾了个小项目，起名叫“C盘AI清理大师”，说白了一句话：把一个AI Agent 接到C盘清理这个场景里，让它自己扫描、自己判断、自己执行清理，最后再跟你汇报清了多少。这东西做出来之后我自己用了两天，二十多G的垃圾文件清掉，系统盘从红条变绿条，整个过程只有最开始我手动确认了几个清理动作，后面基本托管给AI。
C盘清理这件事，说大不大说小不小，每个Windows用户迟早都会撞上“系统盘飘红”这道坎。常见做法无非是用各家电脑管家扫一圈，或者下载个CCleaner点两下，再狠一点就手动翻AppData、Temp去删。问题是，这些传统工具要么不敢动，要么乱删，删错了系统出问题还得重装。这次我想试的是一件大多数人想过但没见到完整实现的事：把大模型的识别与决策能力拉进C盘清理流程，做一个能看懂文件、敢做判断、还能自己收尾的“AI清理大师”。
这篇文章我会把这个项目的完整思路、架构设计、核心代码、踩坑记录全部过一遍，想做类似AI Agent工具的朋友可以直接照着抄作业，对“AI清理”这个方向好奇的人也能知道它到底是怎么跑起来的。
1. 先说清楚：这个项目的思路到底长什么样
1.1 传统C盘清理工具的三个死穴
先摆一下我体验过的传统清理工具的通病，这决定了为什么需要引入AI。
第一个死穴是规则僵化。WinSxS临时文件、浏览器缓存、Windows Update残留、软件安装包，这些都是老面孔了，但不同电脑的情况完全不一样。有人C盘是64G的小硬盘，有人是512G但被微信和钉钉的聊天记录塞爆，还有人是Steam游戏库误挂到了C盘。固定规则扫不出这种差异化问题，天天只会怼着同一批Temp文件反复清，效率很低。
第二个死穴是不敢深层次判断。传统工具对“这个目录能不能删”的判断依据基本靠白名单黑名单，你不认识的软件数据它不做区分，看起来能删就列出来，删错了它也不管。最典型的是C盘根目录下的hiberfil.sys、pagefile.sys，还有C:\Windows\Installer下的补丁备份，这些明明有处理空间，但很多工具压根不给你展示细节。
第三个死穴是交互体验反人类。动辄弹窗、要你开通会员、顺带装个全家桶。我每次装完都得再花二十分钟把捆绑软件请走，这种额外负担比C盘满本身还让人烦躁。
1.2 AI清理大师的定位与整体闭环
我的方案是把C盘清理做成一个“扫描→分析→决策→执行→汇报”的完整闭环，核心是让大模型充当“会看文件的管家”，而不再是一条条写死的规则脚本。
具体来说，整个流程大致是这样：
- 扫描阶段：用Python脚本递归统计C盘所有目录和文件的体积，构建出一个完整的“目录画像”，记录路径、大小、是否存在系统属性、修改时间、基本文件类型等信息。
- 分析阶段：把目录画像的摘要信息喂给大模型，让模型对每一个“可能可清理项”做风险分级，是“建议清理”“可以清理”还是“千万别动”。
- 决策阶段：模型输出一份结构化的清理方案，里面写清楚要删哪个目录、为什么删、预估回收多少空间、风险等级是多少。
- 执行阶段：按风险等级从低到高逐级执行，执行前自动给每个目标创建回收站备份，删错了也能一键还原。
- 汇报阶段：清理完成后生成一份完整报告，列清楚“清了哪些东西、释放了多少空间、如果出了故障怎么回滚”。
这个闭环看起来不复杂，但里面最核心的难点不在“删”这个动作，而在“判断”和“安全兜底”。传统工具敢不敢删、删得准不准，全部卡在里面。
1.3 为什么选AI Agent而不是规则引擎
有人可能会问：同样几十条扫描规则，我写一个传统脚本也很快，何必上大模型？这里我有一个很有体感的对比。
普通规则引擎能回答的是“这个目录是Temp，可以清”，但AI能做的是“这个Temp目录里有两个大文件，其中一个还在被进程占用，另外一个三天没改过可以被清理，剩下的小文件虽然多但合并起来还不到50MB，不值得为它们花时间”。这个粒度完全不是同个维度，AI是在逐项分析文件特征，而不是套模板。
另外，C盘清理里有一种高频撞墙场景叫“目录看起来一样，底层情况完全不同”。同样是AppData\Local\Temp，有的软件会实时写入，有的只是囤了几百MB安装包碎片。规则引擎只能让你自己从“信任名单”选，AI则会把每个目录的边界情况摊开给你看，你授权之后它才动手。这个“看懂文件再决定怎么处理”的能力，就是AI Agent天然擅长的。
2. 架构设计与核心模块拆解
2.1 三层架构：Detective、Analyzer、Executor
我把整个工具拆成了三个独立模块，分别是Detective（扫描层）、Analyzer（决策层）、Executor（执行层）。彼此之间通过标准JSON传递数据，方便调试，也方便以后替换任何一层。
Detective负责“看”，它的任务就是问文件系统要数据。我直接用的是Python的os.scandir和os.walk组合，扫描C盘全盘目录，统计所有目录体积、文件数量、平均文件大小、最老/最新文件时间。这个模块不关心哪些文件能不能删，只关心怎么把它们找出来并且描述清楚。
Analyzer负责“想”，它接收Detective产出的目录画像摘要，然后调用大模型API生成清理方案。这一层是项目的核心，也是我调整最多的地方。模型需要理解“哪类文件是用户不小心留下的、哪类文件是系统更新备份、哪类软件残留虽然看起来安全但删了会出问题”，这种理解来自大模型的通用知识，而不是一个写死的清单。
Executor负责“做”，它拿到Analyzer下发的结构化任务列表，按风险等级从低到高执行删除动作。执行前把目标文件或目录移动到回收站，而不是直接rm，这一步极其重要。之后更新报告，把“理论回收空间”和“实际回收空间”做对比。
2.2 安全护栏：AI永远不直接删除文件
这个项目里最硬的一条规矩是：AI只出方案，不直接动手删除。所有的删除操作都要经过一个中间层，这个中间层有两条护栏：
- 第一道护栏是回收站优先。所有被清理的目标并不是物理删除，而是先移动到回收站。Python里用send2trash库实现，Windows下它是调系统接口，目标文件会出现在回收站里，用户随时能恢复。
- 第二道护栏是人工确认闸门。清理方案生成后，并不是马上执行，而是把方案打印成一张清单展示出来，标好风险等级。风险等级为“建议清理”的项目自动进入队列，风险等级为“谨慎操作”的项目必须由用户手动输入“yes”才执行。
这个设计思路跟自动驾驶的分级很像：L2级的辅助驾驶可以让车自己开，但驾驶员必须盯住方向盘。AI清理同理，它完全可以自主，但人类保留最终一脚刹车的权利。
2.3 各模块之间的数据流动
数据流动路径是这样一条线：
- Detective扫描完成，输出
directory_report.json，里面是所有目录的体积、文件数、状态标记。 - 用一段压缩算法把冗长的JSON“摘要化”处理后再喂给Analyzer，避免把几十万条路径全部塞进模型上下文，token根本扛不住。
- Analyzer返回
cleanup_plan.json，每条计划包含target_path、action（move_to_recycle_bin）、risk（low/mid/high）、reason、estimated_size。 - Executor读取
cleanup_plan.json，先过滤掉risk=high的项目，再逐条执行low和mid项，执行完成后把结果回填进execution_report.json。
我把这层数据流写成一个简单的管线，每个环节都有独立的日志文件，哪怕哪一步出了问题，翻日志就能定位。
3. 核心模块实操：Detective扫描与目录画像
3.1 磁盘空间统计的原理和坑
这里有一个很容易踩的大坑：你以为Windows资源管理器显示的“文件夹大小”是从哪里来的？它并不是存储在你文件系统里的元数据，而是系统实时遍历所有子文件算出来的。所以第一次打开一个大目录时资源管理器会卡一下，就是在后台跑统计。
Python里实现目录大小统计最基础的方式是os.walk，逐个文件累加。但C盘这种级别的目录树，文件数量动辄几十万甚至上百万，os.walk走全盘性能很差，第一次扫描要跑很久。我实际做下来，C盘大概60万文件、400G数据，纯walk需要十几分钟，太影响体验了。
优化的思路是两级扫描：第一级只扫目录结构，用os.scandir逐层打开目录并累计大小，不做文件级细节；第二级针对Detective筛选出的“潜在可清理项”做文件级详细扫描。第一级扫描的输出就是一个大目录树，模型需要的信息全部从这棵树上取。
3.2 检测C盘可用空间与统计目录体积
统计目录体积我用了两个函数，第一个是常用递归版本，第二个是性能优化版本：
import os from pathlib import Path TARGET_DIR = "C:/" def get_dir_size(path): """返回目录总字节数，跳过无权限及隐藏系统文件异常""" total = 0 for dirpath, dirnames, filenames in os.walk(path): for f in filenames: fp = os.path.join(dirpath, f) try: total += os.path.getsize(fp) except (OSError, PermissionError): pass return total这个版本简单直接，但全盘跑会非常慢，因为每个文件都要单独调用一次os.path.getsize，最后的IO开销非常大。
实际项目里我用了os.scandir的迭代版本，一次性获取目录下的文件大小并做累加，还要处理硬链接和符号链接的情况。Windows下有些系统文件的硬链接会被统计多次，导致个别目录体积虚高，需要判断文件属性后再决定是否跳过。
另外一个必须提前处理的坑是权限。C盘下有一堆受保护的系统目录，比如C:\System Volume Information、C:\Windows\CSC，普通进程根本进不去。os.walk遇到这些目录会抛权限异常，如果不处理就会中断整个扫描流程。
import os from send2trash import send2trash def get_dir_size_fast(root_dir): total = 0 file_count = 0 for entry in os.scandir(root_dir): try: if entry.is_file(follow_symlinks=False): total += entry.stat().st_size file_count += 1 elif entry.is_dir(follow_symlinks=False): sub_size, sub_count = get_dir_size_fast(entry.path) total += sub_size file_count += sub_count except (PermissionError, OSError): pass return total, file_count3.3 构建目录画像JSON
Detective的核心输出是一棵目录树，树上每个节点都带有这些关键字段：
path：目录绝对路径size_bytes：目录总体积（字节）file_count：目录下文件数量top_files：该目录下体积最大的前5个文件，帮助AI判断是什么类型的数据older_than_30d_bytes：超过30天未修改的文件总大小recent_file_count：最近7天内新增或修改过的文件数
这个结构相比单一的数字多了一个重要的信息维度：时间特征。一个体积庞大但全是老文件的目录，和一个体积不大但持续有新文件写入的目录，清理策略完全不同。大模型看到这些特征以后，能给出远比“能不能删”更聪明的建议。
例如，如果目录下有个缓存型文件，大小超过2GB，修改时间距离现在15天以上，模型很可能会建议“优先清理，属于典型缓存残留”；但如果是系统正在高频写入的日志文件，即使体积很大，模型也会警告你“清理后可能影响后续故障定位”。
{ "path": "C:/Users/test/AppData/Local/Temp", "size_bytes": 3456789012, "file_count": 18233, "top_files": [ {"name": "installer_20240101.zip", "size_bytes": 2147483648}, {"name": "chrome_update_cache.dat", "size_bytes": 1023308839} ], "older_than_30d_bytes": 3000000000, "recent_file_count": 40 }我加了一层摘要逻辑：完整JSON可能几百KB，但喂给模型的摘要只需挑选体积超过500MB的目录、文件数超过1000的目录、以及Allusers下的共享临时目录。一句Prompt让模型“只看摘要，不要试图分析每个条目”，省下来的token和响应时间非常可观。
4. 让AI做判断：Analyzer决策层的设计与实现
4.1 决策层的Prompt设计
Analyzer层是全项目最见真功夫的地方。我在调整Prompt上花的时间比写整份代码还多，因为这个项目好不好用，完全取决于模型能不能给出准确的风险判断。
第一版Prompt特别简单，就是“根据目录信息判断哪些可以清理”，结果模型给了很多模糊且危险的答案，比如把系统盘根目录都列成了“可清理”。后来我把Prompt重构为“角色设定+决策依据+输出格式”三段式，终于稳定下来。
实际使用的是这样一段核心Prompt：
你是一名Windows系统清理专家，拥有15年C盘空间优化与故障恢复经验。 我会给你一串C盘目录扫描摘要，每个条目包含目录路径、大小、文件数、 修改时间分布与典型文件。 请你对每个条目给出清理建议。必须遵守的安全规则： 1. 绝对不要建议删除Windows系统核心目录、Program Files下的软件主体目录。 2. 用户文档、桌面、下载目录里的内容，即使看起来没用，也只标注“用户自决”。 3. 对临时文件、缓存文件、更新备份包，可以标注“建议清理”，但必须附原因。 4. 有任何不确定的情况，一律归类为“谨慎处理”。 输出格式必须是JSON数组，每条包含： {"path": "...", "risk": "low"|"mid"|"high", "action": "recycle_bin"|"keep"|"user_decision", "reason": "判断依据说明", "estimated_reclaim": "预估回收空间"}这个Prompt最关键的改动是给模型设计了决策边界。之前它敢乱闯的系统目录，现在被明确禁止。同时加入一个“用户自决”分类，对应下载文件夹这种灰色地带，AI不背锅，把决定权交还给用户。
4.2 模型选型：本地推理 vs 云端API
Analyzer可以选择两条路线：本地模型和云端API。我两种都试过，结论是不同场景各有取舍。
我本机是32GB内存加一块中端显卡，跑quantized版本的Qwen2.5-7B-Instruct是流畅的，分析一个中等体量的C盘扫描摘要大概耗时20秒左右，好处是数据完全本地处理，不用上传任何目录信息到外部服务器，隐私上有优势。坏处是对复杂决策的理解力比云端大模型弱一些，偶尔会给出有点笨的判断，比如把杀毒软件日志目录建议“直接清空”，吓得我差点砍掉这个方案。
云端API走的是GPT-4级别的大模型，分析质量明显更高，对Windows目录结构的理解也更准确，但会涉及数据出境，且每次分析要耗几万token，虽然单次成本不到一毛钱，但一个流程走两次，跑多了还是有点心疼。
最终我的项目里做了一个可配置项，环境变量支持model_provider=local或model_provider=cloud。日常清理自己用本地模型完全够用，给不太懂电脑的朋友做远程诊断就用云端模型，尽量用质量换安全。
4.3 让模型输出结构化结果，而不是一篇散文
大模型默认输出是纯文本，如果不加约束，它会给你写一大段“建议如下：首先，您应该清理……”，这种输出对于程序来说毫无意义。要让模型直接变成执行计划，必须强制输出JSON，并且要用代码方式校验、纠错。
我用的模块是LangChain的输出解析器，配合Pydantic模型定义：
from pydantic import BaseModel class CleanupItem(BaseModel): path: str risk: str action: str reason: str estimated_reclaim: str class CleanupPlan(BaseModel): items: list[CleanupItem]拿到模型输出后，先做一次JSON解析，如果失败就做一次“修复解析”——把模型误加的Markdown代码块标记剔除，再把裸JSON重新load。这一步看起来很简单，但实际使用中几乎每次都能捕获到各种怪异输出，比如模型把注释写进了JSON、字符串引号缺了一半、逗号放到数组尾端。这些细节不处理干净，后续执行层完全没法跑。
我还用了一个文本分类器做二次校验，对模型标注为“low”风险（建议清理）的条目，用预设关键词进行扫描，如果路径匹配到C:\Windows、System32、Program Files这类系统目录，即使模型标成low，系统也直接自动升级为high。这算是给AI加了一层传统规则兜底，双保险。
5. 执行与回滚：Executor落地实操
5.1 先按风险分级执行
Executor拿到计划后，第一件事不是动手删，而是把计划按风险分级重新排序。我的设计是分三个梯队执行：
- 第一梯队：low风险。典型是用户级临时目录、浏览器缓存、软件升级包残留。这些文件删了最多是重新生成，完全不影响系统稳定性，可以自动执行。
- 第二梯队：mid风险。典型是Windows Update的旧备份、已卸载软件留下的大块数据目录。这些目录删了以后，可能会出现“无法回滚补丁”之类问题，但实际概率很低，我会把清单打出来等待用户确认，按下回车才会执行。
- 第三梯队：high风险。系统核心目录、正在运行的软件数据目录、杀毒软件隔离区，一律不执行，只展示给你看，让你知道这里有这么个情况。
执行的时候我用的是send2trash，而不是shutil.rmtree。原因前面说过，回收站能让所有删除行为变得可逆。具体代码很简单：
from send2trash import send2trash import os def execute_cleanup(plan_item): path = plan_item["path"] if not os.path.exists(path): return {"status": "skipped", "reason": "path not exists"} try: send2trash(path) return {"status": "ok", "path": path} except Exception as e: return {"status": "failed", "reason": str(e), "path": path}5.2 清理前后的空间对比与跟踪
执行完成后，我会调用两次系统计数器，一次是清理前，一次是清理后，之间的差值就是真实释放空间。这一步看起来简单，但里面有个细节容易被忽略：如果被清理的文件还在回收站里，磁盘空间实际上没有真正被释放。系统报告的可用空间不会因为“移入回收站”而有任何变化。
所以在执行完所有任务后，我加了一个可选的“挤压回收站”步骤，弹窗提示用户“是否要彻底清空回收站以真正释放空间”。这一步会让删除变得不可逆，所以我默认不自动做，而是把决定权完全交给用户。用户自己确认没有需要恢复的文件后，再手动倒掉回收站也不迟。
5.3 生成清理报告
所有操作完成后，项目会生成一份人类可读的Markdown报告，放在用户桌面，内容包括：
- 清理前总可用空间、清理后总可用空间、差值
- 执行成功/失败的条目列表
- 每个目录预估回收大小与实际回收大小的对比
- 本次清理的风险分级统计
- 如果后续系统出现问题，如何从回收站找回文件的步骤说明
这份报告的最大价值不在“展示战果”，而在于“留证据”。哪天用户发现某软件异常了，回来翻报告能快速定位到是哪次清理动了手，回滚路径一目了然。这也让AI清理工具在用户心里的可信度大大提升——不是黑盒操作完就不管了，而是每一步都有记录。
6. 踩坑实录与常见问题排查
6.1 Java级文件锁与占用：为什么有的目录删不掉
实际跑起来后第一个翻车现场是文件占用。C盘跟别的盘不一样，系统、后台服务、杀毒软件全在往里面读写文件，很多目录扫描时存在，删除时却被某个进程锁住了。send2trash不会报错，文件就停在原地不动，看起来像删了，但空间没变。
我调试时专门写了一个占用检测逻辑：删除失败后顺手调一次os.open尝试独占打开文件，如果抛PermissionError，基本可以判定是被占用。这种文件不适合强行处理，直接跳过即可，AI的下一步操作是把它挂到一个“等待列表”，并在下次开机后再清理。
另一个高频占用场景是浏览器开着的时候清理浏览器缓存。大家都有体会，Chrome开着一堆标签页，它的Cache目录是在持续写入的，删到一半必定撞锁。所以项目会在执行前先检查浏览器进程是否在运行，如果开着就跳过该目录并提示用户“关掉浏览器后这个项目会释放额外XGB空间”。
6.2 Token上下文爆炸：怎么处理超大目录树
C盘扫描出来的JSON动不动就是几十万行，直接塞给大模型，再强的上下文也扛不住。我第一版就是把完整JSON传过去，结果API直接报context length exceeded，改小了又丢失关键信息，模型经常回答“看起来没有明显的垃圾文件”。
最后找到一个平衡点：只把体积排行前200的目录，和体积大于500MB的单独大文件做摘要处理。超过200条的部分直接丢弃，因为对清理来说价值不大。小文件数量再多，加一起也没一个大型缓存目录值钱，丢掉不影响判断。这个“质量优先于数量”的摘要思想让token消耗降到了原来的五分之一，模型回答精准度反而上来了。
6.3 系统还原点与硬链接误判
还有一次比较惊险的误判差点让我整个项目废掉。模型对C:\System Volume Information目录标了“建议清理”，理由是体积大且看起来像系统临时数据。这个目录实际上存放的是系统还原点，贸然清空会导致所有还原点失效。
我在后期加了硬编码黑名单，这个目录永远不允许任何人碰。类似的还有C:\Windows\WinSxS，虽然里面确实有大量可清理的旧组件备份，但清理方式必须用DISM命令而不是直接删目录，直接删会让Windows更新链断裂。
经验就是：AI判断再聪明，也必须在关键系统目录上“一刀切”——禁用删除。AI可以用来发现和理解，但底线规则永远是人给的。
6.4 常见问题速查表
| 现象 | 原因 | 解决方案 |
|---|---|---|
| 清理后空间几乎没有变化 | 文件被移入回收站，未真正删除 | 清空回收站或调整执行策略 |
| 部分目录删除失败 | 文件正在被系统或应用占用 | 关闭相关软件，重启后重试 |
| 模型给出危险建议 | 上下文信息不足或模型理解偏差 | 增加系统目录硬编码黑名单 |
| 扫描耗时过长 | 全盘os.walk导致性能瓶颈 | 改用两级扫描策略 |
| 大模型API响应超时 | 请求内容太长或网络不稳 | 减少摘要条目数，限制单次请求大小 |
7. 怎么扩展成一个真正的“AI系统盘管家”
7.1 从“一次性清理”到“持续监控”
现在这个C盘AI清理大师还是手动触发的，我觉得下一步最有价值的扩展方向是把它做成一个常驻后台的守护进程。每隔24小时跑一次扫描，发现可用空间低于预设阈值就自动报警，AI分析出可清理项后直接生成方案并推送到用户端，确认动作在手机App或微信上点一下就能完成。
这种模式的好处是C盘永远不会飘红，因为问题在发生之前就被发现了。传统杀毒软件有“实时防护”，AI清理工具也可以做“实时预防”，这套逻辑在以前的规则引擎时代很难实现，但现在大模型做分析判断的成本已经足够低，技术上完全可行。
7.2 结合开源智能体框架做升级
我之前关注过DeepSeek公开的AI智能体训练新方法，里面提到的一个重要思路是“让模型在训练阶段学习工具调用和结果反馈”。直接应用到现在这个场景里，就是收集一批真实清理案例，把“扫描输入→AI建议→执行结果→用户反馈”作为一条经验数据，持续对模型做微调，让AI的判断力越来越准。
配合上现在各家开源的Agent框架，整个流程可以做得更顺滑。模型不仅能判断清理项，还能自己调用工具执行扫描、执行状态检测、计算空间变化。整个C盘管理可以完全自动化，用户只需要在删除前看一次清单就行。
7.3 数据安全与隐私保护
最后聊一下隐私，这是任何工具类项目都不能回避的一环。C盘扫描会接触到大量个人信息，包括聊天记录、文档缓存、浏览器历史碎片。我在设计上做了几个保护措施，希望能给大家做个参考：扫描数据默认只保存在本地，上传到云端API前必须经过用户明确同意；输出报告中不包含文件名详情，只展示路径和大小；所有网络请求走可信通道，并在本地做一次脱敏处理。
我在实际使用中最大的体会是：AI清理工具的能力上限不是由模型决定的，而是由安全机制决定的。你敢给AI多少权限，它就能帮你多少忙，但前提是每一层权限都有回收机制、都留了后路。“可以删但不准物理删”“可以建议但不准直接执行”“可以扫描但不准默认上传”这三条铁律，是我这次做项目最值钱的收获。如果后续要做更大的AI本地自动化项目，这套思路可以直接照搬。
