开源项目AI代码争议：保守派与务实派的路线分歧

对于是否接受由 AI 生成的代码，开源界的元老们分成了态度鲜明的两大阵营。

上个月底，Wayland 生态核心贡献者、知名开源老兵 Drew DeVault 在自己的博客上发表了一篇名为《Vim 的悼文》的文章。他直言，自己曾经信任的那个 Vim 已经“死”了，而矛头则指向了社区中不断涌入的 AI 生成代码，他认为这些代码对项目造成了“污染”。

对 AI 零容忍的保守派

Vim 在开源界是不折不扣的元老。它的前身 vi 诞生于 1976 年，由 Bill Joy 在加州大学伯克利分校开发。Vim 本身发布于 1991 年，与 Emacs 的“编辑器战争”曾是程序员群体中一道独特的风景，甚至成为一种身份认同的象征。

Vim 创始人 Bram Moolenaar 于 2023 年 8 月去世，他曾独自维护这个项目三十多年。此后，维护工作主要由以 Christian Brabandt 为代表的一批长期贡献者接手。而 DeVault 虽然不是核心维护者，但作为长期用户和深度参与者，他对 Vim 的发展一直保有巨大影响力，此前就多次发文影响社区对 Vim9 的讨论。

他批评如今的 Vim 和 NeoVim 在开发中都使用了 LLM 生成代码，并多次用“slop”（原意泔水、剩饭剩菜）这个词来形容这些缺乏质量下限的 AI 生成内容。DeVault 对 AI 的反感是全方位的，从技术质量延伸到环境、人权甚至政治影响：他认为数据中心消耗了全球约 1.5% 的能源；芯片需求推高了非洲矿工的死亡风险；AI 生成的虚假信息正在助长全球的法西斯主义。

“生成式 AI 的本质，是为少数人敛财、集中权力、减少竞争，并支撑一个巨大的泡沫。”这是他最核心的指控。因此，在发布“悼文”的同时，他建立了一个名为 Vim Classic 的分支，基于 Vim 8.2.0148 —— 即 Vim9 Script 出现前的最后一个版本。项目托管在他自建的 SourceHut 上，并已回移植了一些 CVE 补丁和小修复。DeVault 欢迎所有人贡献，但 CONTRIBUTING.md 文件里写着一条铁律：不接受任何 AI 生成的代码。

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

4 月 15 日，跨平台多媒体开发库 SDL 更新了贡献政策，明确拒绝 LLM 生成的代码。维护者给出的理由非常实际：AI 生成代码的可追溯性不足、许可证归属不明、审查成本不可控。 更早之前，NetBSD、GIMP、Zig、QEMU 等项目也都宣布了类似的“禁 AI”政策。

实用主义至上的务实派

与这些坚决反对的“保守派”不同，更多的知名老牌开源项目对 AI 参与贡献持开放或审慎接受的态度。研究员 Phil Eaton 在 2026 年 3 月的一项调查显示，在接受调查的 112 个主要开源项目中，约 63% 已接受明确标注的 AI 辅助贡献，这其中包括 Linux、Chromium、Kubernetes 等巨无霸项目。其中，Linux 内核社区的决策过程尤为曲折和具有代表性。

2025 年底，Nvidia 工程师 Sasha Levin 向 Linux 6.15 内核提交了一个补丁：代码是 AI 写的，更新日志是 AI 写的，测试用例也是 AI 写的。虽然他本人做了审查和测试，但提交时并未告知维护者。此事一经发现，立刻在 Linux 内核邮件列表上引发了轩然大波。

这次事件直接推动了内核社区正式制定 AI 贡献规则的进程。2026 年 1 月，争论达到顶峰。Intel 的 Dave Hansen 与 Oracle 的 Lorenzo Stoakes 就内核应如何监管 AI 工具爆发了激烈冲突。核心分歧不仅是“允不允许用”，更触及一个棘手的法律问题：DCO 要求提交者法律认证自己有权提交代码，但 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 在邮件列表中的原话是：“我不希望内核开发文档也卷入这种站队。因此我坚持文档中对 AI 的唯一定位，就是「工具」。”他做了一个类比：禁止特定的 AI 工具，就像禁止某个特定品牌的键盘一样毫无意义。

至此，Linux 内核社区确立了“AI 仅作为工具、拒绝无意义的限制、强调人类提交者绝对责任”的核心原则。这代表了一种典型的务实派立场，也反映了大规模项目面对技术浪潮时的现实选择。

新政策下的意外实验与思考

就在新框架确立后不久，发生了一件耐人寻味的事。Anthropic 研究员 Nicholas Carlini 用 Claude Code 做了一次漏洞挖掘实验：他写了一个 bash 脚本，让 AI 遍历检查 Linux 内核源代码树中的每一个文件。

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

漏洞位于 Linux 内核 NFS v4.0 驱动中。攻击原理直接：当两个 NFS 客户端对同一文件加锁产生冲突时，内核会试图把 1056 字节的数据写入一个仅有 112 字节的静态缓冲区，造成堆缓冲区溢出，可被远程利用。

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

答案或许令人不安：人类审查的价值，可能不在于发现漏洞，而在于承担漏洞被发现之后的责任。 Carlini 称他已锁定了“数百个潜在漏洞”待确认。这意味着，未来将有大量由 AI 发现、待人类验证的漏洞列表，等待被分配到具体负责人头上。新政策在逻辑上自洽，但它的一个潜在代价是，一旦 AI 大规模发现漏洞成为常态，人类维护者的“审查”可能越来越像一种划分责任的仪式，而非真正的安全屏障。这引发了关于如何有效利用 人工智能 工具的更深层思考。

规模决定选择，责任定义立场

Linux 内核社区并非不想拒绝 AI。Linus 说得很清楚：“我们不会去买一个 AI 检测软件来识别谁用了 AI 写代码却没标注。”他没有这个义务，也认为没有意义。内核社区依靠的是深厚的技术经验、模式识别和同行审查来维持健康迭代，而非工具扫描。

反观 DeVault，他能完全“封杀” AI，很大程度上是因为 Vim Classic 项目规模小，可以靠个人或小团队的高标准来维持。但代价是放弃快速成长、新功能迭代，以及大多数潜在贡献者。这就是为什么 Linux 内核和 Vim Classic 的选择其实都合理。Redox OS、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