我一开始以为 Codex 越用越卡,是我自己活该。
平时拿它跑项目、看代码、改页面,偶尔还让它干一些奇怪的小活。机器卡一点,我第一反应不是怀疑工具,是怀疑自己:是不是开太多窗口了,是不是项目太大了,是不是 Windows 又开始抽风了。
后来我看了一眼本机日志库,发现事情有点不对。
在我的 ~/.codex 目录里,logs_2.sqlite 主库已经到了几百 MB,旁边的 logs_2.sqlite-wal 也不小。更夸张的是,我做了一个 30 秒的安静窗口:脚本只记录起点,等 30 秒,再记录终点,期间我不操作 Codex。
结果新增可见日志大概 1130 行,其中 TRACE 级日志 1093 行,差不多 37 行每秒。
先说边界。
这不是官方 bug 定性,也不是说 Codex 一定会写坏你的硬盘。我这里讲的是本机观察到的现象,以及一个普通用户可以怎么做只读排查。日志正文里可能有路径、请求和工具调用,别截图乱发,也别把原始 sqlite 传给别人。
这件事真正值得讲的地方,不是“抓到一个离谱数字”。
它提醒我们:AI 工具现在越来越像一个小系统。回答之外,它还会写日志、写缓存、建索引、维护状态。你只看到前台那个聊天框,但后台成本会落在你的机器上。
别先删库,先看它到底在不在写
很多人看到一个日志库变大,第一反应是删。
这一步太急了。
如果程序还在运行,你一边开着一边删,轻则没效果,重则把当前状态搞乱。更麻烦的是,你删完以后只知道“空间回来了”,不知道问题是不是还在继续发生。
先查。
最小排查只看四件事:
- 主库
logs_2.sqlite有多大。 - WAL 文件
logs_2.sqlite-wal有多大。 - 最近一段时间 TRACE 级日志有多少。
- 安静 30 秒,新增了多少行。
这里的关键词是“安静窗口”。
你不要一边让 Codex 跑任务,一边测写入。那样测出来的结果没有意义。先停下操作,记录起点,等 30 秒,再看终点。如果这 30 秒里你什么都没做,日志还在高频增加,才值得继续追。
我这台机器当时看到的是:30 秒新增约 1130 行,TRACE 约 1093 行,约 37 行每秒。
这个数字不一定会发生在每个人机器上。也正因为不一定,所以文章里的重点不是让你相信我的数字,而是让你学会测自己的。
为什么只看聚合,不看正文
日志正文很诱人。
你打开数据库,看到一堆字段,就想直接搜到底是谁在写、写了什么、哪一行最大。技术上当然可以做。
但我不建议普通用户第一步这么干。
因为日志里可能带着路径、请求、工具调用、文件名,甚至你刚刚让 AI 处理过的内容线索。你把这些东西截图发到群里,或者丢给另一个工具分析,本来是排查性能问题,最后变成隐私问题。
所以最稳的做法是:只读、聚合、不打印正文。
只读,是不要改数据库。
聚合,是只看数量、级别、大小、时间窗口。
不打印正文,是不要把具体日志内容吐出来。
这也是我为什么把资源块里的脚本写成只输出这些东西:
- DB size
- WAL size
- before / after count
- max id 变化
- 新增可见行数
- 每秒新增行数
- 按 level 汇总
这些数字足够判断“有没有高频写盘”。你不需要把日志正文翻出来审判。
TRACE 级日志是什么问题
日志级别里,TRACE 通常是非常细的追踪信息。
它对开发和调试很有用。程序哪里进了哪个函数,哪个模块在跑,某个内部状态怎么变,这些都可能写到 TRACE 里。
但问题是,普通使用场景不一定需要这么细。
如果一个桌面工具或 CLI 工具在常规使用时持续写大量 TRACE,成本就会从“帮你排查问题”变成“持续占用你的磁盘和 I/O”。这件事对大多数用户来说没有体感,直到某天工具变卡、风扇变吵、磁盘空间变少,才反应过来。
我这里看到的还有一个细节:总行数没怎么变,但新 id 还在增加。
这说明它可能不是简单地无限追加。更像是一边写新日志,一边清旧日志,或者做某种轮转。这个判断要加“可能”,因为我没有拿官方实现做结论。
但对普通用户来说,够了。
你要判断的不是它内部机制到底优雅不优雅,而是:在你不操作的情况下,它是不是还在高频写。
真正该带走的是一句提示
这期最有用的东西,其实不是那张梗图,也不是 37 条每秒这个数字。
是这句话:
帮我检测 ~/.codex/logs_2.sqlite 是否因 TRACE 日志持续高频写盘?
你可以直接复制给 Codex。
然后加上几个限制:
不要打印日志正文,不要上传 sqlite 文件。
只看主库体积、WAL 体积、最近 60 秒 TRACE 数量。
再做一个 30 秒静默窗口,输出新增行数、TRACE 行数和每秒新增行数。
这句话的价值在于,它不是让 AI 给你讲一篇“如何优化电脑性能”的泛泛建议。
它让 AI 去查一个具体文件、一个具体级别、一个具体时间窗口。
AI 工具排查本地问题时,最怕你问得太抽象。你问“为什么我的电脑卡”,它会给你一堆通用建议。你问“帮我检测这个 sqlite 是否因 TRACE 日志持续高频写盘”,它才会沿着一个明确路径查。
如果确认很夸张,别边运行边删
如果你测出来的数字很正常,那就不用折腾。
如果你也看到很夸张的 TRACE 写入,先别做两件事:
第一,不要把原始日志库传给别人。
第二,不要在 Codex 还开着的时候,直接删 logs_2.sqlite、logs_2.sqlite-wal、logs_2.sqlite-shm。
更稳的顺序是:
- 先让 Codex 停止当前任务。
- 完全退出 Codex。
- 备份日志库,而不是直接永久删除。
- 重启确认能生成新的日志库。
- 更重要的是,让 Codex 关闭 trace 级日志。
- 再做一轮静默窗口,看每秒新增行数有没有掉下来。
这里要强调一下:移动或备份日志库,只是止血。
真正要处理的是 trace 级日志为什么持续高频写。如果不关掉这个级别,你今天移走一份,明天可能又长回来一份。
这件事给普通 AI 用户的提醒
很多人学 AI 工具,只盯着它会不会干活。
会不会写代码,会不会剪视频,会不会做表格,会不会查资料,会不会帮我省时间。
这些当然重要。
但你用得越深,就越要开始看另一层:它在你机器上留下了什么成本。
一个工具可能很聪明,但它也可能有日志、缓存、索引、模型文件、临时渲染、数据库、浏览器 profile。你让它替你干活,它就会在某个地方写东西。写得合理,那是工程需要;写得太猛,就会变成你机器上的隐性账单。
这不是让你怕工具。
正好相反。越是要长期用工具,越要学会检查它。
就像你不会因为车能开,就从来不看油耗、胎压和保养记录。AI 工具也是一样,前台回答得再漂亮,后台日志、缓存和成本也要偶尔看一眼。
我的建议很简单:
- 看到工具越来越卡,先别急着玄学重装。
- 看到日志库变大,先别急着删。
- 先做只读聚合检测。
- 确认是 TRACE 高频写入,再关 trace。
- 处理完再复测。
这比“删了再说”慢一点,但它能让你知道问题到底在哪里。
最后
这期的结论很短:
别只问 AI 能不能帮你干活。
也要偶尔查查,它有没有在帮你干硬盘。
如果你用 Codex 已经很久,尤其是感觉越来越卡、.codex 目录越来越大,可以先用上面的提示词查一轮。数字正常就放过它。数字不正常,再处理。
工具是帮你上桌的,不是悄悄把你硬盘拖进 ICU 的。