📌 好文共赏 | Editor’s Pick
原文：The Wonders of AI: We Are Retiring Our Bug Bounty Program 作者：Glauber Costa（Turso CEO，前 ScyllaDB 联合创始人 / VP Eng，前 Linux 内核 cgroups 主作者之一）| 发布：2026-05-12 | 阅读时长：约 10 分钟
多模评分：Opus 8.9 / Sonnet 8.7 / Gemini 8.8（综合 8.80 / 10）
一句话推荐理由：在过去一年里我们读过太多"AI 让开源更繁荣"的乐观叙事，Glauber Costa 这篇 1700 字的告别信，是第一次有一位真正做底层系统软件、有大规模社区运营经验的工程师，在公司官方频道里，承认这件事:“在开放协作系统里，只要在某一类 bug 上挂一个非零的金钱奖励，LLM 灌水 PR 就会在几天内把整条治理链路冲垮。"——他没有怪 LLM，他把矛头指向了激励结构本身。这是 2026 年第一篇官方版的 OSS 治理告白书。
为什么值得读
这篇文章并不长，原文连 HN 评论加起来读完不超过 20 分钟，但它在 2026 年 5 月这个时间点上，意义远大于篇幅。
事情的剧本简单到让人怀疑是不是太轻巧了：Turso——一个由 Glauber Costa 在 2023 年开始、目标是用 Rust 把 SQLite 从零重写一遍的项目——在 2024 年中开了一项赏金计划：任何人，只要能演示出一个会导致数据损坏（data corruption）的 bug，并且把对应的测试 case 补进他们的 Deterministic Simulator 里（也就是说，“找到"还不够，必须证明"我们的仿真器为什么没找到”），就能拿 $1000。
将近一年里，他们一共付出去 5 个奖金。5 个奖金，全部是高质量提交：其中一位（Alperen Keles）后来甚至成了仿真器自己的核心 contributor；另一位 Pavan Nambi 把仿真器与形式化方法接起来，不仅在 Turso 里找了 bug，还反过来在 SQLite 主线上挖出了 10 个以上的问题。Glauber 在文章里用了 “incredibly special people” 来形容这五个人——这句用词在他过去十几年的博客里都算克制，但在这个语境里几乎是赞美的极限。
然后，奇点（singularity，他原话）来了。
原文：> “But then an army of slop was released overnight. It became too high a reward to just point an LLM at Turso, and try to find a bug.”
注意他用的是 “an army of slop was released overnight”——不是"逐渐增多”，不是"我们注意到一些异常"——是"一夜之间，灌水大军被放了出来"。Turso 的维护团队连续几天几乎没干别的事，只在不停地关闭由 LLM 自动生成的"我发现了一个 critical vulnerability"PR。在尝试了"投票认证机制"等若干种过滤手段都被机器人轻易绕过之后，他们做了一个对开源项目来说非常痛苦、对个体维护者来说非常理性的决定：直接拆掉赏金这个奖励本身。
为什么这件事值得专门写一篇导读？因为这是我读过的、第一份由当事公司亲笔写出来、并且点名挑战激励结构的 LLM-OSS 治理事故报告。在它之前，我们读过 curl 之父 Daniel Stenberg 对 Mythos 等 AI 安全工具的祛魅、读过 TanStack 投毒事件的官方复盘、读过 Ghostty 离开 GitHub 自托管的 OSS 治理思考——它们都是从不同角度看 LLM 时代 OSS 是否还能正常运转。Turso 这篇文章，是第一份直接落在"经济激励"这个最敏感的环节上的报告。
而且，写这篇报告的人不是路人。Glauber Costa 在 Linux 内核里写过 memory cgroups 的早期实现，是 ScyllaDB 在 C++ 上重写 Cassandra 那十年的核心人物之一，他过去十几年最有名的几篇博客——“Modern storage is plenty fast. It is the APIs that are bad”、“C++ vs. Rust: an async Thread-per-Core story”——都是关于"现有系统的瓶颈被错误地理解了，需要重新评估假设"。这一次，他在 Turso 的官方博客上写"我们的赏金计划假设也错了"，分量比任何一篇 op-ed 都要重。
1. 这不是一篇抱怨 LLM 的文章，这是一篇关于"经济门"的文章
读这篇文章最容易踩进去的坑，是把它当成"又一个开源维护者吐槽 AI 生成的低质量 PR"。这种叙事在过去半年里几乎每周都出现一次，从 curl 的 Daniel Stenberg 到 Seven Hacker News 高票贴，痛点是一样的：维护者把时间花在驳斥 LLM 幻觉上。
但 Glauber 写这篇文章的角度比这刁钻得多。他没有花一段去骂 LLM 输出质量差，他直接把矛头指向赏金计划本身这个激励结构：
原文：> “The main problem of course is that it costs the slopmaker perhaps a minute to generate their submission. But it costs us hours to read, understand, and engage with them. … We have to either close the system, or get rid of the incentive. For now, we are choosing the latter.”
把这句话翻译成博弈论的话就是：在一个开放协作系统中，如果攻击者生成一份"看起来像那么回事"的提交的边际成本是 $0.001（几百个 token），而防御者验证每一份提交的边际成本是 $50（一小时维护者时间），那么任何一个 > $0 的奖励都会立刻吸引一支无限规模的、不在乎期望值正负的灌水大军——因为对灌水方来说，只要这个 $1000 奖励的中签概率高于 1/百万，期望值就是正的。
更要命的是这个 expected value 是线性可叠加的：开 100 个账号、用 GPT/Claude/Gemini 各撞一次，期望值就翻 100 倍，而每一份新提交对维护团队来说都是一个完整的 1 小时。
Glauber 给出的解法不是"提高奖励门槛"、不是"加强身份验证"，而是直接拆掉门——把奖励降到 $0，让灌水的期望值跌回 $0，让真正爱 Turso、想给仿真器做贡献的人留下来。他在文章末尾很直白地写：
原文：> “We value our Open Source community of contributors a lot … But at this point, we just don’t believe that a financial incentive of any kind works well with an open system. We have to either close the system, or get rid of the incentive. For now, we are choosing the latter.”
这里有一个非常有意思的修辞——“For now”。他没有承诺这是永久的，他承认这是一次战术撤退。这个用词，比任何"AI 让 OSS 变得不可持续"的标题党都要诚实。
2. 那 5 个拿过奖金的人：测试方法论的"逆向勘察兵"
如果只读文章本身，会以为这是一篇"我们关掉了一个不再有效的项目"的告别信。但如果你顺着他的几个内链点进去——尤其是关于 Alperen Keles、Mikael 和 Pavan Nambi 的介绍页——你会发现这个赏金计划的真正价值从来都不在 $1000 那 5 张支票上。
Turso 在做的事，是把 SQLite——一个被广泛认为是世界上测试得最彻底的开源软件——用 Rust 重写。SQLite 自己有 TH3 (Test Harness 3) 这种私有专有的航空级测试套件，号称 ~100% MC/DC 覆盖。要在没有 TH3 的情况下、用一个 OSS 项目重新实现 SQLite，Turso 选择的路径是确定性仿真测试 (Deterministic Simulation Testing, DST)——这一脉血缘上来自 FoundationDB、Antithesis 和 TigerBeetle。
Glauber 在文章里非常清楚地承认了 DST 的根本局限：
原文：> “You can write all the fuzzers and simulators in the world, but they will only catch bugs in the combinations that are effectively generated. For example, if your fuzzer never generates indexes, you will by definition not find any bugs related to indexes.”
这句话比文章主线更值得反复咀嚼。它的潜台词是：DST 不是 “完美测试”，它只是 “在你的生成器里穷举得很好”。你的生成器里没有 1GB 以上的数据库？那你永远不会发现"SQLite 在 1GB 边界会插入一个特殊的 pending page"这种行为——这就是他们在之前那篇 “An adventure in writing compatible systems” 里讲过的著名 1GB 之谜。
所以这个赏金计划真正的设计意图，从来不是悬赏 bug 本身，而是悬赏生成器盲区——付钱给那些能告诉你"你的仿真器永远不会触发这种状态"的人。Alperen、Mikael、Pavan 这 3 个人，本质上是测试方法论的逆向勘察兵：他们不是用直觉去 fuzz，他们是用人类的元思维去推断"哪一类状态空间在 Turso 的当前生成器分布里有 0 概率被触达"。
这就是为什么 Glauber 把他们叫做 “incredibly special people”——LLM 不能取代他们的原因，不是因为 LLM 写代码不够好，而是因为 LLM 没法"看着一份 Rust 数据库实现，回答出’你的生成器没有覆盖到的状态空间在哪里’"。后者需要的是对生成器自身的元认知，是一种至少在今天的 frontier model 上还不存在的能力。
灌水 PR 之所以全是垃圾，恰恰反过来证明了这一点——LLM 能批量生成"看起来像 bug 的提交"，但不能批量生成"对仿真器盲区的洞察"。这两件事在表面上长得很像，在本质上是两个完全不同的认知任务。这点和 Daniel Stenberg 那篇 5 个 Mythos 报告只剩 1 个真问题里所验证的现象高度一致。
3. 几个具体的"灌水样本"：LLM 在干嘛？
文章中段，Glauber 列了 4 个具体的灌水 PR 例子。我用自己的话复述（避免直接转引完整 issue 截图），它们的形态非常一致：
样本 A：手动把数据库 header 写坏，然后宣称"数据库被破坏了"。 作者（或者作者背后的 bot）把数据库文件的 header 字节段直接覆盖为乱码，然后提交 PR 声称"我证明了 Turso 不能正确处理损坏的 header"。维护者指出"是你自己手动写坏的"之后，bot 接着用一整面"em-dash + 表格 + 绿色 checkmark"的回复继续坚持自己发现了 critical bug。
样本 B：在源码里手动插入一个 out-of-bound array 访问，然后说"我发现了数据损坏"。
这是字面意思——作者在 Rust 代码里加了一段 unsafe 或类似机制，故意制造内存越界，然后 PR 声称"我找到了数据损坏 bug"。逻辑上等价于"我把锁砸了，然后向警察报告说门不安全"。
样本 C：在 Turso 的并发写功能上演示"SQLite 不能打开这个文件"。 Turso 区别于 SQLite 的核心特性之一就是 concurrent writes（详见 Turso Cloud 的 private beta），它使用了 SQLite 兼容性之外的 journal mode。LLM 生成的 PR “证明"了在打开并发写之后，原版 SQLite 无法读这个文件——这恰恰是设计本身。LLM 把 feature 当成了 bug。
样本 D：维护者自己也看不懂。 Glauber 写得很坦率：他真的不知道这个 PR 在做什么。维护者 Mikael（就是当年自己拿过赏金那位）评价说：“这个人显然只是看到了奖金公告，开始流口水，然后把灌水机器对准了我们。”
这 4 个样本的共同点不是"质量低”——它们的输出在表面上看起来都有体例：充实的英语描述、漂亮的 markdown 表格、绿色对勾、--- 分隔线、em-dash 修辞、对自己解决了 critical issue 的笃定语气。它们的失败发生在更深的层级：对 Turso 这个具体系统的语义没有任何理解，对"什么算 bug"的定义本身没有任何概念。
LLM 在生成这种东西时的体验我们都见过：它在做"看起来像 bug 报告的英文文本"的优化，而不是在做"找到 Turso 中的真实数据损坏"的优化。这两个目标之间的语义鸿沟，恰恰是 RLHF / instruction tuning 喂出来的副作用——模型学会了"写得像专家"，但没学会"是不是真的找到了 bug"。
4. “We invented a vouching system, the bots beat it”——Sybil attack 的当代复刻
文章倒数第二段最值得标黑：
原文：> “In our last attempt to establish some order, we have designed and implemented a vouching system. If we suspect that a submission is coming from a bot, we just auto-close it. And this worked okay for some time, until the bots just started opening issues questioning the closing of their PRs and requesting a manual inspection.”
Turso 团队尝试做了一道反 bot 的"voucher 制"门——大概是要求 PR 提交者需要被现有 contributor 担保。这个机制的设计直觉是对的：把"无成本生成新账号"这条 attack vector 堵掉。
但 bot 的对策是什么？它们开始用同样的语气、同样的体例，开 issue 反对自己 PR 被关闭，要求人工复审。
这是一个非常经典的 Sybil attack 变体：当你给身份引入信任分级时，攻击者不会停下来，他们会用机器生成的"看起来很真诚的伸冤"去消耗你这条信任链路上的额外人力。维护者面对这种"伸冤"几乎没有低成本的解法——你不能直接 ignore，因为 9 成 9 是机器人但万一第 100 个是真人；你也不能逐条阅读，因为这正是机器人在期望的。
这一段是整篇文章最具普遍性的部分。它告诉所有还在挣扎的 OSS 项目：任何引入"复审 / 申诉 / 二次确认"环节的反 bot 机制，本身都会被同一波 bot 用同样的成本压垮。这是因为 LLM 的灌水能力天然就是 stateless 的——它在每一轮"申诉"里都能生成同样体例、同样语气的新文本，根本不在乎前一轮发生了什么。
读到这里你也许会想到 Ghostty 离开 GitHub 选择自托管 forge 的决定 背后的同样焦虑：大型 OSS 项目正在系统性地把"任何匿名、低门槛的协作入口"关闭，因为这些入口在 LLM 时代的预期价值已经变成了负数。Turso 的应对方式比 Ghostty 更温和——他们没有关掉协作入口本身，只是把"金钱激励"这个杠杆撤掉，让攻击者的期望值跌回 $0。
但这其实是同一类决策。
5. 反向思考：为什么 Pavan Nambi 还在赢
文章里 Glauber 顺手提到了一句几乎被一笔带过的关键信息——Pavan Nambi 用形式化方法挖出了 SQLite 主线 10 个以上的 bug。这个数字非常震撼。
SQLite 是被广泛认为世界上测试得最彻底的开源软件——除了 TH3，他们还有 Anomaly Test、连续多年的 OSS-Fuzz 覆盖、上市公司级别的客户压测。能在 SQLite 主线上挖出 10 个 bug 的人，业界数得过来。
但 Pavan 是怎么做到的？根据 Glauber 在 X 上的串，他用的方法是把 Turso 的 deterministic simulator 和形式化方法工具（应该是某种 model checker，可能类似 Alloy 或 P 语言）耦合起来——让形式化模型告诉仿真器"这个状态在数学上不应该出现"，然后让仿真器去试着达到那个状态。在 Turso 上找到的 bug 反过来用 SQLite 跑一遍，于是发现 SQLite 也有同样的边界 case。
这就是为什么 Glauber 会感慨 “incredibly special people”。Pavan 干的事，从输入输出上看，和 LLM 干的事很像（都是"找 bug 然后写报告"），但中间那一段的认知结构完全不同：
- LLM 在做：随机扰动输入 → 看输出有没有 panic/error → 写一段像样的英文
- Pavan 在做：把规约写成形式化模型 → 让 model checker 找到反例 → 让 DST 复现反例 → 写一段证明
这两种工作流的根本差别在于有没有一个"应该是什么样"的内部模型。LLM 没有 Turso 的形式语义模型，它只有 Turso 的文本表达；Pavan 有 Turso 的形式语义模型，并且能在这个模型里推理。所以 Pavan 的产出比 LLM 高 1000 倍，Turso 也愿意为他付那 $1000——这笔账在经济学上是赚的。
赏金计划本来要做的，就是把 Pavan 这种人从大海里捞出来。问题是 LLM 灌水 PR 的体量太大，导致 Pavan 之类的真实贡献者被淹没了——维护者必须用 99% 的时间在筛 LLM 噪声，留给真实贡献者的对话带宽接近 0。
文章里没有明说的潜台词是：Turso 还会以别的方式继续招 Pavan 这种人——只是不再通过 “$1000 公开赏金” 这个 API 端点了。可能是直接 outreach，可能是邀请制，可能是通过 Antithesis 这种第三方平台。
6. 跟 antirez “DS4 一周写完"那篇放在一起看：人与人的协作机制要改写了
在我今天早上发的那篇 antirez 用 GPT 5.5 一周写出 DS4的导读里，结论是相当乐观的：Redis 之父用 LLM 做 pair programmer，一周从零到端到端的本地推理引擎。同一天，Glauber Costa 的这篇关闭赏金的文章告诉我们：当 LLM 出现在协作的另一边——不是你的助手，而是匿名陌生人手里的武器——开源治理的成本曲线就会瞬间反转。
这两件事不矛盾。它们其实是同一个工具被放在两个不同的位置：
- 在 antirez 那一侧：LLM 是一个被 Redis 作者亲自驾驭、用于探索新代码的私人助手。这是高度受信的协作，LLM 的输出会被一个真正懂行的人 review 每一行。
- 在 Turso 这一侧：LLM 是一个匿名陌生人手里的 PR 生成器。这是低信任、高频率的协作，LLM 的输出会冲进一个完全不认识对方的维护者的 inbox。
这两种位置带来的经济学完全不同。前者的边际成本是 $0 / 边际价值高，后者的边际成本是 $0 / 边际价值（对接收方而言）严重为负。
这个二分法，过去半年里被很多人各自摸到一部分。Daniel Stenberg 的 Mythos 5 报告只剩 1 个真 触到的是同一个问题在安全报告上的版本；TanStack 投毒事件碰到的是同一个问题在供应链上的版本。Glauber 是第一个把它写成经济激励公式的人。
我猜测接下来几个月会陆续看到的事情：
- 更多大型 OSS 项目悄悄关闭或大幅收紧赏金条款。Hacktoberfest 模式已经死了——这个去年大家就有共识。但商业公司挂着的 cash bounty，今年还会陆续清理一波。
- 赏金计划转向受邀制 / 实名制 / 抵押制。MostlyStable 在 HN 评论里建议的"先交 $10 押金，找到真 bug 退还"方案不会少见。
- 维护者 inbox 的反 LLM 中间件会变成新品类。GitHub 自己肯定要做，但第三方（类似 StepSecurity 之类）会先出手。
- DST + 形式化方法这条路径会更加值钱。Antithesis、TigerBeetle、Turso 这一脉的方法论会被更多严肃数据库 / 分布式系统采用——因为这是少数几条 LLM 暂时无法"灌水"的工程实践。
7. 编辑延伸思考：开放协作的"门”，正在从"几乎不收门票"变成"按身份收门票"
如果把视野放得更大一点，Turso 这次撤掉赏金的决定，本质上是开放协作世界的"门票制改革"的一个微小切片。
互联网过去 30 年的一个底层假设是：让所有匿名陌生人都能向你的项目提建议 / 提 issue / 提 PR，整体收益是正的。这个假设在 90 年代到 2010 年代被一次又一次验证——Linux 内核、Firefox、Wikipedia 这些项目都是它的具体例证。
但这个假设有一个隐含前提：每个"提建议"的人，背后是一个会被你花时间回应而获益的人类。一旦背后变成一个边际成本 $0、不需要从你的回应里获益的 token generator，整个 ROI 就翻负号。
Turso 现在做的事，是在保留"开放协作"这个 surface 的同时，把"有金钱激励"这一类协作单独筛出来取消。它没关 GitHub issue，没关 PR，只关了赏金。这是非常克制、非常有外科手术感的一刀。
但这一刀过后，问题没有走，问题转移到了下一个层级——没有金钱激励的协作里，LLM 灌水的边际成本依然是 $0。它只是从 $1000 的中签期望值，变成了"在简历上写一句 ‘Turso 主要 contributor’“的声誉期望值。声誉期望值低一些，灌水大军体量会小一些，但本质机制不变。
所以我的预测是：接下来 12 个月，开放协作的"门"会逐渐从"匿名免费门票"演化成"按身份收门票”——你需要带着一份可被验证的身份才能在严肃 OSS 项目里发起协作。这个身份可能是 sigstore-style 的供应链签名、可能是 GitHub Sponsors 的支付历史、可能是 Bluesky 的 DID、可能是 ENS / .eth 域名。但无论是哪一种形态，匿名平等贡献这件事正在变得越来越奢侈。
这件事在哲学上让我有点难受。我们这一代人在 90 年代末上网时学到的"互联网最大的奇迹就是任何匿名陌生人都可能给你一个改变一切的 PR"，正在被慢慢收回去。但站在 Turso 这种维护团队的具体处境上，我又完全理解他们为什么必须这样做——让维护者的健康可持续，永远比"维护一个抽象的开放性"更重要。
Glauber 最后一句话是 “For now, we are choosing the latter."——选择拆除激励、保留开放性。但这句话的 “For now” 三个字，是他作为一个工程师、一个 CEO、一个被现实拖着走的人，最诚实的留白。
明年 5 月再回来看这篇文章，我们会知道这条选择能撑多久。
8. 配套资料 / 延伸阅读
作者其他代表作:
- “Modern storage is plenty fast. It is the APIs that are bad” (Glauber, 2020) — io_uring 时代为什么大多数存储引擎都在做错事。Glauber 这一类"重新评估假设"的写作母题，本文是它的最新版。
- “C++ vs. Rust: an async Thread-per-Core story” (Glauber, 2020) — Seastar 与 Rust async 模型的对比，Turso 选 Rust 的早期心路。
- “Career advice for young system programmers” (Glauber, 2023) — 关于"为什么底层系统工程师永远会有工作"的预测，与今天他面对 LLM 灌水的态度对照着读，会有意思。
- “An adventure in writing compatible systems” (Glauber, 2025-08) — 1GB pending byte 之谜，是理解 Turso 仿真器局限性的最佳前置阅读。
- “SQLite: QEMU All over Again?” (Glauber, 2022) — Turso 立项之前的精神原点。
Turso 工程实践参考:
- Antithesis - 确定性系统的反向测试平台 — Turso 在用的外部 DST 服务。
- TigerBeetle 的确定性仿真测试 — 与 Turso 同一脉的 DST 实践。
- FoundationDB 的 simulation testing 经典论文 (2014) — DST 在数据库工程里的"圣经”。
- SQLite TH3 测试套件介绍 — Turso 真正要追赶的对手。
LLM-OSS 治理的同期讨论:
- 我之前写过的 《curl 之父亲测 Mythos：5 个"确认漏洞"最后只剩 1 个，AI 安全工具的祛魅时刻》 — curl 在同样的灌水浪潮里的应对。
- 我之前写过的 《TanStack npm 投毒事件官方复盘：三条独立漏洞如何被串成一条供应链刀锋》 — 同一波 LLM 时代供应链问题在 npm 上的版本。
- 我之前写过的 《Ghostty 离开 GitHub：Mitchell Hashimoto 的自托管 forge 与 OSS 治理 2026》 — 同一波焦虑在另一种应对路径上的版本。
- 我之前写过的 《Redis 的野心代价：当一个"远程字典服务器"想成为一切，它就什么都不是了》 — 同样是数据库领域的元思考，antirez 视角。
- 我今天早上发的 《antirez 一周写出 DS4：当 Redis 之父把 GPT 5.5 当结对程序员》 — LLM 作为"高信任协作者"的另一面，与 Turso 这篇正好镜像。
反方观点 / 不同视角:
- HN 评论区里 MostlyStable 提出的押金制 与 mapt 提出的 “$1000 入场 + $5000 中奖” 反向激励 ——都是不放弃激励本身的设计，值得对照看。
- Metabase 的 “Strip Mining Era of OSS Security” — 从企业视角看 OSS 安全报告产业化的另一面。
- “AI 让 OSS 更繁荣” 的代表立场 — 与本文形成对照的乐观叙事。
9. 谁应该读这篇文章
- 任何在运营开源项目、且当前有 bug bounty / 悬赏计划的人——读完之后立刻去看一下你自己的灌水率统计。
- 数据库 / 系统软件方向的工程师——文章本身关于 DST 局限性的那一段是 SQLite 测试方法论的少有公开侧写。
- OSS 投资人 / 公司管理者——这是 2026 年第一篇明确指出"AI 时代的 OSS 维护成本曲线已经反转"的官方文本，对评估 OSS 项目的 burn rate 模型有直接影响。
- 正在思考 AI 协作伦理的研究者——文章末尾"For now, we are choosing the latter"那句话，是一线工程师对 AI 协作伦理问题的最诚实回答。
- 任何被 LLM 灌水耗尽过精力的开发者——读完会感觉自己不孤独。Glauber Costa 也累。我们都累。
本文是【好文共赏】系列。原文版权归 Turso / Glauber Costa 所有，本文为基于公开内容的深度导读与延伸思考，引用量控制在原文 10% 以内，所有引用均已 blockquote 并标注"原文："。强烈建议读者点击文首链接，阅读原文及其链接的 PR 案例截图。
