AI Slop 的代价：为什么 Turso 终止了其漏洞赏金计划

在近一年的时间里，Turso——这个兼容 SQLite 的数据库重写项目——提供了一个直接的激励措施：对于任何能够证明会导致数据损坏的漏洞，提供 1,000 美元的奖励。这是一场针对其系统可靠性的高风险赌注，旨在补充包括确定性模拟器、模糊测试器（fuzzers）以及针对 SQLite 的差异测试在内的严密测试套件。

然而，Turso 最近宣布终止该计划。原因并非缺乏漏洞或缺乏兴趣，而是“slop machine”（垃圾信息机器）的出现：大量 AI 生成的 pull requests (PRs) 和 issues 形成了一场猛攻，将原本宝贵的安全激励措施变成了一场维护噩梦。

AI Slop 的解剖

当经济奖励与特定类型的漏洞挂钩时，它就会成为 LLM 驱动自动化工具的首要目标。Turso 发现，这种激励措施过于“诱人”，导致了大量低质量提交的涌入。问题的核心在于成本的不对称性：AI 生成一份看起来合理的漏洞报告只需几秒钟，但人类维护者调查、拆穿并关闭它却需要数小时。

Turso 强调了几个此类“slop”的荒谬案例：

• 手动损坏： 一位提交者手动向数据库头中注入垃圾字节，并将其声称为一个漏洞。
• 蓄意破坏： 另一位提交者修改了源代码，手动添加了一个越界数组访问以触发损坏。
• 逻辑谬误： 一个 PR 声称存在“严重漏洞”，理由是 SQL 数据库允许执行 SQL 语句。
• 设计误解： 一份提交证明了 SQLite 在将日志模式设置回 WAL 之前无法打开文件，而这恰恰是该系统的设计运行方式。

尽管实施了“担保系统”（vouching system）来自动关闭疑似机器人的提交，但机器人只是进行了适应，通过开启新的 issues 来质疑关闭操作，并使用同样通用的、LLM 风格的长篇大论来请求人工检查。

开源生态的困境

Turso 的经历反映了开源生态系统中日益增长的紧张关系。该项目强调“开放贡献”是其基因的一部分，但经济激励创造了一个漏洞，AI 代理可以大规模地利用它。

Hacker News 上的社区成员对这一现象发表了看法，指出软件开发的瓶颈已经发生了转移。正如一位用户 (@wg0) 所观察到的，问题不再是编写代码的能力，而是阅读和理解代码的能力。当生成的代码量超过了人类审查的能力时，团队的开发速度实际上会降低。

AI 时代的应对方案建议

围绕 Turso 决策的讨论引发了关于如何在 AI 生成的噪音世界中管理漏洞赏金和开放贡献的几点建议：

1. 经济摩擦

几位用户建议引入一项名义费用（例如 20 美元）用于提交，如果发现真实的漏洞，该费用将退还。这将消除机器人提交的“零成本”特性，同时对合法的研究人员来说仍然是微不足道的门槛。

2. 声誉与证明

另一个提案涉及“漏洞赏金保安服务”（Bug Bounty Bouncer Service）——一个第三方证明层，用户必须建立声誉或为他们的首次提交支付人工审查费用。这将把验证的成本从维护者转移到提交者身上。

3. 工作量证明

有人建议要求提供“工作量证明”（proof of work），例如要求提交者在 PR 被接受审查之前，必须在本地运行全套模拟器测试用例，以证明漏洞是可复现的。

4. AI 驱动的过滤

一些人认为，解决方案是“以火攻火”，通过部署 AI 机器人来在 PR 进入人类维护者手中之前，预先筛选掉其中的 slop。

结论

Turso 决定终止其赏金计划是对系统性问题的务实应对。随着 AI 继续降低生成技术内容的门槛，基于信任和低摩擦贡献的开源项目模式——即传统的开源参与模式——正面临挑战。下一代开源治理的挑战在于，如何找到一种方法在保持开放性的同时，不被那些旨在辅助我们的工具所淹没。