PR 不再受欢迎：顶级 AI 开源项目如何管理成千上万的贡献者
Pull Request（PR）曾是开源协作的基石，但如今，一批顶尖的 AI 原生开源项目正在关闭这条通道。Vercel、Astro、tldraw 等团队开始用 AI 智能体接管分类、复现、修复和审查工作，将“人提 PR”的传统模式，转变为“人给线索、AI 干活”的软件工厂模式。这场变革，正在重新定义开源贡献的含义。
开源协作的范式转换
GitHub 发明了 Pull Request（PR）——这一协作机制默认向所有人开放，已经走过了 18 个年头。但今天，一些顶尖的 AI 原生开源项目正在关闭 PR 通道，因为它们找到了更好的替代方案。
这些项目包括 Flue 和 tldraw，它们拒绝接受外部贡献者的 PR，部分原因是这些 PR 通常由 AI 生成。维护者们更倾向于使用自己的智能体（agent，即能自主执行任务的 AI 程序）来创建和管理 PR。此外，许多项目还开始采用“软件工厂”模式来管理社区贡献，典型的做法是：一组智能体分工协作，先对 PR 进行分类，复现问题（如果是 bug 的话），实现修复或新功能，进行审查，最后交给人类维护者合并。
Vercel 为 AI SDK 搭建的软件工厂
Vercel 最近发布了一篇文章，标题是 “Building a software factory for AI SDK”（为 AI SDK 搭建软件工厂）。文中描述了开源项目 AI SDK 如何部署智能体来管控 PR 和 issue（问题）积压问题——截至 6 月底，这个每周 npm 下载量超过 2000 万的项目，积压了“超过 1000 个未处理的 issue 和近 800 个 PR”。
Vercel 的系统中配备了几种不同类型的智能体，每种负责不同的任务。例如，有的智能体专门复现 bug，有的负责应用修复，还有的负责审查修复代码。
Vercel 搭建这个软件工厂的一个关键原因在于：它更信任自己的智能体，而不是社区成员运行的智能体。Vercel 工程师 Lars Grammel 在 YouTube 视频中解释说：“如果我们有一个针对特定提示词做了优化的专用智能体，而且历史数据表明它在修复某类 bug 上非常成功，那么我们就会对这个智能体配置产生信任。”他补充说：“对于开源项目来说，值得考虑使用自己的智能体和自己的配置，而不一定信任社区，因为这实际上可以缩短你的审查时间。”
Grammel 还展示了该系统的部署架构。他提到：“有一个 UI（用户界面）、一个 Web 应用、一个底层 API（应用程序接口）、一个执行空间，还有若干沙箱（隔离的测试环境）。”这套系统与 GitHub 同步，任何变更会自动触发后续操作。Grammel 提到的 UI 是定制开发的。
Vercel 软件工厂部署架构（图：Lars Grammel）
这个软件工厂上线仅四周后，Vercel 就声称它已经“编写了我们合并的 PR 中的 25% 到 35%，并关闭了 70% 到 80% 的 issue。”
Astro 的自动分类系统
Astro 是 GitHub 上拥有 6.2 万 star（收藏标记数，反映项目热度）的 Web 框架，也采用了其创作者 Fred Schott 所说的“软件工厂思路”。Schott 对 Latent Space 说：“过去五年，我们一直处于 issue 涌入速度快过处理速度的状态。”而现在，智能体接管了分类工作，他们重新掌握了控制权。他说：“过去六个月情况完全变了。我们现在可以用这些自动化来处理这些 issue——负责分类、复现，并在我们（维护者）还没有查看之前，先让用户去验证智能体建议的修复是否有效。”
Astro 工厂机器人运行示例
结果不仅是未解决的 issue 大幅减少，更彻底改变了 Astro 团队应对社区请求的方式。Schott 说：“我做了十多年开源，从未见过这种情况。现在可以把 issue 当作一个每周都必须优先处理的事情，而不是一个要不断修剪的积压清单。”
此外，Astro 的自动分类系统还直接促使 Schott 创建了一个全新的智能体框架，名叫 Flue。
Flue 与 tldraw：关闭 PR 通道的先行者
Bug 报告和修复建议会被转成 issue，功能请求则进入讨论区。按照 Flue 的贡献者指南，现在大部分 PR 工作都能交给智能体来做。“如果你提交了一个 PR，别介意，我们只会把它转成 issue 和讨论。然后从那里开始，想办法找到合适的方式把大家带进来。”这有点像把收到的请求当作“线索”来对待，而不是一件维护者必须义务去审查的工作。
贡献者指南里解释，团队会结合自身的专业知识，加上“我们能用到的最好的 SOTA（State-of-the-Art，最先进）大语言模型”，来决定接下来该做什么。一旦在 issue 或讨论中做出决定，智能体就会被派去做“研究、设计、实现和初步审查”。
既然智能体能写代码，那你的外部 PR 就没价值了吗？和 Flue 类似，采用“源码可用”模式的 React 绘图工具 tldraw（5 万星标）会自动关闭外部 PR。项目创始人 Steve Ruiz 在 1 月份宣布了这一政策，五个月后又再次强调，指出这是“一个基于以下变化做出的主观决定：我们编码方式的变化（更多讨论、更多智能体）、公共贡献方面的社交惯例，以及代码安全领域的格局变化”。
HashiCorp 联合创始人、Ghostty 创建者 Mitchell Hashimoto（现在是 Superlogical 的联合创始人）则更进一步。他认为“未来大型开源项目会完全关闭外部贡献”。Ruiz 对此回应说：“如果 issue 描述得足够清晰，代码又可以让智能体来写，那让人来贡献代码就没什么意义了。”
对开发者意味着什么？
这场变革对普通开发者影响深远。过去，“提交 PR”是参与开源的默认路径；如今，在 Flue、tldraw 这类项目中，这条路径正在被“提交 issue → 等待维护者或智能体处理”的新流程取代。
对于想要参与开源贡献的开发者来说，理解这些项目的新规则变得至关重要——盲目提交 PR 可能会被直接关闭，而一份高质量的 issue（问题描述清晰、包含复现步骤）反而比一份代码更受欢迎。对于开源维护者来说，“软件工厂”模式提供了一条应对贡献洪流的可行路径，但它也需要投入精力搭建基础设施、配置智能体，并重新定义与社区的关系。
从整个行业来看，AI 正在从“辅助写代码”走向“管理代码库”，而开源协作的规则，也正在被重新书写。