Chousei · 数字花园

科技

开源社区同时禁用AI和非英语使用者

3 min read

你写完了一个小工具——一个把 Markdown 转成幻灯片的小脚本，或者一个给自己用的命令行小工具。

代码大部分是你自己写的，但有几个函数卡了你一下午，最后是问了 AI 才写出来的。README 你用翻译工具转成了英文，因为你觉得国际友人可能用得上。GitHub 账号是上个月刚注册的。

现在你准备做一件再正常不过的事：给一个你常用的项目提一个 issue，报告一个你在用的时候发现的边界情况。

你点进那个项目的 Discussions，找发帖按钮。

没有发帖按钮。

你往下翻规则说明，看到一行字：

如果你不会英语，你得去找另一个社区。

那一刻你才反应过来，你连"能不能开口说话"的资格，都还没有开始谈。

一个 39 万人的社区，规定了谁能进来

10 月 24 日周六晚上，Reddit 上最大的开源社区之一 r/opensource 的版主 u/Wolvereness 发了一个帖子，标题是《Your tokens aren't valuable: No more AI》（你的 token 不值钱，不要再 AI 了）。

这个社区当时有将近 39.2 万名成员，每周约 9.8 万人访问。帖子的第一句是：

如果你的项目用了 AI、是由 AI 做的，或者是给 AI 用的，r/opensource 不欢迎你。以今天这种形态存在的 AI，与这个开源社区格格不入。

听起来像一条无关紧要的社区公告。但往下读，它其实同时关掉了五扇门：

第一扇：项目。 要在这里展示一个项目，它必须同时满足——存在满一年、还在积极维护、有多名贡献者（帖子里写的是"凭主观判断，3 个以上"）、不是常见的毕设项目（笔记软件、PDF 阅读器、命令行音乐播放器都算）、不是"给 AI 用的"（MCP 服务器被点名了）、并且已经有了一个社区。OSI 许可证依然要。

第二扇：账号。 账号注册满一年，"有明显的 Reddit 贡献"，而且原话是："别为了来这里才注册一个 Reddit 账号。"

第三扇：AI。 原话是：

如果你明显在你的项目里用了 AI，我们不想要。Token 很便宜，我们不在乎你花了多少 token 做出你的惊人项目。

第四扇，也是最让人愣住的一扇：语言。

如果你不会英语，你得去找另一个社区。我们分不清 AI 写的和 AI 翻译的。既然你不会英语，你甚至没法核实它翻译得对不对。

第五扇：处罚。 临时封禁只留给"一时判断失误"的人。如果你发帖或评论的内容是"LLM 输出 token 的结果"，那你"永远不会再被欢迎回来"。版主还顺手邀请大家加入一个叫 "cleanup crew"（清理队）的志愿小组，并建议不认同的人去 r/opensourceeai——他自己都标注了 (sic)，也就是"原文如此"。

规则发布后大约十几个小时，评论区堆了 1180 到 1400 条评论，帖子净票数是 0。几乎立刻，一个新的竞争社区 r/TrueOpenSource 被创建出来，创建者置顶了一个申诉 mega thread。Wolvereness 后来还加了一段编辑，祝那个新社区成为"一个很好的避难所"。

它要解决的，是一个真问题

我们先别急着骂。因为版主想解决的问题，是真问题，而且是整个开源世界这两年最痛的那个问题。

GitHub 官方在 2026 年 2 月发布的年度开源趋势报告里，说了一段后来被反复引用的话：

即使你把 AI slop 从等式里拿掉，贡献量的绝对规模也在增长，可能大到无法管理。这感觉像一场针对人类注意力的拒绝服务攻击（denial of service attack on human attention）。

GitHub 自己把这种情况叫做 AI slop——大量低质量、而且经常是错的贡献。它们不增加项目价值，却要占满维护者的审查时间。

报告里的数据把这件事的严重程度说得很清楚：

  • 2025 年 GitHub 上接近 10 亿次提交，同比增长 25%
  • 每月合并 4320 万个 PR，同比增长 23%；全年公共仓库累计 5.187 亿个 PR
  • 2025 年 5 月到 9 月，光是 Copilot 的 agentic 工具就创建了超过 100 万个 PR
  • 2025 年增长最快的顶级项目里，约 60% 是 AI 项目

而报告里那句最要命的话是：

在很多情况下，审查这些额外建议所需要的时间，增速快过了维护者人数的增速。

更麻烦的是结构性的：GitHub 说，加入开源项目的人越来越多，但进入 owner / maintainer 位置的人数保持稳定。贡献者漏斗的底部在剧烈膨胀，顶端却没跟上。GitHub 自己的结论是——开源不能指望贡献者共享工时、沟通策略、文化期待，"甚至语言"。

