AI 时代,开源项目要重新定义贡献

当 AI 能批量生成补丁，开源项目真正稀缺的就不再是代码，而是责任。

Ladybird 浏览器项目宣布：不再接受公开 Pull Request。

这句话很容易被理解成“开源倒退”。但如果放在 AI Coding Agent 正在普及的背景下，它其实指向一个更大的变化：代码提交的成本被 AI 降低后，维护责任没有同步降低。

过去，一个复杂补丁往往意味着贡献者投入了大量时间。投入本身不是质量保证，但至少是善意和理解深度的信号。

现在不一样了。

一个人可以用 AI 在很短时间里生成大量看似完整的补丁。维护者面对的不只是代码数量增加，而是信号系统失效：补丁看起来像努力，实际上可能只是一次低成本生成。

1. 开源项目害怕的不是 AI 代码，而是无人负责的代码

Andreas Kling 的核心判断很清楚：代码是不是手写的并不重要，重要的是谁在合并它，谁维护它，谁为后果负责。

这句话比“禁用 AI”更准确。

AI 生成代码本身不是原罪。问题是当补丁进入真实产品之后，它就会变成用户要承受的系统行为。

浏览器尤其如此。安全、兼容性、性能、隐私、可访问性，任何一个小改动都可能带来长期后果。

如果提交者只是把 AI 生成结果扔给维护者审，真正承担风险的人就变成了项目核心团队。

这不是协作，而是风险转移。

开源协作依赖信号。

一个贡献者愿意读文档、复现问题、解释设计、响应 review、持续维护，这些行为共同构成可信度。

AI 改变的是其中一个关键环节：产出代码的难度下降。

于是维护者更难通过“补丁规模”和“实现完整度”判断贡献质量。一个大型 PR 可能代表深度理解，也可能只是模型把上下文猜了一遍。

这会让 review 成本急剧上升。

维护者需要检查的不只是代码是否能跑，还要判断：

当 review 成本高于贡献价值，项目自然会收紧入口。

这件事不只属于 Ladybird。

未来更多开源项目会把贡献流程从“谁都可以提交 PR”，转向更明确的责任制度。

可能出现几种变化：

换句话说，开源项目会变得更像一个产品组织：入口、权限、责任、质量门槛都要被设计。

如果你用 AI 参与开源，最重要的不是多提交，而是证明你理解问题。

一个更健康的方式是：

AI 可以帮你更快完成这些工作，但不能替你承担这些责任。

开源项目最终需要的不是“看起来能跑的代码”，而是“有人愿意为它负责的代码”。

AI Coding Agent 如果想真正进入严肃工程场景，也不能只优化生成速度。

它们需要帮助开发者做责任链：

未来优秀的 AI Coding 工具，不会只是“写得更快”，而是“让人更容易审、敢合并、能追责”。

AI 让代码变便宜，但让信任变贵。

开源项目的下一轮治理，不是讨论要不要 AI，而是重新定义：什么才算一个负责任的贡献。