AI 编码正在杀死开源：当 10 个 PR 中 9 个是浪费维护者时间的垃圾

2026 年 1-2 月，开源世界发生了一场静默的地震。

四个看似独立的事件在六周内接连发生，每一个都是标志性项目对 AI 编码浪潮的防御性反应：

cURL——关闭运营 6 年的 bug bounty。 2026 年 1 月 26 日，cURL 创始人 Daniel Stenberg 宣布永久关闭 bug bounty 计划。该项目累计确认了 87 个安全漏洞，支付了超过 10 万美元奖励。压垮骆驼的最后一根稻草：AI 生成的低质量漏洞报告占据了压倒性多数，维护者审查这些报告的时间成本远超 bounty 本身的价值。

Ghostty——零容忍 AI 代码政策。 Ghostty 终端模拟器创始人 Mitchell Hashimoto（HashiCorp 联合创始人）宣布对未经请求的 AI 生成贡献采取零容忍政策。他的表态直截了当：「这不是反 AI 立场，这是反白痴立场。」随后他推出了 Vouch 信任系统——贡献者必须被现有社区成员「担保」才能提交代码。截至 2026 年 6 月，约 150 个仓库采用了 VOUCHED.td 文件。

tldraw——自动关闭所有外部 PR。 2026 年 1 月，协作白板项目 tldraw 宣布自动关闭所有来自外部贡献者的 Pull Request。维护者 Steve Ruiz 在博客中写道：「一个开放的 PR 代表着维护者的承诺——它会被仔细审查并认真考虑纳入。但我们现在无法兑现这个承诺。」

GitHub——上线 PR 控制工具。 2026 年 2 月，GitHub 产品经理 Camilla Moraes 在社区讨论中宣布正在开发 PR 数量限制功能，允许维护者设置外部贡献者同时可开启的 PR 上限。GitHub 开源总监 Ashley Wolf 表示：「AI 让生成贡献变得更容易，我们要给维护者更多选择来控制接收和审查工作的方式。」

这四个事件不是孤立的。 它们是同一个结构性问题的四种不同症状：当 AI 让提交代码的边际成本趋近于零时，审查代码的成本仍然完全由人类维护者承担。这个成本不对称正在摧毁开源协作的基本均衡。

「AI 代码质量差」不是维护者的偏见，而是有严格数据支撑的事实。

2026 年初，多项独立研究从不同角度量化了 AI 生成代码的问题。当这些数据汇聚在一起，呈现出一幅令人不安的图景：

CodeRabbit 的 470 PR 分析。 AI 代码审查平台 CodeRabbit 对 470 个开源 PR 进行了对比分析，发现 AI 生成的代码每个 PR 产生的问题是纯人工代码的 1.7 倍，其中关键和重大问题（包括业务逻辑错误和有缺陷的控制流）约为 1.4-1.7 倍。

GitClear 的 1.53 亿行代码分析。 代码变更追踪平台 GitClear 分析了 1.53 亿行代码变更后发现，AI 生成代码的流失率（churn rate）比人工代码高 41%——即代码在提交后两周内被回退或大幅修改的比例。高流失率意味着代码在首次提交时就没有达到可接受的质量标准。

METR 的随机对照试验。 这是一个令人尴尬的发现。METR 对经验丰富的开源开发者进行了随机对照试验（RCT），结果发现：使用 AI 工具的开发者完成任务的时间反而多了 19%。更讽刺的是，这些开发者预期 AI 会让他们快 24%，事后也相信 AI 确实让他们快了 20%——感知和现实之间存在 39 个百分点的差距。

Voiceflow 基础设施负责人 Xavier Portilla Edo的经验总结：「每 10 个 AI 生成的 PR 中，只有 1 个是合法的。其他 9 个在浪费维护者的时间。」

Stack Overflow 的社区衰退。 PNAS Nexus 的研究显示，ChatGPT 上线后 6 个月内，Stack Overflow 的用户活跃度下降了 25%，每周帖子从 60,000 降至 30,000。这种衰退影响了所有经验水平的用户——不仅新手在减少，老手也在离开。

这些数据共同指向一个结论：AI 编码工具降低了「生产代码」的成本，但大幅提高了「验证代码」的成本。 在开源场景中，验证成本完全由无报酬的维护者承担，而生产收益则归 AI 工具的用户独享。这是一个典型的负外部性问题。

要理解这场危机的深层原因，需要用经济学框架来分析。

