GitHub 发明了 pull request（PR），18 年来它一直默认对外开放。但现在，一些顶尖的 AI 原生开源项目正在关闭 PR，因为它们找到了更好的办法。
这些项目包括 Flue 和 tldraw，它们拒绝接受外部贡献者的 PR，部分原因是这些 PR 通常由 AI 生成。维护者更愿意用自己的智能体来创建和管理 PR。
此外，许多项目已开始用“软件工厂”来管理社区贡献。通常的做法是由一个智能体“团队”对 PR 进行分诊、复现问题（如果是 bug）、实现修复或新功能、进行审查，然后交回给人类合并。
Vercel 为 AI SDK 打造的软件工厂
Vercel 最近发表了一篇题为“Building a software factory for AI SDK”的文章。文中介绍了开源项目 AI SDK（每周 npm 下载量超过 2000 万次）如何部署智能体来掌控其 PR 和 issue 积压，到 6 月下旬，积压已达到“超过 1,000 个未解决的 issue 和近 800 个 pull request”。
Vercel 的系统中有几种类型的智能体，每种专注于不同的任务。例如，有的智能体负责复现 bug，有的负责应用修复，还有的负责审查修复。
Vercel 建立这座软件工厂的一个关键原因是，它信任自己的智能体来完成工作，胜过信任社区成员运行的智能体。
“如果我们有一个提示词非常明确、经过优化的专用智能体，而且从历史记录来看，它在修复某一类 bug 上一直很成功，那么我们就会对这种特定的智能体配置建立信任，”Vercel 工程师 Lars Grammel 在 一段 YouTube 视频中解释道。
“对于开源项目，值得考虑拥有自己的智能体和自己的配置，而不一定要信任社区，因为这实际上可以缩短你的审查时间，”他补充说。
Grammel 还展示了该系统的部署架构，并指出“有 UI，有 Web 应用，有底层 API，有执行空间，还有沙箱”。随后它与 GitHub 同步，自动触发其他操作。Grammel 提到的 UI 是定制开发的。
这座软件工厂上线仅四周，Vercel 称它现在“撰写了我们合并的 PR 中的 25% 到 35%，并且关闭了 70% 到 80% 的 issue”。
Astro 的自动分诊系统
在 GitHub 上拥有 62,000 颗星的 Astro Web 框架也采用了创始人 Fred Schott 所说的“那种软件工厂的思路”。
“五年来，我们一直处于issue 进来的速度比我们处理得更快的状态，”Schott 对 Latent Space 说。
但现在，由智能体负责分诊工作，他们重新掌控了局面。
“过去六个月发生了彻底的转变，”他说。“我们现在可以用这些自动化来解决这些 issue：处理分诊、复现问题，让用户去实际验证机器人建议的修复，而这一切发生在我们看到它之前。”
结果不只是未解决 issue 的大幅减少，而是 Astro 团队处理社区来信请求的方式发生了彻底改变。
“在我十多年的开源经历中，我从未见过这样的情况，”Schott 说。“能够把 issue 当作每周无论如何都要排定优先级的事项，而不是一个你不断修剪的积压清单。”
此外，Astro 的“自动分诊”系统直接促使 Schott 创建了一个全新的智能体框架，名为 Flue。
Flue 不接受你的 PR，但欢迎讨论
在 Flue 上，Schott 正在尝试一种更为激进的 PR 处理方式。Flue 的贡献者指南写道：“我们打算尝试重新构想一些事情”，部分目的是防止它所说的“路过式 AI 垃圾 PR”（Drive-by AI slop PRs）。
Schott 解释说，基本上，Flue 项目中的每个外部 pull request 都会被自动关闭，并转换成 issue 或讨论。bug 报告和修复建议会变成 issue，功能请求则变成讨论。
“如果你提交了 PR，请不要介意，我们只是会替你把它重新表述为 issue 和讨论。然后从那里出发，想办法找到合适的方式让大家参与进来。”
这有点像把收到的请求当作线索，而不是维护者觉得有义务审查的一份工作。贡献者指南解释说，团队会结合自身的专业经验和“我们能用到的最好的 SOTA [State-of-the-Art] LLM”，来帮助决定接下来要做什么。
一旦在 issue 或讨论中做出决定，就会部署智能体来完成“研究、设计、实现和初步审查”。
如果我们的智能体来写代码，你的外部 PR 就一文不值
与 Flue 一样，“源码可用”的 React 绘图工具 tldraw（50,000 颗星）也自动关闭外部 PR。
项目创始人 Steve Ruiz 在 1 月宣布了这项政策，五个月后又重申了一遍，指出这是“一个有明确主张的决定，是为了应对我们编码方式的变化（更多讨论、更多智能体）、公开贡献的社会惯例，以及代码安全格局的变化”。
▶ Steve Ruiz (@steveruizok): absurdity in my issues rn
HashiCorp 联合创始人、Ghostty 创建者 Mitchell Hashimoto 现在是 Superlogical 的联合创始人，他走得更远。他认为“未来是大型开源项目将完全关闭贡献通道。”
Ruiz 回应道：“如果 issue 的描述已经相当清楚，代码又可以由智能体来写，那么让人来贡献代码就越来越没有意义了。”
但是……社区会怎么样？
按传统，在开源中维护者审查 pull request，不仅是为了检查代码，也是为了指导贡献者，并评估他们能否成为未来的维护者。如果 AI SDK 和 Astro 这样的项目用自己的智能体完成大部分代码审查和实现工作，那些想更积极参与的社区成员该何去何从？
Schott 承认这是一种风险。
“这仍然留下了一个漏洞：如果你不断收窄项目的参与面，到了某个时刻，你和我都去度假了，会发生什么？它并没有真正解决所有问题。”
不过，Flue 和 tldraw 都不接受 PR，却接受新的 issue 和讨论，这也许指向了一种解决办法：社区成员通过更多地相互交流，能更好地了解并信任彼此，这既是向同行学习的途径，也可能是证明自己有资格成为维护者的方式。
至于代码，如果维护者自己使用 AI 比接受外部代码贡献更省事，那么正如 tldraw 创始人 Steve Ruiz 所说，“最好把社区贡献限制在仍然重要的地方：报告、讨论、视角和用心。”