这两天我的私信炸了。朋友给我丢来一个链接：Node.js 社区有人联名请愿，要求核心仓库禁止 AI 生成代码。看起来像是“新技术 vs 老习惯”，但我盯着那条 1.9 万行的 VFS PR 想了半天，脑子里冒出来的不是“用不用 AI”的二选一，而是一个更古老、却被我们忽略很久的问题——开源是怎么建立信任的，又该如何在 AI 时代理一遍。

我自己日常既写代码也审代码，习惯了用 Copilot、Cursor、Claude Code 做样例和重构提示。也维护两个不大不小的开源项目，代码量不算吓人，但每多一位贡献者，我就得多花一份心力在评审、测试和沟通上。AI 这波浪潮带来的并不是“更快合并”，而是把这份心力放大成了一个新的变量：可不可靠、成本怎么分、出了问题谁负责。

这场争议到底在吵什么

故事的线索并不复杂：Matteo Collina 提了一个给 Node.js 加虚拟文件系统（VFS）的 PR，体量接近两万行，在说明里坦承大量使用了 Claude Code。

功能刚需、动机正当，作者还是社区中坚；但这波操作还是引爆了舆论。

Fedor Indutny 发起请愿，Kyle Simpson、Andrew Kelley 等人跟进签名，诉求并非技术歧视，而是对“如何在核心项目接受 AI 产物”感到不安。

担忧的层次挺清楚：

• 审查负荷被推高。一口气扔进来两万行，哪怕是资深 Reviewer，也会被上下文切换和细节验证拖垮。我做过一个不严谨的小统计：在团队里把一次大规模 AI 重构拆成 6 批，每批不超过 400 行，整体合入时间比一次性提交缩短了近 40%，Bug 率还低了一截。这不是 AI 的锅，是批次化的常识。
• 法律灰区让人心里没底。DCO 让贡献者承诺“我有权利提交这段代码”。模型训练数据里含有复杂授权来源时，这句话该怎么立？基金会法务可以背书，但维持信心的是可溯源的流程，而不是一句“没问题”。
• 社会契约正在被稀释。开源的默契是“互评中成长”。如果产出者是模型，Review 的建议没有落到一个会变更认知的人身上，维护者会产生“我在跟空气对话”的挫败感。
• 隐性门槛抬高。维护者要复现实验，可能需要同款付费工具或算力。开源一直在对抗“参与门槛”，新负担不该悄悄转嫁给志愿者。

另一边的反驳也站得住脚：质量应当是唯一标准；禁令难以执行——没人能从字节级别判断“哪一行出自 AI”；Matteo 这样的长期贡献者有信用记录，不该因为使用新工具而被一票否决。TSC 的 James Snell 也在评论里表达了类似立场。

更微妙的是，这并不是 Node.js 独有的烦恼。Linux 内核、QEMU、Python、Rust 都在讨论“AI 补丁”的边界。区别只在于，这次双方都是核心成员，争议被放到了聚光灯下。

把工具之争，翻译成“信任工程”

我更愿意把这件事理解为一次“信任的重构”。AI 在产能上是加速器，在协作层面却容易变成干扰项。与其纠结“能不能用”，不如把注意力放在“用到什么程度、配套什么承诺、让谁来买单”。

过去一年，我在团队里摸索了一套“人机协作三条线”，在这里给出一个可落地的版本，供开源维护者参考。

一、来源可追溯：给 Reviewer 可验证的信息

• 提交元数据加尾注（commit trailer）：AI-Assisted: yes/no、Model: vendor@version、Scope: e.g. tests/refactor/feature、Prompt/Script: 链接或摘要。不是为了审“Prompt 正不正确”，而是给出追溯线索。
• PR 描述里放“复现脚本或思路”——不要求付费账号，也不强制同款模型，至少给一个可对照的过程。能复现到 70%，就能把心里的那只猫按住一半。
• 引入 OpenSSF/SLSA 风格的“轻量级来源声明”。社区不需要一夜之间上强监管，但可以从模板做起。

二、体量可审量：把复杂度换成批次

• 设置“审阅能量预算”。例如核心仓库建议：功能型 PR 不超过 500 行有效变更；超过需要拆批或先提交设计草案。
• 强制配套测试或基准。AI 生成代码，评审者最怕“看不出问题”，那就让回归测试、微基准替你说话。哪怕是简单的 API Golden Test，也胜过空口保证。
• 对跨模块改动采用“灰度路径”：先合入隔离层，再逐步切换调用方。AI 擅长铺路，不擅长收尾，让流程来兜底。

三、责任可界定：让“谁在学习”变具体

• 提交者撰写“审阅说明”。逐段解释改动意图、潜在副作用、替代方案权衡。不是长文比赛，而是对 Reviewer 时间的尊重。
• 对新功能设定“观察期负责人”。无论是否用 AI，只要是新路径，就有人在一段时间内负责异常收敛和回滚策略。
• 把“AI 参与”当作协作事实，而非标签化身份。责任跟随提交权，而不是跟随模型。

这三条线并不会让争议消失，但能把抽象的“信任感”变成可以讨论的流程节点。一旦流程可讨论，就能被优化、被复用，也能被其他社区借鉴。

对普通开发者的现实指南

如果你常用 Copilot/Claude/Cursor 写代码，又想给核心项目贡献，不妨把下面这套“最小礼仪包”装上：

• 明确标注 AI 参与范围：重构/样例/测试/文档，还是核心逻辑；别一句“部分使用”，说不清等于没说。
• 控制提交粒度：把大改拆成语义清晰的小步，配上对应测试。维护者看到的是“可合并单位”，不是你今天写了多久。
• 准备好解释每一处改动：你得能不用模型，完整口述设计和边界。做不到这一点，等于把维护成本倒给别人。
• 别把付费门槛丢给对方：能用开源工具复现的，用开源工具；复现不了，就给出最小工作示例或截图/日志。

这些看起来麻烦，但换来的是评审效率的提升。我的体会是，只要 PR 描述和测试做到位，“AI 参与”本身并不会拉低通过率，反而往往能把争论聚焦到真正的设计权衡上。

维护者可以做的几件小事

• 在模板里加上 AI 使用说明字段与复现建议；把“超大 PR 拆分”写成明确标准，减少临场争吵。
• 给评审者留出“拒绝大改”的制度空间。不是不欢迎贡献，而是让评审能量有上限、有优先级。
• 设立“AI-Assisted” 标签与试点分支，把风险变化从主干移到可控区域。先跑一周 CI，再谈合并。
• 将赞助或基金会资源部分倾斜到“复现与测试”所需的算力与工具，别让隐性成本压垮志愿者。

别把“执行难”当成“不作为”的理由

很多人说，“就算禁了也查不出谁用了 AI”，于是得出结论：不如不立规矩。可执行性确实是门槛，但“来源标注、体量约束、责任承诺”这三件事并不靠取证，它们靠的是公开承诺与同行压力。开源的力量一直来自共识，而不是执法队。

尾声：工具会变，人心要稳

Node.js 这次风波，不是一次技术路线之争，更像是一次“协作方式升级”的倒逼。禁止或放开，很难给出一刀切答案；但把信任工程补齐，却几乎没有副作用。来源要能追、体量要能审、责任要能落，这三件事做到了，AI 只是把键盘换成了另一双手，协作的本质没变。

我常对团队说，AI 负责提速，人负责兜底。代码之外，我们还要为流程、为彼此的时间负责。等这套共识在更多社区固化下来，今天的争论，或许会被写进“最佳实践”的序章。

等风过去，再回头看，你会发现：我们真正驯服的不是模型，而是协作的复杂性。