老牌开源项目该不该接受 AI 代码？

对于是否接受由 AI 生成的代码，开源界的 OG 们似乎分成了两大派别。

上个月底，Wayland 生态核心贡献者、知名开源老兵 Drew DeVault 在自己的博客上发表了一篇文章，标题叫《Vim 的悼文》。他在文中写道：自己所信任的那个 Vim 已经死了。矛头直指 Vim 社区中不断新增的 AI 生成代码，他认为这些代码对 Vim 造成了“污染”。

对 AI 零容忍

Vim 在开源界是毫无疑问的元老级项目，它的前身 vi 诞生于 1976 年，由 Bill Joy 在加州大学伯克利分校开发。Vim 本身发布于 1991 年，在开源编辑器战争里，Vim 和 Emacs 是两大阵营，程序员为此争论了几十年，写出了无数篇文章和段子。在老一辈程序员群体中，某种程度上用什么编辑器已经不只是工具问题，而是一种身份认同。

Vim 的创始人 Bram Moolenaar 在 2023 年 8 月去世，他曾在荷兰独自维护这个项目三十多年。在此之后，Vim 的维护工作主要由以 Christian Brabandt 为代表的一批长期贡献者接手，而 Drew DeVault 并不在此列。

DeVault 长期使用 Vim 进行创作和写代码，对 Vim 有深厚情感，多次发文评论 Vim 发展，直接影响了社区对 Vim9 的讨论。他认为如今的 Vim 和 NeoVim 都在开发过程中使用了 LLM 生成代码，并抨击这些代码都是“slop” —— 这个词他用了不止一次，原意是泔水、剩饭剩菜，在开源社区里被广泛用来形容 AI 生成的、缺乏质量下限的内容。

他对于 AI 的厌恶是全方位的，DeVault 对 AI 的批评不止于技术质量，还延伸到了环境、人权和政治三个维度：数据中心消耗了全球约 1.5% 的能源；芯片需求推高了非洲矿工的死亡风险；AI 生成的虚假信息正在喂养全球法西斯主义。

“生成式 AI 的本质，是为少数人敛财、集中权力、减少竞争，并支撑一个巨大的泡沫。”这是他对当下全球爆火的 AI 最大的指控。因此，他在发布“悼文”的同时建立了一个 Vim 分支，这个版本被命名为 Vim Classic，基于 Vim 8.2.0148 —— Vim9 Script 之前的最后一个版本。DeVault 没有时间去分辨现任维护者的工作哪些来自已故创始人 Bram Moolenaar，哪些不是，所以他选择彻底不要 Vim9 Script。项目托管在他自己做的 SourceHut，代码仓库里已经回移植了若干 CVE 补丁和小 bug 修复。DeVault 欢迎所有人贡献补丁，但有一条铁律写在 CONTRIBUTING.md 里：不接受任何 AI 生成的代码。

DeVault 的反应不是孤例。2026 年 3 月，用 Rust 编写的微内核操作系统 Redox OS 正式宣布禁止 LLM 生成代码，同时引入 DCO（开发者来源证书）机制。项目在公告里说了一句很直接的话：历史上，动手写PR本身就是一个隐性的质量过滤机制 —— 现在这个门槛被 AI 抹掉了，维护者的审查负担变得完全不可控。

4 月 15 日，跨平台多媒体开发库 SDL（Simple DirectMedia Layer）也更新了贡献政策，明确拒绝 LLM 生成的代码。SDL 维护者给出的理由很实际：AI 生成代码的可追溯性不足、许可证归属不明、审查成本不可控。

再往前数，NetBSD、GIMP、Zig、QEMU 等项目都在更早时候各自宣布了类似的“禁 AI 政策”。

实用主义至上

与这些坚决反对 AI 代码参与开源的“保守派”们不同，更多的知名老牌开源项目对 AI 参与社区贡献持开放态度。

研究员 Phil Eaton 在 2026 年 3 月调查了 112 个主要开源项目，结果是：约 63% 已接受明确标注的 AI 辅助贡献，包括 Linux、Chromium、Kubernetes 等。其中，Linux 内核社区在接受 AI 这件事上经历了很大的内部斗争才达成统一。

2025 年底，Nvidia 工程师 Sasha Levin 向 Linux 6.15 内核提交了一个补丁：代码是 AI 写的，更新日志是 AI 写的，测试用例也是 AI 写的。Levin 本人做了审查和测试，但提交时没有告诉维护者这件事。维护者发现后，Linux 内核邮件列表（LKML）炸了锅。

这不是 Linux 内核第一次面对 AI 生成的代码，但从来没有一次如此彻底 —— 连提交信息都没有人类写的痕迹，这件事直接推动了内核社区正式制定规则。

2026 年 1 月，争论在 LKML 上达到顶峰。Intel 的 Dave Hansen 与 Oracle 的 Lorenzo Stoakes 就内核应该如何监管 AI 工具爆发了激烈冲突。核心分歧不只是“允不允许用”，而是一个更棘手的法律问题：DCO（Developer Certificate of Origin，开发者原产地证书）要求提交者法律认证自己有权提交这段代码，但 LLM 的训练数据里包含了大量带有许可证限制的开源代码 —— 这意味着一个使用 Copilot 写代码的开发者，实际上无法完全保证提交代码的来源是否干净。

Red Hat 在同期发布的一份分析报告中指出：如果继续忽视这个问题，内核社区可能无意中违反开源许可证，并彻底瓦解整个 DCO 框架。

