PHP 框架 Laravel 关闭 Issues：AI 正在重写开源协作规则

一、先把事实说准：它禁的不是"整个 Laravel"

2026 年 9 月初，Laravel 创始人 Taylor Otwell 在 X 上轻描淡写地说了一句话：上周我关掉了大部分 Laravel 开源包的 GitHub Issues。如果你遇到 bug，把它描述给一个编程 agent，然后开一个 PR。哪怕代码写得不怎么样也没关系——代码可以迭代。PR 至少记录了问题本身，正经的修复可以随后跟上。我怀疑很快大多数开源库都会这么运作。

然后互联网炸了。他后来补了一句："我本来没觉得这是多大的事，但互联网显然不这么想。另外，这只针对周边包，不包括 Laravel 主仓库本身。"

第一处需要纠偏的地方，就藏在这句"周边包"里。因为 Laravel 有两个都能被称为"主仓库"的地方，极易混淆：

● laravel/framework —— 框架核心源码，Composer 实际拉取的包。Issues 仍然开放，这才是 Taylor 说的"不包括主仓库"。

● laravel/laravel —— 应用骨架，laravel new 生成的那套目录结构。Issues 已经关闭。

所以如果你打开 github.com/laravel/laravel 发现 Issues 标签没了，那不是错觉。两个仓库的命运并不相同。

再往下查第一方包，会发现"全部关闭"同样不准确（以下为 2026 年 9 月实测）：

Horizon 作为最主力的队列监控包却留着 Issues，说明这不是一刀切的政策，而是逐个仓库判断的结果。官方措辞用的是"大多数"（most）而非"全部"，这个词是准确的。

第二处纠偏：官方贡献指南的措辞不是"禁止"，而是"强烈鼓励"。Laravel 13.x 的 Contribution Guide 现在这样写：

为了鼓励积极协作，Laravel 强烈鼓励通过 pull request 来解决问题，而不是提交 GitHub issue。我们大多数第一方软件包都禁用了 GitHub issue。如果你发现了问题，请创建一个解决该问题的 pull request……如果你不知道如何修复，请把问题描述给一个编程 agent，并利用它来尝试提交 pull request。

注意最后这句——官方文档里明文写着"不会修就让 AI 帮你修"，这在一份主流框架的贡献指南里是相当罕见的措辞。它标志着一件事：AI 编程助手已经被一线开源项目正式写进了贡献流程，不是作为可选项，而是作为默认路径。

第三处纠偏：支持类问题并没有无处可去。官方明确列了 GitHub Discussions、Laracasts 论坛、Laravel.io、StackOverflow、Discord 等渠道。安全漏洞走 security@laravel.com。被关掉的只是"我遇到个 bug，你们看着办"这一种交互形态。

二、为什么这个看似荒谬的规定其实站得住脚

第一反应确实是荒谬的：用户连报告问题的权利都没有了？但拆开看，四条逻辑都成立。

第一，它过滤掉了垃圾 issue。 提交 issue 的成本几乎为零，这在 LLM 时代成了一个致命缺陷。批量生成的"疑似 bug"报告、机器人刷的低质量条目、复制粘贴报错栈就走人的伸手党，正在以指数速度淹没维护者。而创建一个 PR，哪怕借助 AI，也需要 fork、改代码、跑通测试、写清楚描述——这道门槛不高，但足以把"顺手抛个问题"和"我真的在意这个问题"区分开。这是一次典型的成本再分配：把成本从维护者一侧挪回提交者一侧。

第二，PR 携带的信息密度远高于 issue。 一个 issue 告诉你"某某场景下报错了"，维护者要复现、定位、判断影响面，可能花掉半天。一个 PR 直接告诉你：问题出在这个文件的这一行，我这样改了，附带一个能复现的测试用例。即使这个修复方案是错的，它也把问题钉在了具体代码位置上——这比一段自然语言描述有价值得多。Taylor 那句"哪怕代码写得不怎么样也没关系，PR 至少记录了问题本身"，说的就是这个意思：PR 是一种更高保真度的问题描述格式。

第三，在 AI 时代，提交门槛并没有真的提高。 这是整件事成立的前提。放在五年前，要求用户提交 PR 等于把 95% 的报告者拒之门外。但现在，一个不懂 Laravel 队列内部实现的用户，完全可以把报错和复现步骤丢给编程 agent，让它读源码、定位、生成补丁。提交 PR 和提交 issue 之间的能力鸿沟，被 AI 大幅填平了。规则的变化，本质上是对工具能力变化的追认。

第四，也是根本原因：开源项目的维护资源从来就不够。 维护者数量是线性的（甚至在萎缩），而 AI 让问题的产出速度变成了指数的。这个剪刀差无解。过去的开源默契是"用户抛出问题，社区里总有热心人会解决"，这套机制建立在提问和解答的速率大致匹配的前提上。这个前提已经失效了。于是 Laravel 选择改写默契：不要把问题抛给别人，带着解决方案的草稿来。

三、但代价是真实的，不该被轻轻放过

任何一次成本转移都有人承担损失，这件事也不例外。

首先是"能发现问题但无法表达为代码"的那批用户。 现实中大量有价值的 bug 报告来自运维、来自生产事故、来自某个特定 PHP 版本 + 特定扩展的组合。报告者可能连本地复现环境都搭不起来，更别说提 PR。这类信息如果找不到入口，就会彻底消失。Laravel 用 Discussions 接住了一部分，但 Discussions 的可检索性、去重机制、状态流转都远不如 Issues——它更像一个论坛，而不是一个问题追踪器。

