下午五点半正打算收工回家系统突然弹了个磁盘空间不足的警告。我的工作机是台 512G 的笔记本平时自觉挺爱干净可当时一看可用空间只剩 3.2G眼看着就要变成只读模式。以前遇到这种情况我基本是开终端 du / df 一层层往下钻翻完缓存翻构建产物折腾一个多小时也就清出几个 G。那天实在不想手动查了顺手把 Codex 丢进终端让它帮我看看到底是什么东西把磁盘吃满了。结果它不光定位了罪魁祸首还主动生成了一份清理脚本前前后后帮我腾出来 60 多 G 的空间属实 Nice。这篇文章就是把这次实操完整复盘一遍怎么给 Codex 下需求、怎么约束它先分析后动手、哪些地方容易翻车、以及事后我怎么把这套流程固化成定期体检的方案。如果你也是每到月底磁盘就告急的开发或运维这篇应该能直接抄作业。1. 磁盘告急的那天为什么我会想到找 Codex 帮忙1.1 传统清理路径的问题在于数据到了判断没到先说手动流程。最基础的是 df -h 看整体水位再用 du -sh 搭配 sort 从大到小排目录。这一步本身不难难的是你拿到排名之后得自己凭经验判断哪些能删、哪些不能删。比如缓存目录占了 78G你砍掉固然可以但某些应用下次启动又得重新生成缓存慢不说个别冷门软件还可能因为缓存异常直接抽风。再比如依赖目录和构建产物删了能救急可一重建又是半小时起步。市面上确实有更直观的工具像交互式的磁盘分析器能用树状图把各个目录的占用画出来。这类工具解决了哪里大的问题但还是把能不能删留给用户。我每次打开它都要在一堆密密麻麻的色块里回忆这个目录是什么项目留下来的那个目录是不是还在被某个服务占用说白了磁盘清理大多数时候不是技术难题而是一个高强度的心智负担问题——尤其在你对着一个占满了一半盘的目录发呆的时候。1.2 Codex 的差异在于理解意图之后还能闭环执行这次试下来Codex 和传统工具最大的区别不是它跑得快而是它能同时做三件事。第一它读得懂模糊指令。帮我看下磁盘被什么占了这种话普通命令工具听不懂但 Codex 能把它拆成几步先扫目录层次、再算体积、再按常见套路圈出可疑对象。第二它能直接执行命令并迭代。发现某个目录异常大它能主动进去再细分而不是让我手动敲第二次命令。第三它会解释每一步并产出报告。清理过程中它同步了每个操作的路径、动作和释放空间这给了我做审计的底子。打个比方普通工具等于一张体检报告能告诉你哪个指标超标Codex 更像一个带操作证的实习生能自己测、自己分析、把重点圈出来还会写一份处置建议。你要做的是在它圈出的重点上做最终决定。1.3 适合与不适合的场景先说清楚不过也得泼盆冷水不是所有盘都能交给 AI 代理清理。场景是否建议原因个人工作机的缓存、日志、构建产物推荐损失可接受重建成本低开发环境里的依赖缓存npm/pip/容器镜像推荐删了能重新拉取生产服务器上的数据库文件不推荐业务数据误删后果不可逆加密卷、离线备份盘、挂载存储谨慎权限模型复杂删除前必须人工复核inode 严重不足的小文件海量场景谨慎需要专项排查常规大文件优先思路无效我这次处理的是第一和第二种属于低风险高回报的类型。如果你的需求落在后面几行我的建议是先用 Codex 做分析报告删除动作全部改用手动确认别让它一步到位。2. 动手前先定边界让 Codex 不跑偏的话术与规则2.1 先给它一张安全边界清单AI 清理代理的问题不是不聪明而是它没有你的业务上下文。它不知道某个历史归档目录是你绝对不能丢的东西也不知道某条日志是你排查线上问题唯一的线索。所以动手之前我会先给它一张边界清单明确什么不许碰。我常用的几条规定系统目录/usr、/bin、/etc、/System 这类一律只列不改。数据库数据目录、配置目录只统计体积不进入任何删除候选。用户目录下优先看缓存、临时文件、构建产物、下载目录里的旧压缩包。所有删除动作在正式执行前必须先输出完整清单等我确认。不确定用途的文件一律标记为人工确认不要顺手归类成垃圾。这些条件看起来保守但它是后面所有操作的安全垫。Codex 这类代理默认是尽量满足你的你越早把边界说清楚它就越不会在某个模糊指令下做出激进操作。2.2 可以直接抄的初始提示词我第一次执行时的提示词长这样可以对照着改你是我的磁盘清理助理。请严格按下面的规则工作 1. 先用 du/df 做整体盘面分析输出目录级别占用排行 2. 在排行中标注每个候选目录的用途分类缓存、日志、构建产物、容器层、个人数据、系统数据 3. 对每个候选目录给风险等级低可安全删除中删除后需要时间重建高不确定或可能影响数据必须人工确认 4. 禁止修改 /usr、/bin、/etc、/System 下的任何内容 5. 禁止删除任何数据库数据文件、配置文件 6. 输出一份清理计划包含要删除的具体路径、文件数量和预估释放空间等我确认后再执行 7. 执行删除前先以 dry-run 方式跑一遍展示将要删除的内容确认无误再正式执行 8. 每一步操作都要汇报并给出当前可用空间变化。这条提示词的核心是第 6 和第 7 条先出计划、再 dry-run。后面我会讲我所有翻车经历几乎都发生在跳过这两步的时候。2.3 一个心法让它先汇报再动手给 Codex 下需求心态上就像给新来的实习生派活。你不会让一个刚上手的人直接删数据库备份而是让他先整理一份清单你把关之后再说。AI 代理也一样先汇报再动手不是效率低而是把判断权留在人手里。我习惯把这条心法类比成去医院医生不会不看检查报告直接开刀一定是先做检查、看指标、出方案再让你签字确认。磁盘清理看着是小手术但小手术也是手术。我吃过一次亏没设确认环节让它直接清空超过 30 天的日志结果它把某个服务正在用的轮转日志也删了那服务当天下午就异常。后面我会在翻车篇详细讲这个案例。3. 实测一遍从磁盘画像到清理脚本的完整链路3.1 第一步全盘扫描拿到磁盘地图提示词发出去之后Codex 的第一轮操作是先摸清整体状况。它会跑一组类似 df -h 和 du -sh 的命令把分区的使用率、容量和可释放空间先列出来然后按目录层级逐层统计占用。我这边大概扫了五分钟输出结果大致是这个样子目录名做脱敏处理Filesystem Size Used Avail Capacity Mounted on /dev/disk3s5 512G 472G 3.2G 99% / 扫描完成最大目录排行 /Users/me/work/archive 86G 历史项目归档 /Users/me/Library/Caches 78G 各类应用缓存 /Users/me/Projects/app-b/deps 42G /Users/me/Projects/app-a/build 24G /var/log 28G ...看到排行那一刻我大概就明白为什么平时总觉得没干啥就满了——大头全部集中在历史归档、缓存和依赖目录属于典型的细水长流型吃盘。这个过程里 Codex 还会边扫边解释比如它发现某个目录里散落了上千个小文件会单独提示我注意文件数量而不是只看总体积。3.2 第二步按风险等级给候选对象分类扫描完成后Codex 会按照我提示词里的规则把候选目录逐一分级。这一步是整轮清理里最有价值的部分因为它把能删什么从经验变成了结构化的清单。它给我的分类大致如下类别典型对象风险等级处理建议缓存类浏览器缓存、应用缓存、包管理器缓存低可删顶多损失一点重新缓存的时间日志类系统日志、应用日志中只删超过一定时间的保留近期用于排查构建产物build、dist、target 目录中可重建但有时间成本容器层容器镜像缓存、悬空层中删前确认没有服务在依赖它们运行个人数据下载目录的大压缩包、旧备份高必须人工确认不归为自动删除对象同时它还会输出一份候选删除清单每一条都带着路径、文件数量、体积和预估释放空间。这份清单本身就有价值哪怕你最后什么都不删光是知道原来这东西占了 20G就已经值回票价了。3.3 第三步生成清理脚本人工过目后再执行确认计划之后Codex 进入执行阶段。它没有直接一条条敲删除命令而是先生成一个清理脚本把动作固化下来。我拿到脚本先过了一遍确认里面没有超出计划范围的路径才放行执行。脚本长这样节选#!/usr/bin/env bash set -euo pipefail # 1. 清理包管理器缓存 npm cache clean --force 2/dev/null || true # 2. 清理超过 30 天的日志文件 find /var/log -type f -name *.log -mtime 30 -print -delete # 3. 回收容器悬空镜像与无用层 docker image prune -f # 4. 删除超过 7 天未构建的 target/dist 目录 find /Users/me/Projects -type d \( -name target -o -name dist \) \ -mtime 7 -exec rm -rf {} 2/dev/null || true放行之后Codex 会把脚本逐段执行、逐段汇报每跑完一步就报一次当前可用空间。整个过程大概七八分钟最后 df -h 显示可用空间从 3.2G 涨到了 65G。其中缓存清理贡献了最大头其次是历史归档的清理——那部分是我确认之后单独处理的毕竟归档目录里有些东西还是要留着的。这轮跑完之后我的感受是Codex 干的活本质上和我手动清理一样但它把查数据、分类、写脚本、执行、汇报这五步压缩成了一次对话我花在等待和确认上的时间不到原来的五分之一。4. 踩过的坑和翻车现场Codex 也不是省心的清理工4.1 坑一它真的会删东西而且比你想象中果断第一次用它我图省事提示词里直接写了把超过 30 天的日志都清掉没要求先出计划。Codex 执行力很强一条 find 加 -delete 下去几百个日志文件就没了。当时看着释放空间确实爽结果当天下午有个服务跑得不对我想翻它的轮转日志查线索这才发现最近一个月的轮转日志全被清了——那一刻人直接傻掉。那次之后我定了两条死规矩删除必须走 dry-run先输出完整清单命令里能不用 rm -f 就不用优先 mv 到一个临时回收目录观察没问题再清空。改完这个习惯后面再没出过删错后悔的情况。给你看一下 dry-run 的样子它就长这样——只列路径不动文件[DRY-RUN] 将删除以下 128 个文件预估释放 1.8G /var/log/my-app/app.log.20250501.gz 848M /var/log/my-app/app.log.20250502.gz 822M ... 如确认无误请输入确认执行。这一步多花十秒钟换来的是整晚睡个安稳觉非常值。4.2 坑二inode 用完和空间用完完全是两码事有次清理完几个大目录df -h 显示空间还很多但系统就是频繁报错说设备上没有空间。排查了半天才意识到问题根本不在容量而在 inode——文件系统里用于索引文件的节点数耗尽哪怕磁盘还有几十个 G也照样写不进任何新文件。那次的问题来源是某个项目目录下散落了上百万个极小文件典型的缓存碎片。Codex 一开始按大文件优先的思路扫完全没注意到这个目录因为它单体体积小到可以忽略。后来我让它同时检查 df -i再用 find 按文件数量排序才把矛头找到。所以现在我的提示词里固定有一句同时检查 df -h 和 df -i如果 inode 使用率接近 100%优先找出小文件密度最高的目录。4.3 坑三有些空间删了也没用还有一类让人非常容易慌的情况文件删了空间一个字节都没释放。我第一次遇到时差点以为脚本出了 bug还没头没脑地又扩大了一轮删除范围结果只是把更多东西删掉了空间依然没回来。这里面的机制主要有三种。第一种是文件被进程占用删掉只是把文件名从目录里移除但进程还握着文件描述符空间要等进程释放文件句柄才回来。日志文件特别容易触发排查方法是用 lsof L1 找出所有被标记为 deleted 但还打开着的文件然后重启对应服务。第二种是容器的 overlay 层在容器里删除文件并不会直接释放宿主机空间因为底层镜像层是共享且只读的必须用镜像清理命令去回收。第三种是文件系统的本地快照机制它会暂时保留文件和目录的旧版本删掉文件后空间可能被快照占着要等快照定期合并或手动删除快照才释放。搞懂这三件事之后我再也不会看到删了没反应就急着扩大删除范围而是先确认物理释放路径是哪一条。4.4 坑四sudo 的边界怎么给磁盘清理往往绕不开权限问题。系统日志、容器数据、其他用户目录下的缓存普通用户权限根本碰不到。这就有个两难不给权限Codex 只能清你 home 目录下的东西效率打折扣给了 root 权限就等于把一个会执行命令的 AI 代理放进了整台机器的核心区域。我的做法是分层授权普通分析用普通用户权限跑Codex 负责把所有需要特权的操作整理成一份命令清单我审视完清单之后自己开一个临时 sudo 会话去执行。这样既不影响效率又把特权操作的最终开关握在自己手里。如果你想更激进一点可以考虑建一个受限用户并只允许白名单命令但这需要额外配置成本我目前没有在个人机器上这么干。5. 把这套清理流程固化成长期方案5.1 把 Codex 生成的脚本沉淀成自己的工具首轮清理之后我发现最怕的不是磁盘又满而是每次都得重新走一遍流程。所以我把那次 Codex 生成的脚本存下来稍微参数化了一下日志保留天数、构建产物的目录列表、是否回收容器悬空镜像全部抽成变量。现在每个月跑一次磁盘水位基本稳定不再动不动告急。Codex 在这套体系里的角色也变了从实操员变成了顾问。日常清理我用沉淀好的脚本跑只有当磁盘出现新的异常状况、靠老脚本解决不了时我才会再叫 Codex 出来分析一次找出新的占用来源。5.2 建立简单的磁盘体检节奏除了月更脚本我还加了一个很轻的体检节奏每天早上用定时任务跑一次 df -h 和 df -i把结果追加到一个日志文件里顺便把剩余空间低于 10%当成告警线。这样磁盘是不是在缓慢膨胀翻一下趋势就清楚了不用等到系统弹警告才想起来处理。如果你用的环境没有传统的 cron也可以用系统自带的任务计划器把同样的事情挂上。体检脚本本身不复杂几十行就能搞定关键是定期看趋势这个意识——绝大多数磁盘问题都是慢慢积累出来的早发现半小时处理成本能低一个数量级。5.3 进一步扩展同一个思路能用到别的日常运维这次之后我得出的一个体会是让 AI 代理干这种跑腿 分析的活确实是它最靠谱的用法之一。同样的套路我还用来做过查端口占用、找长期驻留的高内存进程、对比两份配置文件的差异、批量清理临时文件。原则都是一样的让它负责把模糊需求翻译成具体动作把所有中间结果摆到明面上由人来拍板。最后再分享一个小建议。无论你把 Codex 调教得多顺手清理磁盘这种带删除性质的操作请始终保持三个习惯动手前备份执行前 dry-run执行后立刻复查磁盘状态。工具帮我们把工作从两小时压缩到十分钟但万一删错了怎么办的兜底逻辑最好还是握在自己手里。
