企业官网建设流程全解析

磁盘满这个事，估计每个写代码的人都经历过。我这台工作机，系统盘 500G，平时也没装多少电影游戏，结果某天编译一个项目直接提示 "no space left on device"，才发现磁盘已经亮红灯了。之前清理磁盘全靠手动，一个目录一个目录地du、find、rm，费时间不说，还总怕删错东西。这次我换了个思路，把清理过程交给 Codex，让它帮我分析占用、找出可以安全清理的文件、生成清理脚本，我和它来回确认后才真正执行。整个过程差不多一个下午的时间，最后腾出来 120G 空间。这篇文章就把完整的思路、命令和踩过的坑都写出来。

对于已经装了 Codex 环境、平时会用命令行的朋友，可以直接按后面的步骤操作；如果只是听说过 AI 编程助手、想看看它到底能不能干这种系统维护的活，这篇也能给你一个很具体的参考。清理磁盘看着简单，但真正做起来，最难的不是执行，而是判断哪些该删、哪些不该删。Codex 最擅长的恰好是这个判断环节的辅助。

1. 为什么我会选择 Codex 来清理磁盘

1.1 手动清理的老套路为什么效率低

以前遇到磁盘满，我的习惯操作是：

df -h du -h --max-depth=1 / 2>/dev/null | sort -hr | head -20

看到哪个目录大，就层层往下钻，再用ls -lS找大文件。这种办法有效，但有两个明显问题。

第一是慢。磁盘上的大目录往往藏在很深的层级里，比如某个容器数据目录、某个日志目录、某个缓存目录，靠肉眼一层一层往下戳，能戳半天。第二是与上下文脱离。du只告诉你哪个目录占多少空间，不告诉你这个目录是什么应用在用、里面的文件能不能删、删了以后会不会影响正在跑的服务。我经常遇到这种情况：查到一个目录好几个 G，看了半天也没想明白它什么来路，只能放着不敢动。

1.2 Codex 在清理场景里能提供什么

Codex 这类 AI 编程助手，平时大家可能都拿它写业务代码、改 bug，但它底层的能力是理解自然语言、生成并执行命令。清理磁盘正好是一个非常适合它发挥的场景，因为这件事本质上不是技术难度高，而是信息密度太高：

• 系统里有哪些占用空间的角落；
• 哪些缓存是应用运行中必然会生成、删掉也没事的；
• 哪些旧日志只是历史遗留、早就没有保留价值；
• 哪些文件虽然很大，但可能被某个服务引用，删了会引发连串问题。

这些判断需要结合系统知识、应用习惯和实时反馈。Codex 可以一边执行一边读结果，根据du、find的输出继续追问，缩小范围。我只需要负责最终拍板，它负责把“分析-建议-验证”这个循环跑起来。

1.3 我和 Codex 定的合作方式

在实际开工之前，我先给自己定了几条原则：

1. 所有删除操作都不让 Codex 直接执行，而是让它先生成清理脚本，我审查以后自己跑；
2. 对不确定的文件，先用mv移到临时目录，而不是rm直接删；
3. 每条删除动作都要有可解释的理由，Codex 需要说明这个文件是什么、为什么可以删；
4. 操作之前先把关键数据备份到手头，避免意外。

这几条原则很重要。AI 再聪明也是基于数据训练的，它不可能知道我本机上某个具体文件是不是有特殊用途。把决策权留在自己手里，才能既享受它的效率，又保证安全。

2. 核心实操：从诊断到释放 120G 的完整流程

2.1 让 Codex 盘一盘磁盘整体占用

我一开始只给了它一条指令：

我磁盘快满了，帮我看看系统盘空间都耗在哪了。

Codex 先跑了df -h，确认/的占用率已经到了 94%。然后它执行了下面的命令，把根目录下第一层子目录按大小排序：

du -x -h --max-depth=1 / 2>/dev/null | sort -hr | head -30

这里用-x是为了不跨文件系统，避免把/proc、/sys这种虚拟目录也统计进去；2>/dev/null是为了屏蔽掉那些没有权限访问目录的报错，否则刷屏会严重影响判断。

输出结果里，占用最大的几个目录是：

Codex 没有急着给出结论，而是先做了一步很关键的操作：把这两个目录再往下多挖两层。

du -x -h --max-depth=2 /var 2>/dev/null | sort -hr | head -20 du -x -h --max-depth=2 /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-size=200M

然后它又盯上了/var/log里持续增长的软件日志，比如某个开发工具的调试日志，一个文件就 8 个 G。像这种日志，只要当前没有进程在写，其实完全可以删掉，因为日志本身就是文本，删了以后下次启动会自动新建。

缓存环节是我这次拿到的最大一块空间。Codex 帮我逐个检查了常见的缓存目录，最后统计出来的结果是这样的：

每个目录为什么能删、删了之后能不能自动重建，Codex 都给了明确说明。比如说 pip 的缓存，它的作用是“避免重复下载安装包”，删掉以后只是下次安装包的时候重新下载一遍，本地已经装好的环境一点影响都没有。npm 也是同样逻辑。

2.4 生成清理方案，分优先级执行

Codex 把找到的清理项整理成了一份清单，并标了风险等级。我把其中一部分摘录成一个简化版：

这份清单累计加起来已经超过 120G。但这只是“看起来很美好”的预估，真正执行的时候还得一步步来。

