文章归档

GitHub 上的 AI 项目增长很快，但不同指标代表的含义不一样。累计 Star 更像是长期认可度，适合观察生态里已经被大量开发者验证过的工具；Trending 今日新增 Star 更像是短期热度，适合发现正在爆发的新方向。

一、问题背景

本地使用 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 不再增长。

一、AI 适合做什么样的代码评审

AI 做代码评审，不应该只当成“自动找 bug”的工具。更合理的定位是辅助阅读、整理上下文、发现遗漏，并把评审者的注意力集中到高风险位置。

一、Codex CLI 是什么

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

简单理解：

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