开源软件本质上是一种「公共品」（public good）——非排他性（任何人都可以使用）和非竞争性（一个人使用不影响他人使用）。开源的可持续性依赖于一种隐性的社会契约：用户从项目中获益，作为回报，一部分用户以贡献代码、报告 bug、撰写文档等方式回馈社区。

AI 编码工具打破了这种契约的均衡。

在传统的开源贡献模式中，提交一个 PR 需要：理解问题 → 阅读代码库 → 编写修复 → 测试 → 提交。这个过程本身就是对贡献者的「筛选」——只有真正理解问题且愿意投入时间的人才会提交。维护者审查 PR 时，可以合理预期贡献者具备一定的上下文理解。

AI 编码工具将这个流程压缩为：粘贴 issue → 生成 patch → 提交。整个过程可以在一分钟内完成。贡献者可能完全不理解代码库，也不打算参与后续迭代。正如 tldraw 维护者观察到的：「虽然这些 PR 在形式上可能是正确的，但大多数存在不完整或误导性的上下文、对代码库的误解，以及作者几乎没有后续参与。」

这就是经济学中的「公地悲剧」（Tragedy of the Commons）。

每个 AI 用户理性地最大化自己的利益（用 AI 快速提交 PR 来练习技能或建立贡献记录），但这些行为的总和却摧毁了公共资源（维护者的审查精力和社区的代码质量）。当维护者被迫关闭贡献通道来保护自己时，所有人都变得更差——包括那些真正想做出有价值贡献的人。

匈牙利经济学家 Miklós Koren 等人在论文 「Vibe Coding Kills Open Source」（arXiv:2601.15494）中建立了形式化模型。 核心结论是：当 AI 编码（vibe coding）降低了使用和改进现有代码的成本时，它同时削弱了维护者通过用户参与获得回报的渠道。在仅通过直接用户参与来变现 OSS 的条件下，vibe coding 的更大采用会降低贡献者的进入和分享意愿，降低 OSS 的可用性和质量，尽管生产力提高了，但总体福利反而下降。

论文的关键洞察是：AI 编码不仅是一个技术问题，更是一个激励结构问题。 当 AI 用户不需要与维护者深度互动就能获得代码时，维护者失去了通过用户参与建立声誉、获得反馈和改进项目的机会。这种「用户参与的侵蚀」比代码质量本身更危险。

cURL 的故事是这场危机最完整的缩影。

cURL 可能是世界上最重要的开源项目之一——据估计，它运行在超过 100 亿个设备上，从手机到汽车到太空飞船。创始人 Daniel Stenberg 在 2020 年启动了 bug bounty 计划，通过 HackerOne 平台向发现安全漏洞的研究者支付奖励。

六年间，cURL 的 bug bounty 取得了显著成果： 87 个已确认的安全漏洞，累计支付超过 10 万美元。这些数字证明了一个成功的 bounty 计划可以如何有效地发现和维护软件安全。

但到了 2025-2026 年，情况急剧恶化。 AI 生成的漏洞报告如潮水般涌来。Stenberg 在告别博文中描述了一个典型的场景：某一周内收到 7 份提交，其中一些确实发现了 bug，但没有一个描述了真正的安全漏洞。这些报告消耗了大量维护者时间，却没有产生可操作的发现。

Stenberg 的回应既愤怒又无奈：「我认为，曝光、讨论和嘲笑那些浪费我们时间的人，是传递信息的有效方式之一：你永远不应该在不理解 bug 的情况下报告 bug——你应该能够复现它。」

Socket.dev 的分析揭示了更深层的问题：「低努力、AI 生成的报告数量已经明确地将成本从『为真实发现付费』转向『为维护者审查噪声的时间付费』，对于一个像 cURL 这样的 FOSS 项目来说，这是不公平的。」

2026 年 1 月 31 日，cURL 正式关闭了 bug bounty 计划，删除了所有对 HackerOne 的引用，更新了安全文档和治理文件。Stenberg 同时宣布，cURL 在 2026 年 7 月将完全不接受安全报告——给维护者一个喘息的空间。

cURL 的案例表明：AI 不仅降低了生成代码的成本，也降低了生成（虚假）安全报告的成本。 当 bounty 的经济激励遇上 AI 的批量生成能力，理性经济人会选择用最低成本提交最多报告——即使质量极低。这种激励错配最终摧毁了一个运行六年的成功项目。

面对危机，开源社区正在探索多种应对策略。这些策略从简单的防御措施到根本性的协作模式重构，各有利弊。

策略一：关闭贡献通道（cURL / tldraw 模式）

