企业官网建设流程全解析

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/DerivedData（Xcode编译派生数据，动辄几十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配合sort，Windows上可以用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开发机为例，一份典型的候选清单和我的复核结论是这样的：

这张表是我自己踩坑后总结的，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帮你写，你自己来把关。