SQLite 最近加了一个很小的文件，但话说得很重：仓库里新增了 AGENTS.md。

这个文件五天前进入 SQLite 仓库。它大概率不是写给 SQLite 自己开发用 agent 的说明书，而是写给那些把 coding agent 指向 SQLite 代码库的人看的。

规则一句话就能概括：AI 可以帮你找 bug，但 AI 写的代码别直接塞进来。

这件事最有意思的地方，不是 SQLite 拒绝 AI。它没有。SQLite 接受 agentic bug report，前提是带可复现测试用例。它拒绝的是 agentic code。

AGENTS.md 写得很直：报告可以，代码不行

SQLite 的规则不复杂，但每一条都在挡风险。

事项SQLite 的说法实际含义
普通 PR没有事先同意，或缺少把代码置入 public domain 的法律文件，不接受代码权属必须干净
人类提交的 PR简洁、写得好的 PR 可作为 proof-of-concept 审阅维护者可以看思路，但会自行重写
AI 生成代码不接受 agentic code代码权责不能外包给 agent
AI bug report接受带可复现测试用例的 agentic bug report问题必须能跑、能复现
修复 patch / PR欢迎用于说明可能修复方向可以当文档材料，不等于合并

还有一个小改动很关键。

SQLite 最近一次修改 AGENTS.md 时，把“不接受 agentic code”里的 “currently” 删掉了。commit message 写的是：Strengthen the statement about not accepting agentic code。

也就是把“目前不接受”改得更像“就是不接受”。

这不是情绪表态，是治理表态。

SQLite 原本就有特殊的贡献要求。它不随便收 PR，不只是因为代码质量，还因为法律归属。SQLite 代码进入 public domain，这要求外部贡献的权利边界非常干净。

AI 生成代码一进来，事情立刻变脏：作者是谁，权利怎么确认，未来谁解释，出了问题谁担责。SQLite 选择不碰这团泥。

真正变化：AI 把开源入口流量放大了

SQLite 论坛已经被不少 AI 生成的 bug report 涌入，质量参差不齐。项目方现在把这类报告分流到了新的 SQLite Bug Forum。

D. Richard Hipp 正在里面快速处理问题，并提交修复。

所以别把这事读歪。材料能说明的是：报告太多，需要分流。它不能说明 SQLite 被 AI 搞乱了，也不能说明项目质量出了问题。

更准确的说法是：AI 降低了“提交一个像样问题”的成本，也降低了“提交一个不像样问题”的成本。

这对开源维护者很要命。

过去，一个人要报底层项目的 bug，至少得读文档、写复现、整理环境。现在 coding agent 可以帮他生成一段看起来完整的报告。好报告会变多，噪声也会变多。

开源维护者会被推到一个新位置：不是只写代码，而是先当质量筛选器。

这也是 SQLite 这次处理得老练的地方。它没有把门关死，而是把入口拆开：

  • bug report 可以进专门论坛；
  • 必须带可复现测试；
  • patch 可以说明思路；
  • 核心代码仍由承担责任的人重写。

这套做法对小项目也有参考价值，但不能照抄成口号。

SQLite 有 D. Richard Hipp，有成熟流程，有足够强的项目权威。很多小项目没有。小项目维护者更现实的动作，可能只是加一个 CONTRIBUTING 或 AGENTS.md：写清楚 AI 生成内容必须标注，bug report 必须包含复现步骤，PR 不保证审阅。

别等 issue 区被灌满再补规则。到那时，维护者已经在替工具付账。

受影响的不是 AI，而是用 AI 参与开源的人

这件事最该看的两类人很明确。

一类是开源项目维护者。

如果你的项目开始收到 AI 辅助生成的 issue 或 PR，别只在心里骂。把规则写出来：什么能收，什么不收，什么格式才看，什么情况直接关闭。

尤其是底层库、安全相关项目、数据库、编译器、加密组件。越是高信任项目，越不能让“看起来能跑”的代码绕过责任链。

另一类是使用 coding agents 的开发者。

以后拿 AI 帮你给开源项目报 bug，别把 agent 输出原样贴过去。至少做三件事：

  • 自己跑一遍复现；
  • 给出最小测试用例；
  • 把修复建议当说明，不要当“请合并”的压力。

如果你只是让 agent 扫仓库、编一个可疑点、生成一段补丁，然后扔给维护者，这不叫贡献。那叫把验证成本转嫁出去。

技术史里这种事不新鲜。铁路、电力、互联网平台，每次新工具把生产效率推上去，都会顺手制造一批新的审核工作。旧话说，“天下熙熙，皆为利来”。今天的“利”不一定是钱，也可能是效率、名声、贡献记录，或者自动化带来的虚假成就感。

AI 写代码也一样。生成便宜了，验证就更贵。

SQLite 这次划的线，真正保护的不是某种开发洁癖，而是基础设施项目最稀缺的东西：可解释、可追溯、可承担责任的代码链条。

接下来最该观察的，不是 SQLite 会不会“拥抱 AI”。这个问题太粗。

更该看三件事：更多项目会不会加入 AGENTS.md；维护者会不会要求 AI 报告必须提供最小复现；开源社区会不会把 agentic code 和 agentic bug report 分开治理。

这才是分水岭。

SQLite 给出的答案很克制，也很硬：你可以带着 AI 来找问题，但别让 AI 直接坐到提交席上。

开源不是无门之城。门槛低，不等于城墙该拆。