最直接的反应是完全关闭或严格限制外部贡献。tldraw 自动关闭所有外部 PR，只保留 issue 和讨论通道。cURL 关闭了 bug bounty，并在特定月份暂停接受安全报告。

这种策略的优点是立竿见影地减少维护者负担；缺点是误伤真正有价值的贡献者，并可能使项目逐渐与社区脱节。

策略二：信任验证系统（Ghostty / Vouch 模式）

Mitchell Hashimoto 推出的 Vouch 系统代表了一种更精细的方案。它不是简单地拒绝所有外部贡献，而是要求贡献者被现有社区成员「担保」。这种「信任网络」模式将审查负担从维护者分散到整个社区。

截至 2026 年 6 月，Ghostty 已有 250+ 受担保的贡献者，约 150 个仓库采用了 VOUCHED.td 文件。这个模式正在从 Ghostty 的私人解决方案演变为一种行业标准。

策略三：平台级控制（GitHub 模式）

GitHub 在 2026 年 2 月开始开发 PR 数量限制功能，允许维护者设置外部贡献者可同时开启的 PR 上限。GitHub 开源总监 Ashley Wolf 将此描述为「给维护者一个节流阀，而不是一个开关」。

这种平台级方案的优势是标准化——维护者不需要自己开发工具；劣势是可能过于粗放，无法区分高质量和低质量贡献。

策略四：AI 约束工具（Ponytail 模式——讽刺的另一面）

2026 年 6 月，一个名为 Ponytail 的开源项目在 9 天内获得了 44,190 GitHub stars。它的核心理念是让你的 AI 编码代理「像房间里最懒的高级开发者一样思考」——只写任务真正需要的代码，减少 54% 的代码量。

Ponytail 的流行是一个讽刺的注脚：AI 编码产生了太多不必要的代码，而最受欢迎的「解决方案」是另一个 AI 工具来限制 AI 生成的代码量。这暗示了一个更深层的问题——也许 AI 编码的根本问题不在于代码质量，而在于代码数量本身。

策略五：学术建模（Koren 等人的形式化分析）

Miklós Koren 等人在论文 「Vibe Coding Kills Open Source」 中建立了包含内生进入和异质项目质量的均衡模型。模型显示，当 OSS 仅通过直接用户参与变现时，vibe coding 的更大采用会降低均衡状态下的 OSS entry 和分享，降低可用性和质量，并在生产力提高的同时降低总体福利。

论文的结论暗示了一种可能的政策干预：需要新的机制来让 OSS 维护者从 AI 编码的广泛使用中获取价值——比如强制性的 AI 训练数据许可费、代码使用费、或平台级别的维护者补偿基金。

如果我们跳出开源的具体场景，这场危机揭示的是一个更普遍的技术经济学问题。

经济学家鲍莫尔（William Baumol）在 1960 年代提出了「鲍莫尔成本病」（Baumol's cost disease）：在制造业等可自动化部门生产力快速提升的同时，劳动密集型服务部门（如教育、医疗、艺术表演）的生产力提升缓慢，导致后者的相对成本持续上升。

AI 编码正在软件领域制造类似的不对称。

代码生成正在经历自己的「摩尔定律」——AI 工具每隔几个月就能生成更多、更复杂的代码。但代码审查——理解上下文、验证逻辑、检查边界条件、评估架构影响——仍然是一个高度依赖人类认知能力的劳动密集型活动。

这种不对称的后果是：

• 代码生产的边际成本趋近于零（AI 生成一个 PR 的成本几乎为零）
• 代码审查的边际成本保持不变甚至上升（每个 PR 仍需 30-60 分钟的人类审查时间）
• 净效应是审查瓶颈越来越严重

在传统软件工程中，代码审查是质量保障的关键环节。但当代码生产的速度远超审查的速度时，我们面临两个选择：要么降低审查标准（接受更多低质量代码），要么限制代码生产（关闭贡献通道）。开源社区目前明显倾向于后者。

这个困境没有简单的技术解决方案。 AI 辅助审查（如 CodeRabbit、GitHub Copilot 的代码审查功能）可以在一定程度上提高审查效率，但无法根本解决「谁来验证 AI 生成的代码是否正确」的问题——这最终仍需要人类的理解和判断。

从更宏观的角度看，这场危机可能是 AI 对知识工作「鲍莫尔成本病」的一个预警案例。 当 AI 让内容生产变得廉价时（无论是代码、文章还是数据分析），验证和理解这些内容的成本并没有同步下降。社会需要新的分工模式来应对这种不对称——在开源场景中，这可能意味着维护者需要从「代码审查者」转型为「架构决策者」，或者需要新的经济模型来补偿维护者的审查劳动。

