当维护者说“不想再收陌生 PR”：AI 正在改写开源协作的默认规则

一位开源维护者在个人博客里把态度说得很直：陌生人别再给我提 PR 了。原因不是讨厌开源，而是他觉得，LLM 已经把“写出一段代码”的成本压得很低，外部 PR 带来的审查和协同负担，反而更贵。

这件事值得看，不是因为作者脾气大，而是它碰到了开源社区一个老前提：提交代码，默认就是最好的贡献。现在这个前提开始松了。维护者更在意的，成了判断、设计、审查和责任归属。

他拒绝的到底是什么，理由站不站得住

作者拒绝的不是所有协作，而是陌生贡献者提交、希望直接进主干的 PR。他给出的理由很集中：安全风险、风格偏好、沟通同步成本，以及自己用 LLM 实现往往更便宜。

这套理由在个人维护项目和小团队项目里，至少是成立的。很多项目缺的本来就不是几百行实现，而是上下文。谁理解历史包袱，谁知道为什么不能这么改，谁要对合并后的 bug 负责，谁就有更大的裁量权。

作者也没把门彻底关死。他欢迎别的帮助方式：反馈、讨论、报 bug、帮忙定位问题、提交参考性质的 PR 或提示词、参与 code review，或者直接 fork。

这点很关键。他拒绝的是“默认可合并的陌生代码”，不是“任何外部参与”。

为什么这事重要：开源贡献正在从提交代码，转向提交判断

作者有个判断很值得抠出来：真正的瓶颈不再是写代码，而是理解现有代码、设计改动、审查结果。这不是“程序员没用了”，也不是“开源贡献者被替代了”。问题小得多，也现实得多：代码生成便宜后，代码本身的证明力在下降。

以前开源文化强调“show me the code”。这套逻辑在代码昂贵的时候很合理。你写出来了，就是价值。现在模型把实现门槛往下压，维护者自然会问另一件事：你是不是理解这个项目，还是只是把一段能跑的补丁扔过来。

我更在意的是这背后的权力变化。代码越便宜，裁量越值钱。谁定义风格，谁判断风险，谁决定路线，谁就更像真正的门卫。《史记》里那句“天下熙熙，皆为利来”，放到这里并不玄：谁承担后果，谁就会把贡献标准改写成对自己最省成本的样子。

但这也不是所有项目都会照抄。项目越大，模块越清晰，维护流程越成熟，外部 PR 仍然可能很重要。相反，越是个人色彩重、设计一致性要求高、维护者时间少的小项目，这种态度越容易出现。现在只能说，这是一种正在冒头的协作取向，不是整个开源世界已经达成的新共识。

对维护者和贡献者，接下来该怎么做

对开源维护者，这件事的意思很直接：如果你已经用上 AI 编程工具，流程也许要改。不要再默认“多收 PR 就是社区健康”。你更该把入口重新设计清楚：什么改动欢迎先开 issue，什么只接受讨论，什么可以给参考 PR，什么必须先对齐设计。

动作层面，维护者至少会做两件事：一是把贡献指南写得更硬，减少陌生 PR 直接落到主分支的概率；二是把外部贡献转向 bug 复现、设计讨论、review 和原型验证。这会省时间，但也会把决定权更多留在核心维护者手里。

对活跃贡献者，过去那种“我写好了，你合一下”的诚意，今后未必总是加分。你更需要提供的是上下文：问题边界、复现步骤、为什么这样改、替代方案为什么不行。能写参考实现当然仍有价值，但它更像讨论材料，不再天然等于可合并成果。

更现实一点说，贡献者以后想帮项目，至少要学会这几件事：

• 写清楚可复现的 bug 报告
• 把需求边界和副作用说完整
• 提交能帮助讨论的原型，而不是直接要求合并
• 参与 review，帮维护者筛错，而不是只负责生成代码

对关注 AI 编程如何改变软件协作的人，这件事至少说明了一点：AI 先改掉的，不一定是“谁写代码”，而是“谁有资格让代码进入主干”。表面看是效率问题，骨子里是治理问题。

这里也别把 fork 说得太轻松。fork 当然是开源的合法出口，黑客传统里也一直如此。但 fork 往往带来维护分裂、补丁回流变慢、上游影响力下降。它适合价值观不合或需求长期分叉的情况，不是零成本替代。

接下来最该观察三件事：

• 哪类项目最先把陌生 PR 从默认欢迎改成默认谨慎
• 贡献指南会不会从“请提交 patch”改成“请先提交判断和证据”
• 平台和工具会不会把 review、issue、设计讨论做成比写代码更核心的协作入口

如果这些变化真的铺开，开源不会消失，但“共建”的样子会变。以前是代码先行，维护者把关；以后更可能是维护者定题，外部协作者提供证据、反馈和候选实现。名义上还是开放，结构上会更中心化。

这不是灾难，也不是喜讯。它更像一层旧秩序回潮：生产成本降了，入口权反而更贵。历史上这种事见得太多了，不完全一样，但味道很像。