Turso 在 5 月 12 日宣布，停止运行近一年的漏洞赏金计划。规则原本很清楚：只要能证明某个 bug 会导致 Turso 数据损坏，就支付 1000 美元。

反常的地方在这里。Turso 不是说这类 bug 不重要，也不是说不再接受贡献。它取消的是“公开入口 + 现金奖励”这套组合，因为维护者被大量疑似 AI 生成的低质量 PR 和 Issue 拖住了。

我更在意的是这件事背后的成本差。提交一份看起来像样的报告，现在很便宜；审核它、复现它、解释它为什么不成立，仍然很贵。开源项目最怕的不是有人用 AI，而是劣质提交借着赏金涌进来。

这笔赏金原本是给“数据不坏”买外部压力测试

Turso 设这个赏金，不是普通的营销动作。它正在重写 SQLite，而 SQLite 在软件世界里长期被当作可靠性的标杆。对这类基础软件来说，“不损坏数据”不是卖点，是底线。

Turso 自己也有一套测试体系。包括确定性模拟器、fuzzer、基于 oracle 的 SQLite 差分测试、并发模拟，以及在 Antithesis 上的大规模测试。

但自动化测试有边界。原文提到，有些 bug 只有数据库超过 1GB 后才会出现；如果故障注入太激进，测试数据库根本长不到那个体量。赏金计划补的就是这类盲区：让外部研究者带着真实思路来撞墙。

这套计划确实有效过。Turso 曾向 5 名个人支付赏金。Alperen 参与改进模拟器；Mikael 后来被 Turso 雇用；Pavan Nambi 把模拟器和形式化方法结合，不只发现了 Turso 的问题，还在 SQLite 本身发现了十多个 bug。

所以不能把结论写成“LLM 做不了安全研究”。原文还承认，Mikael 曾创造性地使用 LLM，找到模拟器覆盖不到的区域。分界线不在于用不用 AI，而在于提交者有没有承担验证责任。

问题出在低成本生成，撞上了高成本审核

Turso 展示的低质量案例，问题并不复杂。有人手动向数据库头部注入垃圾字节，然后声称发现数据损坏；有人修改源代码加入越界访问，再证明数据库会坏；还有人把“SQL 数据库可以执行 SQL 语句”包装成严重漏洞。

这些例子看上去荒唐，但维护者不能只凭第一眼关闭。尤其是数据损坏类 bug，项目方必须判断：是不是可复现，是否在真实边界内，能不能用模拟器或测试用例证明。

这就是 AI 垃圾提交最麻烦的地方。它把写报告的成本压低，却没有压低审核成本。报告越像报告，维护者越要花时间确认它是不是废话。

维度原本的赏金设计被 AI 低质提交放大的问题
赏金范围可证明导致数据损坏的 bug低质量报告也会贴近这个关键词
单笔金额1000 美元足以吸引批量试探
验证门槛需要证明、复现，最好进入模拟器提交者把验证成本转嫁给维护者
开源入口公开接受 PR 和 Issue入口开放，噪声也开放
Turso 的选择继续开放贡献取消现金激励

这不是 Turso 经营恶化的信号。至少从公告能看到的，是治理成本失衡。钱一挂出来，低质量提交就有了理由；门一开着，维护者就要接住噪声。

漏洞赏金平台通常会用身份、信誉、范围规则和报告格式过滤噪声。Turso 这个计划更接近开源协作：入口低，讨论公开，维护者直接面对提交者。好处是透明，坏处是没有缓冲层。

对维护者和安全研究者，动作要变具体

对开源项目维护者，这件事最直接的提醒是：不要把“可以提交”和“可以拿钱”混成一条路。

更现实的做法，是把赏金入口收紧。比如要求最小复现、测试用例、模拟器扩展、差分测试结果；或者只对有历史贡献记录的人开放奖金。项目仍然可以开门，但奖金不必挂在门口。

对安全研究者和漏洞赏金参与者，信任成本也在上升。只交一份语言完整的报告，价值会越来越低。更能区分人的，是复现脚本、失败条件、边界说明，以及对项目测试体系的补丁。

这里有个现实限制：门槛越高，可能挡住新人；门槛越低，又会伤到维护者。Turso 选择了中间路线：不关闭开源贡献，但取消公开现金激励。这不是最漂亮的方案，却是眼下更省命的方案。

接下来要看的不是 Turso 会不会恢复 1000 美元，而是开源项目会不会把规则拆开：普通贡献继续开放，赏金改成邀请制、信誉制，或只奖励已经进入测试体系的高质量报告。

回到开头那 1000 美元。它买的本来是外部可靠性压力测试，不该变成维护者替机器批改作业的工钱。千金买马骨可以，千金买噪声不行。