22 个开源项目公开拒绝 AI 代码：vibe coding 的账单，维护者不想买了

lucas_AI
0 阅读1分钟

💡 一句话总结：一个叫 Open Source Says No 的目录站收录了 22 个公开拒绝 AI 生成贡献的开源项目（yt-dlp、Godot、QEMU、immich……），11 月 11 日冲上 Hacker News 首页。这不是新政策发布，而是把开源社区持续近一年的「AI slop 反击战」摆上了一个台面——如果你用 AI 往开源项目提 PR，这份名单值得先查再动手。

先问一个可能戳到你的问题：你有没有想过，自己顺手让 Claude Code 或者 Copilot 生成一个 PR 提给开源项目，会发生什么？

以前的标准答案是「排队等审查」。现在的答案可能是：直接关闭，屡犯封号——连解释的机会都没有。yt-dlp 的贡献指南里用大写字母写着「NO AI / NO LLM」，红线覆盖代码、文档、issue、翻译、美术，全都不收。

11 月 11 日，一个叫 Open Source Says No（osssaysno.com）的目录站登上了 Hacker News 首页（61 分、106 条评论）。它做的事情很简单：把那些公开宣布拒绝 AI 生成贡献的开源项目一个个列出来，附上政策原文引用、覆盖范围和验证日期。截至当天，名单上有 22 个经过验证的项目。

为什么一个「列表页」能火？因为它把一件分散在几百个 CONTRIBUTING.md 里的事，变成了可以一眼看全的生态信号：开源社区对 AI 生成内容的态度，已经从默许滑向了系统性反弹。

想自己查/围观？

事情是怎么走到这一步的？

把时间线摊开看，你会发现这场反弹不是某天的集体抽风，而是一年里一步步被 AI slop（AI 泔水——低质量、没人真正理解的 AI 生成内容）逼出来的。

今年 2 月，GitHub 自己先坐不住了：官方产品经理开帖讨论要不要给 PR 加「kill switch」——让维护者能一键关停容易被 slop 淹没的 PR 入口。连靠 Copilot 吃饭的平台都在琢磨这个，可见问题已经不小。

3 月，Redox（Rust 写的操作系统）把话说死：「本政策不接受讨论」，AI 生成的内容一律立即关闭，试图绕过的直接封禁。同一时间，研究者的统计也出来了：112 个被调查的开源项目里，71 个已经有明确标注 AI 助手参与的提交。

6 月底，标志性的一锤落下：Godot 基金会（就是那个开源游戏引擎）官宣修改贡献政策。规则相当细——

  • 新贡献者（合并 PR 不超过 3 次）未经维护者许可，不得提交新功能或大规模重构；
  • 禁止自主 AI Agent 和 vibe coding 式提交，违规者会被 GitHub 自动封禁提交权限；
  • AI 只允许用于补全、正则、查找替换这类「机械性小任务」，用了必须主动披露；
  • 连社区沟通都禁止贴 AI 翻译器生成的文本。

Godot 的理由说得直白：「AI 无法承担责任，而重度依赖 AI 的开发者，我们没法指望他们真正理解自己的代码到能修好它的程度。」这句话后来被 The Register、IT之家等多家媒体反复引用。

8 月，Oracle 给 OpenJDK 设了临时规则：不得提交大模型或扩散模型生成的内容，正式政策还在路上。10 月初，System76 给 Pop!_OS 的 COSMIC 桌面更新了 PR 模板——贡献者必须勾选声明「没有包含任何 AI 生成的代码、注释和描述」。

有意思的是 System76 给出的理由。首席工程师 Jeremy Soller 的逻辑不是意识形态，是算术：AI 让提 PR 的成本趋近于零，PR 数量暴涨，而能审查的人数没变——账算不平，只能拒收。

10 月下旬，Linux Foundation 的调研给出了量级：受访者估计，约四分之一的新进 PR 是低质量的 AI slop。The Register 的标题起得很直白：「AI 在帮开发者省时间的同时，也把开源社区的收件箱塞满了垃圾。」

然后就是 11 月 11 日，osssaysno.com 登上 HN 首页——至此，「封禁 AI 贡献」从一个个项目零星的自我保护，变成了一个有目录、有原文、有社区工作流（你可以粘贴仓库链接自动检查政策、生成预填 issue 提醒维护者表态）的显性生态。

政策其实分三大阵营

