Laravel 关闭多数官方包 Issues：拥抱 AI，开源协作正在重新定义

最近，Taylor Otwell 做了一个颇具争议的决定：关闭绝大多数 Laravel 官方生态包的 GitHub Issues（核心框架 laravel/framework 暂时保留）。

按照 Taylor 的说法，现在的开发者遇到 Bug，完全可以先丢给 Coding Agent 试着修，修完直接提 PR。哪怕 AI 给出的代码不够完美也没关系，至少这个 PR 本身就是一个带完整上下文的问题记录，维护者可以在此基础上继续调整，或者给出一个更优雅的实现。

从“报告问题”变成“尝试解决问题”

长久以来，开源社区最消耗维护者心力的，往往不是修 Bug，而是理 Issue。

很多 Issue 往往只有一句模糊的“用不了”或者一张报错截图，没有版本号、没有复现步骤、没有最小 Demo。维护者只能兼职当客服，反复追问上下文，折腾半天最后发现要么是使用者姿势不对，要么根本无法复现。

Issues 的反馈门槛确实极低，但代价是把所有的排查成本全推给了维护者。

Coding Agent 正在打破这个旧秩序。现在一个开发者哪怕完全没看过某个库的源码，也可以让 AI 先通读代码、定位报错位置、补齐复现测试，甚至掏出一个像模像样的初版补丁。

Taylor 的这一刀，本质上是重塑了协作规则：别只告诉我哪里坏了，请带着问题，以及一个跑得起来、可以继续讨论的方案过来。

我的感想

我认为这是一项值得尝试的调整。GitHub Issues 和 Pull Requests 只是过去逐渐形成的协作方式，并不是不能改变的固定规则。既然 coding agent 已经可以阅读代码、执行测试并生成修改，我们没有必要坚持所有问题都必须按照过去的流程处理。

拥抱 AI，也不应该只是让 AI 帮我们更快地写代码。更重要的是，我们可以借此重新思考整个开发流程：过去哪些工作必须由人完成，哪些工作现在可以交给 AI，以及人的精力应该放在哪里。

当然，关闭 Issues 也会带来新的问题。不是所有使用者都熟悉 Git、测试和 Pull Request。即使有 AI 帮助，提交 PR 的门槛仍然高于创建 Issue。另一方面，如果大量未经验证的 AI 代码直接涌入仓库，维护者的工作可能只是从“整理低质量 Issue”变成“审核低质量 PR”。

所以，拥抱 AI 并不意味着降低质量标准，更不意味着把 AI 生成的内容复制粘贴后便交给维护者。

提交者仍然应该确认：

• 问题确实存在，并且可以复现；
• 修改针对的是问题本身，而不只是绕过错误；
• 测试能够覆盖失败场景和修复结果；
• 没有引入明显的兼容性或安全问题；
• PR 清楚说明了问题、原因和验证方式。

AI 可以完成大量准备工作，但提交者仍然需要对最终结果负责。

代码越来越便宜，判断越来越重要

过去参与知名开源项目，门槛极高。你得吃透作者的设计架构、熟悉项目规范，还要亲手写出一套漂亮的实现。

到了今天，生成一段像模像样的代码成了成本最低的事情。但代码越容易写，开发者的核心价值越不在“输入代码”上，而在“判断与把控”上：

• 你能不能把真实场景与上下文交代清楚？
• AI 给出的修改方案，是在解决根因，还是在掩耳盗铃？
• 这套改动符不符合项目原本的设计哲学？

未来的优秀贡献者，未必是亲手输入最多代码的人，而可能是最擅长发现问题、提供上下文、指导 AI 并验证结果的人。

本作品采用《CC 协议》，转载必须注明作者和本文链接