开源维护者的困境
本文永久链接 – https://tonybai.com/2026/06/04/the-maintainers-dilemma
大家好，我是Tony Bai。
开源软件的繁荣建立在一种隐形的“社会契约”之上：贡献者贡献智慧，维护者投入精力审核。然而，当维护者面对成百上千个待处理的拉取请求（PR）而精疲力竭时，这个契约正滑向崩塌。
AI 的介入似乎提供了一线生机，但也带来了一个灵魂拷问：如果代码是 AI 写的，审核也是 AI 做的，那么“受保护的分支”究竟是在保护什么？开源社区赖以生存的“人与人的连接”是否会随之消失？前Go 语言核心团队成员、gohugo和Cobra 创始人 Steve Francia 近期撰写了一篇文章，深度剖析了这一“维护者的困境”。
本文便是这篇文章的中译文。
受保护的分支（protected branch）需要第二个人在代码发布前进行审核。这条规则的存在是因为人类会犯错，而第二双眼睛可以捕捉到第一双眼睛遗漏的东西。但如果其中一个审核者是机器人呢？如果两个都是呢？
目前，我可以要求 AI 在我的仓库里发起一个拉取请求（PR），然后由我自己合并它。或者我可以自己写代码，让 AI 来审核。在这两种情况下，分支在技术上都是“受保护的”。但这种保护现在究竟意味着什么？
这些问题值得思考。但它们往往占据了太多的注意力，而一个更迫切的问题却无人问津：现在，在我的各个仓库中，都有来自那些花时间理解代码库、编写测试并提交简洁补丁的人们的未处理拉取请求。我还没审核它们。遗憾的是，讽刺的是，我没审核是因为我深深地在乎。我知道花时间在一个项目上发起 PR 是多么大的事，对于那些我作为志愿者维护的项目更是如此。对于每一个拥有受资助维护者的开源项目，都有数以百万计的未付报酬的人类正盯着日益增长的待办事项，思考着这个周末是该花在处理问题上，还是直接合上电脑出门去。
AI 工具现在可以进行可靠的代码审查、编写补丁和分拣问题。问题不再是它们是否足够好到有用。真正的问题在于，“有用”在何处变成了“负担”，以及过度依赖我们无法轻易重建的东西——维护者与贡献者之间、通过经验积累的判断力，以及围绕这种交流形成的社区——是否会造成破坏。
118 个待处理的拉取请求
我上周查看了 GitHub 通知，然后直接关闭了标签页。Cobra 有 243 个未解决的问题（issues）和 118 个待处理的拉取请求（PR）。Afero 有 114 个问题和 55 个 PR。这两个项目都是我创建的。
尽管我没有及时行动，但这些都是活跃维护的项目。Cobra 支持着 kubectl、GitHub CLI、hugo 以及成千上万的其他工具。当你输入 kubectl get pods 或 gh pr list 时，Cobra 正在解析你的命令。Afero 存在于 Hugo 内部，也存在于 Cobra 自身，以及数以百计的其他项目中。对 Cobra 的一次草率合并可能会破坏 Kubernetes 的工具链。对 Afero 的一次错误审核可能会开启一个静默传播到下游所有环节的文件系统漏洞。
我创建 Cobra 是因为我需要为 Hugo 提供特定的 CLI 用户体验，而当时没有现成的库可以支持。我将它拆分为一个独立项目，想着其他人可能会觉得有用。我从未想过十年后我还在维护它，也没想到这两个项目会成为这么多人的关键基础设施。我只是想做些有用的东西，也许能交几个朋友。但开源意味着我有义务无限期地维护它吗？随着我发布的每个新项目，维护旧项目的时间就越来越少。有些 PR 已经等了三年了。在 Afero 的 BasePathFs 中有一个已报告的安全漏洞，自从 2025 年 6 月起就挂在那里——直到写这篇文章之前，我都还没意识到它在那里，因为积压工作太惊人了。
维护的数学逻辑行不通。这是一个众所周知的开源问题（相关 XKCD 漫画）。贡献的数量增长速度远超维护者的数量，且随着项目的复杂性和影响力的增加，审查每个 PR 所需的时间也在增长。有些项目能吸引志愿者维护者，但这又带来了新问题：没有人对全局负责，每个人都只挑选对自己重要的事情，剩下的就随它去。Cobra 故意设计得节奏缓慢——有太多的项目依赖它，不能草率合并任何内容——因此每次更改都需要更彻底的审查，而不是更少。我的许多其他项目则掉进了既被维护又被遗弃的灰色地带。我会将其描述为针对最关键路径优化的维护，但这种区别对八个月前提交了修复方案且从未得到回音的人来说，意义并不大。
这不仅仅是我的问题。GitHub 托管着超过 4.2 亿个仓库。我有幸成为 Secure Open Source Fund 首批资助对象的一员——这是一项真正产生了影响的投资。但即使在经过几个周期的扩展后，它也只覆盖了约 200 个项目。OpenSSF 每周扫描数百万个关键项目。Tidelift 向维护者支付报酬。把这些加起来，你也只覆盖了成千上万个项目。这虽然很有意义，但与实际的表面积相比只是杯水车薪。
百分之九十六的代码库包含开源组件，而它们赖以生存的基础是由盯着永远清不空的待办事项的人类维持的，他们思考着是否这就是他们最终耗尽精力或干脆停止查看的周末。随之而来的还有维护者的愧疚感——明知道人们指望着你的工作，而你却没有能力帮忙，但又无法撒手不管。
进入机器人时代
我一直在几个仓库里尝试 AI 工具——比如在 fileflow 上的 Jules 和在 pathologize 上的 AI 尝试，这些仓库依赖较少，有更多尝试空间。我也一直在 Afero 上运行 GitHub Copilot，它有更多依赖，但其模块化架构允许我扩展新后端而不触及其他项目依赖的关键路径。
我去了一次邮轮旅行。当我在海上时，Jules 还在继续工作，每天都会发起新的 PR，因为我还没来得及合并第一个。等我回到家时，这两个项目已经有了超过 120 个 PR。我抽出一个早晨来审核它们，却发现它们其实代表了大约五个不同的更改集，每个更改集都在几周内每天提交一次。PR 本身并没有错，Jules 确实发现了真实的问题。但没有一个 PR 是完全正确的；在合并之前，每个都需要修正。在 Jules 提供的指导下，我做了调整，总体方向显示出前景。但实验目前带来的维护工作量是增加了，而不是减少了：我必须核实这 120 个 PR 中每一个是否真的是重复的，然后才能关闭。本意是减少积压工作的工具，反而增加了积压。
Jules 发起的这些 PR 署名是我，而不是 Jules——这引发了关于归属和责任的问题。从仓库的角度看，我是这些更改的作者。但我一行代码都没写。如果其中一个补丁引入了 Bug 或漏洞，提交历史记录指向的是我。大多数贡献者政策在编写时并未考虑到这种情况，标准的 CLA（贡献者许可协议）也不区分人类编写的代码和人类指导 AI 编写的代码。
目前看来，Jules 似乎没有关于其之前工作的记忆，也没有检查未处理 PR 的能力。它扫描仓库，发现问题，发起 PR，然后停止。如果你不合并，Jules 下次扫描时会发现同样的问题并再次发起 PR。它没法知道你已经意识到了问题但还没合并，原因可能是：你不同意这个修复，或者修复优先级较低，或者你正在船上度假且两周内没法上网。这种语境对工具来说是不可见的。Jules 发现了一个真实的漏洞——文件操作中的 TOCTOU（检查时间到使用时间）漏洞——它是对的，它指出了这一点……指出了 12 次。
对于机械性的工作——标记问题、更新依赖、起草样板回复——这些工具确实非常有用。但 Jules 和 Copilot 无法告诉我，这 55 个 Afero 的 PR 中，是否有一个根本不属于这个项目。这种判断需要了解代码库的过去和未来，而不仅仅是它的现状。
这些工具只能基于可见的事物工作：代码、未解决的问题、PR 历史。维护者的约束条件是那些没人写下来的东西：内部辩论如何塑造了 API。人类判断力最无可替代、AI 最盲目的鸿沟，就在这两者之间。
曾和我一起在 Go 团队工作的 Russ Cox 在最近的一次关于 AI 贡献的讨论中说得很好：“人们吹嘘代码库有成百上千行，是由 AI 在创纪录的时间内完成并提交的。仔细观察会发现，这些代码库往往更像是跳舞的大象，而不是有用的工程产物。”
他是对的。但我一直在思考代码之外的事情。编写新软件和维护现有软件是有区别的。更新依赖并不是跳舞的大象。分拣一个陈旧的问题并不是创造性行为。告诉一个贡献者“谢谢，但我们不接受对这个 API 的更改”只是在维持运营。而现在，对于数百万个项目来说，灯已经熄灭了。
这还不是最大的挑战。大多数人没意识到的是，评估和合并更改比编写新代码要难得多。理解一个更改如何融入现有的代码库、它的历史以及它的计划，需要一部分隐形的知识——这些知识存在于创意工作中，需要某种目前没有模型能复制的判断力。
“受保护”到底保护了什么
Go 项目对我来说真的很美——那是运行了 15 年、极其细致的评审、设计讨论和精炼的评审文化。那是理想状态。但 Go 是个例外，大多数项目无法企及：由 Google 资助的全职贡献者，一项旨在持续 50 年且不受外部截止日期压力的任务。
Go 团队最近有一个长长的讨论，关于是否接受 AI 生成的贡献——Russ Cox 的名言也源自那个讨论。这些人我共事多年——同样的评审、同样的方案、在同样的白板前争论。阅读那个论坛线程，我能听到他们的声音。我能看到他们每个人是如何坚持自己认为正确的事情，以及为什么。
Rob Pike 第一个发言且毫不含糊。这是一条非常危险的道路。在你的第一步上要小心。我建议简单地说“不”。那是 Rob。直接、原则性强，且通常是正确的。然后 Alan Donovan 指出了不舒服的现实：“我怀疑我们今天收到的一大部分 CL（更改列表）已经包含了 LLM 生成的代码，无论作者是否承认。马已经跑出马厩了。”
Russ Cox 写下了我见过的最深思熟虑的回应。他的核心观点是：“我们能做的最重要的事情是维持我们平时的代码评审和代码质量标准……当代码的部分或全部是在 AI 工具的帮助下编写时，同样的标准必须适用。”以及：“当你使用 AI 工具完成工作时，你的责任并不会减轻。”
这些立场中的每一个都是合理的。每一个都基于一个假设，而这个假设揭示了困境的核心：他们假设有人类可以进行评审。
Go 能负担得起“维持同样的标准”，因为它有全职贡献者。它能负担得起“直接说不”，因为 Go 有足够多的人对重要的事情说“是”。
Afero 没有。大多数开源项目没有。当 Rob Pike 说“不”时，Go 项目保持运行。当我说“不”时，PR 就挂在那里。那是不同种类的“不”。
这里有一个光谱，你落在哪里取决于你究竟在两者之间如何权衡。在实践中，维护者面临五个选项：
- 人类编写，人类审核。
- AI 编写，人类审核。
- 人类编写，AI 审核。
- AI 编写，AI 审核，人类点击合并。
- AI 编写，AI 审核，AI 点击合并。
列表中的每一步通常都是在用严谨性换取速度，用信任换取吞吐量。但对于大多数人类或 AI 都不评审的 PR，根本谈不上标准。
我们真正保护的是什么
当维护者评审贡献者的 PR 时，存在一个潜规则（契约）。贡献者投入数小时理解代码库、编写测试并提交干净的内容。评审者投入数小时进行评估、打回并提出改进建议。双方都在学习。评审者理解了项目的一个新角落。贡献者学会了更好地使用代码库的惯用法。这种关系形式。这种交流是使开源成为一个社区，而不仅仅是供应链的重要原因。
Bryan Cantrill 在 Oxide 描述了这种关于 LLM 使用的内部政策：通常，“读者和作者都默认，是编写者付出了更大的智力劳动。”当内容是 AI 生成时，“这个社会契约就变成了作者付出的努力最少。如果双方都没有付出努力，那么评审还有什么意义？”Oxide 的答案是，无论如何人类都要负责；工具不吸收责任。这是正确的直觉。但它假设有人真正在那里承担责任。
对于大多数项目，根本没有人在评审。社会契约不是被 AI 破坏的——它正被沉默破坏。六个月前提交了一个干净、测试完备的补丁却从未收到回音的贡献者，并没有体验到一个退化版的理想契约。他们什么也没体验到。
一个不完美的社会契约，是否好过一个从未发生的完美契约？
来自 AI 的在一天内的响应，可能比来自人类的永远的沉默更受尊重。
前方的实验
我决定弄清楚到底怎么回事。我在 Afero 上看到了 55 个尚未处理的 PR 请求，显然，这种拖延态度本身就已经构成了一种忽视行为。
AI 工具会让我更投入，让我从那些本不需要我的决策中解脱出来吗？还是会让我感觉连接更少——人类元素又减少了一层？我不知道让 AI 评审 PR 而不是人类评审是什么感觉，也不知道当双方的努力都减弱时，问责制是否还存在。这就是实验。
Russ 在那个讨论中还说了另一句话，我一直在回味：“最重要的事情是保持思考。工具让关掉大脑变得非常容易，但如果你小心避开那个陷阱，你就能产出好的成果。”这就是我要尝试走的路。让 AI 处理大量数据吧。而我自己则要继续负责做出正确的判断。
没有一个通用的政策可以同时适用于 Go 和 Afero。也不应该有。
受保护的分支依然受保护。我只是不再确定那究竟意味着什么。
你遇到过这种情况吗？我特别想听听那些尝试过使用人工智能进行代码审查的维护人员的意见——哪些方面运作正常，哪些又出现了问题。
原文地址：https://spf13.com/p/the-maintainers-dilemma/
今日互动探讨
“如果一个 AI 能够修复你项目中困扰已久的 Bug，但由于它是 AI 生成的，没有人能完全解释其每一步的逻辑，你会选择合并它吗？”
在开源社区的未来，我们究竟是在守护代码的质量，还是在守护人类参与的痕迹？欢迎在评论区分享你的看法。
还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：
- 告别低效，重塑开发范式
- 驾驭AI Agent(Claude Code)，实现工作流自动化
- 从“AI使用者”进化为规范驱动开发的“工作流指挥家”
扫描下方二维码，开启你的AI原生开发之旅。
原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球，快来加入星球，开启你的技术跃迁之旅吧！
我们致力于打造一个高品质的 Go 语言深度学习 与 AI 应用探索 平台。在这里，你将获得：
- 体系化 Go 核心进阶内容: 深入「Go原理课」、「Go进阶课」、「Go避坑课」等独家深度专栏，夯实你的 Go 内功。
- 前沿 Go+AI 实战赋能: 紧跟时代步伐，学习「Go+AI应用实战」、「Agent开发实战课」、「Agentic软件工程课」、「Claude Code开发工作流实战课」、「OpenClaw实战分享」等，掌握 AI 时代新技能。
- 星主 Tony Bai 亲自答疑: 遇到难题？星主第一时间为你深度解析，扫清学习障碍。
- 高活跃 Gopher 交流圈: 与众多优秀 Gopher 分享心得、讨论技术，碰撞思想火花。
- 独家资源与内容首发: 技术文章、课程更新、精选资源，第一时间触达。
衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
评论