磁盘满这个事估计每个写代码的人都经历过。我这台工作机系统盘 500G平时也没装多少电影游戏结果某天编译一个项目直接提示 no space left on device才发现磁盘已经亮红灯了。之前清理磁盘全靠手动一个目录一个目录地du、find、rm费时间不说还总怕删错东西。这次我换了个思路把清理过程交给 Codex让它帮我分析占用、找出可以安全清理的文件、生成清理脚本我和它来回确认后才真正执行。整个过程差不多一个下午的时间最后腾出来 120G 空间。这篇文章就把完整的思路、命令和踩过的坑都写出来。对于已经装了 Codex 环境、平时会用命令行的朋友可以直接按后面的步骤操作如果只是听说过 AI 编程助手、想看看它到底能不能干这种系统维护的活这篇也能给你一个很具体的参考。清理磁盘看着简单但真正做起来最难的不是执行而是判断哪些该删、哪些不该删。Codex 最擅长的恰好是这个判断环节的辅助。1. 为什么我会选择 Codex 来清理磁盘1.1 手动清理的老套路为什么效率低以前遇到磁盘满我的习惯操作是df -h du -h --max-depth1 / 2/dev/null | sort -hr | head -20看到哪个目录大就层层往下钻再用ls -lS找大文件。这种办法有效但有两个明显问题。第一是慢。磁盘上的大目录往往藏在很深的层级里比如某个容器数据目录、某个日志目录、某个缓存目录靠肉眼一层一层往下戳能戳半天。第二是与上下文脱离。du只告诉你哪个目录占多少空间不告诉你这个目录是什么应用在用、里面的文件能不能删、删了以后会不会影响正在跑的服务。我经常遇到这种情况查到一个目录好几个 G看了半天也没想明白它什么来路只能放着不敢动。1.2 Codex 在清理场景里能提供什么Codex 这类 AI 编程助手平时大家可能都拿它写业务代码、改 bug但它底层的能力是理解自然语言、生成并执行命令。清理磁盘正好是一个非常适合它发挥的场景因为这件事本质上不是技术难度高而是信息密度太高系统里有哪些占用空间的角落哪些缓存是应用运行中必然会生成、删掉也没事的哪些旧日志只是历史遗留、早就没有保留价值哪些文件虽然很大但可能被某个服务引用删了会引发连串问题。这些判断需要结合系统知识、应用习惯和实时反馈。Codex 可以一边执行一边读结果根据du、find的输出继续追问缩小范围。我只需要负责最终拍板它负责把“分析-建议-验证”这个循环跑起来。1.3 我和 Codex 定的合作方式在实际开工之前我先给自己定了几条原则所有删除操作都不让 Codex 直接执行而是让它先生成清理脚本我审查以后自己跑对不确定的文件先用mv移到临时目录而不是rm直接删每条删除动作都要有可解释的理由Codex 需要说明这个文件是什么、为什么可以删操作之前先把关键数据备份到手头避免意外。这几条原则很重要。AI 再聪明也是基于数据训练的它不可能知道我本机上某个具体文件是不是有特殊用途。把决策权留在自己手里才能既享受它的效率又保证安全。2. 核心实操从诊断到释放 120G 的完整流程2.1 让 Codex 盘一盘磁盘整体占用我一开始只给了它一条指令我磁盘快满了帮我看看系统盘空间都耗在哪了。Codex 先跑了df -h确认/的占用率已经到了 94%。然后它执行了下面的命令把根目录下第一层子目录按大小排序du -x -h --max-depth1 / 2/dev/null | sort -hr | head -30这里用-x是为了不跨文件系统避免把/proc、/sys这种虚拟目录也统计进去2/dev/null是为了屏蔽掉那些没有权限访问目录的报错否则刷屏会严重影响判断。输出结果里占用最大的几个目录是目录占用大小初步判断/var96G日志、容器数据、缓存/home78G用户数据需要细分/usr32G系统程序/opt28G第三方软件Codex 没有急着给出结论而是先做了一步很关键的操作把这两个目录再往下多挖两层。du -x -h --max-depth2 /var 2/dev/null | sort -hr | head -20 du -x -h --max-depth2 /home 2/dev/null | sort -hr | head -20这一步给我的体验最好。普通人的思路可能是“马上找到大文件然后删掉”但 Codex 的思路是“先在地图上找热点区域再做局部细查”这和我平时排查问题的节奏是完全一样的。很快它就发现两个重点对象/var/log占了 31G/home下的某个隐藏缓存目录占了 42G。2.2 找大文件和重复文件当磁盘空间告急时除了目录级的“面”统计还需要文件级的“点”统计。我要求 Codex 去找全系统里大于 1G 的文件。find / -type f -size 1G -exec ls -lh {} \; 2/dev/null | sort -k5 -hr | head -40这里用了-exec ls -lh来把文件大小同时显示出来再用sort -k5 -hr按第五列大小排序。虽然find -printf更高效但 Codex 选的这个方案在可读性上更好也方便我逐个人工确认。另外它还发现了一个我之前容易忽略的点重复文件。开发环境下我习惯在多个目录各留一份项目压缩包、镜像备份时间一长同一个压缩包可能在三四个地方都存在。Codex 直接调用了fdupes工具fdupes -r /home /var/tmp /opt 2/dev/null | less如果你系统里没有 fdupes可以用rdfind或者干脆用find -type f -exec md5sum {} \;再sort但后者的效率在大目录上会很慢。建议有需要的话先安装 fdupes它专门做重复文件查找速度要快很多。2.3 细查系统日志和缓存在/var/log占了 31G 这个结果出来以后Codex 很快就定位到了几个大头。先看journalctl占用的系统日志journalctl --disk-usage结果输出Archived journals: 14.2G。这意味着整个日志系统里光 journald 就囤了 14G 的日志。对一台个人工作机来说这显然过量了。我用 Codex 给的命令把 journald 的限制改到 200M并手动清了一次旧日志journalctl --vacuum-size200M然后它又盯上了/var/log里持续增长的软件日志比如某个开发工具的调试日志一个文件就 8 个 G。像这种日志只要当前没有进程在写其实完全可以删掉因为日志本身就是文本删了以后下次启动会自动新建。缓存环节是我这次拿到的最大一块空间。Codex 帮我逐个检查了常见的缓存目录最后统计出来的结果是这样的缓存目录大小清理方式~/.cache/pip11Gpip cache purge~/.npm/_cacache9Gnpm cache clean --force~/.cache 其他工具缓存12G手动确认后删除/var/cache/apt6Gapt cleandocker 相关残留15G清理悬空镜像和构建缓存每个目录为什么能删、删了之后能不能自动重建Codex 都给了明确说明。比如说 pip 的缓存它的作用是“避免重复下载安装包”删掉以后只是下次安装包的时候重新下载一遍本地已经装好的环境一点影响都没有。npm 也是同样逻辑。2.4 生成清理方案分优先级执行Codex 把找到的清理项整理成了一份清单并标了风险等级。我把其中一部分摘录成一个简化版清理项预估释放风险等级理由journald 旧日志14G低系统日志无需保留/var/log 下软件日志8G低可重建pip/npm 缓存20G低仅下载缓存/var/cache/apt6G低可自动重建docker 悬空镜像15G中确认容器未依赖后删重复的备份压缩包26G中保留一份即可/home 下缓存文件42G中逐个确认这份清单累计加起来已经超过 120G。但这只是“看起来很美好”的预估真正执行的时候还得一步步来。我先让 Codex 把每个待删除的目录路径打印出来我再逐一核对这些路径是否真的对应我预期中的文件。核完之后我手动执行了第一批低风险的清理命令因为这部分操作简单而且可逆性高journalctl --vacuum-size200M pip cache purge npm cache clean --force sudo apt clean执行完后再跑一遍df -h发现可用空间已经多出 30 多 G。剩下那些中风险的就麻烦一点比如重复压缩包我不能用一个命令全删而是前后对比文件列表确认保留的是最新、最完整的那一份。docker 悬空镜像也检查了镜像被哪些容器引用只删掉了引用关系为空的那些。最终统计下来实际释放了 120G 多一点。我在清理前后分别记录过df -h的输出所以这个数字可以精确到 G。3. 清理过程中的安全底线与核心避坑3.1 删除之前先过一遍“可重建性”判断很多人在清理磁盘的时候容易犯一个错误就是只看到“大”就想删。实际上真正安全的判断标准不是“大不大”而是“删了以后能不能自动重建或者我有没有备份”。我把清理对象分成了三类可自动重建缓存、日志、临时文件删了以后应用会自动重新生成安全有备份版本重复的压缩包、旧镜像确认手头有保留版本后可以删风险取决于备份的完整性不可重建且无备份比如自己写了一半没提交的代码、某次现场拷回来的素材这类文件不管多大都不能只因为空间紧张就处理。Codex 在这三类的判断上帮了我大忙。它会主动询问“这个文件是否有备份”或者“这个目录是否还在使用”有些时候它的建议甚至会偏向保守比如在删某个旧版本工具链时提示我“最好先确认软件管理器里没有依赖它”。我觉得这正是 AI 协助运维时该有的态度。3.2 永远先 dry-run 或 mv 到临时目录如果你只在命令行里用rm -rf一条命令删大目录那是把全部信任都交给了“路径输得对”这一件事。我这次遇到一个有惊无险的场景Codex 建议删除某个工具的历史版本目录结果在打印出来的路径列表里我发现有个目录的路径开头少了一个层级。如果直接执行脚本极大概率会把不该删的同名目录一起处理掉。所以后来我跟 Codex 的约定改成了一个硬性规则对于任何涉及多个文件的删除操作必须先执行“预演”。所谓预演有两种做法。一是把rm换成ls或者du先看这条命令会命中哪些路径。例如# 先看会删除哪些 find /path/to/target -type f -name *.tmp -ls # 确认无误后再删 find /path/to/target -type f -name *.tmp -delete二是用mv把目标移动到一个专门建的临时回收目录观察几天确认系统一切正常后再清空。mkdir -p /tmp/trash_for_clean mv /path/to/doubtful /tmp/trash_for_clean/这种方式比直接rm安全得多。虽然在“立刻释放空间”这个目标上会打点折扣但换来的是一层实实在在的后悔药。3.3 权限问题不要一股脑上 sudo清理磁盘过程中十有八九会遇到Permission denied。很多人的第一反应是“那我 sudo 一下不就行了”我的经验是不要让 Codex 在分析阶段就使用 sudo更不要让它直接拿 sudo 去批量删除。分析阶段用普通权限跑就足够看到 99% 的共识目录。遇到权限不足的时候应该先把路径打印出来人工确认这个路径到底是什么。比如/var/log下有些日志是 root 所有但删除它们并不需要把所有相关文件都交给 sudo只需要把最终确定的、明确需要删除的几条命令加 sudo 执行即可。Codex 在这一点上表现得很细致它会把需要权限的操作单独列出来而不是直接把整条分析命令都加上 sudo。这种做法值得推荐因为sudo find / -type f -delete这种命令一旦路径写错后果完全不可控。3.4 删完空间没有立刻释放是怎么回事清理过程中我遇到过一个比较蹊跷的情况明明删掉了 2G 的文件df -h显示可用空间只增加了 500M。Codex 很快反应到可能是“文件仍被进程占用”。Linux 下文件被进程打开以后即使你把它从目录里移除空间也不会真正释放直到所有引用它的进程关闭句柄。解决办法是找到哪些进程还在占用它lsof L1 | grep deleted这里的L1表示显示 link count 为 0 的文件也就是已经被删除但还在被占用的文件。如果看到有进程的 deleted 文件占着大量空间重启该进程或关掉对应服务后空间才会回来。这个坑容易出现在日志文件上。比如某个服务一直在写日志你把日志文件rm了服务进程还握着它的文件描述符物理空间一直被占着。处理办法要么是service xxx restart要么用truncate清空而不是删除。Codex 给的建议是对于日志文件最好用truncate -s 0 /path/to/log或 /path/to/log这样既清空了内容又不影响正在写入的进程。4. 常见问题与排查技巧实录4.1 Codex 的建议我不敢直接执行怎么让它更保守如果你和我一样对自动删除心有余悸最简单的方式是在最开始就把“边界条件”告诉它。比如我第二次用 Codex 清理另一台机器时直接在提示词里加了这几条约束只生成命令不要自动执行 删除前必须给出文件路径、大小、理由 遇到不确定就问我不要猜。效果差很多。Codex 在明确约束下的行为会保守很多它会把“分析”和“执行”阶段明确分开。实际操作中提示词写清楚比事后反复纠正它的错误要省心得多。这里也顺便分享一个小技巧让 Codex 把所有待处理文件的路径输出到一个文本文件里然后我再cat这个文件逐行过一遍。这样一来它有哪些建议、哪些是我真正批准过的全程都有记录。4.2 识别“看着像垃圾但其实是配置”的文件AI 清理工具最容易犯的错就是把一个看起来名字像缓存的目录当成缓存。我这次差点踩中的例子是在/home下有个目录叫.appcache里面足足占了 12G。如果按名字理解肯定觉得是缓存可以删。但 Codex 在我追问之后发现这个目录其实是一个应用的本地备份库里面存着我重要的项目状态删了之后应用虽然能重新生成一份但历史状态全丢。怎么判断让 Codex 多给信息。它会建议用ls -la看目录最后的修改时间用file看文件类型用head看文件开头内容综合这些信息再判断。我最后的结论是最少见的“垃圾文件”往往是某些老程序的残留缓存而不是名字里带 cache 的东西。所以我的原则是任何目录在被分析为“可删除”之前都必须有一个“访问时间在很久以前”或者“所属应用已知”这样的条件做支持。凭空出现的可疑目录不值得为省那几 G 去冒风险。4.3 清理完以后软件运行异常怎么办理论上遵循“可重建 有备份”原则清理后软件不会出问题。但凡事总有例外。我清理完第二天发现某个命令行工具启动时会报Cant open cache directory的警告。原因是那个工具希望缓存目录存在而我把它删了以后工具本身没有自动创建的逻辑。解决办法很简单手动建回目录并给对应权限mkdir -p ~/.cache/that-tool这类问题在删除“自定义路径”的缓存时比较常出现。标准工具的缓存目录都会有自建逻辑但一些小众工具做得不那么完善。遇到这种情况不用慌把报错信息丢给 Codex它通常能很快指出是哪个目录缺失。基于这个经验我后面的清理策略做了一个调整删缓存之前先快速看一下缓存目录里有哪些子目录把工具名记录下来。如果工具不多可以完全不删反正重新生成的代价也就是几百 M 的空间。5. 这次磁盘清理带给我的另外几个收获5.1 重复文件比大文件更容易被忽略清理出 120G 空间最大头其实是重复文件。我一开始把注意力都放在缓存和日志上没想到真正占地方的是散落在各处的重复压缩包和备份镜像。它们单个可能都不到 1G但叠加起来非常可观。这个发现让我开始重视“重复文件扫描”这个步骤。如果你是手动清理建议每次磁盘紧张的时候都先跑一遍fdupes或类似工具。如果你用 Codex它会主动建议你去做这件事而且会帮你过滤掉一些不该合并的目录比如两个不同项目的同名文件虽然内容一样但目录结构不同不一定适合去重。用 Codex 去重的时候我习惯把它的输出按目录分组后再人工确认重点看“是否在同一项目的同一层级下重复”。跨项目的重复文件我倾向于保留因为每个项目目录最好独立完整。5.2 定期维护比一次性大扫除更省心释放 120G 之后我把清理命令整理成了一个可重复执行的脚本每次磁盘占用超过 80% 就跑一遍。脚本内容其实很简单# 日志与缓存快速清理低风险 journalctl --vacuum-size200M pip cache purge npm cache clean --force docker system prune -f然后又让 Codex 写了一个“大文件周报”脚本每周开机时自动扫描并输出一个文件列表我扫一眼就放心了。定期维护的价值在于很多“垃圾”刚产生的时候很小不够引起注意但一旦攒了几个月量就非常可观。每周花五分钟清理比每半年花一个下午去赌“这次不要删错”要轻松得多。5.3 对 AI 协助系统维护这件事的看法如果你是第一次尝试我的建议是别一上来就让它处理根目录先给它一个特定的、范围明确的目录比如~/downloads或者/var/log。范围越小AI 判断越精准你也越容易理解它在干什么。等建立起信任感以后再逐步扩大范围效果会好很多。我在这次清理中最大的体会是Codex 不是替我做了清理而是把我的想法用更快的速度、更完整的信息密度去验证。多数时候我还没想清楚“这个目录到底哪里占空间”它已经把相关证据摆出来了。但最终决定删除动作的还是我自己。最后再分享一个小技巧清理完磁盘后建议把这次所有的命令和结果沉淀成一个简单的 Markdown 笔记放到自己的知识库里。下次不管是自己用还是帮朋友看电脑直接翻出笔记就能复制命令。我这次就是靠着一份笔记给朋友的同款场景又省了一个多小时。一条命令的价值只有在现场用过才会被放大。如果以后 Codex 类工具能接入文件系统的事件监听也许能更进一步让磁盘占用从“出问题再来救火”变成“日常自动发现并提醒”。但目前这个阶段我更推荐大家把它当成一个“带监督的智能助手”效率和安全性都能兼顾。希望这份清理经验能帮你从磁盘告警里解脱出来。