资讯动态

用Claude和Codex清理100G磁盘垃圾:AI辅助开发机清理实战

发布时间:2026/9/20 7:21:48 来源:尧图企业网站定制
1. 当磁盘告急遇上AI助手这个组合到底能干什么很多人第一次看到用Claude和Codex清理100G垃圾文件这个说法第一反应是AI还能干这个它又没长手怎么帮我删文件这个疑问非常合理也是我在实际动手之前最大的困惑。真相是Claude和Codex这类AI编程助手本身并不直接操作你的磁盘它们做的是另一件更有价值的事——帮你生成、审查、执行那些你平时懒得写、不敢写、写不对的清理脚本。换句话说它们是你的脚本代笔加安全顾问真正动手的还是终端里的命令但命令从哪来、对不对、安不安全AI帮你兜底。我自己的一台开发机用了三年多硬盘是512G的某天系统提示只剩不到20G可用空间编译Flutter项目时频繁报磁盘写入失败Xcode打包直接卡死。手动翻了一圈发现罪魁祸首是各种缓存、派生数据、模拟器镜像、旧版SDK、Docker镜像层、node_modules残留加起来轻松超过100G。手动一个个删光是找到它们在哪就要花半天。这时候把Claude Code或者Codex拉进来让它根据我的目录结构生成针对性的清理脚本效率完全不是一个量级。这篇文章适合三类人一是Mac上做Flutter、Xcode、iOS开发被DerivedData和模拟器吃光硬盘的开发者二是Windows或Linux上跑Docker、Node、Python被各种缓存和虚拟环境撑爆磁盘的工程师三是任何想学会用AI辅助系统清理这套方法论的普通用户。你不需要是脚本高手但需要愿意在终端里动手并且理解一个核心原则——AI生成的删除命令执行前必须自己看懂。这一点我会在后面的章节反复强调因为这是整套流程里唯一可能让你翻车的地方。关键词里出现了Claude Code、Codex、Flutter、Xcode、终端、Tabby终端工具这些词说明这个场景高度集中在开发者的日常环境里。所以下面的内容我会围绕真实的开发机清理场景展开把每一步为什么这么做、AI在其中扮演什么角色、哪些坑必须避开全部讲透。你照着做清理出几十上百G是完全现实的但更重要的是你会建立一套可复用的AI辅助清理工作流下次磁盘再告急十分钟就能搞定。2. 先搞清楚垃圾从哪来开发机磁盘占用的真实分布2.1 那些看不见的缓存目录才是元凶大多数人清理磁盘的第一反应是翻下载文件夹和废纸篓但开发机上真正吃空间的从来不是这些。我实测统计过自己这台机器100多G的占用里下载文件夹只占不到5G而各类缓存和派生数据占了七成以上。这些目录的特点是藏在用户库深处、名字带点、系统不主动提示、删了也不影响系统运行但会随着开发活动不断膨胀。在Mac上最典型的几个空间黑洞是~/Library/Developer/Xcode/DerivedDataXcode编译派生数据动辄几十G、~/Library/Developer/CoreSimulator/Devices模拟器镜像每个设备几个G、~/Library/Caches各类应用缓存、~/Library/Containers沙盒应用数据。在Linux和Windows上则是Docker的镜像和容器层、npm和yarn的全局缓存、pip缓存、conda环境、各种IDE的索引目录。这些地方的共同点是它们都是可再生的删掉之后下次用到会重新生成只是重新生成需要时间。理解这一点非常关键因为它决定了清理策略的边界。可再生数据可以放心删不可再生数据比如你的源码、文档、数据库文件绝对不能碰。AI助手在生成脚本时理论上知道这个区别但它不知道你的具体目录里哪些是重要的所以最终判断还得靠你。我一般会先让AI列出候选清理目录然后自己逐个确认再让它生成删除命令。2.2 用一条命令摸清家底而不是盲目删在动手清理之前必须先知道空间到底被谁占了。Mac和Linux上最实用的命令是du配合sortWindows上可以用PowerShell或者第三方工具。我习惯先跑这一条du -sh ~/Library/* 2/dev/null | sort -rh | head -20这条命令的意思是统计~/Library下每个子目录的总大小按从大到小排序取前20个。2/dev/null是把权限报错屏蔽掉sort -rh是按人类可读的大小倒序排。跑完之后你基本就能看到谁是大头了。我第一次跑的时候Developer目录赫然排在第一占了60多G其中DerivedData和CoreSimulator是大头。更细一层可以针对Developer目录再钻一次du -sh ~/Library/Developer/* 2/dev/null | sort -rh这时候把结果贴给Claude Code或者Codex让它帮你分析哪些可以安全清理、哪些需要保留它给出的建议通常相当靠谱。比如它会告诉你DerivedData可以整个删、CoreSimulator里没用的设备可以删、但Xcode的Archives如果里面有你要保留的发布包就别动。这一步就是AI价值最直接的体现——它把哪些能删这个需要经验判断的问题变成了一个可以快速获得参考答案的问题。2.3 为什么不能直接rm -rf了事有人可能会想既然知道哪些目录能删直接rm -rf不就完了要AI干嘛。这里有个真实的教训我曾经图省事直接rm -rf ~/Library/Developer/Xcode/DerivedData/*结果因为路径里有个软链接指向了别的地方差点把另一个项目的构建产物也删了。还有一次某个缓存目录里混着我手动放进去的配置文件一删全没了。AI助手在这时候的价值是它会提醒你先dry-run、会建议你先移动到临时目录而不是直接删、会帮你写带确认步骤的脚本。比如让Claude生成一个清理脚本它通常会写成先列出要删的文件、统计总大小、等你确认后再执行删除。这种谨慎是手动操作时最容易忽略的而AI恰好能补上这个短板。所以正确的姿势不是让AI直接删而是让AI帮我写一个安全的、分步骤的、可回滚的清理流程。3. 把Claude Code和Codex请进终端环境准备与选型3.1 Claude Code和Codex分别适合什么场景Claude Code和Codex都是能在终端里工作的AI编程助手但用法和侧重点不太一样。Claude Code更偏向agent模式它能直接在你的项目目录里读写文件、执行命令、根据执行结果调整下一步适合做那种需要多轮交互、边看结果边决策的任务比如清理这种需要先探查再动手的场景。Codex则更偏向代码生成和补全你给它一段描述或者上下文它给你生成代码或命令适合你已经想清楚要干什么、只需要它帮你把命令写对写全的情况。我的实际用法是探查阶段用Claude Code因为它能自己跑du、自己分析结果、自己给出下一步建议交互体验像有个助手在旁边帮你翻目录生成具体清理脚本时两个都用让它们各写一版对比一下谁的更稳妥、更周全取长补短。这种双AI交叉验证的做法在涉及删除操作时特别有价值因为两个模型同时犯同一个错误的概率比单个模型犯错要低。安装方面Claude Code一般通过npm全局安装Codex也有对应的命令行工具。安装完成后需要在终端里完成一次授权登录之后就能在任意目录下唤起。这里不展开具体安装步骤因为版本更新较快建议直接看官方文档。重点是要确保你的终端环境是干净的、PATH配置正确否则会出现命令找不到的情况。3.2 终端工具的选择Tabby还是系统自带关键词里提到了Tabby终端工具这确实是个值得说的点。系统自带的终端Mac的Terminal、Linux的gnome-terminal完全够用但如果你要长时间跟AI助手交互、频繁复制粘贴命令、同时开多个会话一个好用的终端工具能明显提升体验。Tabby的特点是跨平台、界面现代、支持分屏和会话管理配置也相对简单。不过我要提醒一句终端工具的选择不影响清理效果只影响你的操作舒适度。如果你现在用的终端顺手没必要为了这个任务专门换。真正影响效率的是你的shell配置比如有没有配好别名、历史命令搜索、以及一个清晰的提示符。我在清理时会开两个标签页一个跑探查命令一个跑AI助手来回切换比在一个窗口里挤着舒服得多。另外如果你在Windows上建议用WSL或者PowerShell 7而不是老版的cmd。因为很多清理命令和AI生成的脚本是基于Unix风格的在WSL里跑会顺畅很多。Windows原生的磁盘清理可以用cleanmgr或者Storage Sense但针对开发缓存的精细清理还是Unix工具链更给力。3.3 让AI助手看见你的磁盘现状AI助手再聪明也得先知道你的磁盘长什么样。所以第一步不是让它生成命令而是把探查结果喂给它。具体做法是先自己跑du命令把输出复制下来粘贴给Claude Code或Codex然后问它这些目录里哪些是可以安全清理的请分类说明。它会给你一个分类清单通常分成可安全删除需确认后删除建议保留三类。这个分类清单就是你后续操作的路线图。我一般会把它保存成一个文本文件边清理边对照。这里有个小技巧让AI在分类时顺便估算每类能释放多少空间这样你能优先清理收益最大的部分。比如它可能会告诉你DerivedData约25G可全删CoreSimulator约15G可删未使用设备Caches约10G可部分清理你就能按收益排序先啃大骨头。提示把磁盘目录结构发给AI时注意不要包含敏感的个人信息比如包含真实姓名的路径、包含账号信息的目录名。可以先用占位符替换掉再发。4. 实战清理流程从探查到执行的完整链路4.1 第一步生成候选清单并人工复核假设你已经把du的结果喂给了AI它给出了一份候选清理清单。接下来最重要的一步是人工复核。不要跳过这一步哪怕AI说得再肯定。复核的方法是对清单里的每一个目录先确认它是什么、删了会怎样、有没有你的重要数据混在里面。以Mac开发机为例一份典型的候选清单和我的复核结论是这样的目录典型大小是否可删复核要点~/Library/Developer/Xcode/DerivedData10-40G可全删编译缓存删后首次编译变慢~/Library/Developer/CoreSimulator/Devices5-30G删未使用设备保留常用模拟器删旧的~/Library/Caches5-20G可部分删有些应用缓存删了要重新登录~/Library/Developer/Xcode/Archives5-50G谨慎删里面是发布包确认无用再删~/Library/Containers不定谨慎删沙盒应用数据可能含配置Docker镜像和容器10-50G可清理用docker system prunenode_modules残留不定可删确认不是活跃项目这张表是我自己踩坑后总结的AI给的清单通常八九不离十但具体到Archives里哪个包能删只有你自己知道。我一般会打开Archives目录按日期排序把半年前、且已经上架或废弃的包删掉保留最近几个月的。4.2 第二步让AI写一个带dry-run的清理脚本复核完清单就可以让AI生成清理脚本了。这里的关键要求是必须带dry-run模式。dry-run就是空跑只打印将要删除的文件不真正删。我让Claude Code生成脚本时会明确要求它写成先列出、再确认、后删除的三段式结构。一个典型的脚本骨架长这样#!/bin/bash # 清理脚本 - 先dry-run确认再执行 DRY_RUN${1:-true} clean_dir() { local dir$1 if [ -d $dir ]; then local size$(du -sh $dir 2/dev/null | cut -f1) echo 目标: $dir (大小: $size) if [ $DRY_RUN true ]; then echo [dry-run] 将删除此目录内容 else rm -rf $dir/* 2/dev/null echo 已清理 fi else echo 跳过不存在: $dir fi } clean_dir $HOME/Library/Developer/Xcode/DerivedData clean_dir $HOME/Library/Caches/com.apple.dt.Xcode这个脚本的好处是你先用./clean.sh跑一遍看输出确认没问题了再用./clean.sh false真正执行。AI生成后你要逐行读一遍确认路径没有写错、没有通配符误伤、没有删到不该删的地方。我见过AI把~/Library/Caches写成~/Library/Cache的情况虽然只是少个s但路径就不对了这种错误必须靠人工发现。4.3 第三步分批次执行每批后验证真正执行时不要一次性把所有目录都删了。我的做法是分批次比如先删DerivedData跑一次验证再删模拟器再验证最后处理Docker和缓存。每批之后用df -h看一下可用空间的变化确认释放的空间符合预期。这样做的好处是万一某一步出了问题你能立刻定位是哪一批导致的。验证的时候除了看空间还要看系统是否正常。比如删完Xcode相关缓存后打开Xcode编译一个小项目确认能正常编译删完模拟器后确认Xcode还能识别剩余设备。这些验证花不了几分钟但能避免删完发现环境坏了的尴尬。我有一次删了某个缓存目录后发现某个命令行工具启动报错后来才知道那个目录里有个它依赖的配置文件只好重装。从那以后我每批清理后都会跑一遍常用工具确认没问题再继续。4.4 第四步处理那些顽固的大文件有些空间占用不是目录而是单个大文件比如旧的iOS备份、虚拟机镜像、下载了一半的安装包、日志文件。这些用du不一定能一眼看出来需要用find按大小搜find ~ -type f -size 1G 2/dev/null -exec ls -lh {} \;这条命令会找出你主目录下所有大于1G的文件。跑出来的结果里经常会有惊喜——比如某个几年前的iOS备份、某个忘了删的虚拟机磁盘、某个日志文件涨到了几个G。把这些结果贴给AI让它帮你判断哪些能删、哪些要保留。对于日志文件AI通常会建议你先看看内容再决定而不是直接删。处理这类文件时我一般会先移动到外置硬盘或者云盘确认一段时间不用了再彻底删除。这种先移后删的策略对于不确定是否还需要的大文件特别稳妥。毕竟磁盘空间可以再清误删的重要文件可不一定能找回来。5. 那些AI不会主动告诉你的坑与经验5.1 软链接和硬链接的陷阱这是我在清理时踩过的最隐蔽的坑。有些缓存目录里包含软链接指向项目源码目录或者其他重要位置。如果你用rm -rf删目录内容时没注意可能会顺着软链接把目标目录也删了。AI生成的脚本通常不会主动处理软链接因为它不知道你的目录里有没有。所以执行前最好先检查一下find ~/Library/Developer/Xcode/DerivedData -type l 2/dev/null这条命令会列出目录下所有的软链接。如果发现有指向重要位置的链接就要在脚本里排除它们或者干脆手动处理。硬链接的情况类似虽然不常见但一旦误删影响的是链接指向的实际文件。这个坑AI基本不会提醒你因为它看不到你的文件系统细节只能靠你自己把关。5.2 正在运行的程序会锁住文件另一个常见问题是你想删的缓存正被某个程序占用。比如Xcode开着的时候删DerivedData可能删不干净Docker容器跑着的时候清理镜像会报错。这时候AI生成的脚本可能会静默失败你以为删了其实没删。解决办法是清理前先关掉相关程序。删Xcode缓存前退出Xcode清理Docker前停掉容器删模拟器前关掉Simulator。如果不想关程序可以用lsof检查文件是否被占用lsof D ~/Library/Developer/Xcode/DerivedData 2/dev/null | head如果有输出说明有进程在用这些文件最好先处理掉再清理。这个检查步骤AI不会主动帮你做但它是保证清理彻底的关键。5.3 清理后的重建成本要有心理预期删缓存不是没有代价的。DerivedData删了下次编译项目会慢很多因为要重新生成模拟器删了下次要用得重新下载镜像Docker镜像删了下次构建要重新拉取基础镜像。这些重建成本在清理前要有预期别删完发现第二天要赶项目结果编译慢得让人抓狂。我的经验是在项目间隙做清理比如周五下午或者版本发布之后给自己留出重建的时间。如果正在赶项目就只清理那些重建成本低的比如日志、临时文件、旧的下载包把DerivedData这种留着。AI在给建议时你可以主动问它哪些清理后重建成本高它会给你一个排序帮你做取舍。5.4 别让AI直接执行删除命令这一点必须单独强调。Claude Code这类agent模式理论上可以自己执行命令。但在清理这种高风险操作上我强烈建议不要让AI直接执行删除。让它生成命令、让它分析结果、让它写脚本都可以但最后按下回车的那一下必须是你自己。因为AI可能会误解你的意图可能会在路径上犯错可能会忽略某个边界条件而删除是不可逆的。正确的协作模式是AI负责想和写你负责审和执行。每次执行前把命令读一遍确认路径对、范围对、没有误伤。这个习惯看起来麻烦但能帮你避免99%的误删事故。我见过太多人图省事让AI直接跑结果删错了目录追悔莫及。6. 清理之外的长期习惯让磁盘不再告急6.1 建立定期清理的节奏一次性清理100G很爽但如果不养成习惯几个月后又会堆回来。我的做法是每月固定清理一次时间选在月初或者项目间隙。清理的内容不用像第一次那么彻底主要是DerivedData、模拟器旧设备、Docker悬空镜像、日志文件这几样。每次花十几分钟就能把空间维持在健康水平。为了减少手动操作可以把清理脚本保存下来每月跑一次dry-run看看确认没问题再执行。AI助手这时候可以帮你更新脚本比如新增了某个缓存目录让它加进去。这种脚本AI维护的组合比每次从头来要省事得多。6.2 用工具监控磁盘变化与其等到磁盘告急才发现不如平时就监控着。Mac上可以用df -h定期看一眼或者装个菜单栏小工具显示剩余空间。Linux上可以写个cron任务每周把du的结果发到日志里。Windows上可以用Storage Sense自动清理临时文件。这些工具不复杂但能让你对磁盘状况心里有数不会突然被空间不足打个措手不及。我自己的习惯是每周五下午跑一次du -sh ~/Library/* | sort -rh | head看看有没有异常增长。如果某个目录突然变大就顺手查一下原因。这种小步快跑的维护方式比攒到100G再一次性清理要轻松得多。6.3 把清理经验沉淀成自己的脚本库每次清理都会遇到新情况把这些经验沉淀下来下次就能直接用。我维护了一个cleanup目录里面放着针对不同场景的脚本clean-xcode.sh、clean-docker.sh、clean-node.sh、clean-logs.sh。每个脚本都带dry-run都经过实际验证。需要清理时挑对应的跑一下就行。AI助手在这个环节的角色是脚本医生——当你遇到新情况把问题描述给它让它帮你写新脚本或者改进旧脚本。比如你发现某个新的缓存目录让它加进现有脚本比如你想让脚本更安全让它加上确认步骤。这种持续迭代的方式能让你的清理工具越来越趁手最终形成一套完全贴合自己环境的方案。说到底Claude和Codex在这件事上的价值不是替你删文件而是把清理磁盘这个需要经验、需要谨慎、需要写脚本的活儿变得更快、更安全、更可复用。你提供判断力它提供执行力和周全性两者配合100G垃圾文件清理起来也就是一个下午的事。而更重要的是这套方法一旦跑通你以后面对任何重复性、需要谨慎操作的系统任务都能用同样的思路去解决——让AI帮你写你自己来把关。

读完文章,也想定制专属网站?

尧图设计师 24 小时内与您沟通定制方案

免费获取报价