AI写代码这事，从诞生那天起就没消停过。如今这把火终于烧到了Node.js头上。

最近，一份请愿书在Node.js技术委员会（TSC）那里炸开了锅。短短几天，一百多个开源开发者、前端工程师和程序员签了名，要求“Node.js核心仓库禁止AI生成的代码”。这一下，把社区里藏了很久的分歧彻底摆到了台面上。

有人说这是守住了代码质量的底线，也有人说这是对新技术的害怕。

事情要从一个1.9万行的代码提交说起

今年1月，Node.js技术指导委员会成员、Fastify框架维护者Matteo Collina提交了一份大PR，将近19000行代码，改了80个文件。他给Node.js加了一个大家盼了很久的功能——虚拟文件系统（VFS）。

他还专门写了篇文章解释为啥Node.js需要这个功能：应用打包成单一可执行文件时得带一堆额外资源、测试时没有和模块系统一致的内存文件系统、多租户环境里靠路径校验做隔离容易出错、运行时动态加载代码只能依赖临时文件……这些问题确实存在。现有的memfs、unionfs这些方案，只能打个补丁模拟一下fs，根本接不进模块解析流程，import()这些调用照样绕过VFS。

Matteo自己也知道社区早就想要这个功能，就是没人真正把它做出来。所以去年圣诞节，他开始动手，到1月就交出了这份大PR。

本来这是件好事，可他在PR里加了一句免责声明，把火药桶点着了：

“我用了大量Claude Code token来创建这个PR。所有改动都是我本人审核的。”

他还在博客里说得更明白：“这本来就是个假期玩玩的项目，结果变成了PR #61478。这么大一个PR，正常情况下得全职干好几个月。这次能这么快，全靠Claude Code。我让AI去处理那些枯燥重复的活——每个fs方法的不同写法（同步、回调、Promise）、测试覆盖、文档生成。我只管架构设计、API设计，然后一行行审代码。没AI，这个假期项目根本做不出来。”

Claude Code是Anthropic出的AI编程工具，能处理20万token的大上下文，生成跨文件的复杂逻辑。但Node.js可是跑在全球几百万台服务器上的核心项目，AI写的代码，让不少老开发者心里不踏实。

在很多开发者眼里，问题不只是Matteo“用了AI”，而是这份PR太大、改的是核心模块、生成过程不透明，还有代码版权到底归谁。

结果接下来两个月，这个PR被审查了128次，评论108条。这么大的量，评审的人根本忙不过来。到2026年3月26日，这个PR还躺在那里没被合并。

从一个PR变成一场大讨论

事情升级是因为Node.js TLS模块的主要作者、前TSC成员Fedor Indutny在GitHub上发了个公开请愿：《致Node.js TSC：禁止在核心代码中使用AI》。

很快，YDKJS作者Kyle Simpson、Zig软件基金会主席Andrew Kelley等一百多个核心开发者都签了名。

请愿书里写得很直白：Node.js是全球几百万台服务器的关键基础设施，也是开发者日常用的命令行工具。用AI生成的代码去冲淡多年打磨出来的核心代码，跟项目使命和价值观背道而驰，还可能毁了靠公共贡献建立起来的声誉——正是这个声誉让Node.js走到了今天。

他们还列出了反对AI代码的三个理由：

伦理：主流大模型公司训练时用了来路不太正当的数据，包括受版权保护的作品和各种许可证下的开源代码。

教育：有证据说用大模型会影响学习。开源项目需要新人进来，如果代码质量门槛低了，新人可能就搞不懂Node.js核心是怎么回事，项目长远看撑不住。而且代码评审不光是找bug、看安全、查规范，也是帮提交者成长的机会。AI不会学，评审花的时间等于白费，没法变成贡献者能力的提升。

特权：用大模型要么花钱订阅，要么自己搭硬件跑（效果还差）。提交的代码得让评审的人也能复现，不能要求人家先掏钱才能验证。

两边吵得不可开交

