sqlite-migrate 0.2：一份不起眼的“退休声明”
7月7日，开发者Simon Willison发布了sqlite-migrate 0.2。release note只有一句话：这个版本让sqlite-migrate自我“退休”，只保留一个对接新版sqlite-utils的兼容垫片。
乍一看这是件小事——一个几千行代码的SQLite迁移小工具，功能被主库收编，剩个空壳向后兼容。这种整合路径在开源世界很常见：卫星包成熟后并入核心库，原包降级为兼容层，保住存量用户的代码不报错。
但把时间线拉长两周看，这条release note背后藏着一个更值得记下来的细节：这次库合并的大部分代码，是AI写的。
两周前发生的事，才是关键
sqlite-migrate和sqlite-utils是一对师徒关系。sqlite-utils是Willison长期维护的SQLite命令行/Python工具库，支撑着Datasette等一系列项目；sqlite-migrate是他后来单独拆出来、专门处理数据库schema迁移的配套库——SQLite的ALTER TABLE能力本来就有限，这是所有同类工具都要绕开的共同限制。
时间线是这样的：
6月21日，sqlite-utils 4.0rc1发布，正式把迁移功能内置进核心库，新增了Migrations API和sqlite-utils migrate命令。Willison在当时的说明里承认，这是sqlite-migrate实现的“a slightly modified port”——原样搬过去，稍加改动。
真正引人注意的是7月5日的4.0rc2。Willison在这个版本的标题里直接写明：这版“主要由Claude Fable编写”，花费约149.25美元。也就是说，把sqlite-migrate的迁移逻辑搬进核心库、打磨成正式功能的这部分工作，很大程度上是一个AI agent做的，而不是Willison自己一行行敲出来的。
7月7日的sqlite-migrate 0.2，只是把这条已经走完的整合路线，补一个兼容壳收尾。
- 结论.一个独立维护者用不到150美元的成本，让AI agent完成了核心基础设施库的一次功能级重写，这比“库退休”本身更值得记住。
谁该关心，谁该动
对现有sqlite-migrate用户来说，这次变动不是紧急警报。PyPI上的项目页面已经把它标注为“deprecated compatibility package”，建议新项目直接用sqlite-utils 4；老项目短期内不改代码也能跑，兼容垫片就是为了这个存在的。但sqlite-utils 4目前仍停在rc阶段（截至rc2），迁移相关的API是否还会调整，还没有定论——想升级的人最好等正式版。
放进更大的SQLite迁移工具版图里看，sqlite-migrate的位置变了。此前它是一个可以单独拿来用的选项；现在它只是历史兼容层，新项目的选择基本收窄到三条路：纯SQLite场景直接用sqlite-utils，想要SQL优先加显式回滚可以看yoyo-migrations，用SQLAlchemy或未来可能迁移到Postgres/MySQL的项目还是Alembic更合适。
一个小库的退休不算新闻，一个独立维护者敢让AI写核心库才算。
留白的问题也很明确：Willison没有说清楚“主要由Claude Fable编写”具体是什么程度——是AI生成草稿、人工逐行审核，还是接近全自动提交。约149.25美元这个成本相对于人工重写一个核心模块意味着什么，同样没有展开。这类细节现在只能靠等他后续披露，或者等sqlite-utils 4.0正式版发布时对照代码变化去反推。
- 风险.AI主笔的核心库代码审核标准和边界如果不透明，下游项目升级时的信任成本会转嫁给使用者。