所以版主想去挡住 slop，我完全理解。如果每个周末都有 200 个 AI 生成的"万年历 CLI"涌进来要你 star，那个社区确实会死。

但 Linux 内核刚投了相反的一票

真正让我停下来的，是这件事发生的时间点。

就在 r/opensource 立规矩的前几天——10 月 13 日——Linux 内核的邮件列表上，Linus Torvalds 说了这样一句话：

"你还看不出那类规则有多蠢吗？"（Do you not see how UTTERLY STUPID those kinds of rules would be?）

他说的是要求提交者申报 AI 工具使用的那类规则。

事情原本是这样：2026 年 1 月，Linux 内核文档里多了一条要求——凡是用"任何高级编码工具"帮过忙的提交，都要在 commit message 里加一个 Assisted-by: 标签，写明用了哪个模型。当时这条规则是内核里正式写着的。

然后事情反转了。

10 月 9 日，内核开发者 Sasha Levin（Nvidia）提交了一个补丁，废除这条要求，理由是 2026 年 Maintainers Summit 上已经达成共识。他还甩了一个很硬的数据：Linux 7.3 到 7.3-rc 一共 18533 个非合并提交，其中只有约 10% 带着 Assisted-by: 标签——而 LLM 的实际使用率远高于这个数字。标签早就形同虚设了，因为你根本没在标注。

Greg Kroah-Hartman 这位此前支持保留标签的资深维护者，后来转成了支持删除。Levin 一度撤回补丁，因为审查者要求他在 commit message 里写清楚为什么要在一年后推翻自己之前的立场。

最后，内核给出的方向是：别再在 changelog 里打标签了，如果你愿意，就在 cover letter（提交说明信）里描述你实际用了什么工具。 换句话说——记录，但不强制、不标准化、不拿来当准入条件。

顺便说清楚，内核并没有对 AI 完全关门。它保留的硬约束恰恰是责任那一层：AI agent 不得添加 Signed-off-by 标签，因为只有人才能认证 DCO（Developer Certificate of Origin，开发者原创声明）；人类提交者要负责审阅所有 AI 生成的代码，并确保许可合规。

同一家公司、同一套社区、同一个月，出了两个相反的决定。

一边是全球最专业的开源治理机构：不要用"你用了什么工具"来当门槛，因为那没有客观标准，而且会惩罚那些最需要帮助的人。

另一边是一个 39 万人的论坛版主："明显用了 AI"的项目我们不想要，而且他自己承认了没有客观标准。被问到"怎么判断明显用了 AI"时，他的回答是：

"规则写成这样，是为了让版主在审核时有足够的裁量权，删掉尽可能多的 slop。"

一条靠裁量执行的规则，落到具体某个人身上，就不再是规则，是运气。

社区自己算出了这条规则的边界

最有意思的部分，是社区自己动手把这条规则的逻辑推到底，然后发现它推不下去。

第一个漏洞：Linux 内核现在含有 AI 生成的代码。

按字面读，"用了 AI 的项目不欢迎"——那么所有构建在 Linux 上的项目，按字面都不合规。评论区立刻有人贴出了这样一张清单：在这个社区里，你再也不能讨论的项目包括——

Linux、Chromium、Firefox、WordPress、VS Code、Python、VLC、Blender、Git、Docker、LibreOffice、React、Node.js、PHP、TypeScript、Rust。

这张清单基本上就是过去三十年开源世界最重要的那一串名字。

第二个漏洞：单个人维护的项目。 要求"3 个以上贡献者"（而且是"凭主观判断"），加上"我们不能再受理寻找维护者或征求他人参与贡献的请求"——这条单独拿出来，就等于把独立开发者从求助的入口上切断了。一个刚起步的新项目，本来最需要的就是发个帖问一句"有没有人愿意一起做"，而这恰恰是明文不受理的。

第三个漏洞：一年门槛。 项目要满一年，账号要满一年。这意味着今年做的所有东西、今年注册的所有账号，在这一年里都发不出帖子、也拿不到版主的"批准用户"豁免。

第四个漏洞，也是最扎人的一个：语言条款和 AI 条款是被绑在一起的。

版主的逻辑链是：我们分不清 AI 写的和 AI 翻译的 → 既然你不会英语，你就无法核实翻译对不对 → 所以请你去别处。

