Laravel 关掉周边包 Issues：把 bug 描述给编程 agent，然后提 PR

相关仓库：

• laravel/framework —— 框架核心源码，Composer 实际拉取的包
• laravel/laravel —— 应用骨架，laravel new 生成的那套目录结构

Taylor Otwell 的表态

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 标签没了，不是错觉。两个仓库的命运并不相同。

Issues 状态

已关闭：laravel（骨架）、telescope、sanctum、scout、socialite、pint、prompts、reverb、sail、breeze、folio、pennant、docs

仍开放：framework（核心）、horizon、jetstream、passport、cashier-stripe、nova-issues

贡献指南的措辞

官方 Contribution Guide 用的词不是"禁止"，而是"强烈鼓励"。Laravel 13.x 的文档现在这样写：

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

主流框架的贡献指南里直接写"不会修就让 AI 帮你修"，措辞相当少见。它标志着一件事：AI 编程助手已经被写进贡献流程，不是作为可选项，而是作为默认路径。

AI 贡献的约束

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

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

另一种模式：只收 issue

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

兜底通道

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

"不会修就让 AI 帮你修"这句话之所以刺耳，是因为它挑战了开源世界一条流传二十年的隐性契约：用户提问、维护者回答。Laravel 的动作等于公开宣布这条契约到期——不是因为维护者不响应，而是因为 AI 回答问题的速度已经甩开了人工。