C盘爆红这件事我几乎每隔一阵就要处理一次。前几天又碰到了剩余空间不到1GB打开资源管理器往下翻罪魁祸首毫无悬念又是AppData——这个目录一个人就占了 87.81GB。以前我会一层层点开目录、按大小排序翻到后面眼睛发花还分不清哪些是缓存哪些是配置。这次我换了个思路用 Codex 帮我做磁盘占用分析把扫描、分类、定位的工作交给 AI我只负责确认和执行清理。整个过程走下来比手动翻目录快了不知道多少倍也顺手总结出了一份“能删/不能删”的清单。这篇文章就把整个流程复盘一遍包括提示词怎么写、脚本怎么跑、哪些坑绝对不能踩希望能给同样被 C 盘折磨的人一个可以照着复制的方案。1. 为什么第一个要查 AppData以及“别乱删”到底是什么意思1.1 AppData 到底是个什么样的目录AppData是系统里专门给应用程序存放运行数据的目录下面默认分成Local、LocalLow、Roaming三个子目录。你可以这么理解本地安装的每个软件几乎都会在这里建一个属于自己的小房间用来放配置、缓存、日志、临时文件、下载的更新包甚至是崩溃时生成的转储文件。比较细心的软件会定期清理自己的“房间”但大部分软件的设计逻辑是“只要磁盘放得下就尽量不删”因为它们觉得缓存能加速下次启动日志能帮助排查问题临时文件也许还有用。我这些年处理过几十次磁盘告急的情况AppData占掉 50GB 以上是非常常见的现象。因为 Windows 系统目录本身是受保护的普通用户不会轻易动Program Files而AppData隐藏得深、路径又长很多用户根本不知道这里堆了这么多东西。它就像一个常年不整理的杂物间平时看不见等开门一看已经堆得快顶到天花板了。1.2 为什么 AppData 能堆到 87.81GB根据我这次扫描的结果87.81GB 并不是单一软件造成的而是多个“贡献大户”叠加出来的结果。常见的膨胀来源包括浏览器缓存、网页离线资源、临时下载文件各类开发工具的依赖缓存比如某个 Python 生态的包缓存、某个 Node 生态的全局缓存动辄十几 GB软件自动更新机制下载了新版本但旧版本文件不会自动删除日志文件只增不减有些程序每天能写几百 MB 日志程序崩溃时生成的 dump 转储文件单个文件经常上 GB各类安装包、升级包的残留文件安装完成后不会再被读取却一直占着空间。这些目录单独看都不算离谱但架不住数量多。生活里类比就是你每天往包里塞一张纸一年下来包就会变得很重而你可能完全想不起来那些纸都是从哪来的。AppData 膨胀的核心原因是“只进不出”的机制加上大量软件各自为政谁也不替全局磁盘空间着想。1.3 为什么 C 盘爆红不能靠“乱删”解决我特别理解 C 盘爆红时的心情看到哪个目录大就想删哪个。但 AppData 不是一个大垃圾筐里面既有可以随时再生的缓存也有删了就会出大问题的配置和数据。如果盲目把整个 AppData 删掉最轻的后果是软件需要重新登录、重新设置严重的情况下一些本地存储的数据、项目配置、邮件归档、数据库文件会直接丢失。还有一个很容易忽略的问题很多目录正被运行中的程序占用。你点删除系统提示“操作无法完成因为文件已在另一个程序中打开”这时候如果你去强行修改权限可能导致该程序崩溃甚至影响系统稳定性。所以正确的思路永远是先分析、再分类、最后才动手清理。这也是我这次坚持用 Codex 做“扫描-分类-标注”而不是直接删文件的原因。2. 用 Codex 排查磁盘占用的整体思路2.1 为什么这次选择 Codex 而不是纯手动操作手动排查 AppData 最大的痛点是路径深、目录多、肉眼排序根本不靠谱。AppData\Local下面经常有五六十个子目录每个子目录里还可能嵌套多层。用资源管理器一个个看属性、记大小、做对比工作量很大而且很容易看漏。Codex 是一款命令行 AI 编程助手可以读取目录结构、执行命令、分析输出结果然后直接给你结论。这次我让它做的事情可以概括成三步第一用脚本统计出 AppData 下各级目录的大小第二把超过阈值的目录按类型分类第三生成可执行的清理建议并明确标注“哪些可以删、哪些不要碰”。这种任务很适合交给 AI因为重复计算和路径拼接是它的强项而“能不能删”的判断还是需要我结合经验来确认。2.2 排查前的环境准备我这次是在 Windows 系统上操作的所以提前做了这么几件事打开系统自带的终端并准备一个普通权限的窗口部分目录扫描会提示没有权限这不要紧后面会讲到怎么处理。确认 Codex 已经安装好并且能正常对话。如果你还没装可以通过对应的包管理工具安装它的 CLI 版本装好之后在终端里输入codex就能进入交互界面。把当前正在运行的大型软件退掉一大半。比如浏览器、开发工具、设计软件、渲染程序等先让文件句柄尽量释放扫描结果才准确后续清理也少一些“文件被占用”的提示。准备一个专门用来放“待删除文件”的临时目录清理时先把文件移动过去而不是直接删除相当于给自己留一条后悔路。提示排查阶段任何让 AI 执行的操作都应该限定为“只读”。我这次给 Codex 的第一条指令就明确说了“不要修改任何文件”等分析结果出来之后再单独开一轮对话做清理。2.3 给 Codex 分配任务的提示词模板这次实践下来我认为一个好的提示词应该包含四个要素明确扫描目标、要求统计口径、指定输出格式、加上只读约束。下面是我复制进终端的第一段提示词帮我扫描 C 盘 AppData 目录下的空间占用情况。 要求 1. 分别统计 AppData 下面一级子目录和二级子目录的大小 2. 找出所有超过 1GB 的目录 3. 把每个大目录标记为【缓存】【日志】【配置】【数据】【程序本体】【未识别】中的一种 4. 只输出分析结果不要修改、移动、删除任何文件。这段提示词的核心在于“分类”和“只读”。如果不让它分类它只会丢给你一张大小列表你仍然不知道哪些能删如果不加只读约束AI 可能在分析过程中顺手执行清理命令风险就不可控了。Codex 第一次给我的输出就是一张按大小降序排列的表每个目录后面都标注了分类这比我手动翻资源管理器高效太多。3. 实操过程从扫描到定位 87.81GB 的完整流程3.1 第一轮扫描让 Codex 生成并执行统计脚本为了让 Codex 能分析目录大小它需要在本地执行一段脚本来扫描文件系统。我让 Codex 生成了一段用系统自带脚本语言写的统计脚本核心逻辑是先枚举 AppData 下的所有目录再逐个递归计算文件大小总和。下面是实际使用的脚本示例$root $env:LOCALAPPDATA Get-ChildItem -Path $root -Directory | ForEach-Object { $size (Get-ChildItem -Path $_.FullName -Recurse -File -ErrorAction SilentlyContinue | Measure-Object -Property Length -Sum).Sum [PSCustomObject]{ 目录路径 $_.FullName 大小GB [math]::Round($size / 1GB, 2) } } | Sort-Object 大小GB -Descending这段脚本看起来简单但里面有几个设计很关键。-ErrorAction SilentlyContinue可以让脚本自动跳过没有权限的目录避免扫描中途中断Measure-Object -Property Length -Sum是对文件长度做求和统计最后按大小降序排序让最大的目录直接浮到最上面。执行完这段脚本我拿到了 AppData 下所有一级子目录的大小列表。顺便说一下$env:LOCALAPPDATA只指向Local部分实际分析时还需要用同样逻辑分别扫描Roaming和LocalLow也可以直接用$env:APPDATA获取Roaming路径。3.2 解读第一轮扫描结果87.81GB 到底藏在哪Codex 把第一轮扫描结果整理成了表格我从中挑出了几个关键目录真实情况大概是这样的分布具体路径做了模糊处理但量级和类型具有普遍性目录类型占用大小是否为主要贡献者浏览器缓存18.5 GB是开发工具依赖缓存25.6 GB是系统临时目录12.3 GB是某应用的日志目录8.2 GB是崩溃转储文件6.7 GB是其他杂项16.5 GB部分合计87.8 GB-看到这个分布之后我心里基本有数了。最占空间的是开发工具依赖缓存这几乎是程序员群体里最常见的问题各种包管理工具会把下载过的依赖包缓存在本地下次构建时优先复用但问题是这些缓存永远不清除其次是浏览器缓存正常浏览产生的缓存积少成多到 18GB 并不稀奇系统临时目录和日志则属于典型的“只增不减”数据。3.3 第二轮扫描让 Codex 按文件类型和写入时间二次分类第一轮扫描只能看出“哪个目录大”还不能直接回答“哪些文件可以安全清理”。所以我又让 Codex 做了一轮更细的扫描主要按两个维度切分文件扩展名和最后写入时间。我给 Codex 的提示词是这样的继续扫描刚才分析出的超 1GB 目录。 对每个目录分别统计以下两件事 1. 按扩展名统计文件占用列出扩展名、文件数量、总大小 2. 按最后写入时间分层统计 7 天内、30 天内、180 天前、365 年前的文件各占多少空间。 最后把所有 365 天前写入且扩展名属于缓存/日志/tmp/dmp 的文件列成清单。为什么要把“最后写入时间”当成一个重要维度因为绝大多数缓存和日志文件在被写入之后就不会再被读取时间一长就变成了纯占空间的死数据。如果某个文件最近七天内还在被写入说明对应的程序还在正常使用如果它已经超过一年没有更新清理掉之后影响几乎为零。Codex 生成并按需执行的脚本会把每个目录里的文件按这两类信息汇总输出结果里直接标明了“建议清理”和“谨慎处理”。3.4 解读二次扫描结果时要注意的三个细节拿到第二次扫描输出后我看的时候留了个心眼这里有几个细节值得你留意。第一个细节是扩展名不是判断依据的唯一标准。一个.log文件也可能正在被程序写入需要结合文件的最后写入时间判断一个.db文件虽然看起来像数据库但如果是某个软件的本地缓存清理时也要先确认程序不会因为丢失它而报错。第二个细节是权限问题。Codex 在扫描时如果遇到访问被拒绝的目录会记录下来并继续往后执行。我这次有几个目录显示“部分统计失败”原因就是当前终端没有管理员权限但这不影响整体结论因为最占空间的目录多半不在受限目录里。如果你发现有个大目录统计不到可以用管理员权限重新跑一次。第三个细节是硬链接和符号链接可能让同一份数据被重复统计。某个文件可能通过链接形式在多个目录下出现导致每个目录单独计算时都算了一遍总体统计偏高。这种情况不常见但如果某个目录的大小和你从“属性”里看到的不一致优先相信分目录递归计算的结果。4. 清理方案与“能删/不能删”清单4.1 三类可以放心清理的数据经过两轮扫描和分类我最终把清理目标锁定在“可再生数据”上。所谓可再生就是删了之后系统或软件会在需要时重新生成不会影响正常使用。具体来说有三类。第一类是临时文件。系统临时目录下存在大量.tmp、.old、.bak文件大部分是程序安装或运行过程中产生的中间文件安装结束后就没用了。第二类是各类缓存。浏览器的网页缓存、缩略图缓存、开发工具的依赖包缓存这些都属于“删了最多慢一次”的数据。第三类是日志和崩溃转储文件。日志文件是用来排查问题的但很少有人真的会翻半年前的日志.dmp崩溃转储文件更是只在程序崩溃时才有价值正常情况下可以全部清理。注意清缓存之前最好先退出正在运行的对应程序。比如浏览器缓存要在浏览器关闭后再清否则文件被占用会导致删除失败甚至留下更多零碎文件。4.2 绝对不能乱删的目录类型清理时我也划了一条“红线”所有属于“配置”和“用户数据”的内容都不碰。Roaming下大量目录保存的是软件的登录凭证、偏好设置和账号信息删掉之后轻则需要重新登录重则会让软件回到初始状态某些目录里存放的本地数据库、聊天记录归档、项目级配置文件删了基本找不回来。另外“程序本体”类型的目录也不能碰。有些软件会把核心代码安装到 AppData 里表面看起来像一个缓存目录实际删除后程序直接无法启动。我的判断方法是如果一个目录名看起来像一个软件品牌名打开后里面有.exe、.dll、.bin这类程序文件默认不在清理范围内除非你确实打算卸载这个软件。我还总结了一个简单的判断标准能重新下载、能重新生成、丢了不影响任何状态的数据才值得删凡是需要手动配置、需要登录恢复的都不要动。只要有这条标准在就不会出现“删完开心三分钟重装配置两小时”的尴尬局面。4.3 清理前一定要做的三件事动手清理前我坚持按三步走每次都没吃过亏。第一步把目标目录按“移动而非删除”的方式操作。我在另一个盘建了一个待清理备份文件夹把准备清理的目录先移动过去确认系统和软件运行一周没有任何异常再回头删除备份。这也是为什么我不直接让 Codex 执行删除命令而是让它只负责分析和生成移动脚本。第二步退出相关进程。如果一个目录被占用物理移动都会失败更不用说删除。打开任务管理器找到对应进程结束之后再操作。我这次清浏览器缓存时就是因为没先退出浏览器移动一半提示失败后来结束进程才顺利跑完。第三步记录清理前后的空间变化。清理前记一次剩余空间清理后记一次中间如果有异常可以快速判断是不是误删了什么。我用一条简单的命令就能查看当前剩余空间不建议依赖资源管理器的刷新速度。4.4 我这次实际清理的结果我按照上述方案执行清理最终删掉了大约 63GB 的临时文件、缓存和旧日志剩余空间从不足 1GB 恢复到了 60GB 以上。整个过程我没有删除任何配置目录和用户数据软件全部正常运行唯一需要重新生成的只是下次打开时会自动重建的缓存。这 63GB 的组成大概是开发工具依赖缓存 25GB、浏览器缓存 18GB、临时文件 11GB、旧日志和崩溃转储 9GB。占用大户里最让我意外的是开发工具依赖缓存它就像一个永远不清理的回收站看起来不起眼积起来却是天文数字。5. 常见问题与排查技巧实录5.1 为什么 Codex 统计的目录大小和右键“属性”不一致我在实操过程中就遇到了这个情况某个目录在资源管理器里面看是 4GB但 Codex 脚本统计出来只有 2.7GB。原因有三个一是统计时没有管理员权限部分子目录被跳过二是目录里有隐藏文件或系统文件脚本默认枚举时没算进去三是符号链接问题同一个物理文件被多个目录引用导致两种统计视角不一样。如果你遇到这种差异不要立刻认为哪个结果是错的。优先看“谁更贴近你真正的目的”。比如你想知道“删掉这个目录能释放多少空间”那就以递归计算文件长度为参考你想知道“这个目录为什么占这么多”那就需要查链接和隐藏文件。5.2 删除文件提示“正在使用中”怎么办清理 AppData 时最常见的报错就是“操作无法完成因为文件已在另一个程序中打开”。我试过直接强制改权限再删结果导致某个程序崩溃过一次从那以后我就老实了。正确做法是先看是哪个进程占用了文件在任务管理器里按句柄搜索或者用系统自带的命令行工具找到占用进程结束进程后再清理。有些关键系统进程在结束之后会自动重启重启期间文件仍然暂时被占用这时候可以改成“延迟删除”策略把文件移动到一个空目录重启之后再删除。我的习惯是尽量不在系统繁忙时段做大清理把清理安排在快重启之前安全系数高很多。5.3 为什么 AppData 清完没两天又满了清理完不是终点很多人会遇到“今天清完 60GB过两天又回来 40GB”的问题。这种情况说明有程序在持续写文件常见原因有三个程序在循环崩溃并反复生成转储文件某个软件的日志级别被调到了详细模式每天都在写几百兆日志开发工具的依赖缓存在你重新构建项目后又被大量填充。我这次的排查方式是让 Codex 在清理后 48 小时再做一次同样的扫描对比哪个目录的大小又涨回来了然后单独看那个目录里的最新文件基本就能定位到元凶。如果发现是某个程序反复崩溃应该去修配置而不是继续清缓存否则只是治标不治本。5.4 常见“隐形占位大户”速查表下面这张表是我经过多次清理实践后整理的速查清单可以帮你快速判断 AppData 下的常见目录能不能动常见目录/文件类型是否可清理备注浏览器缓存目录可清理清理前退出浏览器开发工具依赖缓存可清理重新构建时会自动拉取系统临时目录可清理建议重启前清理日志目录可清理保留最近 30 天即可崩溃转储.dmp文件可清理除非正在调试崩溃问题软件配置目录不可清理删除后需重新设置/登录本地数据库/归档数据不可清理属于用户数据带.exe/.dll的目录不可清理可能是程序本体未识别目录先分析再动不要凭目录名猜5.5 一个小习惯防止 C 盘再次爆红清理完之后我给自己的机器加了一个“监控计划”每周固定时间用同一套脚本扫描一次 AppData 下的目录大小把超过 3GB 的项目单独输出成一份报告。这样我不用等到 C 盘爆红才去翻目录只要看一眼报告就知道哪个软件最近在疯狂攒缓存。这比任何清理工具都管用因为清理工具只负责擦地板而我更想知道是谁一直在丢垃圾。如果你也想复制这个方案最简单的方式就是把前面那段扫描脚本保存成文件配合系统自带的任务计划程序每周跑一次输出结果存成一个文本文件。用 Codex 分析报告也可以比如把报告贴给它让它标注哪些目录异常增长、哪些可以清理你只负责最后确认。这套“脚本扫描 AI 分析 人工确认”的组合我用下来非常稳既省时间又不用担心误删。希望你的 C 盘也能早日找回自由。