夜雨聆风当 AI 能批量生成补丁，开源项目真正稀缺的就不再是代码，而是责任。
Ladybird 浏览器项目宣布：不再接受公开 Pull Request。
这句话很容易被理解成“开源倒退”。但如果放在 AI Coding Agent 正在普及的背景下，它其实指向一个更大的变化：代码提交的成本被 AI 降低后，维护责任没有同步降低。
过去，一个复杂补丁往往意味着贡献者投入了大量时间。投入本身不是质量保证，但至少是善意和理解深度的信号。
现在不一样了。
一个人可以用 AI 在很短时间里生成大量看似完整的补丁。维护者面对的不只是代码数量增加，而是信号系统失效：补丁看起来像努力，实际上可能只是一次低成本生成。
1. 开源项目害怕的不是 AI 代码，而是无人负责的代码
Andreas Kling 的核心判断很清楚：代码是不是手写的并不重要，重要的是谁在合并它，谁维护它，谁为后果负责。
这句话比“禁用 AI”更准确。
AI 生成代码本身不是原罪。问题是当补丁进入真实产品之后，它就会变成用户要承受的系统行为。
浏览器尤其如此。安全、兼容性、性能、隐私、可访问性，任何一个小改动都可能带来长期后果。
如果提交者只是把 AI 生成结果扔给维护者审，真正承担风险的人就变成了项目核心团队。
这不是协作，而是风险转移。
2. PR 曾经是一种信号，现在信号变弱了
开源协作依赖信号。
一个贡献者愿意读文档、复现问题、解释设计、响应 review、持续维护，这些行为共同构成可信度。
AI 改变的是其中一个关键环节：产出代码的难度下降。
于是维护者更难通过“补丁规模”和“实现完整度”判断贡献质量。一个大型 PR 可能代表深度理解，也可能只是模型把上下文猜了一遍。
这会让 review 成本急剧上升。
维护者需要检查的不只是代码是否能跑，还要判断：
设计意图是否成立； 边界条件是否被理解； 后续 bug 由谁处理； 贡献者是否真的知道自己改了什么； 项目是否愿意为这段代码背书。
当 review 成本高于贡献价值，项目自然会收紧入口。
3. AI Coding Agent 会迫使开源治理产品化
这件事不只属于 Ladybird。
未来更多开源项目会把贡献流程从“谁都可以提交 PR”，转向更明确的责任制度。
可能出现几种变化：
更强的贡献者分层：新人先从 issue、测试、文档、复现开始，而不是直接提交核心代码。 更严格的 provenance：说明代码如何产生、由谁审阅、是否使用 AI、测试覆盖在哪里。 更小的变更单元：拒绝大而全的生成式补丁，鼓励可审计的小改动。 更重的维护承诺：合并不只看补丁，还看贡献者是否愿意长期响应。
换句话说，开源项目会变得更像一个产品组织：入口、权限、责任、质量门槛都要被设计。
4. 对开发者的启发：别把 AI 当作“刷 PR 工具”
如果你用 AI 参与开源，最重要的不是多提交，而是证明你理解问题。
一个更健康的方式是：
先复现 bug； 写清楚失败场景； 提供最小修复； 解释为什么这样改； 主动补测试； review 后持续跟进。
AI 可以帮你更快完成这些工作，但不能替你承担这些责任。
开源项目最终需要的不是“看起来能跑的代码”，而是“有人愿意为它负责的代码”。
5. 对 AI Coding 工具的启发：产出代码只是第一层
AI Coding Agent 如果想真正进入严肃工程场景，也不能只优化生成速度。
它们需要帮助开发者做责任链：
自动生成变更解释； 标注不确定边界； 关联测试证据； 提醒潜在副作用； 记录生成过程； 支持小步提交和可回滚。
未来优秀的 AI Coding 工具，不会只是“写得更快”，而是“让人更容易审、敢合并、能追责”。
结尾
AI 让代码变便宜，但让信任变贵。
开源项目的下一轮治理，不是讨论要不要 AI，而是重新定义：什么才算一个负责任的贡献。
参考资料
Simon Willison 引述 Andreas Kling：Changing How We Develop Ladybird