文章归档

代码审查最重要的价值，不是把变量名挑得更整齐，而是尽早发现行为风险、边界遗漏和维护成本。AI 工具可以快速阅读 diff、追踪调用链、补充测试思路，但如果直接问“这段代码有没有问题”，得到的答案往往很泛，甚至会把风格偏好包装成严重缺陷。

更稳定的做法，是把 AI 放进一个明确的审查流程里：先限定审查范围，再按风险分层阅读，最后把发现的问题转成可执行的整改项。这样它不是替代人工判断，而是帮助维护者更快看清变化背后的影响面。

AI 编程工具的效果，很多时候不是由模型本身单独决定，而是由它拿到的上下文决定。同一个需求，如果只给一句“帮我修一下登录问题”，输出往往会很泛；如果补充项目结构、复现步骤、日志、约束和验证命令，AI 就更容易给出可落地的修改。

上下文工程不是写更长的提示词，而是把项目里真正影响判断的信息组织好，让 AI 在开始动手之前就知道边界、目标和验收方式。对个人项目和团队项目来说，这比临时追问更稳定，也更容易复用。

重构最怕的不是代码改得多，而是改完以后说不清楚行为有没有变化。AI 工具能很快移动代码、抽函数、改命名、补类型，但如果缺少边界和验证，大规模重构很容易从“改善结构”变成“引入不确定性”。

更稳妥的做法，是把 AI 当成一个执行力很强的工程助手，让它在明确目标、有限范围和可重复验证的约束下工作。重构不应该一次性追求“变得优雅”，而应该被拆成一组可以审查、可以回滚、可以证明行为不变的小步骤。

AI 工具已经可以很快生成一个功能、修复一个问题，甚至顺手补上测试。但在真实项目里，“能生成”不等于“能合并”。代码进入主干之前，仍然需要经过可读性、边界条件、兼容性、测试和运维风险的检查。

更实用的做法，是把 AI 生成代码后的审查过程固定成一张清单。这样每次变更都能从“看起来能跑”推进到“可以被团队维护”，也能减少人工 review 时反复追问上下文的成本。

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

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

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

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

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

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

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”的工具。更合理的定位是辅助阅读、整理上下文、发现遗漏，并把评审者的注意力集中到高风险位置。