sqlite-utils 4.0rc2：主要由 Claude Fable 编写的版本发布（成本约 $149.25）

背景

sqlite-utils 是一个流行的 Python 库，用于简化 SQLite 数据库的增删改查和转换操作。作者 Simon Willison 在几周前发布了 4.0rc1 候选版本。由于他的 Claude Max 订阅（每月 $200）仅在 7 月 7 日之前包含对 Claude Fable（Anthropic 的高性能模型）的无限制使用，他决定在订阅到期前利用 Fable 来推动 4.0 正式版达到完全可靠的状态。他坚持语义化版本控制（SemVer），希望尽量让不兼容的大版本变更变得罕见，因此需要彻底的最终审查。

核心内容

作者通过 iPhone 上的 Claude Code for web 发起了一次提示（prompt），要求对即将发布的 4.0 稳定版进行最终审查，重点找出那些如果事后修复会成为破坏性变更的问题。Claude Fable 生成了一份初始报告，其中发现了若干严重问题，Fable 将其中的 5 个归类为“发布阻塞器（release blockers）”。最严重的一个 bug 如下：

delete_where() 从不提交事务，并污染连接状态，导致数据丢失
Table.delete_where()（位于 sqlite_utils/db.py:2948）直接通过 self.db.execute() 执行 DELETE 语句，没有包裹在 atomic() 上下文管理器中。相比之下，Table.delete()（位于 db.py:2944）则正确地使用了事务包装。执行后，连接处于 in_transaction=True 状态，导致后续所有 atomic() 调用都走保存点分支（db.py:430-440），从而永远不提交。端到端验证：插入三条记录，执行 delete_where，再插入一条记录和另一个表，关闭数据库重新打开后，发现 delete 操作、新插入的行以及整个新表全部丢失。

这是一个非常严重的 bug，幸好没有随 RC 发布出去。不过即便发布了，也属于可以在 4.0.1 补丁版本中修复的缺陷，而不是需要强制升级到 5.0 的设计缺陷。

在后续的 37 轮提示、34 次提交、涉及 30 个独立文件的 +1,321 / -190 行代码修改中，作者与 Fable 逐一处理了所有反馈，并沿途做了若干设计改进。编码 agent 的一个奇特之处在于，像这样难度较大的任务反而为同时做其他事情提供了更多机会——因为 agent 有时需要 10–15 分钟才能完成新任务。作者利用这些时间出去享受了半月湾 7 月 4 日独立日游行，偶尔用手机查看进度并提示 Fable 下一步。

最显著的变化是事务处理机制——这是前一个 RC 版本的标志性新特性。新 RC 增加了关于新事务模型的详尽文档，核心要点包括：

• 库中每个写入方法（insert()、upsert()、update()、delete()、delete_where()、transform()、create_table()、create_index()、enable_fts() 等）都在自己的事务中运行，并在返回前提交。方法调用完成后，更改立即保存到磁盘。
• 使用 db.execute() 执行的原始 SQL 写入语句同样在运行后立即提交。
• 用户永不需要调用 commit()，也无需关闭数据库来持久化更改。只有两种情况需要考虑事务：1）希望将多个写入操作分组确保全部成功或全部失败 → 使用 db.atomic()；2）自己通过 db.begin() 管理事务，此时库不会提交你开启的事务。

Fable 在文档中还指出：db.atomic() 和自动逐方法事务是为 Python 默认事务处理模式的连接设计的。Python 3.12+ 引入的 sqlite3.connect(..., autocommit=True) 或 autocommit=False 选项创建的连接不被支持，因为这些连接上 commit() 和 rollback() 的行为不同。作者承认之前没考虑过 sqlite-utils 如何应对 Python 3.12 的新 autocommit 设置，结果发现该差异会导致几乎整个测试套件失败，于是与模型协作确保库能正确处理这种差异。

最终审查由 GPT-5.5 进行
作者曾认为让一个模型审查另一个模型的工作有些荒谬，像是迷信。但实践证明这很有效——他养成了让 Anthropic 的最佳模型审查 OpenAI 的工作，反之亦然的习惯，因为经常能发现有趣的问题。他使用 Codex Desktop 和 GPT-5.5 xhigh 提示“审查自上次 RC 以来的变更，并确认 changelog 是最新的”。这发现了两个值得调查的问题：

1. db.query() 的副作用：db.query() 在调用 db.execute() 之后才拒绝非行返回语句，且 db.execute() 会自动提交写入操作。因此 db.query("update ...") 会先提交更新，然后才抛出 ValueError。这是文档中“只能用于返回行的 SQL”方法的意外副作用。
2. INSERT ... RETURNING 的事务不完整：通过 db.query() 执行 INSERT ... RETURNING 时，提交操作位于返回的生成器末尾。如果调用者不遍历生成器（如只取 next(db.query(...)) 或完全不迭代），事务会保持打开，写入可能在关闭时回滚。这与 changelog 和文档中“无需迭代即可生效”的承诺矛盾。

作者将这些发现粘贴到一个新的 Fable 会话中，Fable 运行实验确认了问题，并进行了修复。

成本估计
作者升级到 Claude Max $200/月计划（之前是 $100/月）以在 7 月 7 日 Fable 末日（Fablepocalypse，届时即使是 Claude Max 订阅者也要为模型支付完整 API 费用）之前提高 Fable 配额。他好奇如果直接按 API 付费会花多少钱。一开始觉得无法获得这些数字，因为他在远程使用 Claude Code for web，但后来发现在该会话中运行 uvx agentsview --help 并利用 session list --include-children 命令即可估算成本。结果显示该会话的预估（无补贴）成本为 $149.25。订阅计划显然非常划算。作者还提到应该更早采纳自己的建议，更多地利用低价模型的子 agent（subagents）。

他在多个其他主要的 Fable 驱动项目上同步推进，目标是在价格上涨前将 Fable 使用进度条打到 100%。

完整的发布说明在 changelog 的“Unreleased”部分，每项变更落定时由 Fable 添加并由作者审查。

关键要点

• 严重 bug 发现：delete_where() 缺乏事务包装导致连接被污染，后续所有写入操作均不会被提交，造成数据丢失。这是 AI 审查直接抓出的关键缺陷。
• AI 辅助开发效率：通过 37 轮提示、34 次提交、涉及 30 个文件的代码修改，借助 Claude Fable 完成了从 RC 到稳定版的重大修复和改进，耗时约 10–15 分钟/轮，作者可以同时处理其他事务。
• 交叉审查价值：让不同厂商的顶尖模型（Claude Fable vs GPT-5.5）互相审查对方生成或修改的代码，能够发现各自忽略的问题，作者已将此养成习惯。
• 事务模型重构：新 RC 引入了自动逐方法提交的事务模型，并提供详细文档澄清常见误解（无需手动 commit、区分原子性批量操作和手动事务），同时明确了与 Python 3.12+ autocommit 模式的不兼容性。
• 成本效益：该次开发在当前订阅计划下仅花费 $149.25（按 API 直接付费估算），而一个月 $200 的订阅可覆盖多个类似项目，性价比极高。
• 文档先行审查：作者发现先查看 AI 生成的文档编辑，是快速理解代码变更的绝佳方法。

意义与影响

这次 sqlite-utils 4.0rc2 的发布过程展示了大型语言模型在真实开源项目维护中的巨大潜力。它不仅是自动补全或简单代码生成，而是通过多轮对话、错误发现、文档撰写、跨模型审查