2026 年 4 月 12 日，Linus Torvalds 以他标志性的直率终结了争论，Linux 内核正式合并了史上第一份 AI 代码贡献政策文档coding-assistants.rst，三条核心规则落地：

Signed-off-by 必须由人类签署：AI 代理不得使用这个具有法律约束力的标签 必须标注 Assisted-by：注明使用的模型和工具，格式示例： Assisted-by: Claude:claude-3-opus sparse 人类承担全部法律责任：包括审查义务、许可合规，以及未来出现的一切 bug 和安全漏洞

Linus 在 LKML 上的原话：“我不希望内核开发文档也卷入这种站队。因此我坚持文档中对 AI 的唯一定位，就是「工具」。”他做了一个类比：禁止特定的 AI 工具，就像禁止某个特定品牌的键盘一样毫无意义。

至此，Linux 内核社区正式明确了 “AI 仅作为工具、拒绝无意义的限制、强调人类提交者责任” 的核心原则。

政策实验的意外结论

就在这套框架确立之后不久，发生了一件有意思的事。

Anthropic 研究员 Nicholas Carlini 用 Claude Code 做了一次漏洞挖掘实验：他写了一个简单的 bash 脚本，遍历 Linux 内核源代码树中的每一个文件，让 AI 逐个检查（脚本限制了 AI 在同一文件内重复寻找同一个漏洞）。

结果在 90 分钟里，5 个可远程利用的内核漏洞被发现，其中 4 个此前未知。最古老的一个于 2003 年 3 月引入，距今 23 年，比 git 诞生还早两年。

漏洞位于 Linux 内核 NFS v4.0 驱动中。攻击原理很直接：NFS 拒绝消息中的 Owner ID 字段最大可达 1024 字节，但内核用于构建这个响应包的静态缓冲区只有 112 字节 —— 当两个 NFS 客户端对同一文件加锁产生冲突时，内核试图把 1056 字节的数据写入 112 字节的缓冲区，造成堆缓冲区溢出，可被远程利用。

Carlini 的做法，其实恰好是 Linux 新政策所要求的理想模板： **AI 出力，人类把关，Assisted-by 标注，责任归属清晰。**但这个发现本身，却让政策的目的变得耐人寻味：如果 AI 能在 90 分钟内挖出人类维护者 23 年都没发现的漏洞，那么“人类审查 AI 代码”这个机制，在实践中究竟能提供多少保护？

答案也许令人不安：人类审查的价值，可能不在于发现漏洞，而在于承担漏洞被发现之后的责任。

Carlini 称其已经锁定了“数百个潜在漏洞”正在逐一确认。这意味着，未来也会有大量由 AI 发现、人类尚未验证的漏洞躺在某个列表里，等着被分配到具体的人头上。Linux 内核社区的新政策在逻辑上完全自洽：AI 负责找，人负责认责。但这个逻辑的代价是，一旦大规模漏洞由 AI 发现成为常态，人类维护者的“审查”将越来越像一种仪式，而非实质性的安全屏障。

规模越大 责任越大

Linux 内核社区不是不想拒绝 AI。Linus 在 LKML 上说得很清楚：“我们不会去买一个 AI 检测软件来识别谁用了 AI 写代码却没标注。”他没有这个义务，也没有这个意愿。内核社区有数以万计的活跃提交者，代码库规模以千万行计，维护者靠的是深厚的技术经验、模式识别和同行审查维持项目健康迭代 —— 不是靠工具扫描。

DeVault 能完全“封杀”AI，是因为 Vim Classic 项目小到他一个人扛得住。没有数以万计的 PR，没有多架构、多版本并行维护的压力，没有商业公司的 SLA 要求。他的“纯净版”是有代价的 —— 代价是放弃成长，放弃新功能，放弃大多数可能来帮忙的贡献者。

这就是为什么 Linux 内核和 Vim Classic 的选择其实都合理。Redox 能禁，SDL 能禁，因为这些项目的规模和治理结构允许这种选择；Linux 不行，Chromium 不行，Kubernetes 不行，它们如今的规模在面对席卷全球的 AI 浪潮时已无法调转船头。

开源社区在 AI 问题上的分裂，本质上是一个规模问题，也是一个你想在多大程度上为你的项目负责的问题。Linus 选择了负责到底，DeVault 选择了眼不见为净。

1. Drew DeVault 悼文原文: https://drewdevault.com/2026/03/25/2026-03-25-Forking-vim.html
2. Vim Classic 官网: https://vim-classic.org/
3. LKML 关于 AI 政策的讨论: https://lore.kernel.org/lkml/CAHk-=wg0sdh_OF8zgFD-f6o9yFRK=tDOXhB1JAxfs11W9bX--Q@mail.gmail.com/
4. Claude Code 发现 Linux 内核 23 年漏洞: https://mtlynch.io/claude-code-found-linux-vulnerability/
5. 主要开源社区 AI 贡献情况调查报告: https://theconsensus.dev/p/2026/03/02/source-available-projects-and-their-ai-contribution-policies.html

4月24日，OSC源创会 × FAIR plus 2026
【具身智能工程化实战沙龙】
深圳福田会展中心9号馆4号会议室
聚焦具身智能从技术研发到工程落地的核心痛点
现场还能体验模力方舟“口袋龙虾”PocketClaw

✅一线项目复盘
失败案例拆解
AI硬件资源对接

免费报名 oschina.net/event/8598188