先把话撂在这这是一篇写给所有“磁盘空间常年飘红却又不敢乱删文件”的人看的实操记录。我最近刚用 Codex 把一台几乎被塞满的开发机从“爆红”状态拉回安全线整个过程不复杂但里面的门道挺多。如果你手里也有一台“存储告急”的电脑或者你单纯想知道 AI 编程助手除了写代码还能干点啥这篇值得认真看完。起因很朴素。有一天我正开着模拟器跑一个跨平台项目系统突然弹窗提示“磁盘空间不足”紧接着编译就崩了。打开磁盘工具一看好家伙500G 的硬盘只剩不到 15G。当时我脑子里过了一遍常规方案下载图形化磁盘分析工具、手动翻大文件目录、清缓存这些我都干过知道效果也就那样。真正让我决定尝试用 Codex 来搞这件事的原因有两个一是因为它可以直接在终端执行命令二是因为它能在动手删除之前先跟你解释清楚“这条命令到底在做什么”。很多人对 AI 辅助清理的第一反应是“不敢用”怕它乱删系统文件。这个顾虑很正常我在实操之前也很谨慎。但如果你掌握了一套“先审计、后执行、设禁区”的玩法Codex 清理磁盘这件事其实比手动操作更安全——至少它能让你知道每一个删除动作背后的理由而不是像手动删文件那样删完才知道完蛋。1. 这件事的本质磁盘清理难的不是“删”而是“判断”先说清楚一个常见误区。磁盘清理的难点从来不是“找不到大文件”而是“找到了之后不敢删”。你打开任何一个可视化磁盘分析工具都能看到哪些目录占了几个 G但工具不会告诉你这个目录能不能删、删了之后会不会导致某个软件崩溃、会不会连累到项目环境。举个例子你看到~/Library/Developer/Xcode/DerivedData占了 12G你敢直接删吗如果你明天还要编译那个 iOS 项目删了就得重新索引、重新编译浪费一小时。再比如node_modules一个项目依赖占 2G 很正常你批量删了确实腾地方但你下次npm install还得装回来还白白浪费流量和时间。真正值得清的是那些“确定没用、删了无感、不删永远躺在那”的文件——日志归档、临时缓存、过期构建产物、重复下载的安装包。Codex 恰好能解决这个“判断”环节。它能扫描目录、理解文件类型、分析最近访问时间然后给你提交一份清理建议清单。你只需要在终端里像聊天一样问它“帮我看看哪个目录最值得清”它就能自己组装命令去统计。这一步不是多花哨的功能但非常省事尤其是面对几百个目录的时候人的耐心是有限的AI 不设限。1.1 清理磁盘前先分清三类“占空间”的文件我让 Codex 干活之前先自己在脑子里把要处理的目标分了个类这样后续下指令时能更精准第一类可安全删除的“纯垃圾”系统临时文件、日志归档、包管理器缓存、旧的.dSYM调试符号、模拟器运行时残留。这类文件删掉之后基本没有副作用顶多是重新缓存。第二类需要确认后删除的“半垃圾”旧版本的构建产物、已经不再使用的大体积 SDK 目录、解压后没删的压缩包、重复的下载文件。删除前需要看访问时间和项目依赖关系。第三类只看看但不能动的“系统盘”系统快照、Time Machine 本地快照、Docker 镜像的底层层数据、/System下的内容。这些要么是系统在管要么是删除后可能影响恢复功能。清楚这个分类之后你对 Codex 下指令就有的放矢了。坦白讲如果你自己连“什么能删什么不能删”都拎不清那不管用不用 AI都别贸然清盘。AI 能帮你执行、帮你分析但决策权还是得留在你手里。1.2 为什么是 Codex而不是图形化清理工具顺手对比一下其他方案。市面上有不少磁盘清理工具有的能画漂亮的气泡图有的能一键清理“垃圾”但我长期用下来总觉得差口气。图形化工具擅长“展示”不擅长“决策”。它告诉你~/Library/Caches有 7G但你要不要为了这 7G 把所有应用缓存都扬了工具不会帮你权衡。Codex 这种命令行 AI 的工作方式完全不一样。我可以直接说“删除超过 500M 且最近 180 天内没有访问过的缓存文件”然后 Codex 会基于这个条件去筛选、去计算路径、去确认删除范围。它像是一个“带着尺子的施工队”你说清目标它负责测量和执行。更重要的是每一步它都会把将要执行的命令铺开给你看你点头它才动手你摇头它换方案。当然Codex 不是万能的。它没有图形化工具那种直观的圆盘图也没有“一键完成”的省心。但如果你本身熟悉终端操作、习惯看命令输出Codex 的灵活性和可解释性绝对吊打传统工具。这就像一个舍得花时间研究工具的人更愿意用命令行而不是点点点因为每一步都知道发生了什么。2. 准备工作给 Codex 建一个“带护栏”的清理操作间在正式开始之前有几项准备工作必须要做。这步直接决定了后续清理过程是“丝滑”还是“心惊肉跳”。先说环境。Codex 这类命令行工具跑在终端里意味着所有操作都围绕 Shell 权限、路径访问权限展开。我当时的做法是用一台专门的开发机来测试确保不会影响到个人主力机的日常使用。你如果只有一台机器也没关系先把重要数据做一次备份——这一步别省真的别省。我在这行见过太多“我以为没问题”最后翻车的案例备份就是后悔药不用的时候嫌占地方用的时候救命。然后是让 Codex 理解“安全边界”。在第一次正式对话前我会明确告诉它哪些目录是禁区比如/System、/Library/Application Support/下的关键配置、~/.ssh、~/Documents下某些项目目录。这些路径就算再大、再占空间也不允许它主动去碰。2.1 先让 Codex 出一份“磁盘体检报告”正式开始清理前我不会让它删任何东西。我给它的第一道指令非常明确先统计不要改动。具体来说我会让它执行类似这样的命令组合# 查看每个一级目录的占用情况 sudo du -sh /* 2/dev/null | sort -hr | head -n 30 # 查看用户主目录下占用最大的前 20 个子目录 du -h -d 2 ~ 2/dev/null | sort -hr | head -n 20 # 查看应用缓存目录的占用 du -sh ~/Library/Caches/* 2/dev/null | sort -hr | head -n 30这里有个小细节。du命令在统计大量小文件时会很慢尤其是~/Library这种目录所以加2/dev/null把权限报错丢掉是常规操作。Codex 跑完这些命令之后会自己读输出结果然后给我一份“磁盘空间体检报告”。报告里会按容量列出 Top 目录并附带它的分析判断哪些目录大概率是缓存、哪些是日志、哪些可能是旧的构建产物。这一步是整个流程里最值得花时间的。因为后面的删除动作全部建立在报告的基础上如果基础数据不准后面删什么都可能出错。2.2 给 Codex 划清“可以动”和“不能碰”的边界我实际这样写指令“在接下来的清理任务中以下路径是绝对禁区只允许统计不允许修改/System、/Library/Application Support、/Users/用户名/.ssh、/Users/用户名/.config、/Users/用户名/工作项目目录。你需要严格遵守并在每次删除前再次确认路径不在禁区列表中。”听起来有点啰嗦但有用。Codex 在长上下文对话中有时候会在处理复杂任务时出现“注意力漂移”多强调几遍安全规则能有效避免它手滑。而且它确实会遵守这个约束。实测下来只要你在对话里把规则说清楚它在后续的删除操作中基本都能主动避开。如果你想让这个过程更稳还可以利用 Codex 操作系统的目录访问控制能力从系统层面限制它的操作范围。比如在 macOS 的终端权限设置里只给终端分配几个特定目录的完全磁盘访问权限。这样就算 Codex 中途“犯糊涂”系统的权限墙依然能把它挡住——双重保险这个我觉得是有必要的。3. 实操复盘从“磁盘爆红”到“释放 43.6G”的完整过程接下来进入正题完整复盘一下我这次的清理实战。机器配置是 512G 的 SSD系统占用 70G 左右开发环境装了 Xcode、Android Studio、若干版本的模拟器运行时、Node.js 环境、Python 虚拟环境、Docker 桌面端。清理前可用空间 14.8G清理后可用空间 58.4G净释放 43.6G。整体耗时大约一小时其中有三十多分钟是在分析和确认删除范围真正执行删除压缩操作只用了十几分钟。3.1 第一轮清扫开发缓存与包管理器缓存释放约 18.7G第一轮目标非常明确缓存类文件。这类文件的特点就是“删了还能重新生成”不存在数据损失风险心理负担最低。我先让 Codex 扫描了包管理器的缓存目录。以 npm 为例~/.npm/_cacache这个目录我早就知道很大但一直没有很好的理由去手动清理。Codex 只需要一句话“统计 ~/.npm 目录的占用并清理其中的缓存文件。”它就会自己去执行du -sh ~/.npm npm cache verify # 用于校验缓存完整性为后续清理做准备 npm cache clean --force执行结果很利落npm 缓存直接释放了接近 5G。然后是 pip 缓存du -sh ~/Library/Caches/pip pip cache purge这里要注意pip 的缓存目录在 macOS 上通常是~/Library/Caches/pip在 Linux 上是~/.cache/pip。Codex 自己会根据系统差异自动选择路径。pip 缓存清完又释放了 2.1G。接着是 Xcode 的派生数据目录。这个目录如果长期不清动辄十几个 G。我先让 Codex 执行du -sh ~/Library/Developer/Xcode/DerivedData/* 2/dev/null | sort -hr它列出了所有旧项目的编译缓存。我根据最近修改时间判断哪些项目已经很久没碰了确认后 Codex 执行删除。光这一项就释放了 7.6G。这轮清理还没完。Android Studio 的构建缓存也值得清它在~/.gradle/caches目录下。Codex 统计后发现里面有大量旧版本的依赖快照清掉之后释放了约 4G。四舍五入第一轮结束已经腾出了 18.7G 的空间速度远超预期。3.2 第二轮清扫日志文件、临时文件与系统缓存释放约 9.2G第二轮目标切换到日志和临时文件。日志文件的典型特征是“单文件可能不大但数量多如牛毛日积月累非常可观”。Codex 首先扫描了几处常见的日志目录# 系统级日志 sudo du -sh /var/log/* 2/dev/null | sort -hr | head -n 10 # 用户级日志 du -sh ~/Library/Logs/* 2/dev/null | sort -hr | head -n 10扫描结果里最夸张的是一个崩溃报告目录里面堆了几百份.ips文件每份几 MB加起来居然有 3.4G。Codex 分析说这些是过去一年多累积的历史崩溃日志没有分析价值属于可安全删除的范畴。我点头之后它执行删除瞬间清爽。接下来清理的是临时目录。这里有两个地方要注意一个是/tmp还有一个是~/Library/TemporaryItems。/tmp下的文件往往被系统标记为可删除但某些正在运行的进程会占用它们。Codex 执行时用了一个技巧先尝试删除如果遇到Operation not permitted或Text file busy之类的报错就直接跳过。这个策略很聪明避免因为个别文件占用而中断整个清理流程。最后Codex 还发现了一个容易被忽略的大户——iOS 模拟器运行时文件。如果你开发过移动端项目就知道每下载一个模拟器 SDK 就是好几个 G。这些运行时版本如果不经常切换旧版本就是纯摆设。Codex 罗列了已安装的运行时列表并根据我的使用情况判断哪些版本可以删。最终我保留最新版本删掉了两个旧版本又释放了 5.8G。第二轮合计释放约 9.2G。到这个时候磁盘剩余空间已经回到 40G 上下。3.3 第三轮清扫大文件扫描与历史残留释放约 15.7G前两轮已经把最肥的“软柿子”捏完了剩下的是需要更精准判断的内容。Codex 开始扫描全盘的大文件排序后逐一批判每个文件的“存废”。大文件扫描的命令不复杂# 找到大于 500M 的文件 find ~ -type f -size 500M 2/dev/null | xargs -I {} du -sh {} | sort -hr | head -n 40 # 找到大于 1G 的文件 find ~ -type f -size 1G 2/dev/null | xargs -I {} du -sh {} | sort -hr | head -n 20扫描结果显示有几个体积夸张的大块头躺在那。最典型的是一个 6.8G 的 Android 模拟器系统镜像备份文件是半年前为了测试某个功能手动存下来的测试早就结束了文件一直没删。还有两个合计 4.2G 的 Xcode 模拟器运行时下载副本正常的运行时应该在专门目录这两个是下载过程中的残留副本属于半垃圾。Codex 确认这些文件的访问时间都在三个月前并且没有相关联的活跃项目删除风险极低于是执行清理。另外它发现了一个很有意思的东西~/Downloads下有一个 3.1G 的旧安装包备份文件名里带着自己都记不起来的版本号。查看修改时间是去年某个 App 的专用安装包如今那个 App 已经不用了。Codex 问我要不要保留我说删它就把安装包丢进了废纸篓。这轮的收获最大的是“清理之外”的价值。Codex 在分析完大文件后主动建议我以后下载大型 SDK 镜像前先确认磁盘剩余空间避免再次“下载到一半磁盘满了”的尴尬。这种从具体操作中抽象出来的经验提示比单纯释放几个 G 更值钱。三轮合计净释放 43.6G磁盘可用空间从 14.8G 涨到 58.4G。整个过程我没有手动画表、没有开 GUI 工具只是在一堆终端输出中做判断和确认。4. 全程避坑指南Codex 清理磁盘的 6 个关键教训这六条是我这次实操中最想分享的内容。写代码工具的使用心得光写“它多好用”没意义真正能帮到人的是那些“哪里容易翻车”的经验。4.1 一定要让先“演示”再“动手”Codex 有一个我很欣赏的特性就是可以在正式执行前先展示命令。你的指令应该是“请用 dry-run 模式分析以下目录列出将删除的文件列表暂不执行”。等它列出清单你自己快速扫一眼确认没有包含明显不能动的内容后再补一句“确认执行”。这习惯看起来多花了一轮对话但能拦截大部分手滑事故。我后来测试过一个更棘手的场景让 Codex 清理一段非常古老的构建产物目录它在先展示阶段列出的清单里居然混进了几个还正在被某个后台服务引用的二进制文件。如果我直接让它“清理所有旧文件”这几个二进制被删掉后服务就得挂。多了一步演示这种事就能提前发现。4.2 禁区列表要反复重申前面提到过我在对话开头声明了禁区列表但这还不够。在任务执行中途尤其是涉及递归删除时我再三强调“请再次确认路径不在禁区内”。这不是话多这是在调教 AI 权重的长按操作。有一次 Codex 正在处理一个目录时它为了效率直接把父目录作为删除目标候选。要不是我眼疾手快看到路径前缀有点眼熟可能就让它把整个项目目录给清了。这个教训特别深刻AI 工具的上下文再强也有理解偏差的时候“多看它一眼”是必须的成本。4.3 别让它递归清空目录而不重建有个很多开发者的通病也是我这次踩过的一个坑在清理node_modules或者构建缓存时我看到 Codex 执行了精准删除但没留意它是否保留了目录结构。正常的清理逻辑应该是清空目录内容、保留目录本身、后续编译时自动重建缓存。但 Codex 有时候为了“腾空间效率最大化”会直接rm -rf整个目录然后重建缺失结构。这在很多场景下没问题但某些项目对目录权限和属主有特殊要求重新生成的目录权限跟原来不一致编译就报错。后来我的做法是给指令加一条要求——“单独清空目录内的文件不删除目录本身或重建相同路径的空目录”。一句话足够少走一个大弯路。4.4 关注权限问题能减少一半的报错Codex 在终端里执行命令时默认继承当前用户的权限。你如果直接用普通用户跑那清理~/Library下的某些目录没问题但清理/Library或者系统日志目录就需要sudo。这个过程有个坑Codex 调用sudo时可能会卡在密码输入环节表现就是命令“停住不动了”。解决办法是在给它的指令里明确说明“如果需要提升权限请按提示输入授权信息如果输入授权信息后仍然失败请跳过该路径并继续处理其他目录。”这样 Codex 就不会因为单个目录的权限问题而让整个清理流程卡死。4.5 注意“时间戳”和“访问时间”的判断盲区用访问时间判断文件是否可清理是 Codex 很常用的策略。但这个策略有盲区有些目录里的文件会被后台备份服务或索引服务定期访问导致即便文件本身久未使用访问时间戳仍然很新。Codex 如果只按访问时间过滤就会漏掉这些“假新鲜”的大文件。我做了一个补充要求 Codex 结合“修改时间”和“创建时间”一起判断三者同时超过 90 天才列为候选。虽然多了一点误判概率但整体上更贴合“很久没用”的真实语义。4.6 不要删完就万事大吉重建索引往往需要时间最后一个教训是磁盘空间释放后系统索引、Spotlight 索引、文件系统日志可能需要一段时间来同步。刚释放完空间时某些工具显示的可用容量可能还是旧的。别慌等几分钟再刷新就好。Codex 帮不了这一步它能管的是删除动作系统本身的“记账更新”有自己的节奏。5. 清理后的维护策略从“一次清盘”到“持续可控”清理完成只是第一步。如果后续使用中不注意空间管理过几周又会回到爆红的状态。我拿 Codex 顺手做了一件有点价值的事让它帮我写了一个轻量级的磁盘健康巡检脚本定时检查关键目录的占用情况超过阈值时给出提醒。脚本逻辑其实很朴素核心就几段#!/bin/bash # disk-check.sh - 简易磁盘巡检脚本 THRESHOLD80 CURRENT$(df -h / | awk NR2 {print $5} | sed s/%//) if [ $CURRENT -gt $THRESHOLD ]; then echo [警告] 磁盘使用率已超过 ${THRESHOLD}%当前为 ${CURRENT}% du -sh ~/Library/Caches/* 2/dev/null | sort -hr | head -n 5 du -sh ~/Library/Developer/Xcode/DerivedData/* 2/dev/null | sort -hr | head -n 5 else echo [正常] 当前磁盘使用率为 ${CURRENT}% fi这段脚本每隔几天手动跑一次或者丢进 crontab 让它自动跑。Codex 生成的脚本比我想象中要稳它甚至自己加了2/dev/null处理权限报错的细节还提醒我如果目录不存在脚本应该怎么兜底。这就是“持续维护”的意义与其每三个月花一小时手动清盘不如每周花十秒看一眼脚本输出。维护阶段的另一个好习惯是定期检查包管理器缓存和历史日志而不是等磁盘满了才想起来。Codex 本身也不拒绝重复劳动同样的清理流程第二次跑起来明显更顺它会记住上次的关键目录和判断逻辑对话里的废话少了很多。结尾聊聊我的真实感受这次用 Codex 清理磁盘坦白说比我预想的效果好不少。最初我以为它顶多是帮我执行几条rm命令没想到它在“判断哪些该删”这个环节起到了真正的作用。尤其是面对那些“想删但不敢删”的文件它能从时间戳、依赖关系、路径语义等角度给出分析理由最终让我做决策时心里有底。如果你也想试试这个方案我的建议是拿一台非关键机器先玩一圈让它先分析、别动手多验证几次它的判断逻辑。等你对它的“清理风格”有把握了再让它介入更深度的工作。任何 AI 工具的核心用法都一样不要当它是替你决定的“老板”要当它是帮你算账、替你跑腿的“助手”决策权一定要攥在自己手里。下次磁盘再飘红的时候我想我不会再打开那个气泡图了直接在终端里喊一声 Codex它会自己扛着“尺子”和“扫把”出来干活。 
长河君 · 2026/10/13 16:35:17 · 阅读 1.2k 用Codex AI助手安全清理磁盘：从爆红到释放43.6G的实操指南
先把话撂在这这是一篇写给所有“磁盘空间常年飘红却又不敢乱删文件”的人看的实操记录。我最近刚用 Codex 把一台几乎被塞满的开发机从“爆红”状态拉回安全线整个过程不复杂但里面的门道挺多。如果你手里也有一台“存储告急”的电脑或者你单纯想知道 AI 编程助手除了写代码还能干点啥这篇值得认真看完。起因很朴素。有一天我正开着模拟器跑一个跨平台项目系统突然弹窗提示“磁盘空间不足”紧接着编译就崩了。打开磁盘工具一看好家伙500G 的硬盘只剩不到 15G。当时我脑子里过了一遍常规方案下载图形化磁盘分析工具、手动翻大文件目录、清缓存这些我都干过知道效果也就那样。真正让我决定尝试用 Codex 来搞这件事的原因有两个一是因为它可以直接在终端执行命令二是因为它能在动手删除之前先跟你解释清楚“这条命令到底在做什么”。很多人对 AI 辅助清理的第一反应是“不敢用”怕它乱删系统文件。这个顾虑很正常我在实操之前也很谨慎。但如果你掌握了一套“先审计、后执行、设禁区”的玩法Codex 清理磁盘这件事其实比手动操作更安全——至少它能让你知道每一个删除动作背后的理由而不是像手动删文件那样删完才知道完蛋。1. 这件事的本质磁盘清理难的不是“删”而是“判断”先说清楚一个常见误区。磁盘清理的难点从来不是“找不到大文件”而是“找到了之后不敢删”。你打开任何一个可视化磁盘分析工具都能看到哪些目录占了几个 G但工具不会告诉你这个目录能不能删、删了之后会不会导致某个软件崩溃、会不会连累到项目环境。举个例子你看到~/Library/Developer/Xcode/DerivedData占了 12G你敢直接删吗如果你明天还要编译那个 iOS 项目删了就得重新索引、重新编译浪费一小时。再比如node_modules一个项目依赖占 2G 很正常你批量删了确实腾地方但你下次npm install还得装回来还白白浪费流量和时间。真正值得清的是那些“确定没用、删了无感、不删永远躺在那”的文件——日志归档、临时缓存、过期构建产物、重复下载的安装包。Codex 恰好能解决这个“判断”环节。它能扫描目录、理解文件类型、分析最近访问时间然后给你提交一份清理建议清单。你只需要在终端里像聊天一样问它“帮我看看哪个目录最值得清”它就能自己组装命令去统计。这一步不是多花哨的功能但非常省事尤其是面对几百个目录的时候人的耐心是有限的AI 不设限。1.1 清理磁盘前先分清三类“占空间”的文件我让 Codex 干活之前先自己在脑子里把要处理的目标分了个类这样后续下指令时能更精准第一类可安全删除的“纯垃圾”系统临时文件、日志归档、包管理器缓存、旧的.dSYM调试符号、模拟器运行时残留。这类文件删掉之后基本没有副作用顶多是重新缓存。第二类需要确认后删除的“半垃圾”旧版本的构建产物、已经不再使用的大体积 SDK 目录、解压后没删的压缩包、重复的下载文件。删除前需要看访问时间和项目依赖关系。第三类只看看但不能动的“系统盘”系统快照、Time Machine 本地快照、Docker 镜像的底层层数据、/System下的内容。这些要么是系统在管要么是删除后可能影响恢复功能。清楚这个分类之后你对 Codex 下指令就有的放矢了。坦白讲如果你自己连“什么能删什么不能删”都拎不清那不管用不用 AI都别贸然清盘。AI 能帮你执行、帮你分析但决策权还是得留在你手里。1.2 为什么是 Codex而不是图形化清理工具顺手对比一下其他方案。市面上有不少磁盘清理工具有的能画漂亮的气泡图有的能一键清理“垃圾”但我长期用下来总觉得差口气。图形化工具擅长“展示”不擅长“决策”。它告诉你~/Library/Caches有 7G但你要不要为了这 7G 把所有应用缓存都扬了工具不会帮你权衡。Codex 这种命令行 AI 的工作方式完全不一样。我可以直接说“删除超过 500M 且最近 180 天内没有访问过的缓存文件”然后 Codex 会基于这个条件去筛选、去计算路径、去确认删除范围。它像是一个“带着尺子的施工队”你说清目标它负责测量和执行。更重要的是每一步它都会把将要执行的命令铺开给你看你点头它才动手你摇头它换方案。当然Codex 不是万能的。它没有图形化工具那种直观的圆盘图也没有“一键完成”的省心。但如果你本身熟悉终端操作、习惯看命令输出Codex 的灵活性和可解释性绝对吊打传统工具。这就像一个舍得花时间研究工具的人更愿意用命令行而不是点点点因为每一步都知道发生了什么。2. 准备工作给 Codex 建一个“带护栏”的清理操作间在正式开始之前有几项准备工作必须要做。这步直接决定了后续清理过程是“丝滑”还是“心惊肉跳”。先说环境。Codex 这类命令行工具跑在终端里意味着所有操作都围绕 Shell 权限、路径访问权限展开。我当时的做法是用一台专门的开发机来测试确保不会影响到个人主力机的日常使用。你如果只有一台机器也没关系先把重要数据做一次备份——这一步别省真的别省。我在这行见过太多“我以为没问题”最后翻车的案例备份就是后悔药不用的时候嫌占地方用的时候救命。然后是让 Codex 理解“安全边界”。在第一次正式对话前我会明确告诉它哪些目录是禁区比如/System、/Library/Application Support/下的关键配置、~/.ssh、~/Documents下某些项目目录。这些路径就算再大、再占空间也不允许它主动去碰。2.1 先让 Codex 出一份“磁盘体检报告”正式开始清理前我不会让它删任何东西。我给它的第一道指令非常明确先统计不要改动。具体来说我会让它执行类似这样的命令组合# 查看每个一级目录的占用情况 sudo du -sh /* 2/dev/null | sort -hr | head -n 30 # 查看用户主目录下占用最大的前 20 个子目录 du -h -d 2 ~ 2/dev/null | sort -hr | head -n 20 # 查看应用缓存目录的占用 du -sh ~/Library/Caches/* 2/dev/null | sort -hr | head -n 30这里有个小细节。du命令在统计大量小文件时会很慢尤其是~/Library这种目录所以加2/dev/null把权限报错丢掉是常规操作。Codex 跑完这些命令之后会自己读输出结果然后给我一份“磁盘空间体检报告”。报告里会按容量列出 Top 目录并附带它的分析判断哪些目录大概率是缓存、哪些是日志、哪些可能是旧的构建产物。这一步是整个流程里最值得花时间的。因为后面的删除动作全部建立在报告的基础上如果基础数据不准后面删什么都可能出错。2.2 给 Codex 划清“可以动”和“不能碰”的边界我实际这样写指令“在接下来的清理任务中以下路径是绝对禁区只允许统计不允许修改/System、/Library/Application Support、/Users/用户名/.ssh、/Users/用户名/.config、/Users/用户名/工作项目目录。你需要严格遵守并在每次删除前再次确认路径不在禁区列表中。”听起来有点啰嗦但有用。Codex 在长上下文对话中有时候会在处理复杂任务时出现“注意力漂移”多强调几遍安全规则能有效避免它手滑。而且它确实会遵守这个约束。实测下来只要你在对话里把规则说清楚它在后续的删除操作中基本都能主动避开。如果你想让这个过程更稳还可以利用 Codex 操作系统的目录访问控制能力从系统层面限制它的操作范围。比如在 macOS 的终端权限设置里只给终端分配几个特定目录的完全磁盘访问权限。这样就算 Codex 中途“犯糊涂”系统的权限墙依然能把它挡住——双重保险这个我觉得是有必要的。3. 实操复盘从“磁盘爆红”到“释放 43.6G”的完整过程接下来进入正题完整复盘一下我这次的清理实战。机器配置是 512G 的 SSD系统占用 70G 左右开发环境装了 Xcode、Android Studio、若干版本的模拟器运行时、Node.js 环境、Python 虚拟环境、Docker 桌面端。清理前可用空间 14.8G清理后可用空间 58.4G净释放 43.6G。整体耗时大约一小时其中有三十多分钟是在分析和确认删除范围真正执行删除压缩操作只用了十几分钟。3.1 第一轮清扫开发缓存与包管理器缓存释放约 18.7G第一轮目标非常明确缓存类文件。这类文件的特点就是“删了还能重新生成”不存在数据损失风险心理负担最低。我先让 Codex 扫描了包管理器的缓存目录。以 npm 为例~/.npm/_cacache这个目录我早就知道很大但一直没有很好的理由去手动清理。Codex 只需要一句话“统计 ~/.npm 目录的占用并清理其中的缓存文件。”它就会自己去执行du -sh ~/.npm npm cache verify # 用于校验缓存完整性为后续清理做准备 npm cache clean --force执行结果很利落npm 缓存直接释放了接近 5G。然后是 pip 缓存du -sh ~/Library/Caches/pip pip cache purge这里要注意pip 的缓存目录在 macOS 上通常是~/Library/Caches/pip在 Linux 上是~/.cache/pip。Codex 自己会根据系统差异自动选择路径。pip 缓存清完又释放了 2.1G。接着是 Xcode 的派生数据目录。这个目录如果长期不清动辄十几个 G。我先让 Codex 执行du -sh ~/Library/Developer/Xcode/DerivedData/* 2/dev/null | sort -hr它列出了所有旧项目的编译缓存。我根据最近修改时间判断哪些项目已经很久没碰了确认后 Codex 执行删除。光这一项就释放了 7.6G。这轮清理还没完。Android Studio 的构建缓存也值得清它在~/.gradle/caches目录下。Codex 统计后发现里面有大量旧版本的依赖快照清掉之后释放了约 4G。四舍五入第一轮结束已经腾出了 18.7G 的空间速度远超预期。3.2 第二轮清扫日志文件、临时文件与系统缓存释放约 9.2G第二轮目标切换到日志和临时文件。日志文件的典型特征是“单文件可能不大但数量多如牛毛日积月累非常可观”。Codex 首先扫描了几处常见的日志目录# 系统级日志 sudo du -sh /var/log/* 2/dev/null | sort -hr | head -n 10 # 用户级日志 du -sh ~/Library/Logs/* 2/dev/null | sort -hr | head -n 10扫描结果里最夸张的是一个崩溃报告目录里面堆了几百份.ips文件每份几 MB加起来居然有 3.4G。Codex 分析说这些是过去一年多累积的历史崩溃日志没有分析价值属于可安全删除的范畴。我点头之后它执行删除瞬间清爽。接下来清理的是临时目录。这里有两个地方要注意一个是/tmp还有一个是~/Library/TemporaryItems。/tmp下的文件往往被系统标记为可删除但某些正在运行的进程会占用它们。Codex 执行时用了一个技巧先尝试删除如果遇到Operation not permitted或Text file busy之类的报错就直接跳过。这个策略很聪明避免因为个别文件占用而中断整个清理流程。最后Codex 还发现了一个容易被忽略的大户——iOS 模拟器运行时文件。如果你开发过移动端项目就知道每下载一个模拟器 SDK 就是好几个 G。这些运行时版本如果不经常切换旧版本就是纯摆设。Codex 罗列了已安装的运行时列表并根据我的使用情况判断哪些版本可以删。最终我保留最新版本删掉了两个旧版本又释放了 5.8G。第二轮合计释放约 9.2G。到这个时候磁盘剩余空间已经回到 40G 上下。3.3 第三轮清扫大文件扫描与历史残留释放约 15.7G前两轮已经把最肥的“软柿子”捏完了剩下的是需要更精准判断的内容。Codex 开始扫描全盘的大文件排序后逐一批判每个文件的“存废”。大文件扫描的命令不复杂# 找到大于 500M 的文件 find ~ -type f -size 500M 2/dev/null | xargs -I {} du -sh {} | sort -hr | head -n 40 # 找到大于 1G 的文件 find ~ -type f -size 1G 2/dev/null | xargs -I {} du -sh {} | sort -hr | head -n 20扫描结果显示有几个体积夸张的大块头躺在那。最典型的是一个 6.8G 的 Android 模拟器系统镜像备份文件是半年前为了测试某个功能手动存下来的测试早就结束了文件一直没删。还有两个合计 4.2G 的 Xcode 模拟器运行时下载副本正常的运行时应该在专门目录这两个是下载过程中的残留副本属于半垃圾。Codex 确认这些文件的访问时间都在三个月前并且没有相关联的活跃项目删除风险极低于是执行清理。另外它发现了一个很有意思的东西~/Downloads下有一个 3.1G 的旧安装包备份文件名里带着自己都记不起来的版本号。查看修改时间是去年某个 App 的专用安装包如今那个 App 已经不用了。Codex 问我要不要保留我说删它就把安装包丢进了废纸篓。这轮的收获最大的是“清理之外”的价值。Codex 在分析完大文件后主动建议我以后下载大型 SDK 镜像前先确认磁盘剩余空间避免再次“下载到一半磁盘满了”的尴尬。这种从具体操作中抽象出来的经验提示比单纯释放几个 G 更值钱。三轮合计净释放 43.6G磁盘可用空间从 14.8G 涨到 58.4G。整个过程我没有手动画表、没有开 GUI 工具只是在一堆终端输出中做判断和确认。4. 全程避坑指南Codex 清理磁盘的 6 个关键教训这六条是我这次实操中最想分享的内容。写代码工具的使用心得光写“它多好用”没意义真正能帮到人的是那些“哪里容易翻车”的经验。4.1 一定要让先“演示”再“动手”Codex 有一个我很欣赏的特性就是可以在正式执行前先展示命令。你的指令应该是“请用 dry-run 模式分析以下目录列出将删除的文件列表暂不执行”。等它列出清单你自己快速扫一眼确认没有包含明显不能动的内容后再补一句“确认执行”。这习惯看起来多花了一轮对话但能拦截大部分手滑事故。我后来测试过一个更棘手的场景让 Codex 清理一段非常古老的构建产物目录它在先展示阶段列出的清单里居然混进了几个还正在被某个后台服务引用的二进制文件。如果我直接让它“清理所有旧文件”这几个二进制被删掉后服务就得挂。多了一步演示这种事就能提前发现。4.2 禁区列表要反复重申前面提到过我在对话开头声明了禁区列表但这还不够。在任务执行中途尤其是涉及递归删除时我再三强调“请再次确认路径不在禁区内”。这不是话多这是在调教 AI 权重的长按操作。有一次 Codex 正在处理一个目录时它为了效率直接把父目录作为删除目标候选。要不是我眼疾手快看到路径前缀有点眼熟可能就让它把整个项目目录给清了。这个教训特别深刻AI 工具的上下文再强也有理解偏差的时候“多看它一眼”是必须的成本。4.3 别让它递归清空目录而不重建有个很多开发者的通病也是我这次踩过的一个坑在清理node_modules或者构建缓存时我看到 Codex 执行了精准删除但没留意它是否保留了目录结构。正常的清理逻辑应该是清空目录内容、保留目录本身、后续编译时自动重建缓存。但 Codex 有时候为了“腾空间效率最大化”会直接rm -rf整个目录然后重建缺失结构。这在很多场景下没问题但某些项目对目录权限和属主有特殊要求重新生成的目录权限跟原来不一致编译就报错。后来我的做法是给指令加一条要求——“单独清空目录内的文件不删除目录本身或重建相同路径的空目录”。一句话足够少走一个大弯路。4.4 关注权限问题能减少一半的报错Codex 在终端里执行命令时默认继承当前用户的权限。你如果直接用普通用户跑那清理~/Library下的某些目录没问题但清理/Library或者系统日志目录就需要sudo。这个过程有个坑Codex 调用sudo时可能会卡在密码输入环节表现就是命令“停住不动了”。解决办法是在给它的指令里明确说明“如果需要提升权限请按提示输入授权信息如果输入授权信息后仍然失败请跳过该路径并继续处理其他目录。”这样 Codex 就不会因为单个目录的权限问题而让整个清理流程卡死。4.5 注意“时间戳”和“访问时间”的判断盲区用访问时间判断文件是否可清理是 Codex 很常用的策略。但这个策略有盲区有些目录里的文件会被后台备份服务或索引服务定期访问导致即便文件本身久未使用访问时间戳仍然很新。Codex 如果只按访问时间过滤就会漏掉这些“假新鲜”的大文件。我做了一个补充要求 Codex 结合“修改时间”和“创建时间”一起判断三者同时超过 90 天才列为候选。虽然多了一点误判概率但整体上更贴合“很久没用”的真实语义。4.6 不要删完就万事大吉重建索引往往需要时间最后一个教训是磁盘空间释放后系统索引、Spotlight 索引、文件系统日志可能需要一段时间来同步。刚释放完空间时某些工具显示的可用容量可能还是旧的。别慌等几分钟再刷新就好。Codex 帮不了这一步它能管的是删除动作系统本身的“记账更新”有自己的节奏。5. 清理后的维护策略从“一次清盘”到“持续可控”清理完成只是第一步。如果后续使用中不注意空间管理过几周又会回到爆红的状态。我拿 Codex 顺手做了一件有点价值的事让它帮我写了一个轻量级的磁盘健康巡检脚本定时检查关键目录的占用情况超过阈值时给出提醒。脚本逻辑其实很朴素核心就几段#!/bin/bash # disk-check.sh - 简易磁盘巡检脚本 THRESHOLD80 CURRENT$(df -h / | awk NR2 {print $5} | sed s/%//) if [ $CURRENT -gt $THRESHOLD ]; then echo [警告] 磁盘使用率已超过 ${THRESHOLD}%当前为 ${CURRENT}% du -sh ~/Library/Caches/* 2/dev/null | sort -hr | head -n 5 du -sh ~/Library/Developer/Xcode/DerivedData/* 2/dev/null | sort -hr | head -n 5 else echo [正常] 当前磁盘使用率为 ${CURRENT}% fi这段脚本每隔几天手动跑一次或者丢进 crontab 让它自动跑。Codex 生成的脚本比我想象中要稳它甚至自己加了2/dev/null处理权限报错的细节还提醒我如果目录不存在脚本应该怎么兜底。这就是“持续维护”的意义与其每三个月花一小时手动清盘不如每周花十秒看一眼脚本输出。维护阶段的另一个好习惯是定期检查包管理器缓存和历史日志而不是等磁盘满了才想起来。Codex 本身也不拒绝重复劳动同样的清理流程第二次跑起来明显更顺它会记住上次的关键目录和判断逻辑对话里的废话少了很多。结尾聊聊我的真实感受这次用 Codex 清理磁盘坦白说比我预想的效果好不少。最初我以为它顶多是帮我执行几条rm命令没想到它在“判断哪些该删”这个环节起到了真正的作用。尤其是面对那些“想删但不敢删”的文件它能从时间戳、依赖关系、路径语义等角度给出分析理由最终让我做决策时心里有底。如果你也想试试这个方案我的建议是拿一台非关键机器先玩一圈让它先分析、别动手多验证几次它的判断逻辑。等你对它的“清理风格”有把握了再让它介入更深度的工作。任何 AI 工具的核心用法都一样不要当它是替你决定的“老板”要当它是帮你算账、替你跑腿的“助手”决策权一定要攥在自己手里。下次磁盘再飘红的时候我想我不会再打开那个气泡图了直接在终端里喊一声 Codex它会自己扛着“尺子”和“扫把”出来干活。