2026 年 3 月，一场关于 AI 生成代码的争议在 Node.js 社区掀起轩然大波。
一份请愿书在短短数天内获得超过百名开发者签名，呼吁技术指导委员会（TSC）禁止 AI 生成的代码进入核心仓库。
这场争议不仅关乎技术选择，更触及开源项目的价值观与未来走向。
1. 事件起因：1.9 万行 AI 代码引发的信任危机
2026 年 1 月 22 日，Node.js TSC 成员、Fastify 框架维护者 Matteo Collina 提交了一个震撼社区的 Pull Request（PR #61478）。
这个 PR 包含约 1.9 万行代码，覆盖 80 个文件，旨在为 Node.js 添加虚拟文件系统（VFS）功能——一个社区期待已久的特性。
然而，PR 描述中的一句话点燃了争议的导火索：
“我使用了大量的 Claude Code tokens 来创建这个 PR。我已经亲自审查了所有更改。”
这份声明立即引发了社区的激烈讨论。
尽管 Collina 是资深贡献者，但如此大规模的 AI 生成代码是否符合开发者原创性证书（DCO）的要求，成为争论焦点。
2. 请愿书：百名开发者的集体发声
3 月 18 日，Node.js 前 TSC 成员、TLS 模块主要作者 Fedor Indutny 在 GitHub 上发起请愿书，要求 TSC 投票否决“允许 AI 辅助开发”的提案，明确拒绝 LLM 生成的核心代码重写。
请愿书在 GitHub 和 Change.org 两个平台同步发布，迅速获得超过 100 名开发者签名支持，其中不乏重量级人物：《You Don‘t Know JS》作者 Kyle Simpson、Zig 软件基金会主席 Andrew Kelley、Gulp 核心维护者 Blaine Bublitz 等。
请愿书开篇即强调：Node.js 是运行在全球数百万服务器上的关键基础设施，多年来由开发者精心手写的核心代码不应被 AI 生成内容稀释，这将动摇 Node.js 的声誉根基和社会价值。
3. 反对方的 3 大核心理由
请愿书列出了反对 AI 生成代码进入核心的三个关键论点：
1. 伦理与版权风险
主流 LLM 模型的训练数据包含大量未经授权的开源代码和版权作品。AI 生成的代码可能埋下版权隐患，而 Node.js 作为全球基础设施，代码版权必须绝对清晰，不能承担潜在的法律风险。
2. 教育价值的断裂
开源项目的代码审查不仅是发现 bug，更是新人学习成长的过程。然而 LLM 无法学习，审查者投入的时间无法转化为贡献者能力的提升，长期可能导致社区出现“技术断层”，威胁项目的可持续发展。
3. 工具特权与可复现性
使用 LLM 需要付费订阅或昂贵的本地硬件。提交的生成代码应该能被审查者无需付费工具即可复现，否则会在贡献者之间制造不平等，违背开源的平等精神。此外，AI 生成的代码不可复现，审查者难以理解设计意图，审查工作从“理解架构”退化为“黑盒找 bug”。
4. 支持方的反驳观点
尽管请愿书获得广泛支持，但也有不少开发者持不同意见：
1. 问题在于 PR 规模，而非 AI 本身
许多开发者指出，1.9 万行代码的 PR 本身就违反了良好实践，无论是否使用 AI。
Linux 内核维护者 Linus Torvalds 几十年来一直拒绝过大的 PR，现有政策已足够应对。
一位开发者评论道：“即使代码完美无瑕，也没人能理解那么多变更。”
2. AI 是工具，关键在于如何使用
反对请愿书的声音认为，这是对技术进步的“恐慌式反应”。
AI 辅助开发的边界应该被明确定义：是 0% 的 LLM 生成代码（仅用于研究），还是 100% 的“氛围代码”？
如果只是辅助研究和小规模代码补全，为何要一刀切禁止？
3. 制定新政策的成本
批评者质疑：如何执行禁令？要求每个贡献者签署未使用 AI 的声明？关闭 AI 自动补全？新政策会带来流程和官僚主义的成本。一位开发者提出：“审查者已经有权拒绝劣质代码，为什么需要两个政策来解决同一个问题？”
4. 应关注代码质量而非来源
部分开发者认为，重点应该是代码的质量、可维护性和安全性，而不是代码的生成方式。如果 AI 能生成高质量、可审查的代码，为什么要排斥它？
5. 争议的深层矛盾
这场争论暴露了开源社区面临的深层次冲突：
效率与质量的权衡：AI 能大幅提升开发效率，但代价是什么？当 AI 写代码的速度超过人类审查的速度，代码质量如何保证？
开放与控制的平衡：开源精神倡导开放与包容，但关键基础设施是否需要更严格的准入标准？
进步与传统的碰撞：技术工具在演进，但开源社区“人对代码负责”的价值观是否应该坚守？
值得注意的是，请愿发起人 Fedor Indutny 在 Reddit 讨论中表示，他并非反对所有形式的自动化重构。
如果 PR 作者能编写 AST 转换脚本或其他可复现的工具来完成相同的变更，他会乐于审查。
真正的问题在于：LLM 生成的代码既不可复现，又需要付费工具，还要求审查者承担巨大的认知负担。
6. 最新进展
目前，这个 1.9 万行的 PR 已被暂时阻止合并。
Node.js TSC 计划就“是否允许 AI 辅助开发”进行正式投票，结果将为整个开源社区树立先例。
这场争议已经超越了 Node.js 本身。从 Linux 内核使用 AI 修复漏洞，到 Node.js 因 AI 代码陷入治理危机，开源世界正在经历一场关于 AI 工具使用边界的集体反思。
无论最终结果如何，这场讨论都提醒我们：在拥抱新技术的同时，我们必须谨慎思考它对开源价值观、代码质量和社区文化的深远影响。
我是冴羽，10 年笔耕不辍，专注前端领域，更新了 10+ 系列、300+ 篇原创技术文章，翻译过 Svelte、Solid.js、TypeScript 文档，著有小册《Next.js 开发指南》、《Svelte 开发指南》、《Astro 实战指南》。
欢迎围观我的“网页版朋友圈”，关注我的公众号：冴羽（或搜索 yayujs），每天分享前端知识、AI 干货。
2026 年 3 月，一场关于 AI 生成代码的争议在 Node.js 社区掀起轩然大波。
一份请愿书在短短数天内获得超过百名开发者签名，呼吁技术指导委员会（TSC）禁止 AI 生成的代码进入核心仓库。
这场争议不仅关乎技术选择，更触及开源项目的价值观与未来走向。
1. 事件起因：1.9 万行 AI 代码引发的信任危机
2026 年 1 月 22 日，Node.js TSC 成员、Fastify 框架维护者 Matteo Collina 提交了一个震撼社区的 Pull Request（PR #61478）。
这个 PR 包含约 1.9 万行代码，覆盖 80 个文件，旨在为 Node.js 添加虚拟文件系统（VFS）功能——一个社区期待已久的特性。
然而，PR 描述中的一句话点燃了争议的导火索：
这份声明立即引发了社区的激烈讨论。
尽管 Collina 是资深贡献者，但如此大规模的 AI 生成代码是否符合开发者原创性证书（DCO）的要求，成为争论焦点。
2. 请愿书：百名开发者的集体发声
3 月 18 日，Node.js 前 TSC 成员、TLS 模块主要作者 Fedor Indutny 在 GitHub 上发起请愿书，要求 TSC 投票否决“允许 AI 辅助开发”的提案，明确拒绝 LLM 生成的核心代码重写。
请愿书在 GitHub 和 Change.org 两个平台同步发布，迅速获得超过 100 名开发者签名支持，其中不乏重量级人物：《You Don‘t Know JS》作者 Kyle Simpson、Zig 软件基金会主席 Andrew Kelley、Gulp 核心维护者 Blaine Bublitz 等。
请愿书开篇即强调：Node.js 是运行在全球数百万服务器上的关键基础设施，多年来由开发者精心手写的核心代码不应被 AI 生成内容稀释，这将动摇 Node.js 的声誉根基和社会价值。
3. 反对方的 3 大核心理由
请愿书列出了反对 AI 生成代码进入核心的三个关键论点：
1. 伦理与版权风险
主流 LLM 模型的训练数据包含大量未经授权的开源代码和版权作品。AI 生成的代码可能埋下版权隐患，而 Node.js 作为全球基础设施，代码版权必须绝对清晰，不能承担潜在的法律风险。
2. 教育价值的断裂
开源项目的代码审查不仅是发现 bug，更是新人学习成长的过程。然而 LLM 无法学习，审查者投入的时间无法转化为贡献者能力的提升，长期可能导致社区出现“技术断层”，威胁项目的可持续发展。
3. 工具特权与可复现性
使用 LLM 需要付费订阅或昂贵的本地硬件。提交的生成代码应该能被审查者无需付费工具即可复现，否则会在贡献者之间制造不平等，违背开源的平等精神。此外，AI 生成的代码不可复现，审查者难以理解设计意图，审查工作从“理解架构”退化为“黑盒找 bug”。
4. 支持方的反驳观点
尽管请愿书获得广泛支持，但也有不少开发者持不同意见：
1. 问题在于 PR 规模，而非 AI 本身
许多开发者指出，1.9 万行代码的 PR 本身就违反了良好实践，无论是否使用 AI。
Linux 内核维护者 Linus Torvalds 几十年来一直拒绝过大的 PR，现有政策已足够应对。
一位开发者评论道：“即使代码完美无瑕，也没人能理解那么多变更。”
2. AI 是工具，关键在于如何使用
反对请愿书的声音认为，这是对技术进步的“恐慌式反应”。
AI 辅助开发的边界应该被明确定义：是 0% 的 LLM 生成代码（仅用于研究），还是 100% 的“氛围代码”？
如果只是辅助研究和小规模代码补全，为何要一刀切禁止？
3. 制定新政策的成本
批评者质疑：如何执行禁令？要求每个贡献者签署未使用 AI 的声明？关闭 AI 自动补全？新政策会带来流程和官僚主义的成本。一位开发者提出：“审查者已经有权拒绝劣质代码，为什么需要两个政策来解决同一个问题？”
4. 应关注代码质量而非来源
部分开发者认为，重点应该是代码的质量、可维护性和安全性，而不是代码的生成方式。如果 AI 能生成高质量、可审查的代码，为什么要排斥它？
5. 争议的深层矛盾
这场争论暴露了开源社区面临的深层次冲突：
效率与质量的权衡：AI 能大幅提升开发效率，但代价是什么？当 AI 写代码的速度超过人类审查的速度，代码质量如何保证？
开放与控制的平衡：开源精神倡导开放与包容，但关键基础设施是否需要更严格的准入标准？
进步与传统的碰撞：技术工具在演进，但开源社区“人对代码负责”的价值观是否应该坚守？
值得注意的是，请愿发起人 Fedor Indutny 在 Reddit 讨论中表示，他并非反对所有形式的自动化重构。
如果 PR 作者能编写 AST 转换脚本或其他可复现的工具来完成相同的变更，他会乐于审查。
真正的问题在于：LLM 生成的代码既不可复现，又需要付费工具，还要求审查者承担巨大的认知负担。
6. 最新进展
目前，这个 1.9 万行的 PR 已被暂时阻止合并。
Node.js TSC 计划就“是否允许 AI 辅助开发”进行正式投票，结果将为整个开源社区树立先例。
这场争议已经超越了 Node.js 本身。从 Linux 内核使用 AI 修复漏洞，到 Node.js 因 AI 代码陷入治理危机，开源世界正在经历一场关于 AI 工具使用边界的集体反思。
无论最终结果如何，这场讨论都提醒我们：在拥抱新技术的同时，我们必须谨慎思考它对开源价值观、代码质量和社区文化的深远影响。
我是冴羽，10 年笔耕不辍，专注前端领域，更新了 10+ 系列、300+ 篇原创技术文章，翻译过 Svelte、Solid.js、TypeScript 文档，著有小册《Next.js 开发指南》、《Svelte 开发指南》、《Astro 实战指南》。
欢迎围观我的“网页版朋友圈”，关注我的公众号：冴羽（或搜索 yayujs），每天分享前端知识、AI 干货。