AI 生成 Pull Request 泛滥开源项目：从 RPCS3 事件看问题与解法

发布日期: 2026-05-11 • 阅读时间: 10 分钟 • 标签: AI PR, 开源维护, RPCS3, AI 编码工具, 代码审查

2026年5月11日，RPCS3 团队——最流行的 PS3 模拟器维护者——做了一件不寻常的事。他们礼貌地请求社区不要再往仓库里灌 AI 生成的 Pull Request 了。不是愤怒的封禁。不是严厉的声明。就是一个疲惫的恳求：求你们了，我们真的没精力审那些没人真正理解的代码了。

这不是孤立事件。这是开源维护者都能感受到的煤井金丝雀——AI 编码工具让生成代码变得极其容易，但低质量 AI PR 的洪水正在成为开源社区的负担。

RPCS3 事件：一个礼貌的警告

RPCS3 项目是一个技术奇迹——一个纯软件实现的 PlayStation 3 模拟器，经历了超过十年的逆向工程。代码库里的每一行代码都代表着无数小时的研究、针对数千款游戏的测试、以及对 Cell Broadband Engine 架构的深刻理解。这绝对不是一个适合让 Claude Code "给某某游戏加兼容性"然后提 PR 的地方。

但这恰恰正在发生。RPCS3 团队报告说，最近 PR 数量明显增加——表面看起来合理，仔细检查却发现根本不理解项目的实际复杂度。代码能编译。看起来也没问题。但缺少上下文、边界情况、以及只有深入参与代码库才能理解的设计约束。

HN 上的讨论很能说明问题。一位开发者这样描述困境：

"我现在都不敢给开源项目提 PR 了。我用 Codex 5.5 做了我想要的功能。在我的机器上跑得完美。但我不想提交垃圾代码，也没有时间好好重构它。所以这个功能就留在我自己的机器上了。"

好意图 + AI 工具 = 低质量 PR。这个等式对维护者来说行不通。

更大的趋势：AI 编码工具降低贡献门槛——但这恰恰是问题

先说清楚：Claude Code、Cursor、GitHub Copilot、DeepSeek TUI 这些 AI 编码工具确实了不起。它们让开发者比以往更快地交付软件。但同时也让生成"看起来对但实际上不对"的代码变得过于容易。

这创造了一种对维护者特别痛苦的新型贡献：

看似合理实则错误——代码能编译、能通过基础测试，但包含只有专家才能发现的逻辑漏洞或性能问题
缺乏上下文——AI 不理解项目的架构、历史和设计决策，产出的代码在真空中说得通但在实际代码库里格格不入
不可测试——生成的代码经常不带测试，或者测试只是循环论证（测试函数返回了它返回的东西）
难以审查——AI 生成的 diff 通常很大，涉及多个文件，对人类审查者来说是噩梦

"Vibe Coding" 趋势进一步放大了这个问题：当开发者依赖 AI 生成代码而不完全理解它时，他们就失去了审查自己贡献的能力。

维护者的负担：审查 AI 垃圾代码消耗的是真时间

开源维护者本来就承受着巨大压力。2017 年的 "Roads and Bridges" 报告就把开源称为"维护危机"——那还是在 AI 出现之前。现在，每个 AI 生成的 PR 都在增加审查队列。每个看起来合理的 diff 都要消耗维护者 15–30 分钟来评估。

算一笔账：

一个像 RPCS3 这样的热门项目每周可能收到 5–10 个 AI 生成的 PR
每个至少需要 15 分钟的专业审查（保守估计）
每周就是 1.25–2.5 小时的纯浪费
一年下来：65–130 小时的维护者时间，烧在没人要求的代码上

而这还是那些被实际审查的 PR。更多的 PR 直接没看就被关了，留下贡献者沮丧、维护者内疚。

这形成了一个负和博弈：贡献者觉得"参与了开源"，AI 公司从交互中免费获得了训练信号，而维护者承担了所有成本。

AI PR 和人类 PR 有什么本质不同

开源一直都有来自初学者的低质量贡献。但 AI PR 在几个关键方面不同：

规模——AI 生成代码的速度比人类快几个数量级，量级前所未有
信心错位——提交者没有参与感。他们没写代码，只是打了个 prompt。审查时无法解释设计决策
没有学习曲线——提交了垃圾 PR 的人类会进步。AI 不会从维护者反馈中学到东西（除非维护者自己去训练它，那又是无偿劳动）
更难拒绝——代码不是明显坏掉的。它是微妙地错。拒绝它需要解释为什么，比说一句"编译不过"花的时间多得多

正如 Addy Osmani 的 Agent Skills 项目所说，我们需要教 AI 编码工具遵循专业软件工程的"隐形脚手架"——写 spec、规划变更、验证结果、确保人工审查——然后再提 PR。

真正能用的解法：如何负责任地用 AI 编码工具

目标不是禁止 AI 进入开源。目标是负责任地使用它。以下是具体做法：

1. 提交之前逐行理解代码

如果你用 AI 编码工具生成了一个 PR，花时间逐行读 diff。如果你不理解某个函数的作用，或者不知道为什么做了某个改动，不要提交。你在审查时无法解释代码，这就是一个危险信号。

2. 先写测试

在让 AI 生成代码之前，先自己写测试。这迫使你思考代码应该做什么，而不是接受 AI 产出的东西。Agent Skills 的生产编码工作流指南对此有更详细的说明。

3. 保持变更小

AI 生成的 diff 通常很大。抵制这种倾向。提交小而专注的 PR，一次只改一件事。这样审查才可控，被接受的概率也更高。

4. 在 PR 描述里写清楚上下文

说明这个 PR 做了什么、为什么重要、你做了什么测试、你做了哪些假设。一个好的 PR 描述能给维护者省下 10 分钟的调查时间。

5. 准备好捍卫你的改动

如果维护者问了一个关于你代码的问题，你应该能回答，而不是跑去问 AI。如果你做不到，那这段代码就不属于这个项目。

6. 从 Issue 开始，不是 PR

在写任何代码之前，先开一个 issue 描述你想做的事情。先获得维护者对方案的认可。很多 AI 生成的 PR 被拒绝不是因为代码写得差，而是因为功能不符合项目的方向。

7. 使用 AI 辅助代码审查工具

像 9Router 这样的工具可以在代码到达人类审查者之前通过自动化质量检查做一轮过滤。这可以作为 AI 贡献的第一道把关。

8. 给你的 AI Agent 配置结构化工作流

如果你在用 Claude Code 或 UI-TARS-desktop 这样的编码 Agent，配置结构化工作流——比如 Agent Skills ——强制在生成 PR 之前写 spec、写测试、做审查。

责任在我们自己身上

RPCS3 团队的礼貌请求是一个警钟。开源依赖志愿者的劳动。每一个需要维护者花时间去审查和拒绝的 AI 生成 PR，都是对这种善意的剥削。最终，人会倦怠，然后离开。

AI 公司也有责任。他们应该：

给 PR 生成添加摩擦——要求用户确认他们审查过 diff
在 PR 元数据中标记 AI 生成标识，方便维护者分流处理
投资开发帮助维护者评估 AI 贡献的工具

但最大的责任在我们这些使用这些工具的开发者身上。AI 能写代码。但 AI 写不出可维护、可审查、符合项目方向的代码——这需要人类的判断力。如果我们因为代码生成容易就觉得 PR 不值钱，我们会毁掉自己依赖的整个生态。

让我们证明自己，可以用 AI 工具而不滥用支持这些工具的社区。RPCS3 团队已经礼貌地请求过了。我们其他人应该听着。

← 返回博客列表