请愿书一发，不少人站队支持：“1.9万行代码让人审，压力太大了。AI辅助搞不好会让PR越来越多、越来越大，最后把全靠志愿者的评审体系拖垮。”

但也有不少人反对。TSC成员James Snell就说：评判代码只看质量，跟用什么工具没关系。

当事人Matteo在博客里硬刚了回去。他打了个比方：“我奶奶有台压面机做意面——意大利人家家户户都有一台。没人会说那不是她做的面。她选面粉、挑鸡蛋、定厚薄、切形状，工具只是帮她完成。我也一样，我定架构、设计API、审每一行代码，这些代码就是我的。”

他还说：“DCO（开发者原产地证明）从来不管代码怎么写的，只管你有没有权提交、愿不愿意担责。这点跟接不接受开源贡献没区别。”

Matteo透露，Node.js TSC马上要就AI辅助贡献的披露和署名规范投票。社区里大家慢慢达成一个共识：负责任地用AI，能帮开源项目跑得更快；一刀切禁止，只会让能来贡献的人变少。软件开发里最重要的角色从来没变过——不是写代码的人，也不是工具，而是能看懂代码、审好代码、为代码负责的那个人。

另一边，Linux内核真香了

有意思的是，就在Node.js为AI代码吵得不可开交的时候，Linux内核社区正在经历AI的真香时刻。

据The Register报道，Linux内核核心维护者Greg Kroah-Hartman在KubeCon Europe上说，AI在内核的应用，从“垃圾”一夜变成了“黄金”。

2026年2月之前，Linux内核社区还被“AI Slop”（AI垃圾）折腾得够呛。AI生成的安全报告全是明显的错误，根本没用。Greg说“有点好笑，压根不用当回事”。

那会儿整个开源圈都一样。cURL创始人Daniel Stenberg吐槽AI垃圾让漏洞赏金计划的有效率暴跌，2026年1月直接叫停了运行6年的计划。Ghostty项目同月出了零容忍政策，谁交AI垃圾代码就永久封号。

但2026年2月，事情突然变了。Greg说他也不知道“发生了什么，世界突然不一样了”——以前的AI垃圾报告突然变成了高质量的有效报告。不光是Linux内核，所有开源项目都在收到AI找到的真bug、真建议。

更让人吃惊的是，这不是个例。各大开源项目的安全团队私下聊了才发现，大家都在经历同样的AI升级，就是没人说得清原因——是AI工具突然开窍了，还是开发者学会了怎么用好它？

Greg自己试了一把，效果确实好。他用一个简单的提示让AI分析内核代码，AI瞬间给出了60个问题和修复方案，三分之二的补丁直接能用，剩下三分之一虽然有问题，但也指出了真实的问题。这些补丁稍微人工改改，就能进内核开发流程，效率提升是实打实的。

现在Linux内核社区早就不纠结“要不要用AI”了，都在想“怎么能用得更好”。AI现在主要是当代码审查助手，还没成为核心代码的主要作者，但这个界限越来越模糊。社区已经出了个“co-develop”标签，用来标AI辅助生成的补丁。简单的错误检测、条件判断这些活，AI已经能生成几十个可用的补丁，基础开发完全能胜任。

最后

Node.js的核心开发者将来会不会也像Greg那样，被AI的产出惊到，现在还不好说。

但有一点可以确定：几乎所有成熟的开源项目迟早都得面对这个问题。AI不会停下来，代码只会越出越快。现在光说“禁止”不现实，关键是怎么把好质量关，保证每行代码都有人好好审过。

说到底，你现在写的代码，有多少是真的“你自己写的”呢？

本文内容仅供个人学习、研究或参考使用，不构成任何形式的决策建议、专业指导或法律依据。未经授权，禁止任何单位或个人以商业售卖、虚假宣传、侵权传播等非学习研究目的使用本文内容。如需分享或转载，请保留原文来源信息，不得篡改、删减内容或侵犯相关权益。感谢您的理解与支持！

链接: https://fly63.com/article/detial/13526