我们正在失去开放贡献
吊桥正在升起
我参与开源贡献已经二十年了。在此期间，贡献的门槛一直在降低，直到现在。
Ghostty 将更新其 AI 政策。AI 辅助的 PR 现在仅允许用于已接受的问题。盲目的 AI PR 将被直接关闭，恕不解释。不良的 AI 使用者将被禁止参与未来的一切贡献。如果你打算使用 AI，最好表现得专业点。 https://#/AJRX79S8XD
— Mitchell Hashimoto (@mitchellh) 2026年1月22日
昨天，Mitchell Hashimoto 宣布 Ghostty 将禁止未经说明的 AI 贡献。AI 辅助的 PR 现在仅允许用于已接受的问题。盲目的 AI PR 将被直接关闭，恕不解释。不良的 AI 使用者将被禁止参与未来的一切贡献。tldraw 已经完全自动关闭外部 PR。未来会有更多项目跟进。
我理解为什么要这样做。我很遗憾我们走到了这一步。我也感到沮丧，因为事情本不必如此。
我们是如何走到这一步的？
开源维护已经崩溃了。在 AI 闸门打开之前，它就已经处于困境之中了。
Mitchell Hashimoto 上周发推文称：“这里简直是个该死的战区，伙计。维护者的士气处于历史最低点。”他另一条推文写道：“如果你拿出一份今天的 PR 列表，在没有任何背景的情况下给我看，我会觉得这些人是不是都有某种学习障碍。但这实际上是对学习障碍者的侮辱，因为他们实际上很完美，而这些 PR 是由极度懒散的人提交的。90% 的 AI 编码 PR 看上去就是这么愚蠢。”
来自 tldraw 的 Steve Ruiz 宣布他们正在自动关闭来自外部贡献者的 PR。我的同事 Brian Douglas 写了《死于千次 AI 合并请求》，讨论了我们已经到达的临界点。
这不是未来的问题，它现在正在发生。
近二十年来（从 1999 年的 SourceForge 到 2008 年 GitHub 成立），我们一直在告诉开发者：参与开源贡献以充实你的简历。让你的 GitHub 贡献图全变绿。让自己被注意到。找到一份工作。提交 PR 的门槛通常足够高，能够自动筛选出那些愿意付出额外努力的人。
糟糕的贡献并非什么新鲜事。Hacktoberfest 的垃圾邮件臭名昭著，以至于 Drew DeVault 将 2020 年的活动称为对维护者的“企业赞助的分布式拒绝服务攻击”。人们为了领取一件免费 T 恤，在 README 文件里加分号、修复空格、提交随机的“Hello World”脚本。那种垃圾邮件显而易见，你可以在几秒钟内识别并关闭它。
今天充斥项目的 AI 生成 PR 并非如此。它们看起来很完美。测试通过。代码甚至可能运行正常。问题在于没有人真正参与，没有后续跟进，没有真正的理解。
我认为这些人中的大多数是出于好意，只是不知道更好的做法。他们没有背景或经验来判断什么是优秀的，或者可能只是觉得一次盲目的 PR 就足够了。但无论是无知还是懒惰，影响都是一样的。这对维护者来说依然是个大问题。现在的门槛低到人们似乎根本不过脑子。
问题不在于代码生成
AI 编程工具最初的卖点很简单：写代码太慢，AI 让它变快。但写代码从来不是最难的部分。最难的是其他一切：理解代码库，了解决策背后的原因，跟进审查意见，以及真正维护你发布的东西。
在 Continue，我们谈论的是“增强型开发者”（Amplified Developer）。AI 应该让你在整个工作流程中都更有效率，而不仅仅是在打字部分。但我们在开源领域看到的是，人们把 AI 当成了一台魔法代码打印机。找到一个标记为“good first issue”的问题，粘贴到 Claude 里，生成一个 PR，然后在出现审查意见时就消失了。
优秀的样子是什么样的
Mitchell 还分享了一个有趣的反例，展示了 AI 如何助力扩展开源贡献。有人为 Ghostty 提交了一个 Bug 报告，他不了解这个技术栈，但他是“优秀的 AI 驱动者”。他使用 AI 编写了一个 Python 脚本来解码崩溃文件，分析代码库以寻找根本原因，并将其提取为 Claude 的技能。
然后他来到 Discord，警告团队他不了解 Zig、macOS 开发或终端，并且他使用了 AI。但他对这些问题进行了批判性思考，并确信它们是真实存在的。他询问团队是否接受。Mitchell 看了一个后印象深刻，说全部发送过来。这修复了 4 个真实的崩溃案例。
Mitchell 说：“他们没有只是把垃圾抛到我们的仓库里。他们作为一个人来到 Discord，作为一个人进行了沟通，并与其他人类讨论了他们的所作所为。他们对这个过程非常谨慎和深思熟虑。”
2026 年优秀的样子是什么样的？我相信它是透明的、专业的 AI 驱动，并且愿意处理项目的“人性”一面。你需要与人沟通，接受反馈并进行迭代。很久以前，我与 Doug Cutting 共事过，他发起了许多具有影响力的开源项目，并曾担任 Apache 基金会董事会主席。Doug 这样谈论开源的力量：“你构建东西不仅仅是为了自己，因为如果你这样做，它走不远，”他说。“你试图构建的是社区，是持久的东西。”
这就是我们面临失去访问权限风险的东西。
我们真正需要的是什么
Mitchell 还发推文谈到了可能的解决方案：“我们真正需要的未来是能够更好地支持将 diff 中的每一行映射回完整且公开的历史记录，包括提示词。来自 Amp 和 Opencode 的线程共享有助于实现这一点，但我需要一个等同于 git blame 的功能。会话揭示了真正的专业知识还是垃圾。”
这是北极星。不仅仅是在提交信息中写着“我使用了 AI”，而是行级的归因。每一次变更都映射回其完整的上下文：提示词、推理过程、迭代逻辑。一个不仅显示谁写了代码，还显示代码是如何产生的 git blame。无论是深思熟虑创作的，还是草率生成的。
要在大规模范围内实现这一点，我们需要 Git 或 jj 支持原生元数据。我们需要 GitHub 和 GitLab 有意义地展示这些元数据。我们需要 LLM 提供商签署其输出。也许我们需要通过类似 YubiKey 的硬件认证来证明来源。这不是一个小工程。
但即使只有原生 Git 支持也不够。正如 Mitchell 在关于 git notes 的讨论中所指出的，提交元数据“可以被篡改。我真的希望智能体本身能够通过签名或其他机制证明提示词未被篡改。简单来说：一个网页链接就有效，我可以信任提供商。”
这就是真正的挑战：来自 AI 提供商的加密认证。一个已签署、不可伪造的记录，声明“是的，这段代码来自这些提示词，是我们生成的。”没有这些，任何提交级的透明度系统都只是“表演”——或许是有用的表演，但最终无法强制执行。
但正是这样的未来，才能使开源在 AI 世界中具有可持续性。维护者可以一眼看出一个 PR 代表的是深度理解还是肤浅的垃圾。优秀的 AI 使用将受到称赞，糟糕的 AI 使用将显而易见。
考虑到复杂性、行业目前对生成的关注，以及众多的大型企业利益相关者，我担心我们还要等上一阵子。
该死，Leeroy
鉴于此——并且知道距离真正的解决方案还有几年时间，我想做一些 1% 的改进。所以我构建了 Leeroy。主要是为了让他能和 Ralph 以及 Gas Town 市长待在一起。
我们还没有 Mitchell 所预见的愿景。天哪，我们甚至还没接近它。但你可以利用今天的工具做到以下几点。
Leeroy 只是一个关于提交中透明 AI 归因可以是什么样子的演示。当你使用 Claude Code 时，Leeroy 会自动记录你使用的工具、模型、给出的提示词以及修改的文件。
Add log function to calculator with tests
---
AI-Assisted: true
AI-Tool: claude-code/2.1.12
AI-Model: claude-opus-4-5-20251101
AI-Prompts:
- [22:53:57] Lets add log to the calculator.
- [22:54:58] Lets commit the change.
透明度。“是的，我使用 AI 工具做了这个。这是我的推理。这些是我的提示词。”
Steve Ruiz 写道，这抓住了为什么这很重要：“当代码很难写，而低质量的工作很容易识别时，审查优秀的内容是值得的。如果代码很容易写，而糟糕的作品与优秀的作品几乎无法区分，那么外部贡献的价值可能小于零。”
如果没有某种方法来区分深思熟虑的 AI 使用和垃圾，维护者将别无选择。他们会升起吊桥。GitHub Actions 将被用来自动关闭 PR。我们将发现自己处于一个项目只接受已知开发者贡献的世界。我不想要那样的未来。
Leeroy 不是我们所需要的。它只是在维护者被迫关闭大门时，让做正确的事变得稍微容易一些。目前，它是自我报告的透明度。你可以撒谎。没有强制执行。*这是一个演示，不是解决方案。*
但我们不必等到拥有完整的愿景才开始透明。低技术含量的方法今天就能行得通。在你的 PR 和提交信息中保持诚实即可。Leeroy 使透明度自动化。你不必记得记录你的 AI 使用情况或手动格式化归因。它会自动发生。我们不能完全靠工具摆脱困境，但我们可以让人们更容易地做正确的事。当做正确的事变得自动化时，会有更多人去做。
走点心吧
使用 AI。保持透明。增强自己。构建你以前无法构建的东西。但要深思熟虑。投入精力去理解你正在贡献的内容。展示你的推理过程。跟进审查意见。
因为如果我们不这样做，更多的项目会追随 Mitchell 和 tldraw。到时候我们所有人的处境都会更糟。
不要只是尖叫着你自己的 GitHub 用户名冲进去。
也许试试 Leeroy：github.com/metcalfc/leeroy-jenkins
开源维护者可以关闭大门，但企业不能。如果你的团队正淹没在需要审查的 PR 积压中，你不能只是自动关闭它们——你需要处理它们。这就是我们构建 Mission Control 的原因。它使用智能体来处理审查意见、修复失败的 CI、解决合并冲突，并在你合并之前提高质量标准。它旨在清除你的 PR 积压并保持高交付速度，同时不牺牲标准。当你无法停止发布时，Mission Control 帮助你在大规模环境中保持质量。