把这一年的政策摊开，RedMonk 分析师 kate holterhoff 给 86 个开源组织画过一张图谱，大致是三种姿态，而且每种的代表项目都很有分量：

  • 封禁派（ban）：Gentoo、QEMU、Zig、Godot、yt-dlp、Redox、immich、Servo、OkHttp……目录站收的 22 个都在这派。共同点是划出硬红线，违规直接关闭甚至封号。
  • 披露派（disclose）：Linux 内核、LLVM、Ghostty。不禁止，但要求如实披露 AI 参与，责任仍在提交者。
  • 宽松派（allow with responsibility）：curl、CPython、Node.js、Debian。接受 AI 辅助，但底线统一——「提交者必须理解、测试并能为每一行辩护」。EFF 的版本最有趣：代码可以让 AI 写，注释和文档必须人写。

听起来三分天下？实际比例远没有这么均衡。那项 112 个项目的调查里，3 月份整站封禁的只有 4 个（Zig、NetBSD、GIMP、QEMU），多数项目停在「允许但要求负责」——这里需要澄清一下：目录站的 22 个和调查的 4 个口径不同，前者是 11 月逐条验证的「明文封禁」收录，后者是更早时点的统计，数字差异主要来自时间和标准，不是谁错了。

但趋势的方向是清楚的：政策在从宽松向披露、从披露向封禁移动，Godot 和 System76 都是 2026 年下半年才动的手。pypa（pip 官方）的新政策是个典型中间态——AI 辅助没被一刀切，但 LLM 不得进 Co-authored-by: 署名、反复提交 slop 不经审查直接关闭、OpenClaw 这类无监督 Agent 明令禁止。

HN 评论区：最大的笑点和最真的担忧

HN 那栋楼里最高赞的调侃一针见血：「一个 vibe coding 出来的网站，专门收录反对 vibe coding 的项目——而所有人都注意到了。」没错，这种讽刺确实存在，而且没人打算否认。

严肃的讨论倒也扎实。主流意见支持封禁派：slop PR 生产便宜、审查昂贵，这个不对称是问题的根，封禁是在保护不堪重负的维护者。少数派则担心两件事：一是检测不可靠，声明式政策靠自觉披露加人工识别，误伤真人的风险真实存在（Godot 的自动封号尤其被点名）；二是一刀切可能劝退合规的新贡献者——毕竟多数认真写代码的人也会用补全。

有意思的是，两派吵到最后落点几乎一致：「真正的问题是披露，以及为自己的提交负责。」这句从评论区被顶上来的话，和宽松派政策里的官方措辞几乎一字不差——社区吵归吵，底线共识反而清晰。

学术界也来凑了热闹。一篇 ACM 论文（北大团队）系统研究了开源项目怎么治理 GenAI 贡献，结论和从业者直觉对上了：生成变便宜，不等于审查变便宜——这个不对称才是所有政策的原点。

这对你意味着什么？

如果你日常会用 AI 写代码，有几件实操的事值得现在就做：

  • 提 PR 前先查政策：目标项目的 CONTRIBUTING.md、AI_POLICY.md 或者直接搜「repo name + AI policy」。osssaysno.com 可以当快速索引用，但别只依赖它——收录有滞后，最终以仓库里的原文为准。
  • 把「辅助」和「生成」分开用：补全、正则、查 bug 这类机械任务几乎所有政策都放行；让 Agent 产出整个功能再原样提交，在封禁派项目里就是撞枪口。
  • 留好披露的余地：就算项目不强制，说清楚「哪些部分 AI 参与、你怎么验证过」只会加分。Godot 事件里被反复引用的那句话反过来看就是标准：你要能对自己的每一行负责到「能修好它」的程度。
  • 别让 AI 替你写署名和沟通：pip 明令禁止 LLM 进 Co-authored-by，Godot 连 AI 翻译的社区沟通都拒收——这些「小事」正在变成新的红线。

往大处看，这件事的信号意义比 22 个项目本身大。AI 编码工具的宣传语境是「人人都是 10 倍工程师」，而开源托管侧的回应是「先证明你读得懂你交的东西」。工具越激进，守门人的政策反弹就越具体——这两股力量的拉扯，才刚刚开始。

参考来源

（注：cURL 关停 bug bounty 项目的具体时间未经独立核实，仅见于 RedMonk 盘点，标注 uncertain；目录站创建者身份与其上线时间未查明。）

avatar
文章
阅读
粉丝