Codex辅助磁盘清理实战：从告急到回收120G的完整指南

1. 磁盘清理这件事为什么值得认真对待1.1 从一次真实的磁盘告急说起大概三个月前我主力工作机的系统盘亮起了红灯。那是一块 512G 的固态装系统、开发工具链、几套本地模型权重、Docker 镜像、各种缓存目录再加上日常随手下载的安装包和素材硬生生被塞到只剩 8G 可用。系统开始频繁弹窗提示空间不足编译大型项目时临时文件写不进去直接报错连浏览器开十几个标签页都开始卡顿。我当时的反应和大多数人一样打开文件管理器按大小排序手动删。删了两轮回收站清空也就腾出来 20 来 G杯水车薪。真正占空间的大头藏在那些名字看起来人畜无害的目录里——包管理器的缓存、构建产物、容器层、日志、旧版本运行时、编辑器索引。这些东西单个看不大加起来能吃掉上百 G。后来我换了个思路与其自己一个个目录去翻不如让 Codex 这类代码智能助手帮我做三件事——扫描定位、分类归因、生成安全的清理脚本。最终这一轮操作下来释放了大约 120G 空间。这篇文章就把整个过程拆开讲清楚包括我怎么跟它配合、哪些目录是重灾区、哪些东西看着能删其实不能碰、以及怎么避免清理一时爽重装火葬场。1.2 这篇文章适合谁看如果你符合下面任意一条这篇内容应该对你有用系统盘或数据盘长期吃紧手动删文件效率低、还怕删错开发机上装了一堆工具链、容器、虚拟环境不知道空间去哪了想用 AI 助手帮忙做系统维护但不确定怎么提问、怎么验证它给的命令单纯想学一套可复用的磁盘分析方法论而不是记几条删除命令。需要先说明一点Codex 在这里扮演的是分析助手 脚本生成器的角色它不会替你点确认所有删除动作最终都要你自己判断、自己执行。这一点很关键后面会反复强调。1.3 核心思路一句话概括整个流程可以概括成一条链路先量化再归因后清理最后固化习惯。量化靠磁盘分析工具归因靠 Codex 帮你读懂每个目录是干什么的清理靠它生成的脚本加上你的人工复核固化则是把清理动作变成定期任务。跳过任何一步要么清不干净要么容易出事。2. 清理前的准备工作与工具选型2.1 先搞清楚空间到底被谁吃了动手删之前必须先有一张清晰的空间地图。我常用的组合是系统自带的磁盘分析加上一两个命令行工具具体选哪个看平台。在 Linux 和 macOS 上du是最基础也最可靠的# 查看当前目录下各子目录占用按大小排序只看前 20 个 du -h --max-depth1 . 2/dev/null | sort -rh | head -20在 macOS 上du的参数略有不同--max-depth要换成-ddu -h -d 1 . 2/dev/null | sort -rh | head -20Windows 上我一般用 WizTree 或 TreeSize 这类图形工具扫描 NTFS 速度很快能直接看到每个文件夹的占比。命令行的话可以用 PowerShellGet-ChildItem -Directory | ForEach-Object { $size (Get-ChildItem $_.FullName -Recurse -File -ErrorAction SilentlyContinue | Measure-Object -Property Length -Sum).Sum [PSCustomObject]{ Name $_.Name; SizeGB [math]::Round($size/1GB, 2) } } | Sort-Object SizeGB -Descending | Select-Object -First 20这一步的产出是一张嫌疑目录清单。我当时的清单里排前面的有容器数据目录、包管理器缓存、几套 Python 虚拟环境、Node 的node_modules汇总、模型权重目录、日志目录、以及一个我早就忘了的旧项目构建产物目录。提示扫描时一定要用管理员/root 权限否则很多系统目录会因为权限不足被跳过统计结果会偏小导致你误判。2.2 为什么选 Codex 而不是纯手动有人会问磁盘清理这种活网上教程一抓一大把为什么还要拉上 Codex我的理由有三个都是实际用下来觉得值的点。第一归因效率。磁盘上很多目录名字很抽象比如~/.cache/xxx、/var/lib/xxx、某个工具链的store目录。你未必记得每个是干什么的、能不能删。把这些路径丢给 Codex它能结合上下文告诉你这个目录通常由什么程序创建、删除后有什么后果、有没有官方推荐的清理命令。这比你自己去搜快得多。第二脚本生成。清理往往不是删一个目录而是几十个目录按规则批量处理。手写脚本容易漏、容易写错路径。让 Codex 根据你的清单生成脚本你再逐条 review效率和安全性都更好。第三风险提示。这是我觉得最有价值的一点。你问它这个能删吗它通常会告诉你哪些是安全的、哪些有风险、哪些绝对不能碰。虽然最终判断还得靠你自己但它能帮你把明显的坑标出来。2.3 工具清单与各自定位工具平台主要用途我的使用频率du / dfLinux/macOS快速定位大目录、看分区剩余每次都用WizTreeWindows图形化扫描速度快Windows 上必用ncduLinux/macOS交互式浏览目录占用经常用Codex跨平台归因分析、脚本生成、风险提示每次都用系统自带磁盘清理Windows/macOS清理系统级缓存偶尔用ncdu值得单独提一句它是交互式的可以像文件管理器一样上下浏览、直接删除比du直观很多# 安装后直接扫描指定目录 ncdu /home注意ncdu里按d是删除手滑很容易误删。我一般只用它来看删除动作还是回到命令行或脚本里做留个复核的缓冲。3. 用 Codex 做归因分析的正确姿势3.1 怎么提问才能拿到有用的答案跟 Codex 配合做磁盘清理提问方式直接决定输出质量。我踩过的坑是一开始只丢一个路径过去问这个能删吗得到的回答往往很泛比如这取决于你的使用情况。后来我改成结构化提问效果明显好很多。我常用的提问模板是这样的我在做磁盘清理系统是 [平台版本]。 下面这个目录占用了 [大小] [完整路径] 请帮我分析 1. 这个目录通常由什么程序或工具创建 2. 里面主要存的是什么类型的数据 3. 直接删除会有什么后果是否可恢复 4. 如果有官方推荐的清理方式请给出具体命令 5. 有没有需要保留的子目录或文件。把平台、大小、路径都给全再明确列出你想要的信息维度它给出的回答会具体很多。尤其是第 4 点官方推荐的清理方式很多时候比直接rm -rf安全得多比如包管理器通常有自己的clean命令。3.2 一次真实的归因对话拆解拿我机器上那个占了大头的容器数据目录举例。我当时把路径和大小发给 Codex它给出的分析大致是这样的我整理后的版本这个目录由容器运行时创建存放镜像层、容器可写层、卷数据、网络配置等直接删除整个目录会导致所有镜像和容器丢失正在运行的容器会异常官方推荐用prune类命令清理未使用的镜像、停止的容器、悬空卷而不是删目录需要保留的是正在使用的卷和镜像这些通过 prune 命令会自动跳过。这个回答帮我避免了一个大坑——我原本真打算直接删目录。后来我用了它给的清理命令先看能回收多少# 先预览能清理多少空间不实际删除 docker system df确认之后才执行清理# 清理停止的容器、未使用的网络、悬空镜像、构建缓存 docker system prune -a --volumes这一条命令下去回收了将近 40G。如果当初直接删目录不仅空间回收效果未必更好还得重新拉镜像、重建容器损失更大。3.3 归因结果的交叉验证Codex 给的分析不能全信尤其是涉及具体路径的时候。我的习惯是做两层验证。第一层是看目录内容。在删之前先ls一下看看里面到底是什么# 看目录结构和文件类型分布 ls -lah /path/to/suspect/dir # 统计文件类型 find /path/to/suspect/dir -type f | sed s/.*\.// | sort | uniq -c | sort -rn | head第二层是查官方文档。对于包管理器、容器、语言运行时这类有明确维护方的工具直接查它的官方清理文档最靠谱。Codex 给的命令我会拿去和官方文档对一遍确认参数含义再执行。提示如果 Codex 给的命令里有rm -rf且路径里带变量或通配符一定要格外小心。我一般会先把命令里的rm换成echo或ls跑一遍确认展开后的路径是我想要的再真正执行。4. 重灾区目录逐个拆解4.1 包管理器缓存最安全也最容易被忽略各类包管理器的缓存是我清理时最先动的地方因为删了几乎没风险最多是下次装包时重新下载。Python 的 pip 缓存# 查看缓存大小 pip cache dir pip cache info # 清理全部缓存 pip cache purgeNode 的 npm/yarn/pnpm 缓存npm cache clean --force yarn cache clean pnpm store prune系统包管理器以 Debian 系为例# 清理已下载的安装包 sudo apt clean # 清理不再需要的依赖 sudo apt autoremove我这一轮从 pip 和 npm 缓存里回收了大概 15G。这些缓存的特点是用的时候自动重建所以清理心理负担最小。唯一要注意的是如果你网络环境下载慢清空后重新装包会花时间可以权衡一下。4.2 容器与虚拟化空间黑洞容器相关的空间占用往往是最惊人的因为镜像分层、卷、构建缓存都会累积。前面提到的docker system prune是主力手段但执行前要搞清楚几个概念。docker system df会列出四类占用Images镜像、Containers容器、Local Volumes本地卷、Build Cache构建缓存。其中悬空镜像dangling images没有标签、没有被任何容器引用的中间层可以放心删未使用的镜像没有被容器使用的删了下次要用得重新拉停止的容器确认不需要了再删卷这个要小心卷里可能有你的数据删之前务必确认。分步清理比一把梭更稳妥# 第一步只清理悬空镜像和构建缓存风险最低 docker image prune docker builder prune # 第二步确认没有需要的停止容器后清理停止的容器 docker container prune # 第三步确认卷数据不需要后再清理未使用卷 docker volume prune虚拟机镜像、WSL 的虚拟磁盘、模拟器镜像也是类似的重灾区。WSL 的虚拟磁盘文件会随着使用不断膨胀即使你在里面删了文件磁盘文件也不会自动缩小需要手动压缩# 关闭 WSL 后压缩虚拟磁盘 wsl --shutdown Optimize-VHD -Path 路径\ext4.vhdx -Mode Full4.3 开发工具链与构建产物这一块是最容易温水煮青蛙的。每个项目目录下的node_modules、target、build、dist、.next、__pycache__加起来能占几十 G。我的做法是写一个扫描脚本找出所有项目里的构建产物目录按大小排序然后决定哪些项目近期不用、可以清掉构建产物# 找出 home 下所有 node_modules 目录并统计总大小 find ~ -type d -name node_modules -prune 2/dev/null | while read dir; do du -sh $dir 2/dev/null done | sort -rh | head -20Python 的虚拟环境也是大头。我习惯把不用的虚拟环境直接删掉需要时用requirements.txt重建# 列出所有虚拟环境及其大小 find ~ -type d -name venv -o -type d -name .venv 2/dev/null | while read dir; do du -sh $dir 2/dev/null done | sort -rh注意删虚拟环境前确认项目里有requirements.txt或pyproject.toml否则重建会很痛苦。我吃过这个亏有个小工具项目的依赖没导出删了环境后花了一晚上才把版本凑齐。4.4 日志、缓存与临时文件系统日志、应用日志、浏览器缓存、编辑器索引这些单看不大但日积月累很可观。系统日志Linux# 查看 journal 日志占用 journalctl --disk-usage # 只保留最近 7 天 sudo journalctl --vacuum-time7d # 或限制总大小 sudo journalctl --vacuum-size500M编辑器索引比如 VS Code 的缓存目录、JetBrains 系列的caches和index目录这些删了之后编辑器会重建索引代价是下次打开项目慢一点但空间回收明显。浏览器缓存直接在浏览器设置里清或者找到缓存目录删。这类数据删了不影响登录状态和书签只是下次访问网站要重新下载资源。4.5 模型权重与数据集删之前想清楚如果你本地跑过模型权重文件动辄几个 G 到几十 G。这部分我建议不要轻易删因为重新下载成本高尤其是大模型。我的处理方式是把不常用的权重移到外置硬盘或网络存储而不是直接删。如果确实要删先确认这个模型你近期不会再跑并且有办法重新获取。数据集同理。很多数据集下载一次要很久删之前想清楚。我一般会给数据集目录做个清单标注每个数据集的大小和用途定期 review 哪些可以归档。5. 实操全流程从扫描到回收 120G5.1 第一步全面扫描建立空间地图我用的是一条组合命令先看整体分区情况再逐层下钻# 看各分区剩余空间 df -h # 从根目录开始逐层找大目录 sudo du -h -d 1 / 2/dev/null | sort -rh | head -20假设发现/home占用最大就继续下钻sudo du -h -d 1 /home 2/dev/null | sort -rh | head -20一层层往下直到定位到具体的大目录。这个过程有点像剥洋葱每一层都缩小范围。我当时的路径是/→/home→/home/user→ 几个具体的缓存和项目目录。5.2 第二步把嫌疑目录清单交给 Codex扫描完我整理出一张清单大概长这样/home/user/.cache 45G /home/user/.local/share/containers 38G /home/user/projects 52G其中构建产物约 30G /var/log 8G /home/user/.npm 6G /home/user/.cache/pip 5G然后我把这张清单整体发给 Codex让它帮我分类哪些是缓存可以安全清、哪些是数据要谨慎、哪些是构建产物可以重建。它给出的分类结果和我预期基本一致但有几个目录它提醒了我风险比如.local/share/containers里可能有正在使用的卷。5.3 第三步生成清理脚本并逐条复核基于分类结果我让 Codex 生成一个分阶段的清理脚本。它的输出我做了大幅修改最终版本大致是这样的结构#!/bin/bash # 磁盘清理脚本 - 分阶段执行每阶段执行后检查效果 echo 阶段 1包管理器缓存低风险 pip cache purge npm cache clean --force sudo apt clean sudo apt autoremove -y echo 阶段 2容器清理中风险需确认 docker system df read -p 确认清理容器资源(y/n) confirm if [ $confirm y ]; then docker image prune -f docker builder prune -f docker container prune -f fi echo 阶段 3日志清理 sudo journalctl --vacuum-time7d echo 阶段 4构建产物需手动确认项目 echo 请手动检查以下目录后决定是否删除 find ~/projects -type d -name node_modules -prune 2/dev/null | head -20 echo 清理完成当前磁盘状态 df -h这个脚本的关键设计是分阶段 交互确认。低风险的缓存直接清中风险的容器和构建产物加确认步骤避免脚本一跑到底误删东西。提示脚本里所有rm -rf我都改成了先echo或find列出确认无误后再手动执行删除。这个习惯帮我避免过至少两次误删。5.4 第四步执行与效果验证执行过程我是一阶段一阶段来的每阶段跑完都df -h看一下回收了多少。阶段 1包管理器缓存回收约 15G阶段 2容器清理回收约 40G阶段 3日志回收约 6G阶段 4构建产物手动清理了几个不用的项目回收约 55G其他零散清理浏览器缓存、编辑器索引、旧安装包约 4G。加起来大约 120G。整个过程花了大概一个半小时其中大部分时间在复核和确认真正执行删除的时间很短。5.5 第五步把清理变成定期习惯一次性清理完过几个月又会满。我的做法是设几个定期任务每周自动清理包管理器缓存和日志每月 review 一次构建产物和虚拟环境每季度做一次完整的空间扫描。Linux 上用 cronWindows 上用任务计划程序。定期清理的好处是每次量不大心理负担小也不容易积累到需要大扫除的程度。6. 常见问题与避坑经验6.1 清理后系统出问题怎么办这是最让人担心的情况。我的经验是清理前做好备份尤其是配置文件和数据目录。缓存类的东西删了无所谓但如果你不确定某个目录是不是缓存先备份再删。如果真的删错了导致程序异常大多数情况下重装对应软件或重建环境就能恢复。真正难恢复的是用户数据所以数据目录文档、代码、数据库文件永远不要纳入自动清理范围。6.2 常见问题速查表问题现象可能原因排查与解决清理后空间没变化文件被进程占用删除后空间未释放重启相关进程或系统容器清理后镜像没了误删了正在使用的镜像重新拉取镜像虚拟环境删了项目跑不起来依赖未导出从 requirements 重建WSL 磁盘不缩小虚拟磁盘未压缩用 Optimize-VHD 压缩日志清理后服务报错删了正在写入的日志重启服务配置日志轮转清理脚本报权限错误没用管理员权限加 sudo 或提权执行6.3 几条用血泪换来的经验第一永远不要在生产环境直接跑清理脚本。先在测试机或虚拟机里验证确认没问题再上生产。我有次在服务器上直接跑结果把正在用的日志删了排查问题的时候没有日志可查非常被动。第二删除命令先 dry-run。把rm换成ls或echo看看实际会删哪些文件。这一步花不了几秒钟但能避免大事故。第三给重要目录加保护。可以在脚本里加白名单或者用chattr i给关键目录加不可删除属性Linux。这样即使脚本写错了也不会误删。第四记录清理日志。每次清理都记下删了什么、回收了多少方便回溯。万一后面发现某个东西不该删至少知道是什么时候删的。第五别迷信 AI 给的命令。Codex 很有用但它不了解你机器的具体状态。它给的命令一定要自己看懂再执行尤其是带删除操作的。我一般会问它这条命令具体做了什么每个参数什么意思确认理解后再跑。6.4 关于 Codex 使用的几点心得用下来我觉得Codex 在磁盘清理这个场景里最大的价值不是替你操作而是帮你理解。它能把一个陌生目录的来龙去脉讲清楚能根据你的描述生成结构化的脚本能在你拿不准的时候给出风险提示。但它不会替你承担删错的责任所以最终判断权必须在你手里。提问的时候尽量给全上下文平台、路径、大小、你的使用场景。信息越全它的回答越准。反过来如果你只丢一个路径问能删吗得到的回答通常很泛参考价值有限。另外它给的清理命令我会习惯性地拿去和官方文档对一遍。这不是不信任而是因为工具的版本更新很快命令参数可能变化官方文档永远是最准的。7. 最后分享几个实用小技巧清理磁盘这件事做多了会形成一些顺手的小习惯这里挑几个我觉得最实用的分享出来。第一个是用别名简化常用命令。我在 shell 配置里加了几个别名比如diskscan对应那条du排序命令bigfiles对应查找大文件的命令。用的时候敲几个字母就行省得每次翻笔记。# 加到 ~/.bashrc 或 ~/.zshrc alias diskscansudo du -h -d 1 / 2/dev/null | sort -rh | head -20 alias bigfilesfind . -type f -size 500M -exec ls -lh {} \; 2/dev/null | sort -k5 -rh第二个是给清理动作分级。我把清理分成随时可做缓存、日志、需要确认容器、构建产物、谨慎处理数据、权重三级日常只做第一级第二三级攒到一定量再集中处理。这样既不会让空间失控也不会频繁打断工作。第三个是关注那些隐形的大文件。有些文件在文件管理器里不显眼但实际很大比如休眠文件、交换文件、崩溃转储、旧的内核版本。这些用find按大小筛一下就能找到# 找出系统里大于 1G 的文件 sudo find / -type f -size 1G 2/dev/null -exec ls -lh {} \; | sort -k5 -rh第四个是定期检查而不是等到告急。我现在养成了每月初花十分钟扫一眼磁盘的习惯发现异常增长就及时处理。等到系统弹窗告急才动手往往已经积累了很多清理起来费时费力。这套流程用下来我的机器再没出现过空间告急的情况。Codex 在其中扮演的是懂行的顾问帮我把看不懂的目录翻译成人话把重复的清理动作变成脚本。真正做决定的还是自己但有了它的辅助这个决定做得更快也更稳。