从"手动清理"到"封装 skill"
最初我让 Codex 帮我做一次清理，理由是"系统数据里应该有很多缓存和项目临时文件"。Codex 实际删掉了约 5.6 GB：其中 /private/tmp 从 5.4 GB 降到 56 MB，用户临时目录又清理出约 206 MB。可用空间依旧显示 28 GiB，因为它被当天的本地快照持有——这正是我后来一直惦记的"80 GB 系统数据"的一部分。
随后我提了一个看似简单、实则很关键的需求：你能不能把我们的清理流程整理成一个 skill，这样我以后每隔一段时间调用一次，就不用每次从头开始排查。Codex 答应得很干脆，但也给自己设了两条修正：快照占用必须实测，不能打包票说"释放十几 GB"；临时目录即使看不到进程占用，也要检查里面有没有源码、Git 改动或者验收记录。这两条都是从今天的实操里学到的教训，不写进 skill，下次还会踩坑。
接下来就是权限的拉扯。Codex 提示当前任务沙箱没有 ~/.codex/skills 的写权限，于是它先在工作区完成 skill 并自校验，最后给出一条安装命令。等到我在终端里放开"完全访问"再跑一遍，结果是通过的：mac-storage-cleanup 已经落到 /Users/chenjin/.codex/skills/mac-storage-cleanup/SKILL.md。以后一句话就能触发它：
使用 $mac-storage-cleanup 帮我清理磁盘空间。
它会复用本机的目录清单和历史基线，刷新容量、快照和进程占用后执行清理——不用我再重复描述问题。
那 80 GB 系统数据到底还剩什么
skill 装好之后，我又回头问了一句"刚刚那个 80 GB"。Codex 把它接住了，并明确告诉我：这部分还没继续清理，只是完成了 skill 安装。这是个很老实的回答——它没有装作已经把所有事都做了。
接着我继续追问，Codex 又清掉了约 2.18 GiB：clang 编译缓存、3 个旧 Ajin 包、一个闲置的 Edge 签名克隆。到现在，关于那 80 GB 已经有了相对清晰的画像：
- 有 6 枚可清除的 Time Machine 本地快照，实际占用尚未测得；
- VM 交换卷占 11.8 GB，不能直接删；
- 还有正在使用的微信、Edge、Codex 等进程的占用。
这是某会话自述里的总结。Codex 也明确说"无法据此认定那 80 GB 全是快照"，它没把不确定的事说死。我自己的判断是：真正能稳定清理的，是快照那一块——但必须先实测，再决定要不要冒险清掉。
一个值得记录的取舍
今天还顺手处理了一件小事：我让 Codex 把一段 HEVC 的视频转成兼容性更好的 H.264。它用本机 FFmpeg 走了一遍：先 ffprobe 读出参数，再用 h264_videotoolbox 硬件加速重编码，音频直接复制。结果是一段 40 分 57 秒、1280×720 的视频，从 1.52 GB 压到约 663 MB，原文件没动。
这跟主线的清理无关，但说明一件事：当流程被描述清楚时，Codex 能在本机直接调用工具完成任务，而不是只给出步骤。这给了我一个隐约的方向感——以后"让它执行"和"让它教我怎么执行"之间，会越来越倾向于前者。
今天的失败复盘
有几件事没做到位：
第一，skill 的封装过程被权限打断了一次，浪费了几轮对话。下次应该在动手前就确认权限边界，而不是默认能写 ~/.codex/skills。
第二，80 GB 系统数据的清理只做了一半就停了，原因是沟通切到了 skill 安装。等下次调用 $mac-storage-cleanup，第一件事应该就是让 Codex 实际测一遍 6 枚快照各自占多少，再决定要不要清。
第三，今天留下了几条没跟进的线索——比如微信容器的某些路径里还藏着什么、临时目录里还有没有未提交的验收材料。它们现在不是阻塞项，但再过一周很可能又会冒出来。
总的来说，这一天的主线是把"一次性清理"升级成"可复用流程"。skill 落地之后，我的工作方式会发生一个微妙变化：我不再需要每次都重新描述问题，只需要问"现在该清了吗"，剩下的由 skill 自己读基线、自己判断。这一点，比今天清出的那几个 GB 更值。