距离 sqlite-utils 4.0 发布只过了几天,Simon Willison 又把 4.1 放了出来。这是一次典型的点版本更新:六个新特性,大多是命令行工具的边角打磨——--code 允许用一段 Python 代码直接生成待插入的行,--type 能强制指定 CSV/TSV 导入时某一列的类型,新增 drop-index 命令,query 命令可以从标准输入读 SQL,upsert 现在能自动识别已有表的主键而不必每次都写 --pk。单看这份清单,像极了一份普通的维护日志。
但这次更新真正有意思的地方,不在功能本身,而在这些功能是怎么被挑出来、又是怎么被验证的。
STRICT 不是新功能,新的是"搬家"能力
六项更新里分量最重的一条,是 table.transform() 和 CLI 的 transform 命令新增了 strict / --strict 开关,可以在 SQLite 的 STRICT 表模式和普通模式之间迁移已有表。这条功能来得很快——起因是 Evan Hahn 那篇《Prefer STRICT tables in SQLite》当天在 Hacker News 上引发讨论,Willison 看到后当天就实现并发布了对应能力,响应速度不算慢。
容易让人误会的一点是:STRICT 模式本身并不是 sqlite-utils 4.1 才引入的,更早的版本就已经支持在建表、插入、更新时指定 --strict。4.1 补的是一个更具体的缺口——已有的表怎么从非 STRICT 转成 STRICT。SQLite 官方从来没有提供 ALTER TABLE 直接切换的机制,唯一的办法是把数据整体复制到一张新建的 STRICT 表里。sqlite-utils 的 transform 机制原本就是干这个的(改列类型、加约束都靠它),这次只是把"改变 strict 属性"也塞进了同一套复制迁移的通用逻辑。换句话说,这不是 SQLite 能力的进步,是应用层对 SQLite 长期缺陷的一次绕行。
issue 优先级,正在从人工经验判断变成 AI 筛选
谁来决定下一个该修的是什么
upsert 自动推断主键这项,来源更值得琢磨。Willison 在发布说明里提到,这是他让 Codex 审查了所有开放的 issue、挑出"最容易实现的"之后冒出来的建议——一个显而易见但此前一直没人补上的 CLI 缺口,恰好对应了 4.0 版本里 Python API 已经做过的改进。
这意味着 issue 优先级排序这件事,开始有了另一种做法:不再完全靠维护者凭经验判断"哪个最痛"或"哪个用户催得最多",而是让模型先扫一遍全部积压的 issue,标出实现成本最低的那批。对独立维护者或小团队而言,这套流程的吸引力很直接——省下的是筛选和评估的时间,而不是编码本身的时间。局限也同样直接:模型挑出来的"容易实现",不代表"最该修",低垂的果子摘完了,难啃的骨头照样得靠人。
让 AI 自己去"手动测一遍"
真正暴露出问题的,是 Willison 在实现 STRICT 迁移功能时用的一个提示词。他没有止步于让模型写完代码、跑完自动化测试就收工,而是额外要求:用 uv run python -c 手动执行一遍新的 .transform(strict=) 选项,自己去找边界情况和 bug。
结果这一步真的挖出了两个此前测试没有覆盖到的边界问题,随后被修复。这个细节比功能列表本身更值得记住:自动化测试通过,不等于代码没有漏洞。写测试的人和写实现的人如果是同一个模型,盲区很可能是重合的——模型会按自己对功能的理解去设计测试用例,而边界情况恰恰容易出在"理解之外"的地方。多让它跳出既有测试框架、用交互式命令行去"手工"敲一遍,是一层不同性质的验证,不是重复劳动。
- 风险.自动化测试通过不代表没有边界 bug,探索性的人工/手动验证仍然是必要的最后一关
这套"AI 筛 issue、AI 写实现、人工再指挥 AI 做一次探索性验证"的三段式,对其他开源维护者有多大复制价值,现在还很难下结论——它更适合 sqlite-utils 这类维护者本人就是核心决策者、代码库边界清晰的小型项目,协作复杂、评审流程重的大型项目未必能直接套用。但对于长期靠个人业余时间维护冷门工具库的开发者来说,这至少提供了一个可验证的思路:优先级判断可以外包给模型,但"这段代码到底靠不靠谱",最后一道关卡还得有人亲自去点一遍。