开源开发者 Miguel Grinberg 最近把规则说得很直：想改他的开源项目，先开 issue，说明问题和拟议变更。得到认可后，再提交 pull request。

未经讨论、又看不出真人参与痕迹的 PR，会被直接关闭。

这件事有意思的地方，不是又有人反对 AI 写代码。Grinberg 一年前就写过，他不愿使用 LLM 编程工具，理由包括工作方式不合、信任成本过高等。现在的新变化是，他维护的项目收到的贡献变多，而且他判断其中几乎都由 LLM 生成。

问题因此变了：代码生成更便宜之后，审查责任是不是也被悄悄推给了维护者？

顺手 PR 为什么从惊喜变成负担

过去，陌生开发者提交 PR，通常意味着他已经花过时间。读代码、理解项目、改动、测试，再把结果交给维护者。

维护者当然也要审查。但那份代码背后，至少有一个能解释取舍的人。

LLM 改变的是成本结构。生成一个看起来完整的补丁、说明和测试建议，门槛比过去低很多。可它是否符合项目设计、是否破坏兼容性、是否只解决提交者的局部需求，仍然要由维护者判断。

这就是 Grinberg 不满的核心。他不是在讨论“AI 写的代码一律不行”，而是在拒绝一种低参与度协作：把机器产物扔进别人的项目，让维护者替你筛。

环节传统陌生 PRLLM 时代的低参与度 PR维护者多承担了什么
生成成本需要先理解项目提示词可快速生成补丁噪音变多
说明质量贡献者通常能解释取舍说明可能很长，但未必真懂要辨别“像懂”和“真懂”
审查重点看代码质量和项目适配还要判断提交者是否理解改动时间成本上升
责任归属贡献者与维护者共同承担风险容易流向维护者长期维护压力增加

这里可以借用 Cory Doctorow 的说法：reverse centaur。不是人驾驭机器，而是人被机器驱使去补位、兜底。

放到开源里，就是机器降低了提交成本，但没有同步降低维护成本。一个项目真正怕的不是 PR 少，而是无效 PR 足够多，挤掉维护者处理真实问题的时间。

issue-first 不是禁 AI，而是给维护者时间重新定价

Grinberg 的新规则很简单：先开 issue，用自己的话说明想改什么、为什么改。维护者认可后，再提交 PR。

如果只是发现问题，也可以只描述问题，让维护者处理。换句话说，他要先看见人的判断，再看见代码。

这类规则并不新。很多大型开源项目早就要求重大改动先走 proposal、RFC 或 issue 讨论。Python 的 PEP、Rust 的 RFC，都是先对齐方向，再进入实现。

差别在于，过去这类流程主要用来管理复杂协作。现在，它也成了过滤机器生成噪音的办法。

这不是整个开源社区的共识，也不该被说成“开源开始禁止 AI”。有些项目会接受 AI 辅助代码，只要测试充分、说明清楚、维护者有精力审。

限制在这里：小型项目和个人维护者没有那么多带宽。他们没有义务为每一个低成本生成的补丁做高成本复核。

这对两类人影响最直接。

对象该怎么做不这么做的结果
开源项目维护者把贡献规则写清楚：先 issue、说明动机、列出测试、未经讨论的 PR 可关闭审查队列被低质量 PR 占用
AI 辅助开发者把省下来的编码时间补到理解、复现、验证和沟通上PR 可能被视为无效劳动

对维护者来说，最现实的动作不是争论 AI 好坏，而是把门槛前置。什么改动需要先讨论，什么 PR 会被直接关闭，什么测试和说明是最低要求，都应该写在贡献指南里。

对使用 AI 的开发者来说，也要换一种思路。能生成补丁，不等于完成贡献。你至少要能解释改动边界、影响范围，以及为什么这个项目应该接受它。

开源参与感正在变窄，也变硬

开源从来不只是把代码贴上去。它包含信任、解释、长期责任，也包含维护者有限的注意力。

LLM 让更多人可以快速进入“提交代码”这一步，但没有保证他们真正进入项目语境。于是参与感出现分层：有人用工具加快理解和实现，有人只是把生成结果投递出去。

Grinberg 的做法更像一次边界声明：贡献可以来，但不能只来一段代码。人要在场。

接下来更该看的，不是“开源会不会禁用 AI”。这个问题太大，也缺少证据。更现实的变化，是项目规则会不会变硬：

  • 未经 issue 讨论的功能性 PR，直接关闭；
  • 拒绝模板化长说明，要求贡献者用自己的话解释；
  • 要求复现步骤、测试范围和兼容性说明；
  • 对明显缺少真人判断的 PR，降低审查优先级。

这对开源文化是个小拐弯。以前，一个陌生 PR 往往代表热情和投入。现在，它也可能只是一次低成本投递。

维护者开始要求先沟通，不是变得冷漠，而是在保护项目的基本秩序。代码可以由工具生成，责任不能由工具承担。