不欢迎 PR：顶级 AI 开源项目如何管理成千上万贡献者
GitHub 发明了 Pull Request 这套机制，18 年来一直默认开放。但现在，一些顶级 AI 原生开源项目正关闭 PR 入口，因为它们找到了更好的方式。
包括 Flue 和 tldraw 在内的这些项目拒绝接受外部贡献者提交的 PR，部分原因是这些 PR 几乎都是 AI 生成的。维护者们更倾向于用自己的 Agent 来创建和管理 PR。
此外，许多项目开始采用软件工厂模式来管理社区贡献。通常由一组 Agent 负责分类 PR、复现问题（如果是 bug）、实现修复或新功能、再做评审，最后交回人类合并。
Vercel 为 AI SDK 搭建的软件工厂
Vercel 最近发布了一篇题为《Building a software factory for AI SDK》的文章，介绍了他们的开源 AI SDK 项目（每周 npm 下载量超 2000 万）如何部署 Agent 来应对 PR 和 Issue 的积压——到 6 月底，这些积压已超过 1000 个未关闭 Issue 和近 800 个 PR。
Vercel 的系统里有多种 Agent，各自负责不同任务，比如有专门复现 bug 的 Agent，有负责打修复补丁的，还有负责审核修复的。
Vercel 之所以搭建这个软件工厂，一个关键原因是它更信任自己的 agent 来完成工作，而不是社区成员运行的 agent。
Vercel 工程师 Lars Grammel 在 一段 YouTube 视频 中解释道："如果我们拥有一个非常特定的 agent，配合一套专门优化的 prompt，而且根据过往经验，它在修复某一类 bug 上一直非常成功，那么我们就会对这个特定的 agent 配置建立信任。"
他补充说："对于开源项目来说，值得考虑部署自己的 agent 和自己的流程，不必一味信任社区，这样做其实可以缩短代码审查的时间。"
Grammel 还展示了该系统的部署架构，指出"系统包含一个 UI、一个 Web 应用、一个底层 API、一个执行空间，以及若干沙箱环境"。整个流程随后与 GitHub 同步，由 GitHub 自动触发后续操作。其中 Grammel 提到的 UI 是 Vercel 自主开发的。
这套软件工厂上线仅四周后，Vercel 声称该工厂现在「贡献了我们合并的 PR 中 25% 到 35%，关闭了 70% 到 80% 的 issue。」
Astro 的自动分类系统
在 GitHub 上拥有 62,000 stars 的 Astro web 框架也采用了相同的理念，项目创始人 Fred Schott称之为「软件工厂思路」。
Schott 告诉 Latent Space：「过去五年，我们一直处于 issue 涌入的速度远超处理能力 的状态。」
而现在，有了 Agent 接手分类工作，他们重新掌握了主动权。
他说：「这半年情况完全不同了。现在我们可以借助这些自动化来解决问题——处理分类、复现问题，在人工介入之前就让用户验证机器人提出的修复方案。」
成效不仅体现在未处理 issue 数量大幅下降，更彻底改变了 Astro 团队应对社区请求的方式。
Schott 表示："在我十多年的开源经历中，从没见过这种情况。"他解释道，关键在于把 issue 当成每周必须处理的优先事项来处理，而不是一个不断修剪的待办列表。
此外，Astro 的"自动分流"系统直接促使 Schott 创建了一个全新的 agent 框架，名为 Flue。
Flue 不接受你的 PR，但欢迎讨论
在 Flue 项目中，Schott 尝试了一种更为激进的 PR 处理方式。Flue 的贡献者指南写道，他们"打算重新想象整个流程"——部分原因是为了防范所谓的"AI 垃圾 PR 随手提"现象。
Schott 解释说，基本上 Flue 项目中所有外部提交的 pull request 都会被自动关闭，并转成 issue 或讨论。Bug 报告和修复提案转为 issue，功能请求则转为讨论。
"你提交了 PR，我们不会有什么意见，只会把它的内容重新整理成 issue 和讨论的形式。然后再从那里出发，想办法找到让合适的人参与进来的方式。"
这有点像是把进来的请求当成销售线索来处理，而不是维护者觉得必须去审阅的一项工作。贡献者指南解释说，他们结合团队自身的专业判断和"我们能用到的最好的 SOTA（State-of-the-Art）大语言模型"，来决定下一步该做什么。
一旦在 issue 或讨论中做出了决策，agent 就会被部署到"调研、设计、实现和初步审查"各个环节。
既然我们的 agent 能写代码，你的外部 PR 就没什么价值了
和 Flue 一样，拥有 5 万星标的"源码可用"绘图工具 tldraw 会自动关闭外部 PR。
项目创始人 Steve Ruiz 在今年 1 月宣布了这一政策，五个月后又重申，说这是"针对我们编码方式的变化（更多讨论、更多智能体）、公共贡献的社交惯例，以及不断变化的代码安全形势做出的有倾向性的决定"。
Steve Ruiz@steveruizokabsurdity in my issues rn 
4:04 PM · Jun 6, 2026 · 11.2K Views6 Replies · 1 Repost · 88 Likes
HashiCorp 联合创始人、Ghostty 创造者 Mitchell Hashimoto，如今也是 Superlogical 联合创始人，他的看法更进一步。他认为，"未来大型开源项目会彻底关闭外部贡献。"
Ruiz 回应道，"如果需求描述得足够清楚、代码又能让智能体来写，那让人来贡献代码就没什么意义了。"
可是……社区怎么办？
在传统开源模式中，维护者审查 PR 不只是为了看代码，更是为了指导贡献者，并从中考察未来的维护者人选。如果 AI SDK、Astro 这类项目用智能体承担了大部分代码审查和实现工作，那些想更深入参与社区的人又该何去何从？
Schott 也意识到这是个风险。
"这始终留下一个敞开的口子：如果你不断收窄项目范围，到了某个节点，你我双双去度假——怎么办？这其实没法解决所有问题。"
不过，Flue 和 tldraw 不接受 PR，但都接受新的 issue 和讨论，这一做法或许指明了一个解决思路：通过更多的交流，社区成员能更好地相互了解和信任，这既是一种向同伴学习的方式，也是证明自己有资格成为维护者的途径。
至于代码本身，如果维护者自己用 AI 比接受外部代码贡献更省事，那正如 tldraw 创始人 Steve Ruiz 所言："与其让社区参与代码贡献，不如把社区贡献限制在仍然有价值的地方：问题反馈、讨论交流、视角分享和用心支持。"