但翻译这件事，本来是开源社区最重要的润滑剂。因为英文不是所有人的母语，翻译是让一个巴西人、一个越南人、一个尼日利亚人也能读懂你的 issue、也愿意帮你改错别字的那座桥。现在，这座桥本身成了可疑证据——一个人不会英语，等于他用机器翻译，于是他就不够"人类"。

而 GitHub 自己的报告，其实已经把这件事说穿了。它在讲维护者疲劳时写下的那句"甚至语言"，说的是开源不能指望贡献者共享语言——这是对英语主导的现实承认，不是一条罪状。到了 r/opensource，它被翻译成了"不会英语的人请离开"。

一座被蓝色裂痕劈开的大桥，桥面一侧闪着电路光，另一侧是手写纸张与信件

规则与现实的裂缝，就在每一个具体的人身上

我们这边的门槛线，画在大多数人身后

可能有人会说：那是 Reddit，那是老外的社区，跟我们没关系。

但把数据摆出来，你会发现这条门槛线画在大多数中国开发者的身后，而不是前面。

中国信通院《AI4SE 行业现状调查报告（2026 年）》（4 月 2 日发布，2109 份有效问卷）里的几个数字：

  • 2025 年"非常重视"软件研发智能化转型的企业占比 46.09%，同比增长 134.55%
  • 90% 以上开发人员都在用智能开发工具的企业占比，从 2024 年的 5.71% 跳到 2025 年的 27.65%
  • 代码生成采纳率 2025 年均值 42.61%，同比 +55.17%；代码入库采纳率均值 40.67%，同比 +74.32%
  • 开发者满意度接近 99%，非常满意的超过 30%；提效超 30% 的企业占比近七成
  • 应用形态里，智能原生开发工具（AI IDE）占比最高，34.31%
  • 工具份额上，国内工具占 60.56%（Trae、通义灵码等），海外工具占 39.44%
  • 94% 的企业选择八大国产模型系列

更直接的体感数据来自 State of AI 2026（7258 名开发者）：受访者写的代码里，AI 生成的比例中位数从 2025 年的 28% 涨到 2026 年的 54%，"一直在用 AI"的比例翻了一倍。

在一个中文开发者社区的第三次 AI 编程工具调查里（609 份"用过"样本），手写代码占比 0% 和 5% 的合计已经到 51%。Claude Code 用过率 72%，Codex 从 23% 涨到 55%，国产替代工具（通义灵码、文心快码、CodeBuddy）21%。而 IDC 的数据是：美国 91% 的开发者用 AI 编程工具，中国是 30%——但这已经是 1H25 的口径，现在早不是了。

大厂内部更直接：腾讯超过 90% 的工程师在用 CodeBuddy，50% 的新增代码由 AI 生成；百度 2025 年二季度内部 AI 生成代码超过 43%；字节超过 80% 的工程师在用 Trae。

所以当你读到"一个 39 万人的社区决定不要 AI"这句话的时候，请记住它的位置——这堵墙是在大多数人的身后，不是身前。 它挡住的不是还在观望的人，而是已经站在里面的人：他们用 AI 写代码，用 AI 翻译文档，用 AI 补测试，然后把成果发到一个正好说"我们不要这个"的社区里。

而另一边，同一个 GitHub 报告里有一句话，同样值得抄下来：

"开源不能指望贡献者共享工时、沟通策略、文化期待，甚至语言。"

它说的是开源必须为此做好准备——准备的意思是写清楚贡献指南、行为准则、决策文档，把多语言、多时区、多文化当成常态来设计，而不是把不会英语的人请出去。

还有一个数字：国内规模最大的代码托管平台 Gitee（开源中国，2013 年上线），2023 年已托管超过 1000 万个仓库、用户突破 800 万；截至 2024 年底，Gitee 有 1350 万注册用户、3600 万个代码仓库，服务超过 36 万家企业。GitHub 2025 年 10 月一度出现过"封禁中国 IP"的事件（后来证实是技术故障），GitLab 已经退出中国市场。

你要选一个能写中文 issue、能让母语者读得懂你写的东西、并且不因为你不会英语就把你请出去的地方，这件事本身就是一种技术选择。

三件今天就能碰的事

这条规则最终会不会执行、执行到什么程度，我们说了不算。但有三件事，我们自己能做。

第一件：把"跨语言可读"当成基础设施，不是负担。

开源社区里最值钱的东西从来不是代码，是一个陌生人愿意为你改一个错别字。英文 README 的成本是翻译一次；双语 issue 模板的成本是维护一份模板。而获客成本——一个因为看不懂英文而放弃提问的用户——是零收入的。

如果你在维护一个哪怕只有三个 star 的项目，也值得准备：一份英文 README、一份中文 README、一份 issue 模板里明确写"中英文提问都可以"。

