年 月，一场关于 AI 生成代码的争议在 Node.js 社区掀起轩然大波。

请愿书引发关注

一份请愿书在短短数天内获得超过百名开发者签名，呼吁技术指导委员会禁止 AI 生成的代码进入核心仓库。

争议的核心

这场争议不仅关乎技术选择，geng触及开源项目的价值观与未来走向。

Node.js TSC 的决策 Matteo Collina 的 PR

年 月 日Node.js TSC 成员、Fastify 框架维护者 Matteo Collina 提交了一个震撼社区的 Pull Request。

大规模 AI 生成代码

这个 PR 包含约 万行代码，覆盖 个文件，旨在为 Node.js 添加虚拟文件系统功Neng——一个社区期待Yi久的特性。

声明引发争议

然而PR 描述中的一句话点燃了争议的导火索： “我使用了大量的 Claude Code tokens 来创建这个 PR。我Yi经亲自审查了所有geng改。”

DCO 的挑战

这份声明立即引发了社区的激烈讨论。尽管 Collina 是资深贡献者，但如此大规模的 AI 生成代码是否符合开发者原创性证书的要求，成为争论焦点。

反对 AI 生成代码的观点 伦理与版权风险

主流 LLM 模型的训练数据包含大量未经授权的开源代码和版权作品。

AI 生成的代码可Neng埋下版权隐患，而 Node.js 作为全球基础设施，代码版权必须绝对清晰。

不Neng承担潜在的法律风险。

教育价值的断裂

开源项目的代码审查不仅是发现 bug，geng是新人学习成长的过程。

LLM无法学习，审查者投入的时间无法转化为贡献者Neng力的提升。

长期可Neng导致社区出现“技术断层”，威胁项目的可持续发展。

工具特权与可复现性

使用 LLM 需要付费订阅或昂贵的本地硬件。

提交的生成代码应该Neng被审查者无需付费工具即可复现。否则会在贡献者之间制造不平等，违背开源的平等精神。

AI生成的数据不可复现,审查者难以理解设计意图,审查工作从“理解架构”退化为“黑盒找bug”。

支持 AI 生成代码的观点 PR规模并非关键

许多开发者指出， 万行代码的 PR 本身就违反了良好实践，无论是否使用AI。

Linux 内核维护者 Linus Torvalds 几十年来一直拒绝过大的 PR ，现有政策Yi足够应对现有情况 。

一位开发者评论道：“即使代码完美无瑕，也没人Neng理解那么多变geng。”

AI是工具而非问题所在

反对请愿书的声音认为这是对技术进步的“恐慌式反应”。

AI辅助开发的边界应该被明确定义：是 % 的 LLM 生成代码，还是 % 的“氛围代码”？

Ru果只是辅助研究和小规模代码补全，为何要一刀切禁止？

制定新政策成本高昂

批评者质疑：如何执行禁令？要求每个贡献者签署未使用 AI 的声明？关闭 AI 自动补全？新政策会带来流程和官僚主义的成本。“审查者Yi经有权拒绝劣质 代码,为什么需要两个政策来解决同一个问题？” 一位开发者提出 。

关注质量而非来源

部分开发者认为，重点应该是 代码的质量、可维护性和安全性 ，而不是 代码的生成方式 。

Ru果 AI Neng生成高质量、可审查的代码 ，为什么要排斥它 ？

开源社区面临的双重压力 效率与质量之间的权衡

效率与质量之间的权衡: AI Neng大幅提升开发效率 ，但代价是什么 ？当 AI 写 代码的速度超过人类审查的速度 ， 代码质量如何保证 ？

开放与控制之间的平衡: 开源精神倡导开放与包容 ，但关键基础设施是否需要geng严格的准入标准 ？

进步与传统之间的碰撞: 技术 工具在演进 ，但 开源社区“人对 代码负责” 的价值观是否应该坚守 ？

Fedor Indutny 的回应

中 , 请愿发起人 Fedor Indutny 表示 , 他并非反对所有形式 的自动化重构 。

Ru果 PR 作者Neng编写 AST转换脚本或其他可复现 的工具来完成相同的变geng,他会乐于审查 。

目前的情况

真正的问题在于：LLM生成的代码既不可复现 , 又需要付费工具 , 还要求审查者承担巨大的认知负担 。

结论

---