Ladybird 项目创始人 Andreas Kling 在一篇题为《Changing How We Develop Ladybird》的文章中表示，Ladybird 将不再接受 public pull requests。Simon Willison 引述了这段表态，其中最关键的一句是：代码是否手写不是重点，重点是谁对进入浏览器的代码负责。

这不是一个开源项目“关门”的简单故事。现有材料没有显示 Ladybird 关闭源码、停止外部参与，或转向商业化。更准确的判断是：当生成式 AI 降低了提交大段代码的成本，维护者开始收紧代码入口，把协作重点从“谁提交了补丁”转向“谁承担后果”。

Ladybird 收紧公开 PR，直接理由是责任边界变模糊

Kling 的原话说得很直白：过去，一个 substantial patch 往往意味着 substantial effort，而这种努力可以作为善意的合理代理；现在，这个假设不再成立。

浏览器项目尤其敏感。Ladybird 正在成为面向真实用户的浏览器，代码不只是跑过测试就结束。渲染、网络、安全、兼容性、性能退化，都可能影响真实用户。Kling 强调，向项目引入变更的人，必须是那些判断这些变更属于项目、并愿意为后果负责的人。

这次变化可以拆成几个层面看：

项目过去的隐含假设AI 之后的问题对 Ladybird 的判断
大补丁通常代表长期投入可能只是低成本生成与拼接不能再自动视为善意证明
公开 PR是外部贡献入口审查成本转嫁给维护者入口被收紧
代码质量主要看实现是否可用还要看责任是否可追溯责任人比生成方式更关键
用户影响多在开发阶段消化浏览器走向真实用户后风险上升治理必须更保守

这里真正重要的不是“AI 写代码能不能用”。很多项目已经在用 GitHub Copilot、Cursor、Claude Code 等工具辅助开发。问题在于，代码生成速度提高后，维护者审查、理解、长期维护的速度并没有同比提高。

AI 让“贡献痕迹”不再等于“贡献承诺”

开源协作长期依赖一种低成本信任：一个人愿意花时间读代码、修 bug、写测试、回应 review，通常说明他至少认真对待这个项目。大补丁曾经带有劳动痕迹，也带有声誉押注。

生成式 AI 改变了这层信号。一个看起来很完整的补丁，可能并不对应相同程度的理解。维护者面对的不只是代码本身，还有隐藏成本：解释设计选择、追查边界条件、重写不合适实现、在后续版本里背锅。

这和 Linux 内核、PostgreSQL、Chromium 等成熟项目的协作方式形成对照。它们并不只看“补丁能不能合并”，还依赖维护者树、模块负责人、提交记录和长期参与形成的信任链。Ladybird 这次选择更像是把这条信任链前置，而不是把所有陌生补丁先收进队列再筛。

原文没有提供更多政策细节，比如外部开发者未来通过何种渠道参与、是否存在邀请制、是否保留 issue 讨论或其他贡献路径。因此不能把它写成“Ladybird 不再开放”。目前能确认的是，public pull requests 这个入口被关上了。

外部贡献者更难进门，维护者少背一点隐性债

受影响最直接的是外部贡献者。过去，开发者可以通过公开 PR 展示能力，哪怕没有项目内身份，也有机会让代码进入主线。入口收紧后，新贡献者要获得信任，可能需要更长时间：先参与讨论、复现问题、提交小范围修复，或通过项目认可的内部流程进入开发。

维护者会少一些“审陌生大补丁”的负担，但也会付出代价。公开 PR 是开源项目发现人才、吸收边缘创新的一条通道。关掉入口后，项目治理更可控，外部活水也可能变少。对一个浏览器项目来说，这不是小事，因为浏览器的复杂度几乎逼迫项目长期依赖多人协作。

真实用户则是这个决定背后的沉默变量。Ladybird 如果只是实验性玩具，开放入口可以更宽；一旦目标是日常可用的浏览器，维护者必须把“能合并”改成“敢负责”。这也是 Kling 表态中最有分量的地方：他没有把问题归咎于 AI，而是把责任重新放回人身上。

接下来最该观察的，不是 Ladybird 是否“反 AI”，而是它会建立怎样的替代协作机制：外部贡献者如何被吸纳，维护者如何证明决策透明，项目又如何避免在安全可控和社区活力之间失衡。开源不是没有门槛，真正的问题是门槛由谁制定、谁解释、谁承担代价。