AI 浪潮下的开源软件：项目通胀与审阅过载

AI 编程工具正以肉眼可见的速度渗透进软件开发，也深刻改变了开源软件的世界。这篇编译自一位资深开源维护者的分析，从「项目通胀」与「审阅过载」两个切面，观察 AI 时代下的开源社区正在经历哪些变化。

项目通胀：GitHub 上的代码不再稀缺

过去十多年，GitHub 上的仓库数量持续膨胀；AI 编码工具普及后，这一趋势被进一步放大。如今任何人都可以在几分钟内生成数千行代码并推送到 GitHub，但这并不意味着高质量项目在同步增长。

文章作者指出，传统意义上的开源项目往往意味着：作者对问题域有一定理解、与作品存在个人联系、并有意愿长期维护。而在「vibe coding」时代，仓库常常只是为了满足一次性需求被生成出来，作者可能用完即弃，数月之内就沦为放弃项目（abandonware）。

以 MeshCore 项目为例，社区中出现了大量衍生分支：官方固件缺一个功能，就有人 fork、让 AI 生成补丁、再以 MeshCore-UltimateEdition 之类的名字发布——但作者往往对该项目并无感情，一个月后就失去兴趣，项目随之荒废。

一个仓库放着代码，并不等于一个开源项目。开源项目的本质是为用户解决真实的问题与场景，而非仅仅满足作者一时的需求；大多数「速成」代码的作者并无意愿走到这一步。

审阅过载：维护者成为新的瓶颈

代码生成变得廉价，但代码评审无法同步廉价——这正是 AI 引入后开源领域出现的新失衡。原有的贡献评审流程在 AI 时代已逼近极限。

文章给出的真实案例之一是 GNOME 50 移除了 Google Drive 支持，原因就是长期无人维护。后来有用户重新补齐功能并向 gvfs 项目提交了约 4000 行的补丁，但显然由 AI 生成；维护者仍需逐行验证其是否真正可用、是否符合长期维护所要求的代码质量。

更普遍的情形是：贡献者用 AI 写出大型 PR，却对主题缺乏深入理解，也无意长期跟进；而维护者一面要审查代码，一面还要面对「扔过墙就不再出现」的提交者。作者本人在 Meshy 项目中就遇到过一个 9000 行的 macOS 支持 PR，一小时快速审查中就发现多处问题，包括：

• 代码明显是 AI 生成；
• 大量只是把单引号替换成双引号的无意义改动；
• 改动涉及与问题无关的代码；
• 覆盖了主分支近期的所有修改。

提交者从未回应过评论，作者也再没收到过回复。他的结论是：对此类贡献，连一小时都不值得花，下次应该更快地拒绝。

走向策展化分发？

面对代码通胀与审阅压力双重夹击，一些项目开始收紧基础贡献要求。作者在文末提到了一种可能性：策展化的软件源——类似 Linux 发行版仓库——可能会卷土重来。在开源生态日益混乱的背景下，用户或将重新珍视那些经过筛选、可在六个月后依然可靠依赖的软件来源。

十多年前，「我在 Debian 里就能找到一切」的体验被认为是结束了；但 AI 带来的噪音冲击，正在让这条路线以另一种形式回归。