Ladybird 拒绝 AI 生成的 Pull Request：开源信任体系的崩塌与重建

起因：一条震动开源圈的声明

2026 年 6 月，Ladybird 浏览器创始人 Andreas Kling 宣布了一项重大决定：该项目将不再接受公开的 Pull Request。理由直指当下开源社区最敏感的神经——AI 生成代码正在摧毁传统贡献体系里的信任基石。他观察到，“一个大型补丁过去意味着大量努力，而这种努力是善意的合理代理。现在这个假设不再成立。” 随着 Claude、ChatGPT 等工具能轻易生成看起来专业、结构完整的代码，维护者越来越难分辨哪些补丁背后站着真正理解改动、愿意长期负责的开发者。

拆解：信任信号失效，责任归属真空

开源协作长期依赖一种不成文的信任模型：你提交的代码越多、越复杂，就越可能被社区接受，因为这暗示你投入了时间、理解了项目并愿意维护。但 AI 让这一切变得廉价——一个新手可以让代理生成一个数千行的重构补丁，一眼看去规范漂亮，但实际上他对代码逻辑一无所知，也无法承诺后续缺陷修复。Kling 的结论很尖锐：“代码是否手写是次要的，真正重要的是谁为代码进入浏览器之后负责。” 对于一个即将服务于真实用户的浏览器来说，任何一个隐藏错误都可能造成灾难，传统的“善意信任”已不足以支撑项目安全。

趋势洞察：开源社区的“AI 污染”危机与治理重构

Ladybird 的激进做法折射出一个更大的趋势：AI 正在倒逼开源项目重新思考贡献模型。过去“开放贡献”是开源运动的核心信条，但 AI 让低质量、无责任 patch 泛滥，维护成本陡增。未来可预见几种演化路径：一是像 Ladybird 那样完全收回外部贡献权，转向核心团队集中开发；二是引入“贡献者署名+维护承诺”协议，要求提交者承担后续义务；三是借助技术手段，如引入 AI 生成代码标注、强化自动化测试和代码审查流程。但无论如何，纯粹基于信任的非正式协作正在被更正式的、契约化的治理取代。

实用价值：开发者、维护者与企业的应对

作为开发者，如果参与开源，现在更需要确保自己理解每一行提交的代码，并能解释设计决策——仅靠 AI 生成然后粘贴将不被接受。作为维护者，可以明确制定项目的 AI 使用政策，甚至像 Ladybird 那样重新设计贡献流程。企业用户在选择开源依赖时，也需要开始评估该项目的“AI 韧性”：它的维护者是否意识到这些问题？是否有足够的防护机制防止低质代码渗入？

反常识：AI 非但没有加速开源，反而威胁其开放性

通常人们认为 AI 能让开源贡献更容易、更高效，但 Ladybird 的例子揭示了丑陋的另一面：当贡献成本低到无需理解和承诺时，信任崩塌反而让项目变得封闭。这是一个值得所有开源参与者深思的悖论——AI 工具越强大，开源治理可能越需要“围墙”。

原文地址: Quoting Andreas Kling