title: "PRs NOT Welcome：顶级 AI 开源项目如何管理数千贡献者"
source_url: "https://www.latent.space/p/pr-not-welcome"
author: "Latent.Space"
excerpt: "公共早报 Flue、tldraw 和 Vercel 的 AI SDK 等领先的 AI 原生开源项目正在拒绝外部拉取请求，转而使用自己的代理来管理代码贡献，以更好地控制质量和安全性。"

GitHub 发明了拉取请求（pull request），18 年来，拉取请求一直默认开放。但现在，一些顶级的 AI 原生开源项目正在关闭 PR 功能，因为他们找到了更好的方式。

这些项目，包括 Flue 和 tldraw，拒绝接受外部贡献者的 PR——部分原因是这些 PR 通常是 AI 生成的。取而代之的是，维护者更愿意使用自己的代理来创建和管理 PR。

此外，许多项目已经开始使用"软件工厂"（software factory）来管理社区贡献。通常这涉及一个代理"团队"来筛选 PR、重现问题（如果是 bug）、实现修复或新功能、审查代码，然后将代码交回给人工进行合并。

Vercel 为 AI SDK 打造的软件工厂

Vercel 最近发表了一篇题为"为 AI SDK 构建软件工厂"的文章。文章描述了这个开源 AI SDK 项目如何部署代理来控制其 PR 和 issue 积压——截至 6 月底，这些积压已超过"1000 个开放 issues 和近 800 个拉取请求"。

Vercel 的系统中有多类代理，每类代理专注于不同的任务。例如，有一个代理负责重现 bug，另一个负责应用修复，还有一个负责审查修复。 来自 Vercel 的图表；Latent Space 标注

Vercel 建立这个软件工厂的关键原因之一是它信任自己的代理来完成工作，而不是信任社区成员运行的代理。

"如果我们有一个具有特定提示的非常具体的代理，而且这个提示已经经过优化——我们知道，从历史上看，它在修复某一类 bug 方面非常成功——那么我们就会对这个特定的代理配置产生信任，"Vercel 工程师 Lars Grammel 在 一段 YouTube 视频 中解释道。

"对于开源项目，值得考虑拥有自己的代理和自己的设置，而不一定信任社区，因为这实际上可以减少你的审查时间，"他补充道。 AI SDK 项目中软件工厂工作流程示例。

Grammel 还展示了他系统的部署架构，指出"有一个 UI、一个 Web 应用、一个底层 API、一个执行空间，还有沙箱。"然后它与 GitHub 同步，自动触发其他操作。Grammel 提到的 UI 是定制的。 Vercel 的软件工厂部署架构；Lars Grammel 绘制的图表。

Vercel 声称，在这个软件工厂实施仅四周后，工厂现在"编写了我们合并的 PR 的 25% 到 35%，并关闭了 70% 到 80% 的 issues。"

Astro 的自动分类系统

拥有 62000 颗 GitHub 星标的 Astro Web 框架 也采用了其创建者 Fred Schott 所称的"软件工厂理念"。

Schott 告诉 Latent Space："五年来，我们一直处于 issue 流入速度超过我们处理能力的困境。"

但现在，通过代理处理分类工作，他们重新建立了控制权。

"在过去六个月里，情况完全改变了，"他说。"我们现在可以用这些自动化手段解决这些问题——处理分类、重现问题、让用户在我们真正查看之前验证机器人建议的修复方案。" Astro 工厂机器人的实际运行示例

结果不仅是开放 issues 的大幅减少，还有 Astro 团队处理社区请求方式的彻底改变。

"在我十多年的开源经验中，我从未见过这种情况，" Schott 说。"能够基本上把 issue 当成每周都要优先处理的事情——无论如何——而不是一个不断修剪的积压清单，这种能力真的很不一样。"

此外，Astro 的"自动分类"系统直接促使 Schott 创建了一个全新的代理框架，名为 Flue。

Flue 不接受你的 PR，但欢迎讨论

使用 Flue，Schott 尝试了一种更激进的方式来处理 PR。Flue 的贡献者指南 指出，"我们将尝试重新构想这些事情"——部分是为了防止它所称的"即抛式 AI 垃圾 PR"。

基本上，Schott 解释道，Flue 项目中的每个外部拉取请求都会被自动关闭并转换为 issue 或讨论。 Bug 报告和修复提案会变成 issues，功能请求变成讨论。 根据 Flue 的贡献者指南，代理现在可以完成大部分 PR 任务。

"如果你提交了 PR，我们没有 hard feelings，我们只是会把它重新表示为 issues 和讨论。然后从那里，试图弄清楚让人们加入的正确方式。"

这有点像是把收到的请求当作 线索，而不是当作维护者觉得自己有义务审查的工作。贡献者指南解释说，它使用团队自己的专业知识，结合"我们能访问的最好的 SOTA [最先进的] LLM"，来帮助他们决定下一步要做什么。

一旦在 issue 或讨论中做出决定，代理就会被部署进行"研究、设计、实现和初步审查"。

如果我们的代理写代码，你的外部 PR 就没有价值

与 Flue 一样，"源码可用"的 React 绘图工具 tldraw（50000 颗星标）也会自动关闭外部 PR。

项目创建者 Steve Ruiz 在 1 月份宣布了这一政策，五个月后再次强调，指出这是"一个基于我们编码方式变化（更多讨论、更多代理）、公共贡献的社交实践以及代码安全格局变化的"有主见的决定"。 [ Steve Ruiz@steveruizok absurdity in my issues rn 4:04 PM · Jun 6, 2026 · 11.2K Views 6 Replies · 1 Repost · 88 Likes](https://x.com/steveruizok/status/2063290888055398516)

HashiCorp 联合创始人和 Ghostty 创建者 Mitchell Hashimoto，现在是 Superlogical 的联合创始人，走得更远。他认为"大型开源项目将完全关闭贡献的未来。"

Ruiz 回应道，"如果一个问题已经相当明确地指定，而且代码可以由代理编写，那么让人来贡献代码就变得不那么有意义了。"

但是……社区会怎么样呢？

传统上，在开源领域，拉取请求由维护者审查，不仅是为了代码，还为了教导贡献者并评估他们作为未来维护者的资格。 如果 AI SDK 和 Astro 这样的项目使用代理来做大部分代码审查和实现，那么想要更积极参与的社区成员该何去何从？

Schott 认识到这是一个风险。

"这仍然留下了一个开放的漏洞，嗯，如果你不断缩小项目，到某个时刻，你和我去度假了——会发生什么？它并不能真正解决所有问题。"

然而，Flue 和 tldraw 都不接受 PR 但接受新的 issues 和讨论 这一事实或许指出了一个解决方案。也就是，通过更多相互交流，社区成员能更好地相互了解和信任——这是一种向同行学习的方式，也可能证明自己值得成为维护者。 tldraw issue 示例（上）被转换为 PR（下）

至于代码，如果维护者自己使用 AI 比接受外部代码贡献更容易，那么正如 tldraw 创始人 Steve Ruiz 所说，"最好把社区贡献限制在仍然重要的地方：报告、讨论、观点和关心。"