跳转至

封面

AI代码洪流:GitHub正在被假贡献淹没

凌晨三点,某个知名开源项目的维护者打开 GitHub,47 个新 PR 等着他。

标题一个比一个正经:"Fix edge case in async handler""Optimize memory allocation for large datasets""Add test coverage for edge cases"。代码格式工整,注释清晰,测试用例一个不少。

他看了三个,全拒了。

全是 AI 生成的。看着像模像样,跑起来一地鸡毛。

这不是个例。这是 2026 年开源世界正在发生的塌方。

假贡献,真灾难

一个数据能让你后背发凉:2026 年第一季度,GitHub 上的 AI 生成代码占比已经突破 45%。但在热门开源项目中,AI 生成的 PR 占比更高——某些项目达到了 60% 以上

不是 60% 的好代码。

是 60% 的垃圾混在面粉里,维护者得拿手指一撮一撮地挑出来。

Linux 内核社区的维护者上个月公开骂了一句——"I'm not your AI's code reviewer." 他负责的子系统每天收到 20+ 个 PR,至少一半是 AI 生成的。其中三个通过了初审但引入了安全漏洞,在合并后第三天才被发现。

这不是机器帮人写代码的故事。这是机器帮人埋雷的故事。

AI PR 为什么比人类 PR 更危险

人类写的烂代码,烂得肉眼可见。变量名乱起、逻辑支离破碎、没有任何测试。

AI 写的烂代码,烂得衣冠楚楚。

变量名工整、注释详尽、测试覆盖率 95%、commit message 还带 emoji。就像一个穿着西装打着领带的骗子——你多看两眼才觉得不对劲。

最可怕的是,AI 会在边界条件上犯低级错误。它不懂你的项目上下文,不懂你三年前为什么要把那个 if 写成 >= 而不是 >。它会自作聪明地"优化"掉那个被你精心设计成安全阀的 sleep(0.1)

一个 Python 生态的核心包——每周下载量超过 3000 万——去年 11 月合并过一个 AI 生成的 PR。那个 PR "修复"了一个内存泄漏,顺带引入了一个竞态条件。Bug 在生产环境潜伏了四个月。发现的时候,数据已经脏了。

修改成本:合并只花了两分钟。修复花了两个工程师三周。

这是 AI PR 的性价比:合并 = 2 分钟,擦屁股 = 6 个月。

维护者在被活埋

开源维护者本来就已经精疲力竭。大多数人靠热爱发电,白天上班,晚上修 bug。现在 AI 又给他们送来了一车假 bug。

GitHub 2025 年的开发者调查:超过 70% 的开源维护者表示 AI 生成的低质量 PR 是他们的头号时间黑洞。平均处理一个 AI PR 的时间,是人类 PR 的 3 倍

因为人类 PR 一看就知道行不行。AI PR 你得看完、想完、测完,才能确定它不行。

PyPI 上一个有 1500 万用户的认证库,核心维护者在 README 里加了一行红色大字:

⚠️ AI-generated PRs will be closed without review.

没用。该来的还是来。

他最后写了个 bot,专测 AI 痕迹。测出来直接关。bot 运行第一周,自动关了 83 个 PR。

83 个。

最荒诞的循环:AI 审 AI

更魔幻的现实是:有的维护者已经放弃了人类 review,开始用 AI 审 AI。

你先用 Copilot 写 PR,我用 CodeRabbit 审 PR。你假装是人,我假装在认真看。你的代码是幻觉,我的 review 也是幻觉。

从头到尾,没一个人类。代码质量呢?听天由命。

这就是 2026 年的开源世界。一个 AI 写、AI 审、AI 测、AI 部署的闭环,唯一的漏洞是——没人知道代码到底对不对。

这叫自动化。叫自欺欺人也行。

一位在 Google 做过 8 年开源项目的老兵在博客里写道:"我们花了 20 年建立起开源社区的信任机制——代码审查、贡献者声誉、测试覆盖率。AI 用 18 个月就把它冲垮了。"

谁在制造这堆垃圾

