文章归档

AI 编程工具最容易被低估的能力，不是一次性写出多少代码，而是能不能把一个任务从需求、修改、验证一路推进到可交付状态。很多团队在试用 AI 时，会把关注点放在“代码是不是能生成”，但真正影响效率的，是生成之后的闭环有没有建立起来。

如果只让 AI 写代码，不让它读项目约束、运行验证命令、说明风险边界，最后节省的时间很可能会被人工复查和返工抵消。更稳定的做法，是把 AI 当成一个可以执行任务的工程协作者，而不是一个只负责补全片段的工具。

AI 编程工具真正影响效率的地方，不只是“能不能写代码”，而是能不能稳定理解项目上下文。很多时候，同一个需求第一次让 AI 做，结果还可以；过几天换个窗口、换个模型、换个入口，再让它做类似任务，质量就开始波动。

原因通常不是模型突然变差，而是上下文没有被工程化管理。项目背景、目录约定、构建命令、测试方式、代码风格、风险边界都靠临时口头描述，AI 每次都要重新猜。

每天写技术博客最容易卡住的地方，往往不是不会写，而是流程太碎：选题、确认仓库格式、创建 Markdown、补 front matter、检查构建、再执行部署。每一步都不复杂，但合在一起就会变成一种阻力。

Codex CLI 适合处理这类重复性内容工作。它可以在当前仓库里阅读已有文章，理解 Hexo 的目录结构和 front matter 约定，然后按同样的风格新增文章。再配合一个小脚本，就可以把“生成今日文章”和“部署到 GitHub Pages”合成一个稳定入口。

一、问题背景

本地使用 Codex CLI 时，如果日志级别过细，~/.codex/logs_2.sqlite 可能会持续写入大量 TRACE / DEBUG 日志。

这类问题不一定会立刻表现为程序异常，但会带来几个隐患：

• SQLite 主库文件持续变大。
• WAL 文件频繁增长。
• 磁盘出现持续小块写入。
• 日志价值不高，但占用大量 IO。
• 长时间运行后影响终端工具响应。

这次排查的目标很明确：

1. 确认 logs 表是否被 TRACE 日志高频写入。
2. 如果中招，先备份数据库。
3. 使用 SQLite trigger 拦截 logs 表 insert。
4. 对 WAL 执行 checkpoint / truncate。
5. 采样确认 MAX(id) 和 WAL 不再增长。

一、Codex CLI 是什么

Codex CLI 是 OpenAI Codex 的命令行工具，适合在本地终端里处理真实代码仓库中的开发任务。它可以读取当前项目、执行命令、修改文件、运行测试、解释代码、做代码审查，并且会根据权限配置决定什么时候直接执行、什么时候向你确认。

简单理解：

• 在 IDE 中写代码时，可以把 Codex CLI 当成一个“终端里的结对编程助手”。
• 在已有项目中排查问题时，可以让它先阅读代码，再给出修改方案并直接落地。
• 在重复性任务中，可以用非交互命令让它批量完成检查、重构、生成文档等工作。