Simon Willison发布了sqlite-utils 4.0rc4——4.0稳定版之前的最后一个候选版本。发布说明只有一句话:主要是吸收了「Claude Fable 5」对代码的一次详细审查意见,对应到GitHub issue 769里的一条评论。
这话说得轻描淡写,但拆开看没那么简单:这段代码本来就是Claude Fable自己写的。这次不是人审AI,是AI审自己写过的代码。
审查揪出了两个隐藏bug
时间往回倒一点。rc2的代码主要由Claude Fable生成,Willison给出的估算是:未补贴成本$149.25。到了审查这一步,他给的prompt原文很直白:「Review changes since the last RC. Also confirm that the changelog is up-to-date.」——review自上一个RC以来的改动,并确认changelog是最新的。
就是这么一句普通指令,审出了两个P1级问题,都跟数据库事务有关:一个是db.query()执行update语句时,ValueError要等写入已经提交之后才抛出来;另一个是执行INSERT...RETURNING时,只有生成器被完全迭代完才会提交,写到一半就撒手,数据在连接关闭时会被悄悄回滚。这两种情况都不是语法错误,是那种代码能跑、偶尔炸雷的类型。Willison确认两处都在正式发布前修掉了。
- 结论.这两个bug不是走过场式的代码风格建议,是真会导致写入时机错乱、数据丢失的事务级问题,说明AI code review在特定场景下有实打实的工程价值。
sqlite-utils到底要解决什么
4.0这个大版本,核心新东西是内置的数据库schema迁移系统:一个Migrations类,加一条sqlite-utils migrate命令,迁移状态记录在_sqlite_migrations表里。
在这之前,纯SQLite项目做迁移基本靠三条路:Alembic(SQLAlchemy生态的标准工具,但对不用ORM的项目偏重)、yoyo-migrations(独立于ORM,但要单独维护一套迁移文件)、还有Willison自己写的插件sqlite-migrate——目前在PyPI上还标着「early alpha」。4.0把迁移能力直接塞进主库,等于让自己这款早期插件被自家新功能边缘化。
对已经在用sqlite-migrate的用户,这是个必须面对的选择题:要不要迁到内置方案。对更多Datasette生态里的开发者来说,好处是省了一层依赖——不用为了给SQLite项目加迁移功能,专门去学一套本是给SQLAlchemy准备的Alembic。
左手写代码,右手审代码
真正有意思的地方在这。既当运动员又当裁判,是最古老的信任问题之一,这次只是换成了AI的版本:同一个模型,先写代码,再审代码。
自己写的代码,未必审得出自己的盲区
这次结果还不错——两个真实的事务bug被抓出来了,不是虚晃一枪。但这恰恰也是该多问一句的地方:审查者和编写者出自同一套训练、同一种写法习惯,能挑出「明显能跑但时机不对」的bug,不代表能挑出「这套设计思路本身就有洞」的问题。人类代码审查强调换一个人、换一个视角,图的就是这个——同一个人反复看自己的代码,容易对自己的习惯性盲点视而不见,AI大概率也逃不开同样的逻辑。
- 风险.审查者与编写者同源,独立性打了折扣,能抓具体bug,未必能抓设计层面的系统性问题。
Willison在issue里说,经过两轮RC,这个版本已经「pretty well baked」,眼下在用datasette和llm自己的测试套件做交叉验证——这其实比单纯信AI审查更靠谱,相当于拿两个独立、成熟的真实项目当活体测试床。
一个还没查实的细节
检索时,GitHub上公开的发布列表页只看得到4.0a0、4.0a1两个预发布版本,以及3.39这个最新的正式稳定版,没能找到rc4的发布记录。这很可能只是索引滞后——rc版本发布节奏快,页面缓存跟不上很常见——但既然查不到,就不该替读者把这一步默认为已核实。想升级或者想看这次改动细节的人,最好自己上GitHub确认一下当前实际的release列表。
真正该盯的,是接下来sqlite-utils 4.0正式版什么时候落地、迁移指南会不会跟着配齐,以及issue 769最终怎么收尾。AI审代码这件事本身没那么玄乎——它更像一面镜子,照得出具体的裂缝,但照不出镜子自己歪在哪。