https://codexer.com/tags/%E7%A3%81%E7%9B%98/Recent content in 磁盘 on CodexerHugozh-cnWed, 09 Sep 2026 09:00:00 +0800https://codexer.com/posts/2026-09-09-codex-22gb-conversation-census/Wed, 09 Sep 2026 09:00:00 +0800https://codexer.com/posts/2026-09-09-codex-22gb-conversation-census/<p>想象一下，你用了 Codex 大半年，某天系统提醒你磁盘快满了。你打开磁盘分析工具，发现一个叫 <code>~/.codex</code> 的目录居然占了二十多 GB。你的第一反应很可能是：这些旧对话留着干嘛，删掉算了。</p> <p>但在动手之前，有一个更冷静的问题值得先问：这些字节里，到底装的是什么？如果不知道里面是什么，任何&quot;清理&quot;都等于蒙着眼睛删东西。</p> <p>Mint 的开发者做了一件很少人愿意做的事：他们把一台开发者 Mac 上整个 Codex 会话存储逐字节读了一遍。1,231 个文件、22.83 GB，每张内嵌图片都做了指纹，每个指纹都在会话内部和会话之间做了比对，每段会话都标注了最后使用时间。这不是抽样，是一次普查。而普查的结果，推翻了不少他们原本的假设。</p> <h2 id="十成字节里有七成是图片">十成字节里，有七成是图片</h2> <p>先说总量。22.83 GB 里，图片占了 16.18 GB，文字（提示词、工具输出、agent 的推理过程）只有 6.65 GB。剩下的东西不值一提：音频几乎为零，没有视频，也没有构建产物，只有藏在工具输出里的构建日志。</p> <p>真正有意思的，是图片内部的结构。16.18 GB 里，只有 3.81 GB 是存储只保存过一次的图片，剩下的大半都是重复：</p> <ul> <li>5.71 GB 是同一段会话里反复出现的截图，也就是上下文压缩机制在&quot;重新嵌入&quot;它刚刚总结过的内容；</li> <li>6.66 GB 是跨会话的重复截图，同一个终端、同一个被测页面，被几天后粘进了另一条线程。</li> </ul> <p>换句话说，这台机器上的&quot;对话历史&quot;，每十个字节里就有七个是像素，而其中不到两个字节是别处不存在的像素。</p> <p>文字也有类似的结构，只是规模小一点。6.65 GB 里，大约 2.7 GB 是被写了两遍的同一段文字：agent 每完成一步，既记一次&quot;步骤&quot;，又记一次&quot;完成该步骤的事件&quot;；一条命令的输出，既作为输出落一份，又作为聚合副本落一份，每份都封顶 1 MB。一条很长的构建日志，最多可以被存四遍。</p> <p>这里作者的态度很有意思：他们测出来了，但他们不去动它。因为这是 agent 自己的读取约定，一个会去改写&quot;别的程序依赖的数据&quot;的工具，就已经不是一个清理工具了。</p> <h2 id="重复的截图几乎都藏在最近里">重复的截图，几乎都藏在&quot;最近&quot;里</h2> <p>最常见的清理思路是按时长：给用户一个滑块，&ldquo;7 天没用、14 天、30 天&rdquo;，让用户清掉那些不再使用的东西。几乎每个存储工具都有这个滑块，Mint 一开始也做了。</p> <p>但等他们把会话内的重复截图按&quot;所在会话的年龄&quot;排个序，结果就反过来了：92% 的重复截图，都待在最近六天内还在使用的会话里。这台机器上最大的一个文件，1.76 GB、才 3.9 天新，光它一个就装下了 1.57 GB 的重复截图。而超过一个月的旧会话，加起来只有 0.02 GB。</p> <p>这不是某一台 Mac 的怪癖。重复是&quot;又长、又新、又截图密集&quot;的会话的属性：压缩机制只在会话长到需要它的时候才启动，而且它重新嵌入的是它自己所在会话里的图片。旧会话要么短、要么纯文字、要么两者都是。</p> <p>于是问题就来了：如果你从&quot;一周没碰的东西&quot;开始清理，你恰好绕开了几乎所有值得回收的空间。一个用户把滑块拖到七天、按下按钮、拿回 151 MB，实际上等于被告知&quot;里面啥也没有&quot;。可里面有 5.7 GB，只是它藏在滑块的另一头。</p>