其次是公共知识的流失。 Issues 长期承担着一个被低估的功能：搜索引擎入口。无数人是靠搜到一条三年前的 issue 才解决了自己的问题，哪怕那条 issue 最后是 closed as stale。关掉 Issues，等于关掉了这个沉淀层。PR 当然也能被搜到，但只有"已经被修复"的问题才会留下 PR，那些悬而未决、只有 workaround 的问题会无处存身。

第三是 AI 政策的内在张力，这一点最有意思。Laravel 一边在贡献指南里说"不会修就交给 coding agent 去开 PR"，一边在同一份文档的"AI 生成的贡献"章节里写着：

主要依赖 AI 生成、未经深思熟虑的人工审查的实质性贡献是不被接受的……PR 描述必须完全由贡献者撰写，带有 AI 生成描述的 PR 将被关闭。大量创建完全由 AI 生成的 issue 或 PR 绝不容忍，此类 PR 将被关闭且不予审查，贡献者可能被封禁。

这两条怎么共存？我的理解是，Laravel 划了一条线：AI 可以是你的工具，不能是你的代笔。 允许用 AI 定位问题、生成补丁草稿，因为那是在帮你把问题表达清楚；不允许用 AI 批量刷 PR、代写描述，因为那是把审查成本又甩回了维护者。区分标准不是"用没用 AI"，而是"有没有人真正为这次提交负责"。

但这条线在执行层面极其模糊。维护者怎么判断一个 PR 描述是不是 AI 写的？怎么区分"认真用 AI 修好的"和"随手让 AI 生成的"？最终大概率还是靠人工感觉和事后封禁。换句话说，Laravel 把一部分垃圾流量挡在了门外，同时也给自己留下了一个更难界定的新问题。

四、其他项目正在走向反面

值得注意的是，PHP 生态里并非所有项目都认同这个方向。据 Laravel News 报道，有些 PHP 项目的选择恰好相反：只允许提 issue，然后由维护者自己的 AI 或开发者来写修复。

这其实是同一个困境的两种解法：

两条路都在试图用 AI 重新平衡"报告"与"修复"之间的落差，只是把 AI 塞在了管道的不同位置。Laravel 的做法把算力和时间成本分散到了成千上万的用户手里，代价是牺牲了一部分表达能力弱的报告者；反向路线保住了低门槛，但瓶颈仍在维护者身上，只是从"读 issue"变成了"读 issue + 指挥 AI 修"。

哪一种更优，现在下结论为时过早。Taylor 自己的态度很松弛："如果这个改动不奏效，那又怎样？把 Issues 重新打开就是了。"这句话可能比规则本身更值得学：这是一次可回滚的实验，不是一份宪法。

五、对其他项目和团队的启示

抛开 Laravel 本身，这件事里有几条可以迁移的经验。

其一，重新审视你的"入口成本"设计。 在 AI 把内容生产成本压到接近零之后，任何"提交成本低于处理成本"的通道都会被淹没。不只是开源 issue——客服工单、内部需求池、代码评审请求，都面临同一个问题。解法未必是关闭入口，但一定要引入某种形式的提交者成本，哪怕只是"必须附带复现步骤和你尝试过的方案"。

其二，把"带着方案来"变成团队默认文化。 公司内部同样适用：与其提"这个接口好慢"，不如提"这个接口好慢，我用 AI 看了下疑似是 N+1，这是我改的 patch，你们看对不对"。后者哪怕方向是错的，讨论的起点也高出一大截。AI 让"先做个草稿"的成本降到了可以随手做的程度，这个红利应该被制度化。

其三，别把 AI 当免责声明。 Laravel 那条"PR 描述必须完全由贡献者撰写"值得所有团队抄走。用 AI 生成内容没问题，但提交动作意味着署名，署名意味着你已经读过、理解过、验证过。分不清这一点的人，在任何组织里都会很快耗光信用。

其四，保留一个兜底通道。 Laravel 没有真的把门焊死：Discussions、论坛、Discord、安全邮箱都还在。任何强约束的规则都需要一个溢出口，否则被挡住的不只是垃圾，还有那些你真正需要知道的坏消息。

六、结语

"禁止提交 issue，只能提交 PR"这句话之所以刺耳，是因为它挑战了开源世界一条流传二十年的隐性契约：用户负责发现问题，社区负责解决问题。 Laravel 的动作等于公开宣布这份契约到期了——不是因为维护者变懒了，而是因为提问的速度已经彻底甩开了回答的速度。

在 AI 大幅拉平"发现问题"与"尝试修复"之间落差的今天，继续维持旧契约，只会让维护者先一步崩溃。Laravel 选择了一个不那么优雅、但足够诚实的方案：既然修一个 bug 的边际成本已经降到了描述一个 bug 的量级，那就请你顺手把它修了。

这个方案会不会成为行业标准，取决于接下来几个月那些 AI 辅助生成的 PR 质量如何。如果它们大多是能用的，Taylor 的预言会成真；如果它们只是把垃圾 issue 换了个更费维护者时间的马甲，Issues 开关随时可以拨回去。

无论结果如何，有一点已经清楚了：开源协作的规则正在被 AI 重写，而重写的方向不是"让用户更省事"，而是"让每个人都往前多走一步"。