我先让 Codex 把每个待删除的目录路径打印出来，我再逐一核对这些路径是否真的对应我预期中的文件。核完之后，我手动执行了第一批低风险的清理命令，因为这部分操作简单而且可逆性高：

journalctl --vacuum-size=200M pip cache purge npm cache clean --force sudo apt clean

执行完后再跑一遍df -h，发现可用空间已经多出 30 多 G。剩下那些中风险的就麻烦一点，比如重复压缩包，我不能用一个命令全删，而是前后对比文件列表，确认保留的是最新、最完整的那一份。docker 悬空镜像也检查了镜像被哪些容器引用，只删掉了引用关系为空的那些。

最终统计下来，实际释放了 120G 多一点。我在清理前后分别记录过df -h的输出，所以这个数字可以精确到 G。

3. 清理过程中的安全底线与核心避坑

3.1 删除之前先过一遍“可重建性”判断

很多人在清理磁盘的时候容易犯一个错误，就是只看到“大”就想删。实际上真正安全的判断标准不是“大不大”，而是“删了以后能不能自动重建，或者我有没有备份”。

我把清理对象分成了三类：

1. 可自动重建：缓存、日志、临时文件，删了以后应用会自动重新生成，安全；
2. 有备份版本：重复的压缩包、旧镜像，确认手头有保留版本后可以删，风险取决于备份的完整性；
3. 不可重建且无备份：比如自己写了一半没提交的代码、某次现场拷回来的素材，这类文件不管多大都不能只因为空间紧张就处理。

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 清理完以后软件运行异常怎么办

理论上，遵循“可重建 + 有备份”原则清理后，软件不会出问题。但凡事总有例外。我清理完第二天发现某个命令行工具启动时会报Can't open cache directory的警告。原因是那个工具希望缓存目录存在，而我把它删了以后，工具本身没有自动创建的逻辑。

解决办法很简单，手动建回目录并给对应权限：

mkdir -p ~/.cache/that-tool

这类问题在删除“自定义路径”的缓存时比较常出现。标准工具的缓存目录都会有自建逻辑，但一些小众工具做得不那么完善。遇到这种情况不用慌，把报错信息丢给 Codex，它通常能很快指出是哪个目录缺失。

基于这个经验，我后面的清理策略做了一个调整：删缓存之前，先快速看一下缓存目录里有哪些子目录，把工具名记录下来。如果工具不多，可以完全不删，反正重新生成的代价也就是几百 M 的空间。

5. 这次磁盘清理带给我的另外几个收获

5.1 重复文件比大文件更容易被忽略

清理出 120G 空间，最大头其实是重复文件。我一开始把注意力都放在缓存和日志上，没想到真正占地方的是散落在各处的重复压缩包和备份镜像。它们单个可能都不到 1G，但叠加起来非常可观。

这个发现让我开始重视“重复文件扫描”这个步骤。如果你是手动清理，建议每次磁盘紧张的时候，都先跑一遍fdupes或类似工具。如果你用 Codex，它会主动建议你去做这件事，而且会帮你过滤掉一些不该合并的目录，比如两个不同项目的同名文件虽然内容一样，但目录结构不同，不一定适合去重。

用 Codex 去重的时候，我习惯把它的输出按目录分组后再人工确认，重点看“是否在同一项目的同一层级下重复”。跨项目的重复文件，我倾向于保留，因为每个项目目录最好独立完整。

5.2 定期维护比一次性大扫除更省心

释放 120G 之后，我把清理命令整理成了一个可重复执行的脚本，每次磁盘占用超过 80% 就跑一遍。脚本内容其实很简单：

# 日志与缓存快速清理（低风险） journalctl --vacuum-size=200M pip cache purge npm cache clean --force docker system prune -f

然后又让 Codex 写了一个“大文件周报”脚本，每周开机时自动扫描并输出一个文件列表，我扫一眼就放心了。

定期维护的价值在于，很多“垃圾”刚产生的时候很小，不够引起注意，但一旦攒了几个月，量就非常可观。每周花五分钟清理，比每半年花一个下午去赌“这次不要删错”要轻松得多。

5.3 对 AI 协助系统维护这件事的看法

如果你是第一次尝试，我的建议是别一上来就让它处理根目录，先给它一个特定的、范围明确的目录，比如~/downloads或者/var/log。范围越小，AI 判断越精准，你也越容易理解它在干什么。等建立起信任感以后，再逐步扩大范围，效果会好很多。

我在这次清理中最大的体会是，Codex 不是替我做了清理，而是把我的想法用更快的速度、更完整的信息密度去验证。多数时候我还没想清楚“这个目录到底哪里占空间”，它已经把相关证据摆出来了。但最终决定删除动作的，还是我自己。

最后再分享一个小技巧

清理完磁盘后，建议把这次所有的命令和结果沉淀成一个简单的 Markdown 笔记，放到自己的知识库里。下次不管是自己用，还是帮朋友看电脑，直接翻出笔记就能复制命令。我这次就是靠着一份笔记，给朋友的同款场景又省了一个多小时。一条命令的价值只有在现场用过才会被放大。

如果以后 Codex 类工具能接入文件系统的事件监听，也许能更进一步，让磁盘占用从“出问题再来救火”变成“日常自动发现并提醒”。但目前这个阶段，我更推荐大家把它当成一个“带监督的智能助手”，效率和安全性都能兼顾。希望这份清理经验能帮你从磁盘告警里解脱出来。