夜雨聆风当开源项目开始给 AI 写说明书
2026 年 5 月的一天，SQLite 的代码仓库里多了一个新文件。
不是什么重大功能更新，不是安全补丁。是一个叫 AGENTS.md 的文件。
SQLite 你大概率用过——它嵌入了你的手机、你的浏览器、你坐的飞机的航电系统。这个项目有 25 年历史，以"测试覆盖率 100%"为荣，代码质量标准严到连外部代码提交都不怎么接受。
但这次，SQLite 的维护者们做了一件以前从未做过的事：他们给 AI 写了一份使用说明书。
AGENTS.md 不是给人看的。README.md 才是给人看的。这份文件的目标读者是各种 AI 编码工具——所有可能被某个开发者指向 SQLite 代码库的 AI 代理。文件里写着项目的构建方式、测试要求、代码风格、哪些文件不能碰。所有你通常会告诉项目新人的东西，现在告诉 AI。
更直白的是这一句：
SQLite does not accept agentic code.
一个被用在地球上每一部手机里的数据库引擎，不得不专门写一份文件告诉 AI：别来帮倒忙。
这不只是一件好笑的事。这是一个信号。
这一年到底发生了什么
如果你觉得这只是 SQLite 自己的问题，那看看这个时间线。从 2025 年到现在，同样的场景在开源世界反复上演，只是换了主角、换了项目、换了姿势。
2025 年 7 月：slop 学会了化妆
Daniel Stenberg 维护 curl 超过 25 年。curl 是互联网最基础的工具之一。你每次打开网页、用命令行下载文件，背后大概率有 curl。
到 2025 年中，curl 的漏洞赏金计划累计收到 415 份报告，只有 64 份是真正的安全问题。三分之二的报告既不是安全问题也不是普通 bug——它们是 AI 生成的、看起来很专业但毫无价值的噪声。英文叫 "slop"，后来成了 Merriam-Webster 2025 年度词汇。
更糟的是，20% 的提交是 AI 生成的，整体有效率掉到了 5%。Stenberg 把这种现象叫作"Death by a thousand slops"——千刀万剐式的消耗。
和最初不同的是，这些新 slop 更难辨认了。描述写得更专业，代码结构更完整，甚至会主动引用旧安全漏洞编号来增加可信度。Stenberg 说，辨别它们需要花更多时间——而每多花一分钟，就意味着真正的安全工作被挤掉一分钟。
2025 年秋天：有人开始立规矩
Fedora 项目率先行动，发布了一份正式的《AI-Assisted Contributions》政策。核心三句话：你对你的贡献负责；AI 生成的内容只是建议，不是最终代码；AI 不得做最终决定。这份政策在社区引发了一百五十多条回复的激烈辩论，最终在 2025 年 10 月正式批准。
差不多同期，Homebrew 在贡献指南里加了更直白的规则：你用了 AI 就必须说，代码你得自己审过，审查意见你自己接，做不到就关掉你的提交。
2026 年 1 月：AI 不只是写报告了
到这时为止，大部分 AI slop 还集中在漏洞报告这个场景。但 2026 年 1 月，战场扩大了。
Node.js 技术指导委员会成员 Matteo Collina 提交了一份代码（行内称为 PR，即 Pull Request），要给 Node.js 加一个虚拟文件系统功能。这份提交包含一万多行代码。他在描述里写得很坦率：
"I used a massive amount of Claude Code tokens to create this PR. All changes have been reviewed by me."
Collina 认为如果没有 AI，这个假期项目根本不可能完成。
但另一位长期核心贡献者 Fedor Indutny 不买账。他发起了一份请愿，质疑 AI 辅助代码是否符合 Node.js 的开发者证书原产地条款——你用 AI 写的代码，版权到底算谁的？几天之内，超过百名开发者签署请愿，呼吁禁止 AI 生成的代码进入 Node.js 核心仓库。
2026 年 1-2 月：掀桌
就在 Node.js 争论还没平息的时候，更多项目选择了更激进的做法。
Ghostty 的创始人 Mitchell Hashimoto 宣布了零容忍政策：提交 AI 垃圾代码，永久封禁。他在变更记录里写了一句后来被广泛引用的话：
"This is not an anti-AI stance. This is an anti-idiot stance."
tldraw 的 Steve Ruiz 更干脆。他在公开帖子里宣布自动关闭所有外部代码提交：
"This is going to be a weird year for programmers and open source especially."
2026 年 2 月：有人崩溃了
开源游戏引擎 Godot 的核心维护者 Rémi Verschelde 在 Bluesky 上说了一句话，后来被反复引用：
"I don't know how long we can keep it up."
他用的词是 "draining and demoralizing"——疲惫又沮丧。一个靠志愿者撑起来的项目，突然要面对每天猜"这个提交是人写的还是 AI 吐出来的"。
2026 年 4-5 月：问题换了衣服
然后事情发生了一个出人意料的转折。
2026 年 4 月，Daniel Stenberg 在 LinkedIn 上说：
"Over the last few months, we have stopped getting AI slop security reports in the curl project. They're gone."
低质量的 AI slop 消失了。但取而代之的不是安宁。
"Instead, we get an ever-increasing amount of really good security reports, almost all done with the help of AI."
他在邮件列表里补充了一个数字：curl 现在平均每 20 小时收到一份新的安全报告。质量提高了，但数量暴涨。维护者更忙了。
Linux 内核维护者 Willy Tarreau 确认了同样的情况：以前每周 2-3 份漏洞报告，现在每天 5-10 份。而且大部分还是对的。
"It's a bit scary (and tiring). But what can we do? The bugs are there."
2026 年 5 月，Linus Torvalds 在 Linux 7.1-rc4 的发布公告中写道，AI 生成的重复报告让内核安全列表"almost entirely unmanageable"。
然后，SQLite 放出了那份 AGENTS.md。
当 slop 学会了伪装
表面上看，这些事件都是"AI 写了烂代码"。但如果你仔细看，会发现烂法完全不同。
Godot 的维护者 Verschelde 讲过一个典型的场景：一个新贡献者提了个代码提交，标题写着修复某个渲染 bug，改动看上去合理，代码结构完整，注释齐全。但 Verschelde 花了半小时深入审查后发现——提交者根本不理解这个 bug 的触发条件。代码改的是表象，根因完全没碰到。
这种提交最消耗人。因为它不是一眼能看出来的烂，而是伪装成了"值得深审"的样子。一个有经验的维护者以前能在 30 秒内判断一个新提交值不值得花时间。现在这 30 秒失效了。
还有一种更让人无奈的。有审核者讲过这样的经历：要求开发者现场解释自己提交的代码逻辑，对方答不上来。PR 被打回。
代码能跑。测试过了。描述写得头头是道。但提交者不知道它为什么能跑。如果审核者不追问一句，这段代码就合进去了。
更隐蔽的是安全问题。Purdue 大学的一项研究发现，Copilot 生成的代码中有 39% 存在安全弱点。更麻烦的是，使用 AI 助手的开发者对自己代码的安全性反而更加自信。这意味着不仅问题在变多，发现问题的能力还在下降。
烂法不同，但说到底——AI 让低质量的东西看起来值得你花时间。它提升了噪声的伪装度。以前一个写得不好的 PR 会被一眼跳过，现在它穿着整洁的外衣，排着队等你审查，而你不得不一个一个拆开看。
Daniel Stenberg 的说法更直接。他说 curl 项目累计收到的漏洞报告里，66% 既不是安全问题也不是普通 bug——它们是 AI 生成的、看起来很专业但毫无价值的噪声。到了 2025 年，20% 的提交是 AI 生成的，整体有效率降到了 5%。
slop 在变聪明。你的筛选器却没有跟着升级。
他们是怎么应对的
面对这些东西，开源社区的反应从温和到激烈都有。
立规矩
最温和的一端是立规矩。Fedora 在 2025 年 10 月正式批准了一份 AI 贡献政策，核心就三句话：你对你的贡献负责；AI 生成的内容只是建议，不是最终代码；AI 不得做最终决定。这份政策在社区论坛上引发了一百五十多条回复的激烈辩论，光是"should not"和"must not"的区别就吵了好几轮。
Homebrew 更直接：你用了 AI 就必须说，代码你得自己审过，审查意见你自己接，做不到就关掉你的提交。
掀桌
但规矩是给守规矩的人看的。当规矩不管用的时候，有人选择了掀桌。Ghostty 的 Mitchell Hashimoto 宣布：提交 AI 垃圾代码，永久封禁。tldraw 的 Steve Ruiz 更干脆——自动关闭所有外部 PR，不管你用没用 AI。
这些反应看起来极端，但如果你每天花几个小时审查一堆看起来像回事但毫无价值的 PR，你可能也会想掀桌。
技术手段
有人做了一个 Anti-Slop 自动化工具，号称能自动关掉 98% 的劣质 AI 提交。自动化测试、代码检查、类型检查、集成测试——这些工具确实能拦住一部分问题。但它们有个天然的边界：自动化最擅长拦"代码跑不通"，最不擅长拦"代码跑得通但提交者不理解"。 测试全绿不代表代码没问题，它可能只是说明测试和代码犯了同一个错误。
三条路，都走不太远。但有一种更底层的变化正在发生。
过去，开源社区的核心契约很简单：你提交代码，我审查代码。代码能跑、测试过了、没有明显 bug，就够了。代码本身就是证明。
AI 打破了这个契约。代码能跑，但提交者不知道为什么能跑。测试过了，但那是 AI 写的测试，测的是 AI 以为该测的东西。描述逻辑清晰，但那是 GPT 的逻辑，不是提交者的逻辑。
所以社区开始意识到一件事：
show me code 不够了。得 show me understanding。
成熟团队不是禁止使用 AI。它们禁止的是把理解责任和验证责任外包给 AI。
这就是为什么 Godot 的维护者花半小时才能识破一个"看起来合理的 PR"修的不是根因——代码本身没问题，但写代码的人不理解问题。这就是为什么审核者问"你知不知道自己的代码在做什么"，对方答不上来。代码能证明"它能跑"，但不能证明"提交者理解它为什么能跑"。
而在所有这些应对方式中，最有意思的是 SQLite 的选择。它没有立规矩，没有掀桌，也没有做自动化工具。它做了一件更简单也更无奈的事：直接给 AI 写了一份说明书。
AGENTS.md 告诉 AI 项目的构建方式、测试要求、代码风格、注意事项——所有你通常会告诉项目新人的东西。既然 AI 已经是事实上的贡献者了，那就给它一份它能读懂的规矩。
问题还在进化
让我们回到 Daniel Stenberg。
他的经历恰好是整个危机的缩影。2025 年，curl 收到的 AI slop 描述写得更好，代码更像回事，越来越难分辨，有效率掉到了 5%。到了 2026 年，他在 LinkedIn 上说：低质量的 AI slop 反而少了，取而代之的是质量更高但数量更大的 AI 辅助安全报告。
问题没有消失。它换了件衣服。
从"过滤 slop"变成"管理洪流"。以前每周 2-3 份漏洞报告，现在每天 5-10 份。更崩溃的是，这些报告大部分还是对的。
如果代码生成已经被 AI 工业化了，那代码审查就不能还停在手工作坊的阶段。这不是加几个人、加几道检查就能解决的事。它需要的是一套能跟上 AI 进化速度的系统。
SQLite 的 AGENTS.md 不会是最后一份写给 AI 的说明书。但它可能是第一份。
引用来源
1. SQLite AGENTS.md：github.com/sqlite/sqlite/blob/master/AGENTS.md 2. Daniel Stenberg, "Death by a thousand slops"（2025.7.14）：daniel.haxx.se/blog/2025/07/14/death-by-a-thousand-slops/ 3. Daniel Stenberg LinkedIn（2026.4.5）：linkedin.com 4. Daniel Stenberg 邮件列表（2026.4.18）：lists.haxx.se 5. The Register, "AI slop got better"（2026.4.6）：theregister.com 6. Fedora AI 贡献政策草案及讨论：discussion.fedoraproject.org 7. Homebrew PR 指南：docs.brew.sh 8. Node.js VFS PR：github.com/nodejs/node/pull/61478 9. Node.js AI 代码请愿：github.com/indutny/no-ai-in-nodejs-core 10. Ghostty AI 政策 PR：github.com/ghostty-org/ghostty/pull/10412 11. tldraw 关闭外部 PR：github.com/tldraw/tldraw/issues/7695 12. Godot 维护者 Rémi Verschelde：gamedeveloper.com 13. Linus Torvalds Linux 7.1-rc4（2026.5.17）：Tom's Hardware 14. LWN.net "A flood of useful security reports"：lwn.net/Articles/1066581/ 15. OSSF wg-vulnerability-disclosures #178：github.com/ossf 16. "An Endless Stream of AI Slop"（Baltes/Cheong/Treude，海德堡/墨尔本/SMU，2026.3.28）：arxiv.org/abs/2603.27249 17. "AI Slop and the Software Commons"（2026.4.17）：arxiv.org/abs/2604.16754 18. GitHub Copilot 生产力研究：arxiv.org/abs/2302.06590 19. Copilot 安全评估（Purdue）：arxiv.org/abs/2108.09293 20. AI 助手与代码安全：arxiv.org/abs/2211.03622
