prolific 的包维护者 Sindre Sorhus 宣布禁用外部 Pull Request，原因是 AI 生成的贡献垃圾。他会继续维护自己的项目，但不再接受外部提交。SWC 也跟进，把 PR 限制为可信贡献者。
发生了什么
AI 编码工具让生成一份看起来像样的 PR 变得极其廉价。对维护者来说，这意味着审查负担急剧上升：大量 PR 代码风格看着没问题，实际没有理解项目上下文，甚至解决的是不存在的问题。
维护者的时间是开源项目里最稀缺的资源。当信噪比跌到某个阈值以下，关闭通道是理性选择。
这件事的影响面有多大
Sindre Sorhus 维护的包被大量项目间接依赖。下载量级的 npm 包背后往往就是几个人甚至一个人在维护。
如果这种模式扩散，受损的不只是个人项目，而是整个依赖生态的纠错能力。以前发现 bug 可以提 PR，以后只能提 issue 然后等。
为什么 AI 贡献特别难处理
传统低质量 PR 容易识别：代码风格差、没跑测试、描述含糊。
AI 生成的问题在于表面质量高：格式规范、描述完整、甚至自带测试。要判断它是否真的解决了正确的问题，维护者需要完整理解项目上下文——这恰恰是最耗时的部分。
成本从贡献方转移到了审查方。
社区在探索的几条路
一是限制提交权限，只接受可信贡献者。这是目前最直接的做法，代价是新人更难进入。
二是要求 PR 关联已确认的 issue，先讨论再动手。把审查前置到方案阶段。
三是用自动化做初筛。但用 AI 筛 AI 的效果存疑，而且有误杀风险。
四是贡献者自律：提交前先开 issue 沟通，说明你实际运行和验证过什么。
给想贡献代码的人的建议
第一，先开 issue 讨论，别直接提 PR。确认维护者认可这个方向再动手。
第二，说明你的验证过程。跑过什么测试、在什么环境验证、覆盖了哪些场景。AI 生成的 PR 通常缺的就是这个。
第三，从小处开始。文档修正、复现用例、测试用例，这些比功能改动更容易被接受。
第四，别用 AI 批量生成 PR 刷贡献记录。这在损害你自己未来的贡献机会。
一个结构性问题
开源协作的前提假设是「贡献的成本高于审查的成本」，这个假设成立时，PR 天然是有筛选的。AI 打破了这个平衡，社区还没找到新的均衡点。
本文由奇幻维度内容助手整理发布，欢迎在评论区交流你的看法。