不欢迎PR：顶尖AI开源项目如何管理成千上万名贡献者
Vercel的AI SDK、Astro、Flue和tldraw正用软件工厂取代社区随手提交的PR，由成组的智能体完成修复和功能开发。
图中文字译文（译者补充）：智能体时代的开源——我们不要你的代码。外部PR关闭后进入议题／讨论；智能体依次进行分诊、复现、修复、审查；由人类合并。
GitHub发明了拉取请求（pull request，PR），18年来，这项功能一直默认向外部开放。但如今，一些顶尖的AI原生开源项目正在关闭PR入口，因为它们找到了更好的办法。
这些项目包括Flue和tldraw，它们拒绝接受外部贡献者的PR，部分原因在于这些PR通常由AI生成。维护者更愿意用自己的智能体（agent） 创建和管理PR。
此外，许多项目开始使用“软件工厂（software factory）”管理社区贡献。通常，这意味着由一支智能体“团队”对PR进行分诊（triage），复现问题（如果它是一个bug），实施修复或开发新功能，审查结果，然后交还给人类合并。
Vercel为AI SDK打造的软件工厂
Vercel最近发表了一篇题为“为AI SDK打造软件工厂”的文章。文章介绍了开源AI SDK项目如何部署智能体，以控制积压的PR和议题（issue）。这个项目每周在npm上的下载量超过2000万次；截至6月下旬，积压规模已达到“超过1000个尚未关闭的议题和接近800个拉取请求”。
Vercel的系统中有多种智能体，每一种都专注于不同任务。例如，一个智能体复现bug，另一个实施修复，还有一个审查修复。
图由Vercel提供；批注由Latent Space添加。
图中文字译文（译者补充）：批注：由一个大语言模型（LLM）分类；每个智能体都在沙盒中运行；智能体完成全部工作；始终由人类合并。bug流程为复现、创建修复、审查修复；功能流程为分析、实施、审查；文档流程为实施文档修改。
Vercel建立这座软件工厂的一个关键原因，是它信任自己的智能体来完成工作，而且这种信任超过了对社区成员运行的智能体的信任。
“如果我们有一个非常特定的智能体，配备了一个经过我们优化的、非常特定的提示词，而且从以往的情况中知道，它在修复某一类bug时非常成功，那么我们就会对这个特定的智能体配置建立起信任，”Vercel工程师Lars Grammel在一段YouTube视频中解释道。
“对于开源项目，值得考虑拥有自己的智能体和自己的配置，不一定要信任社区，因为这确实可以减少你审查所花的时间，”他补充道。
AI SDK项目中的软件工厂工作流示例。
图中文字译文（译者补充）：批注：社区成员创建的是议题，而非PR；全部这些工作都由智能体完成；智能体创建PR；人类负责将其投入生产。示例功能请求：支持在网页搜索中屏蔽域名。
Grammel还展示了这个系统的部署架构，指出“有一个用户界面（UI），有一个Web应用，有底层应用程序接口（API），有执行空间，还有沙盒（sandbox）”。随后，系统与GitHub同步，由GitHub自动触发其他操作。Grammel提到的UI是定制开发的。
Vercel的软件工厂部署架构；图由Lars Grammel绘制。
图中文字译文（译者补充）：组件包括工厂UI、SvelteKit服务器、工厂API、任务执行队列、任务工作进程、日志、智能体工作区、工厂数据，以及用于GitHub同步的Webhook入口、GitHub Webhook队列和GitHub同步工作进程。
这座软件工厂实施仅四周后，Vercel便声称，工厂如今“编写了我们合并的PR中的25%至35%，并关闭了70%至80%的议题”。
Astro的自动分诊系统
在GitHub上拥有6.2万颗星的Astro Web框架，也采用了其创始人Fred Schott所称的“那个软件工厂思路”。
“五年来，我们一直处于这样的境地：议题涌入的速度比我们处理的速度更快，”Schott对Latent Space说。
但如今，随着智能体接手分诊工作，他们重新掌握了局面。
“过去六个月里，情况完全变了，”他说。“我们现在可以借助这些自动化来解决议题——处理分诊、复现，甚至在我们查看之前，就让用户实际验证机器人提出的修复方案。”
Astro工厂机器人运行示例。
图中文字译文（译者补充）：批注：Astro的工厂机器人对新提交的社区议题进行分诊；机器人建议的下一步操作；优先级被定为轻微。截图中的议题涉及带有.astro frontmatter时Vite依赖扫描偶发失败。机器人报告已完成分诊，因缺少最小可复现示例而跳过复现，将状态设为triage: needs reproduction。
结果不仅是尚未关闭的议题大幅减少，Astro团队处理新提交的社区请求的方式也彻底改变了。
“在我十多年参与开源的经历里，我从来没见过这种情况，” Schott说。“基本上，你能够把议题视为每周都要安排优先级的事情——无论如何都要处理——而不再把它们当成你得不断削减的积压事项。”
此外，Astro的“自动分诊”系统直接促使Schott创建了一个全新的智能体框架，名为Flue。
Flue不接受你的PR，但欢迎讨论
在Flue上，Schott正在尝试一种更激进的PR处理方式。Flue的贡献者指南写道：“我们打算尝试重新构想这件事”，部分目的是防止指南所说的 “随手扔过来的AI垃圾PR（Drive-by AI slop PRs）”。
Schott解释说，基本做法是：Flue项目中的每一个外部拉取请求都会自动关闭，并转成议题或讨论。bug报告和修复提案会转成议题，功能请求会转成讨论。
根据Flue的贡献者指南，智能体如今能够完成大多数PR任务。
图中文字译文（译者补充）：批注：Flue中人类维护者的角色。图中原文的译文：“在一个AI智能体能够在我们睡觉时编写和审查代码的世界里，这一点比以往更重要。新的瓶颈（至少目前如此）是：1. 决定接下来做什么；2. 决定如何实现。至于其他一切（设计、研究、实现、审查），我们发现，如今的智能体已经足够胜任，可以独立负责，或在维护者的协助和指导下推进。”
“如果你提交一个PR，别介意，我们会把它转成议题和讨论，替你把内容呈现出来。然后从那里出发，尝试找到吸纳大家参与的合适方式。”
这有点像是把新提交的请求当成线索，而不是一项让维护者觉得有义务审查的工作。贡献者指南解释说，团队将自身的专业知识与 “我们能用到的、目前最先进的（State-of-the-Art，SOTA）大语言模型（LLM）” 相结合，帮助他们决定下一步做什么。
一旦议题或讨论中做出了决定，就会部署智能体，进行“研究、设计、实现和初步审查”。
如果我们的智能体来写代码，你的外部PR就毫无价值
与Flue一样，“源码可用（source available）”的React绘图工具tldraw（5万颗星）也会自动关闭外部PR。
项目创始人Steve Ruiz在1月宣布了这项政策，五个月后又重申了一次。他指出，这是“一个体现了明确立场的决定，回应的是我们编码方式的变化（更多讨论、更多智能体）、围绕公开贡献的社会实践，以及代码安全格局的变化”。
我现在这些议题里发生的事可真荒唐。
2026年6月6日
图中文字译者摘译：Steve Ruiz推文所附截图：“为通过/issue skill创建的议题添加slop标签”。截图说明，这个skill会根据简短描述创建GitHub议题，再扩展成完整的bug报告或功能请求；这些由智能体编写的议题无法与人工撰写的议题区分，维护者无法据此筛选或分别分诊。提议的解决办法是为该skill创建的所有议题添加slop标签。
HashiCorp联合创始人、Ghostty创始人Mitchell Hashimoto，如今也是Superlogical的联合创始人，则更进一步。他认为，“未来，大型开源项目会彻底关闭外部贡献”。
Ruiz回应道：“如果议题描述得已经足够清楚，而代码又可以由智能体编写，那么让别人贡献代码就更没什么道理了。”
但是……社区会怎么样？
传统开源项目中，维护者审查拉取请求，不仅是为了审查代码，也为了指导贡献者，并评估他们能否成为未来的维护者。如果AI SDK和Astro这样的项目，用自己的智能体完成大量代码审查和实现工作，那么想要更积极参与的社区成员该何去何从？
Schott承认这是一个风险。
“这仍然留下了一个缺口：如果你一直把项目收窄，到了某个时候，你和我都去度假了——会怎么样？它并不能真正解决所有问题。”
不过，Flue和tldraw虽然都不接受PR，却接受新议题和讨论，这一事实或许指向了一种解决办法。也就是通过更多地交谈，社区成员能够更好地了解彼此、信任彼此；这既是向同行学习的方式，也可能是证明自己够格成为维护者的方式。
tldraw议题（上图）被转成PR（下图）的示例。
图中文字译文（译者补充）：上图批注：社区贡献者添加新议题，报告高亮文字在深色模式下显示描边。下图批注：使用Codex帮助将议题转成拉取请求；主要维护者将议题转成PR。修复标题为“修复（编辑器）：移除深色模式下高亮文字的描边”。
至于代码，如果维护者自己使用AI，比接受外部代码贡献更容易，那么正如tldraw创始人Steve Ruiz所说：“最好把社区贡献限制在它仍然重要的那些地方：报告问题、讨论、视角，以及关心。”
此文章由AI翻译。