1.9万行Claude Code代码引发百人联名“封杀”，Node.js核心成员请愿：项目里应禁止AI辅助开发

CSDN·2026年03月30日 19:48

在 AI 写代码这件事上，争议从来没有真正停过。

在 AI 写代码这件事上，争议从来没有真正停过。但这一次，战火烧到了最核心的基础设施之一——Node.js。

近日，一份致 Node.js 技术委员会（TSC）的请愿书引起了广泛关注。短短几天，已有超过百名开源开发者、前端工程师和程序员签署，他们呼吁“Node.js 社区应禁止 AI 生成的代码进入核心仓库”，将社区内部的分歧彻底摆上台面。

对于这场争议，有人认为这是对代码质量的坚守，也有人认为这是对技术进步的恐慌式反应。

一份由 Claude Code 生成的 1.9 万行代码 PR

回看事件始末，一切要从 2026 年 1 月的一次代码提交说起。

Node.js 技术指导委员会（TSC）成员、Fastify 框架维护者 Matteo Collina，彼时 Node.js 技术指导委员会（TSC）成员、Fastify 框架维护者 Matteo Collina，为了给 Node.js 添加社区期待已久的虚拟文件系统（VFS）功能，提交了一份包含约 19,000 行代码的 PR，覆盖约 80 个文件。

为此，他还专门发布了一篇长文《为什么 Node.js 需要 VFS》，详细说明了 Node.js 在缺乏虚拟文件系统时的痛点问题，如应用打包为单一可执行文件时需附带大量额外资源、测试中无法获得与模块系统一致的内存文件系统、多租户环境中依赖易错路径校验实现隔离，以及运行时动态加载生成代码只能依赖临时文件等问题。

当前，现有方案如 memfs、unionfs 只能“打补丁”式模拟 fs，无法真正接入模块解析流程，导致 import() 等调用绕过 VFS。

在 Matteo Collina 看来，社区早已明确提出这一需求，但始终缺乏一个真正落地的实现。

在这样的背景下，他从去年圣诞节期间开始着手开发 VFS 实现，并在今年 1 月提交了这份包含 1.9 万行代码的 PR。

按理来说，这本该是件皆大欢喜的事，可他在 PR 描述里添加了一句免责声明，点燃了争议的导火索：

我使用了大量 Claude Code token 来创建此 PR。所有更改均由我本人审核。

另外，Matteo Collina 也在博客中写道：

原本只是一次假期实验，却最终变成了 PR #61478：一个面向 Node.js 的 node:vfs 模块，涵盖 66 个文件，代码量接近 14,000 行。

说实话，这么大的 PR 通常需要几个月的全职工作才能完成。而这次之所以能在假期完成，是因为我使用了 Claude Code。我让 AI 处理那些枯燥重复的部分——正是这些工作让 14,000 行的 PR 成为可能，但没人愿意手动写：实现每一个 fs 方法的不同变体（同步、回调、Promise）、接入测试覆盖、生成文档。而我专注于架构设计、API 设计，并审查每一行代码。

没有 AI，这个假期侧项目根本不可能完成——简直不会发生。

众所周知，Claude Code 是 Anthropic 推出的 AI 编程工具，拥有 200K token 的超大上下文窗口，能生成跨文件复杂逻辑甚至完成代码重构。但在 Node.js 这个运行在全球数百万服务器上的核心项目中，AI 生成代码显然触碰了许多老开发者的底线。

在很多开发者看来，问题不只是 Matteo Collina“用了 AI”，而是这份 PR 体量巨大、修改核心模块、生成方式不透明，还有代码版权归属问题。

所以在接下来的短短两个月里，这份 PR 就经历了 128 次审查尝试和 108 条评论，其庞大的体量几乎让常规的同行评审流程陷入停滞。

截至 2026 年 3 月 26 日，该 PR 仍未被合并进主分支。

从一个 PR，演变为一场“是否禁止 AI”的讨论

这场争议的升级源于 Node.js TLS 模块主要作者、前 TSC 成员 Fedor Indutny 在 GitHub 上发起的公开请愿：《致 Node.js TSC 的请愿：禁止在核心代码中使用 AI》。

短时间内，包括 YDKJS 作者 Kyle Simpson、Zig 软件基金会主席 Andrew Kelley 在内的 100 多位核心开发者纷纷签署支持。

这份请愿书指出：

Node.js 是全球数百万服务器上关键基础设施，同时支撑着开发者日常使用的命令行工具。用 AI 生成的代码稀释多年精心打磨的核心代码，违背项目使命与价值观，可能破坏公共贡献建立的声誉基石，而正是这一基石让 Node.js 拥有今天的地位和社会价值。

与此同时，此请愿书还列出了反对 AI 生成代码的三大核心理由：