如果你是开源项目的用户或潜在贡献者，这场危机对你意味着什么？以下是基于当前形势的实操建议。

1. 理解「贡献」的重新定义

在 AI 编码时代，「提交代码」不再等同于「做出贡献」。维护者越来越看重的是：

• 对问题的深度理解——能够清晰描述问题、复现步骤和预期行为
• 对项目架构的理解——PR 是否符合项目的整体设计哲学
• 持续的社区参与——是否有长期的贡献记录和社区信任
• 审查和测试能力——帮助审查其他人的 PR 比提交自己的 PR 更有价值

2. 避免成为「AI 噪声」的一部分

如果你使用 AI 工具辅助编码：

• 永远不要提交你不理解的代码。 如果你无法向维护者解释每一行代码为什么存在，这个 PR 就不应该被提交
• 在提交前手动审查和测试。 AI 生成的代码必须经过与手写代码相同（甚至更严格）的审查标准
• 在 PR 描述中说明 AI 的使用情况。 透明度有助于建立信任
• 从小贡献开始建立信任。 不要一上来就提交大规模重构——先通过 bug 修复、文档改进等小贡献证明你的理解

3. 考虑「非代码贡献」的价值

在维护者被 AI PR 淹没的环境中，以下贡献形式的价值相对上升：

• 高质量的 bug 报告——带有完整复现步骤、最小复现示例和明确预期行为
• 文档改进——好的文档可以减少大量重复性的用户问题
• 社区支持——回答讨论区的问题、帮助新用户
• 代码审查——帮助审查其他贡献者的 PR

4. 如果你使用 Vouch 类系统

• 主动请求担保。 如果你想在采用 Vouch 的项目中贡献，先通过社区互动建立关系，然后请求担保
• 成为担保人。 如果你已经是受信任的贡献者，积极为新成员担保——这有助于扩大社区的信任网络

5. 关注项目贡献政策的变更

越来越多的项目会调整贡献政策来应对 AI 编码的挑战。在提交 PR 之前：

• 检查项目的 CONTRIBUTING.md 是否有更新
• 注意是否有新的贡献门槛或审查要求
• 尊重维护者设定的任何限制

这场危机最终会走向哪里？我们预测三种可能的演进方向。

方向一：「信任基础设施」的标准化

Vouch 系统可能演变为开源生态的标准组件。想象一个场景：每个贡献者维护一个可验证的贡献档案（包括 AI 辅助和纯手工的贡献记录），项目通过智能合约或自动化系统根据贡献者的信任等级自动调整审查流程。

这种方向的优势是将审查资源集中在最需要的地方——新贡献者和低信任度贡献者的 PR 接受更严格的审查，而高信任度贡献者享有更快的合并路径。

方向二：AI 辅助审查的规模化

CodeRabbit 等 AI 代码审查工具可能成为开源项目的标准配置。但这里有一个根本性的问题：「谁来验证 AI 审查者的判断？」如果 AI 审查者错误地批准了一个有缺陷的 PR，或者错误地拒绝了一个正确的 PR，最终仍需要人类介入。

更可能的演进是 AI 辅助审查作为第一层过滤——自动拒绝明显不合格的 PR，将人类审查者的精力集中在需要判断力的灰色地带。

方向三：经济模型的重构

Koren 等人的论文暗示，开源的根本问题在于激励结构。当 AI 公司从开源代码中获取巨大价值（用于训练模型、构建商业产品）时，维护者却没有获得相应的补偿。

可能的经济模型包括：

• AI 训练数据许可费： AI 公司使用开源代码训练模型时向维护者支付费用
• 平台级维护者基金： GitHub 等平台从 AI 编码功能的收入中拨出一定比例分配给活跃维护者
• 代码使用费： 当 AI 生成的代码包含特定开源项目的模式或逻辑时，自动向原项目支付微量费用

本站判断： 最终均衡很可能是上述三个方向的组合。短期内（2026-2027），「信任基础设施」会快速发展并成为事实标准；中期（2027-2028），AI 辅助审查会成熟到可以处理大部分灰色地带；长期来看，经济模型的重构是不可避免的——否则开源的「公地悲剧」将持续恶化。

但有一点是确定的：开源不会消亡，但「贡献」的含义正在被根本性地重新定义。 在 AI 编码时代，最有价值的贡献不是代码本身，而是对问题的理解、对架构的判断和对社区的信任建设。这些仍然是 AI 无法替代的人类能力。