sqlite-utils 4.0rc2:Claude Fable 揪出一个会静默丢数据的事务bug

sqlite-utils是Python生态里常用的SQLite操作库,独立开发者Simon Willison维护多年。7月5日,他在博客里公布了这个库4.0版本的第二个候选版rc2,同时说了一件不太寻常的事:这一版的大部分代码改动,是他和Anthropic的代码代理Claude Fable一起做的,过程中拦下了一个足以让用户数据"悄悄消失"的事务bug。

这件事的看点不是"AI写了多少代码"。真正值得记的是,Willison把Fable用在了发布前的质量审计上,而不只是补功能——这活儿以前基本靠维护者自己一行行看PR。

sqlite-utils 4.0rc2:一个事务bug差点被带进正式版

两周前的4.0rc1里,sqlite-utils引入了新的事务管理机制db.atomic()。rc2上线前,Willison给Fable下了一道提示:做一次最终审查,专门找那些发布后没法轻易修的破坏性问题。

Fable报告了5个"release blocker"级别的问题,最严重的一个出在Table.delete_where()方法上。它执行删除时没有走atomic()事务包装,导致数据库连接被卡在"事务未提交"状态。这条链路之后,每一次新的写入都会被当成子事务处理,而这个子事务永远不会真正提交。

后果很直接。执行delete_where()之后再插入的新数据,甚至另一张表的写入,只要程序关闭连接,全部被静默回滚。同一连接里读取一切正常,数据是在关闭那一刻无声消失的。

Willison说自己很庆幸没把这个问题带进正式版。他一直坚持SemVer规范,不希望破坏性变更太频繁——如果是4.0.1里发现,还能当补丁修;要是设计层面的语义缺陷混进了稳定版,那就得等5.0才能改。

这一轮改动规模不小:37次提示、34次提交,涉及30个文件,增删代码1321行和190行。sqlite-utils 4.0rc2目前仍是候选版,不是正式稳定版——这一点值得说清楚,因为它决定了现在该不该在生产环境里换版本。

真正的变化是发布流程,不是代码量

这次协作里,Fable承担的不只是修bug,它还牵出一个背景限制:Python 3.12新增了sqlite3.connect(..., autocommit=...)参数,这个参数会让commit/rollback的行为,和sqlite-utils原有的事务假设完全不一样。Willison承认自己此前没考虑过这层兼容性。修复之后,sqlite-utils遇到不兼容的连接模式会直接报错拒绝,不再悄悄出错。

真正体现"审计"而不是"代码生成"的一步,发生在后面。Willison把改动交给了另一个模型交叉复核——用GPT-5.5配合Codex Desktop,检查改动是否完整、changelog是否同步。

这两个新发现的P1问题,都和sqlite-utils自己的文档承诺不一致。一个模型审另一个模型的活儿,Willison说他以前觉得这个做法有点迷信,现在已经变成习惯动作——因为确实经常能翻出东西。

但这套流程没有一步是自动的。触发复核、判断哪些改动算"破坏性变更"、决定要不要因此推迟发布,全是Willison自己做的决定。对正在用sqlite-utils的开发者来说,现在能做的动作很具体:如果项目里用到delete_where()且之后紧跟写入操作,先升级到rc2测试环境跑一遍,确认旧版本里是不是已经吃过这个静默丢数据的亏,再决定要不要等正式的4.0稳定版。

149.25美元买的是什么,谁在为这套流程付钱

Willison为了在Anthropic收紧Fable优惠额度前多用几天,把订阅从每月100美元升级成了200美元的Claude Max套餐。他后来用一个叫AgentsView的工具,估算了这次工作如果按API直接计费要花多少钱。

这149.25美元不是Willison实际付的账单。他用的是200美元包月套餐里的额度,这个数字只是拿API计费口径做的一次成本估算,不代表真实花销。

这个数字对独立维护者和小团队有参考价值:一次发布前审计,如果按次计费接近150美元,包月订阅显然更划算。但这也说明,代码代理介入发布流程目前还谈不上零成本——尤其考虑到Anthropic已经宣布7月7日起,连Max订阅用户也要为Fable按全额API价格付费。团队如果打算把这类审计流程常态化,预算这一项躲不掉,值得提前和采购或财务对一下账。

接下来最该盯的,不是Fable还能挑出多少bug,而是跨模型交叉复核会不会变成开源发布的标配动作——以及维护者愿不愿意为此常态化多花这笔审计成本。