开头先放一个场景某天下午我正写着代码右下角突然弹出提示C盘空间不足。我下意识打开资源管理器一看233GB的C盘只剩不到5GB整个盘标红得像警报灯。第一反应肯定是东西太多该清理了但问题在于往哪儿清、什么能清、什么不能动这些心里没底。太多人在这时候会走两个极端要么拿着删除工具一顿乱砍把系统文件或者软件数据给误伤要么干脆躺平买新硬盘。这次我选择换个思路直接用 Codex 命令行工具来帮我做排查。它很快定位到 AppData 文件夹占了 87.81GB这数字一出来我都有点意外。更让我意外的是排查过程比想象中顺得多——不是靠感觉乱翻目录而是让 Codex 直接生成分析脚本、遍历统计、逐层找大户整个过程有据可依。这篇就记录一下我是怎么排查的哪些目录该删哪些目录碰都不能碰以及这套方法后面还能怎么复用。1. C盘爆红的真相AppData夹在系统和软件之间1.1 先搞清楚 AppData 到底是什么很多人一看文件夹名字带个 App就以为是软件安装目录想都没想就进去删东西。这里先把基础概念说清楚AppData 是 Windows 为每个用户单独划分的配置与数据目录路径一般是C:\Users\你的用户名\AppData它默认是隐藏属性所以在文件管理器里直接看不到得手动在查看选项中开启“显示隐藏的项目”才能定位到它。这个目录的意义在于把用户数据和系统全局数据分离。放在这里面的内容大多是和“某个用户”绑定在一起的而 Program Files 里的内容则是所有用户共享的。也正因为如此AppData 里往往堆着大量个人化的文件——浏览器缓存、桌面软件配置、聊天软件收发的图片视频、开发工具的包缓存全都往这个地方塞。AppData 里面又细分成三个子目录Local、Roaming、LocalLow。Local 存储仅本机使用的数据比如浏览器缓存、软件运行日志Roaming 存储可以跟随用户配置漫游的数据比如一些软件的设置项LocalLow 则是给低权限进程用的比如 IE 的 ActiveX 缓存。搞清楚这三个文件夹各自的定位排查起来心里就有底了。1.2 谁在偷偷填满 AppData我先吐槽一句AppData 是 Windows 里被厂商“滥用”得最厉害的地方。按理说它只是给应用放配置和缓存用的但很多大型软件直接把用户数据全都堆在这里而且几乎不做自动清理。我见过最多的几类第一类是浏览器Chrome、Edge 这类以 Chromium 为内核的浏览器会把网页缓存、图片资源、扩充组件的脚本全都写进AppData\Local\浏览器名\User Data\Cache正常使用三五个月这个缓存能轻松冲到十几GB。第二类是聊天与社交软件比如微信、QQ。这类软件默认把接收的图片、视频、文件存放在 AppData 的某个子目录新版微信通常是AppData\Roaming\Tencent\WeChat或者AppData\Local\微信。实际测过的人都知道一部手机常年接收的群聊图片和视频能堆出几十GB。第三类是开发工具链。Node、Python、Rust 这类生态的依赖缓存都默认落在AppData下npm-cache、pip\Cache、.cargo\registry单独看都是几百MB的小块头架不住装的包多长期下来也攒出好几个GB。Windows 系统自身也会往 AppData 写内容比如缩略图缓存、错误报告、临时更新文件。系统的东西一般不大大多数时候罪魁祸首还是前面说的那几类软件数据。2. 为什么这次我决定用 Codex 来排查2.1 手动排查到底有多难常年清理C盘的人一定有这种感受在资源管理器里一层层点进 AppData全是字母缩写加版本号的文件夹光看名字根本判断不出来是什么。就算把文件名显示全一个叫Roaming\SomeSoftware的目录谁能一眼看出里面装了多少体积、能不能删要拿到准确的占用情况正经做法是用 PowerShell 或者第三方磁盘分析工具比如某知名树状统计工具但命令脚本一个个敲效率太低图形工具虽然直观很多时候也只能告诉你“这个文件夹很大”并不告诉你“这个文件夹删了会不会影响软件下次启动”。我之前的做法是一边开着磁盘分析工具找大文件夹一边开着搜索引擎查这个文件夹是什么、能不能删。一个目录一个目录判断半天下来眼睛都花了遇到拿不准的还只能先留着下次空间不够了再重复一遍。这个流程来回折腾效率实在是低。2.2 Codex 能给我的其实是“一套完整思路”Codex 是 OpenAI 出品的命令行 AI 编程助手我最常用它来写代码、改脚本、跑数据但这套能力其实完全可以用在系统运维上。给它一个具体目标比如“帮我统计某个目录下所有子文件夹的占用大小并按大小排序”它能直接生成对应的 Python 脚本再让它“解释哪些目录适合清理”它能结合目录名给出判断依据顺便告诉我哪些目录必须跳过。这比单纯用磁盘分析工具多了一层价值它不只是告诉你“哪里大”还帮你理解“为什么大、怎么处理、删了有什么后果”。相当于身边有一个能随叫随到的运维工程师而且给出的建议是基于目录结构逐条分析的不是那种“建议清理缓存”的万金油话术。另外Codex 是命令行工具所有的交互记录和输出结果都以文本形式展示我可以随时截取中间信息进行核对和验证不会被图形界面的花哨图表带偏。它执行到哪一步、读取了哪些目录、生成了什么脚本整个过程都是透明的这让我在操作之前就能判断它的方案靠不靠谱。2.3 安全边界怎么把握你可能担心让 AI 直接生成清理命令万一它让你执行删除命令把不该删的删了怎么办我的处理原则很明确Codex 只承担“分析”和“推荐”角色不把删除动作直接交给它。像rm -rf这种强破坏性命令我一律不让它自动执行而是让它输出建议清单我自己再一一核实后手动处理。真实的自控权还在我手里Codex 给我的更多是信息和判断依据而不是替我下单。实际操作中我会在提示词里明确加上“只生成分析脚本不要执行任何删除操作”它给出的脚本也只是计算目录大小、输出排序结果根本不会递归去删除文件。控制好这个边界AI 工具就能当成高级分析器来用而不是一个失控的自动化删除器。3. 排查实操87.81GB 是怎么被我定位出来的3.1 第一步先让 Codex 生成磁盘扫描脚本我在命令行里敲下这样一段提示大意帮我写一个 Python 脚本统计 C:\Users\用户名\AppData 目录下所有子目录的占用空间大小按照占用从大到小排序输出前 30 个目录的路径和大小。注意 1. 不要删除任何文件 2. 不要跟随符号链接 3. 输出结果用 GB 或 MB 显示方便阅读。Codex 很快就生成了一段完整的 Python 代码核心逻辑用os.scandir递归遍历目录逐个累计子文件的大小。这里有个关键细节遍历几千个小文件的时候如果每遇到一个文件就单独调用一次os.path.getsize系统调用次数会非常多速度会很慢。而用os.scandir返回的对象直接带stat信息一次遍历就能拿到大小速度能快不少尤其在 AppData 这种小文件数量庞大的目录里效率差距非常大。脚本大致长这样这是简化版重点看遍历逻辑import os from collections import defaultdict def get_dir_size(path): total 0 try: with os.scandir(path) as it: for entry in it: if entry.is_file(follow_symlinksFalse): total entry.stat().st_size elif entry.is_dir(follow_symlinksFalse): total get_dir_size(entry.path) except (PermissionError, FileNotFoundError): pass return total root rC:\Users\你的用户名\AppData sizes {} with os.scandir(root) as it: for entry in it: if entry.is_dir(follow_symlinksFalse): sizes[entry.path] get_dir_size(entry.path) for path, size in sorted(sizes.items(), keylambda x: x[1], reverseTrue)[:30]: print(f{size/1024/1024/1024:.2f} GB {path})这段脚本在真实机器上跑起来有个体会顶层目录还没什么感觉往下递归时速度才开始变慢。因为 AppData 里面的文件数量极其夸张几万个小文件一个个 stat 也是要时间的。我的电脑是固态硬盘跑完全量统计大概用了一分多钟如果机械硬盘可能要更久耐心等就好。跑完输出结果以后数据一出来我确实吃了一惊。排在最前面的是几个我之前根本没注意过的文件夹它们的体积分别是二十多GB、十几GB、几GB全加起来刚好对应上了标题里那个 87.81GB 的总数。这张清单直接改变了我的清理优先级后面所有决策都是围绕它展开的。3.2 第二步让 Codex 帮我识别每个大户拿到 Top 30 列表之后单单看路径也还是不容易判断里面装的是什么。该让 Codex 上场做第二轮分析了。我把输出结果贴给它然后提示这是某台 Windows 机器上 AppData 目录的占用排名列表。请帮我逐条分析哪些文件夹可以放心清理、哪些不能动、哪些需要保留但可以缩小体积。从这里开始Codex 给出的价值就不只是“统计大小”了。它结合文件夹命名规律和软件数据存放习惯逐条给了建议。比如某浏览器缓存目录它会说这种缓存可以在浏览器设置里清除不会影响书签和密码某个开发工具的缓存目录它可以安全清空后续重新拉取依赖即可。有个细节值得提一下Codex 对路径结构非常敏感。你把目录树的上下文给它它就能根据父目录名称和子目录名称的组合关系推断出这个目录的大致归属。比如看到AppData\Local\Microsoft\Edge\User Data\Default\Cache它能准确判断出这是 Edge 浏览器的缓存目录而不是系统关键目录。这个能力比单纯在搜索引擎里搜目录名要灵活得多因为很多第三方软件的目录名根本搜不到靠谱的中文解释。3.3 动手之前的最后一道检查Codex 给出建议后我没有立刻开删而是先做了一次安全核对。具体来说在脚本输出的路径列表里挑出标着“可清理”的目录逐个右键查看属性确认里面的内容跟 Codex 描述一致。比如某个文件夹里确实全是.png、.mp4、.dat混合的聊天缓存和它描述的“聊天文件缓存”能对上某开发工具缓存目录里确实全是一堆 hash 格式的压缩包一看就知道是下载的离线包删了不影响本地项目运行。同时我也手动排除了一些目录比如AppData\Local\Packages里面是各类 Microsoft Store 应用的沙盒数据直接删可能导致应用重置再比如AppData\Roaming\Microsoft\Windows\Start Menu这属于系统级配置删错影响菜单结构。Codex 的初步建议里其实没提到这些危险处理项好在它生成的分析列表只统计未执行删除我自己的核对又拦住了一批风险项。这一步不能省后面第 5 篇里我还会展开说哪些雷千万不能踩。4. 清理实战不同目录的差异化处理方案4.1 能放心清理的缓存类目录先说结论浏览器缓存是最安全的下手对象。Chromium 内核的浏览器缓存存放在AppData\Local\Google\Chrome\User Data\Default\Cache或 Edge 对应的AppData\Local\Microsoft\Edge\User Data\Default\Cache这里的文件本质是“网页资源的本地副本”下次访问同样的网页时会被新的缓存替代。直接删除缓存文件夹不会影响书签、密码、浏览历史最多是下一次打开网页时加载稍慢一点。清理这些缓存的正确姿势是退出浏览器后再删因为浏览器运行时会锁定一部分缓存文件导致删除失败。实测中我在删 Edge 缓存时忘了退程序结果删到一半提示权限不足还得先结束进程再继续。如果你不想手动操作也可以直接在浏览器设置里点击“清除浏览数据”效果类似只是清理层级会包含更多 Cookie 和站点数据影响范围比单纯删 Cache 文件夹要大我倾向于手动精准清。另一类放心清的是各类临时文件比如AppData\Local\Temp。这个目录是系统和软件写临时中转文件的公共位置里面很多文件早就没进程引用了长期没人管就会堆出一个大体积。清 Temp 目录的最稳妥办法是用 Windows 自带的磁盘清理或“存储感知”如果手动删遇到被占用的文件跳过即可不影响后续过程。4.2 需要动手前确认的聊天软件数据聊天软件数据比浏览器缓存敏感得多。微信、QQ 这类应用会把聊天记录数据库、图片、视频、文件统一放在 AppData 下直接删掉某个文件夹就等于丢掉了历史记录和已接收的文件。正确做法是先打开聊天软件的“存储空间”管理功能应用内自带按聊天对象筛选并清理缓存文件的功能该功能只会删除无效的图片缩略图和过期文件不会动聊天记录。按我的实践这种应用内清理通常能腾出 10~30% 的空间剩下的大头是“已接收文件”和“视频”这部分只能靠手动删除中不重要的文件来实现。比如我清理了某个大群里过去两年攒下的视频文件一下就释放了快10GB这些都是缓存手段做不到的。这里有个小技巧查清微信的数据存储位置。新版微信把数据分散在AppData\Roaming\Tencent\WeChat和AppData\Local\微信中如果你在设置里改了文件存储路径旧路径下可能还残留上一份完整数据这种重复数据可以直接清掉旧目录但前提是确认新路径里的数据已经完整迁移。4.3 开发工具的缓存清理如果你的电脑装了开发环境AppData 里藏着几个意想不到的大户。npm-cache是 npm 下载过所有包的本地镜像默认存在AppData\Local\npm-cache体积动辄几个GBpip\Cache是 Python 包安装时的缓存仓库还有 Rust 的.cargo\registry、Yarn 的缓存目录全都悄无声息地躺在 AppData 下。清理这类缓存的原则是确认项目依赖可以重新拉取再动手。比如 C 盘资源吃紧的处理办法是先用npm cache clean --force清空缓存然后运行一次npm install它会自动重新下载依赖。你可能会问清了缓存之后安装速度会不会变慢确实会第一次重建缓存会慢一些但换来的是几个GB的空间这笔账算下来还是值得的。对开发类目录我建议保留结构、只清内容。比如进入\node_modules缓存文件夹直接删除里面的压缩包保留外层目录结构这样不会出现某些工具因为找不到缓存根目录而报错的问题。跟代码有关的缓存目录大多是这样处理比直接整目录删除更稳。4.4 清理完之后的验证清理只是第一步验证更重要。我清完以后第一件事是重启需要用的浏览器和自己能直接验证的软件确认可以正常打开、数据还在。然后把几个项目路径挨个跑了一遍前端项目npm run dev能正常启动Python 环境 import 关键模块没报错微信能正常收发消息。第二件事是再次运行第一步那个统计脚本重新扫描 AppData 体积确认释放空间符合预期。这次跑完87.81GB 的 AppData 降到了 43GB 左右C盘可用空间从不足 5GB 上涨到 40 多GB红盘警告解除系统整体流畅度也有明显改善。第三件事是顺手检查了一遍“存储感知”给它开启自动清理临时文件的周期任务。以后哪怕一个月不动它临时垃圾也不会再像这次一样堆到爆盘。5. 复盘与避坑哪些坑是我这次差点踩进去的5.1 AppData 里绝对不能乱动的目录清理 AppData 最怕的就是删到系统依赖的配置。这里点名几个我这次核对后主动绕开的目录AppData\Local\Microsoft整个目录要小心。它里面有 Windows 的大量运行配置比如Windows\Explorer下的缩略图缓存、WindowsApps下的应用列表误删可能导致桌面图标异常、应用列表丢失。尤其是AppData\Local\Packages它是 UWP 应用的数据沙盒删除后应用设置和登录信息全部重置某些应用还会因为数据目录不完整直接无法启动。AppData\Roaming\Microsoft\Windows\Start Menu也别碰里面是开始菜单的快捷方式。虽然删除也不会导致系统崩溃但会让开始菜单的入口列表变得残缺影响日常使用而且恢复起来很麻烦。最值得警惕的是AppData\Local\Microsoft\Windows\INetCache的上级目录虽然 INetCache 本身只是 IE/Edge 的临时缓存但在它上面的Windows目录里混着大量系统关键文件如果用户误以为整个Windows子目录都是缓存去删后果会非常严重。我的原则是只针对具体识别过的子目录动手绝不对Microsoft这样的父级目录做批量操作。5.2 用 Codex 辅助排查时我踩过的三个小坑第一个小坑是权限问题。Codex 生成的脚本在扫描某些系统保护目录时会遇到PermissionError如果不做异常处理脚本会在中途直接报错退出导致统计结果少算一堆文件。我的脚本里已经加了try...except PermissionError但实际使用中还会遇到AccessDenied、路径过长等情况所以判断扫描脚本好不好用先看它有没有把异常处理写好。第二个坑是符号链接。AppData 下面其实存在不少指向其他磁盘的符号链接如果脚本傻乎乎地跟着链接进去遍历可能把另一个盘的体积也统计进来结果看起来 AppData 占了上百GB实际上真实占用并没那么大。我特别在提示词里强调了“不要跟随符号链接”这一步很关键没加这个约束之前跑出的数据一度虚高到让我白紧张了一回。第三个坑是编码问题。Windows PowerShell 下的默认编码和 Python 的utf-8输出经常对不上脚本打印路径时如果包含中文目录名终端里会显示成乱码。解决方法是启动命令前先设置chcp 65001切换 UTF-8 编码或者在脚本里对输出做encode()处理。这个小细节虽然不影响统计结果但看输出时一头雾水确实影响效率。5.3 一次清理后面怎么防止复发清理这种事治标还得治本。从根上控制 AppData 无限增大的方法有几个我这次一起做了第一给浏览器设置“自动清除缓存”。Edge 和 Chrome 都内置了退出时自动清理缓存的选项打开这个开关以后每次关闭浏览器都会清空浏览缓存长年累月下来能省下不少空间。代价是每次冷启动浏览器会重新加载一些图片资源换来的是少一个不断膨胀的缓存大户值不值看个人取舍。第二把大型软件的存储路径指到其他盘。新版微信、QQ 和不少浏览器都支持修改下载目录在设置里把“文件保存路径”指到 D 盘或 E 盘的空间AppData 自然不会再被塞满。这个操作比定期清理更一劳永逸。第三养成定期扫描的习惯。只要像这次一样把统计脚本保存下来每个月跑一次花不到两分钟就能看到 Top 惹眼目录的变化。有问题早发现不至于等到系统弹出红盘警告才开始加班清理。6. 关于用 Codex 做这件事我的几点真实体会先说结论AI 辅助排查磁盘占用这件事不是“必须用”但用了确实能省时间。我这次从发现问题到定位到 AppData 的 87.81GB再到逐层判断哪些该清、哪些该留整个过程里最耗时的环节不是让 Codex 写脚本而是我自己逐一核对那些危险目录。换句话说AI 把“找到问题”的速度提上来了但“确认风险”这一步还得靠自己的判断力兜底。我个人的体会是Codex 这类工具在处理熟人擅长的技术问题时更像一个高级助理。它能无怨无悔地把几千个目录遍历一遍按大小排出清单还能根据路径结构给出合理的解释这些原本都需要我手动完成。但它的建议只能作为参考因为 AI 并不了解你这台机器上装了哪些软件、哪些数据对你重要而这些信息恰恰是删除决策里最关键的因素。让 AI 做分析和初筛让用户做最终决策这个分工是我这次摸索出来最舒服的姿势。最后分享一个小技巧如果想让 Codex 这类工具在类似场景下表现更好建议把提示词写得越具体越好比如直接告诉它“跳过符号链接”“输出GB单位”“排除PermissionError的目录”这些边界条件。它会因为你的精确输入生成更符合需求的代码减少来回调价的次数。这个经验不光适用于磁盘分析写任何自动化脚本都是同一个道理。如果你现在也顶着一块标红的系统盘不妨试试这个方法第一步找到占用大户第二步搞清楚它是什么第三步再决定动不动它。大多数情况下大文件夹不是不能清是不能闭着眼睛清。用对工具、守住边界C盘爆红这种问题就能从“惊吓”变成“一次能搞定的例行维护”了。