不是恶意攻击者。大部分 AI PR 的提交者,是真以为自己做了贡献。

"我用 AI 给这个项目修了个 bug!我是开源贡献者!"

简历上写着"Linux 内核贡献者"。点进去一看,全是 AI 生成的格式化补丁。

有些人甚至批量操作。一个周末给 200 个项目提交 PR,全是一个 prompt 跑出来的。GitHub 的 contribution graph 绿得发光。代码质量烂得发指。

这不叫贡献。这叫数字涂鸦

问题是平台默许这种行为。GitHub contribution 计数器不区分 AI 代码和人类代码。Hacktoberfest 送 T 恤的活动,去年爆发式涌入 AI PR 后被迫改了规则——又怎样,今年换个 prompt 继续冲。

开源会因此死掉吗

不会。但会变。

首先,项目门槛会提高。以前开源是"欢迎任何贡献",现在是"欢迎真实人类贡献"。越来越多的核心项目会要求签署 CLA(贡献者许可协议),甚至要求身份验证。

其次,AI 检测工具会成为标准基础设施。每个 repo 会内置一个 AI 版 lie detector,没通过的就自动关。

第三——也是最矛盾的——AI PR 狂潮反而会推动 AI 辅助审查工具的发展。因为人类的审查带宽远远不够了。

但这些都是治标。真正的答案不在工具,在人。

开源从来不是代码的集合。是人的集合。

Linux 内核不是因为代码好而伟大,是因为 Linus 骂了 30 年,几百个核心维护者熬夜审了 30 年。一个 PR 能进内核,不是因为跑通了 CI,是因为有人认真看了每一行、想了每一个后果。

AI 可以写出格式完美的代码。但它不知道你的项目七年前为什么做了一个看似愚蠢的架构决策——那个决策是当时的 CTO 在凌晨两点拍板、后来被证明救了公司一命的。

这些事,AI 不会懂。永远。

最后的防线

所以开源不会死。但开源的易用性会死。

门槛抬高之后,新人更难进入。贡献者变少,维护者更累。这是一个负反馈循环,而 AI 是那个加速器。

唯一的出路是:承认开源是有成本的。 不是代码成本,是人的成本。

企业如果依赖开源,就得掏钱——不是给平台,是给维护者。不是偶尔赞助一杯咖啡,是正经把人雇来维护。

否则,你用的那个免费库,最后一行靠谱的代码,就是一个快被 AI PR 淹死的维护者,在凌晨三点关掉电脑前写的。


他不是超人。别让他一个人扛。

AI代码PR审查困境

在风暴眼里的生存指南

说了这么多,如果你是维护者,现在能做什么?

一、立规矩。

在 CONTRIBUTING.md 里写清楚:AI 辅助可以,但必须声明。不声明的 AI PR,关。声明了但质量低下的,关。声明了、质量好、但你不确定的——也关。

宁可错杀,不能漏毒。

二、升级工具链。

CI 管道里加 AI 检测。现在有一批工具做得不错:检测语言模型生成的文本模式、代码风格一致性分析、贡献者行为分析。不是万能的,但能过滤掉 70% 的垃圾。

三、守住节奏。

不要因为 AI PR 多就加速 review。AI 不累,你会累。保持你自己的审查节奏,该拒就拒,该关就关。你不是 AI 的质量管理员,你是项目的看门人。

四、说出来。

让社区知道你的处境。Apache 基金会的几个项目维护者联名写了一封公开信,标题就叫"Please Stop Sending AI PRs"——被翻译成 17 种语言,在 Hacker News 置顶了一整天。

有时候,说一句"别再发了",比写一个检测 bot 更有效。

风暴之后

AI 代码的洪水不会停。

但我们能选择不被冲走。

开源社区最值钱的从来不是代码行数。是 review 时的那双眼睛,是合并前的那次犹豫,是凌晨三点一个陌生人认真看完你写的每一行——然后打了一个 LGTM

那个 LGTM,AI 永远打不出来。


这个 PR,是人写的。你不用怀疑。

程序员深夜审查AI代码