伦理：主流大语言模型公司在训练过程中使用了来源不合伦理的数据，其中包括受版权保护的作品，以及不同许可证下、未注明来源的开源代码。

教育：有证据表明，大语言模型的使用会阻碍学习过程。由于开源项目经常吸纳新贡献者，如果降低代码质量门槛，可能会削弱人们对 Node.js 核心的理解，进而影响项目的长期可持续性。

此外，代码评审不仅是为了发现 bug、修复安全问题、确保代码符合项目风格和架构规范，也是帮助提交者学习成长的重要环节。然而，大语言模型本身并不会学习，这意味着评审所投入的时间无法转化为贡献者能力的提升，从而被反复“浪费”。

特权：使用大语言模型通常需要付费订阅，或投入大量硬件资源在本地运行（且输出质量往往更低）。因此，提交的生成代码应当能够被评审者复现，而不应要求他们跨越付费订阅等门槛才能验证相关结果。

观点对立，各执一词

这份请愿书一经发布，许多网友表示支持：“1.9 万行代码的人工评审压力巨大，AI 辅助可能导致 PR 数量和规模膨胀，最终压垮依赖志愿者的评审体系。”

同样持反对意见的开发者也不在少数。其中，TSC 成员 James Snell 表示：评判代码的唯一标准应该是质量，而不是开发工具。

作为当事人的 Matteo Collina，更是在博客里写了一篇长文硬核回应，其用了“压面机”理论反驳道：我祖母曾用一台叫“Nonna Papera”的压面机做意大利面——几乎每个意大利家庭都有一台。但没有人会因此说，那不是她做的面。她选择面粉、鸡蛋，决定厚度和形状，工具只是帮助她完成制作。同样，我决定架构、设计 API，并审查每一行代码，这些代码属于我。

他进一步强调：DCO（开发者原产地证明）从未关心代码如何写，只关心贡献者是否有权提交并承担责任。这一点，与接受任何开源贡献并无不同。

对于下一步，Matteo Collina 称，「Node.js TSC 即将就 AI 辅助贡献的披露与署名规范进行投票。社区共识是：负责任地接纳 AI 辅助贡献，可以加速开源项目发展；一味禁止 AI 工具，只会限制贡献者来源。软件开发最重要的角色，从未改变——不是写代码的人或工具，而是理解、审查并为代码负责的人。」

鲜明对比：Linux 内核的 AI 逆袭，“垃圾”报告一夜变“黄金”

值得一提的是，就在 Node.js 为 AI 代码吵翻的同时，Linux 内核社区正经历着 AI 的“真香时刻”。

据外媒 The Register 报道，Linux 内核核心维护者 Greg Kroah-Hartman 在 KubeCon Europe 上透露，AI 在 Linux 内核的应用，完成了从“垃圾”到“黄金”的一夜逆袭。

时间拉回 2026 年 2 月前，Linux 内核社区还在为“AI Slop”（AI 垃圾）头疼 ——AI 生成的安全报告全是明显的错误，毫无参考价值，用 Greg 的话说，“有点搞笑，根本不用担心”。

这也是彼时整个开源圈的常态：cURL 创始人 Daniel Stenberg 曾吐槽，AI Slop 让漏洞赏金计划的有效率暴跌，最终在 2026 年 1 月直接喊停了这项运行 6 年的计划；Ghostty 项目更是在同月推出零容忍政策，提交 AI 垃圾代码将被永久封禁。

但 2026 年 2 月成为了 AI 的关键拐点，Greg 坦言自己并“不知道发生了什么，世界突然变了”：曾经的 AI 垃圾报告一夜之间变成了高质量有效报告，不仅 Linux 内核，所有开源项目都在收获 AI 生成的“真 bug、真建议”。

更惊人的是，这一变化并非个例，各大开源项目的安全团队私下沟通后发现，所有人都在经历同样的 AI 升级，只是没人能说清原因——是 AI 工具突然进化，还是开发者掌握了更高效的使用方法？

Greg 自己的实验更是印证了 AI 的实力：他用一个简单的提示词让 AI 分析内核代码，AI 瞬间输出 60 个问题及修复方案，三分之二的补丁直接可用，剩下三分之一虽有错误，却也指出了真实问题。这些补丁只需简单的人工优化，就能融入内核开发流程，效率提升肉眼可见。

如今，AI 在 Linux 内核社区早已不是“要不要用”的问题，而是“怎么用得更好”。目前 AI 主要承担代码审查助手的角色，还未成为核心代码的主要作者，但二者的界限正在模糊：社区已经推出了“co-develop”标签，用于标注 AI 辅助生成的补丁；简单的错误检测、条件判断等场景，AI 已经能生成数十个可用补丁，完全胜任基础开发工作。