大家好，我是Carl。你可能记得我，就是那个教Claude使用Antithesis的人。

今年早些时候，SQLite发布了3.51.3版本，修复了一个在Write-Ahead Logging（WAL）子系统中存在多年的bug——WAL-Reset bug。这个bug从2010年就潜伏在代码里，但SQLite团队似乎直到今年才意识到它的存在。正如他们在发布说明中所写：这是一个时序约束非常紧的数据竞争，在日常使用中不太容易出现；开发者从未在真实场景中复现过它，不得不专门给SQLite添加了刻意触发该bug的测试逻辑，才能验证问题已经修复。

打开网易新闻 查看精彩图片

读到这条消息时，我正和女朋友在公路旅行中。不过我也是个重度数据库爱好者，所以立刻就被这个bug“狙击”了。SQLite的bug本来就罕见得近乎传奇，而这个bug更像是完美的“棕M&M”：一个已知的、有挑战性的问题，正好可以用Antithesis追根究底。更何况，我刚刚把Claude的技能推送上线。

于是，坐在阳光海岸的山坡上，我掏出手机，让Claude开始干活。我让它把仍然有问题的SQLite 3.51.2装进Antithesis，并在代码里加入大量Antithesis断言。它随后写了一个非常简单的测试负载，用来同时触发WAL插入和检查点逻辑。

需要强调的是，这个负载本身完全没有特殊之处：只是并发地执行写入和检查点，相当于生产环境中每天都在发生的普通操作。而断言也都是数据库里最常规的不变量，比如“已提交的写入不能丢失”“数据库不能损坏”——也就是SQLite里的integrity check。

我们实际跑下来，Antithesis很快就复现了那个看似极难触发的数据竞争，并且精准定位到了WAL-Reset bug的行为。一个被数据库权威都认为“几乎不可能在日常使用中出现”的bug，在通用工作负载和确定性验证工具面前，反而变得清清楚楚。

这正是我当初做Antithesis时最想看到的场景：不是靠运气，不是靠运气复现，而是靠工具把“不可能”变成“可复现”。