Node.js
PR #61478
第二个案例，我想把问题从“能不能做出来”，拉到“社区敢不敢接”。
不是 demo
是 core
这是一份给 Node.js 引入 node:vfs 的巨型 PR，要同时碰 fs、fs.promises 和 module loader。
问题不是
没人想做
作者也是 Node.js 团队的核心成员，专门解释过：VFS 对应的需求一直都在，只是规模太大，长期没人把它完整推进到 core。
164+
interception points
PR 自己给过一个很直白的数字: 要拦截的接口点就有 164+。这不是普通 feature，更像一次系统级改造。
作者主动披露
AI 参与
PR 描述里明确写了: 这份改动用了大量 Claude Code，但所有改动都由作者自己 review。
AI made it
possible
这句话重要，不是因为它像口号，而是因为它说明了 AI 在这里扮演的是“把超大工程推进出来”的放大器。
工程价值
是明确的
而且它的工程价值是明确的。VFS 不是玩具，它对应的是真需求：SEA、不落盘测试、沙箱、多租户、运行时代码生成。
但审查成本
没有消失
代码能更快产出，不等于 review、回归、兼容性验证也会同步变便宜。
代码更快产出
不等于 review
也更便宜
这一点是整个案例的关键反差。
争论很快变成
组织问题
讨论后来不只是“这个 PR 值不值得合”，而是升级成“OpenJS 要不要允许 AI-assisted development”。
甚至出现请愿
No AI in core
社区里有人发起联署，主张 Node.js core 不应接受 LLM 生成的核心重写；它引用的，正是这份 PR 和相关组织讨论。
谁来审
谁来签
谁来兜底
OpenJS 的讨论里，问题已经不只是代码，而是治理、DCO、维护责任，以及一系列后续责任问题。
最后卡住的
不是作者
AI 放大了提交能力，但 reviewer、maintainer 和能为大规模变更兜底的人，并没有同比例增加。