第二件：如果你用 AI 写代码，最有价值的不是隐藏，是留可核验的痕迹。

Linux 内核最后选了 cover letter 而不是 changelog 标签，逻辑是同一个：记录的目的不是给规则判定用，是给人看的时候能对上账。

具体来说：commit message 用自己的话写、自己手写；每一行 AI 生成的代码，你自己过一遍；测试你自己跑，别让 AI 说它跑过了（AI 写的测试最擅长的事，就是绕开它本该验证的那段逻辑）；顺手留一份"这部分是 AI 帮的、我审过了"的说明。

这不是为了自证清白，是因为你才是那个要对代码负责的人。内核文档里写得很明白：Signed-off-by 只有人能签，是因为 DCO 是一个法律意义上的原创声明。你签的字，AI 不能替你签。

第三件：如果你是一个人做项目，把"让人进来"当成项目的一部分。

规则说"3 个以上贡献者"、"已有社区"、"不再受理找人帮忙的请求"——这套门槛背后的真问题，恰恰是独立开发者的处境：GitHub 说得很清楚，加入的人越来越多，变成维护者的人没变多。所以你要做的不是凑人数，是把通道修好：

写一份 CONTRIBUTING.md（哪怕只有十行，告诉别人怎么跑起来、怎么提 issue、怎么提 PR）；把 issue 模板准备好；把贡献者列表挂出来——哪怕只有两个人，也比空着强；如果你实在找不到人，就在 README 里写清楚你需要什么，让路过的人能顺手帮你。

GitHub 那份报告里，被低估的最重要的一句，是"缺乏清晰书面治理规范的项目将难以可持续地应对规模增长"。 一份 CONTRIBUTING.md 的价值，不在于它能给你带来多少 star，而在于当第三个人想帮你的时候，他不必从零开始问你"这个项目怎么参与"。

回到那座桥

我们再回到那句最让人难受的话：

"我们分不清 AI 写的和 AI 翻译的。既然你不会英语，你甚至没法核实它翻译得对不对。"

翻译是把一个人带进社区的那座桥。

一个不会说英语的开发者，本来就比会说英语的开发者多走一步——他得先把想说的话变成英文，才能让别人看懂，才能帮上忙。这已经是很费力的一件事了。现在，有人在这座桥的入口贴了张纸条：因为你走的是这座桥，所以你不像人。

我想说的不是"AI 到底好不好"。r/opensource 里的支持者也不是傻子——他们当中很多人是真的被周末 vibe coding 出来的垃圾项目烦透了。那是一个真实且合理的愤怒。

我想说的是另一件事：当"什么是人类写的"这个问题，从法律和共识手里，挪到一个人的裁量权手里，我们就都不是裁判员了，我们都是当事人。

Linus Torvalds 那句"你还看不出那类规则有多蠢吗"，不是对外人的敌意。那是一个行业里的老手，在骂一个规则。 他骂的每一条，r/opensource 那五条里都能找到对应：拿工具当门槛（他说蠢）、没有客观标准只能靠裁量（他说蠢）、惩罚最需要帮助的人（他说蠢）。他甚至没有提 r/opensource 的名字，他骂的是那类规则本身。

而全世界最专业的开源项目，在同一个月，投票把那条规则从自己的文档里删掉了。

所以最后的问题，可能不是"该不该禁 AI"。

而是：你上一次，为一个你并不认识的贡献者，留过门吗？

木桌上的笔记本电脑显示着代码，旁边是显示着聊天气泡的手机、便签、笔和咖啡杯

门槛是别人定的，但门是可以自己开的

信息来源

文章分类

  1. 01 AI
    15
  2. 02 新闻
    24
  3. 03 技术解读
    0
  4. 04 游戏
    1
  5. 05 经济
    4
  6. 06 体育
    0
  7. 07 教育
    4
  8. 08 文化
    5
  9. 09 商业
    18
  10. 10 健康
    26
  11. 11 科技
    27
  12. 12 信息安全
    24
  13. 13 AI技术
    44
  14. 14 科学
    3
  15. 15 社会
    6
  16. 16 国际新闻
    8
  17. 17 社会热点
    96
  18. 18 能源
    9
  19. 19 经济热点
    126
  20. 20 科技前沿
    55
  21. 21 消费
    18
  22. 22 民生
    33
  23. 23 社会观察
    9
  24. 24 17
    0
  25. 25 30 经济热点
    3
  26. 26 金融
    0
  27. 27 金融热点
    3
  28. 28 科技解读
    0
  29. 29 技术洞察
    0
  30. 30 财经
    2

标签