上周刷到一条挺有意思的消息：RPCS3（那个把 PS3 模拟器做到可玩级别的小组）的开发者在 Hacker News 上公开发了条帖子，标题很直白——请不要再往我们的仓库提交 AI 垃圾 PR 了。
点进去一看，挺无奈的。一堆人用 Claude 和 ChatGPT 生成的代码，往 RPCS3 的 GitHub 上扔 PR，内容从优化了字符串拼接，到重构了整个函数。开发者一个个打开看，发现大部分要么是错的，要么是改出来比原来还慢，还有的直接把编译搞挂了。
这不是个别现象。
**AI PR 泛滥：不是写得好不好，是审不过来**
我维护过一些开源项目，深知代码审查的成本。如果是人写的 PR，你大概能猜到对方的思路和水平，沟通起来有基准线。但 AI 生成的代码不一样——它看起来对（语法正确、变量命名规范、注释工整），但就是不对。逻辑边界错了一位，循环条件多了一层，缓存策略反直觉。
更麻烦的是，AI PR 的提交者通常对代码本身理解很浅。你 review 完打出五个问题，对方回一句我不知道，让我再问一下 AI。一来一回耗掉半小时，最后发现改出来的东西还不如不改。
RPCS3 不是第一个喊停的。去年有 Go 语言的几个项目私下就在吐槽类似问题，今年初 Rust 社区也有人提过。只不过 RPCS3 这次是公开叫板了。
**我怀疑 AI 生成代码的投入产出比被严重高估了**
自己写项目的时候我天天用 Cursor 和 Copilot，效率确实有提升——尤其写 boilerplate、补测试、写注释这些。但我不认为这等于能往别人的项目提 PR 了。
差在哪？项目维护不是能跑就行。你要考虑的：
– **上下文兼容性**：你的改动跟项目既有的架构思路是否一致？AI 没有这个全局理解。
– **测试覆盖**：AI 能补单测，但补的是它看得到的 case，边界条件大概率遗漏。
– **长期维护成本**：AI 喜欢重构，喜欢现代化，但每个项目都有自己的历史包袱和风格约定。AI 不认这些。
RPCS3 团队说，他们现在看到 AI 生成的 PR 直接关掉，评论也省了——没时间一个个解释你的代码为什么不对。
**这个趋势会不会杀死开源社区的信任感？**
这是我最担心的问题。开源的本质是我来贡献我的代码，你相信我不会搞砸。如果每三个 PR 里就有一个是 AI 写的 trash，维护者迟早会变得默认不信任任何新提交者。到时候受伤害的是那些真正想入门的开发者。
老实说，我觉得这是好事：AI 工具把写代码的门槛打下来了，但把写对代码的门槛推高了。写出一段能跑的代码不再值钱，值钱的是理解这段代码为什么该这样写、在更大系统里扮演什么角色。
如果你真的想用 AI 给开源项目做贡献，我的建议是：
1. 自己先用那个项目做点东西，理解它的痛点和设计哲学
2. 让 AI 帮你写，但你自己要能 review 每行代码
3. 提 PR 之前，先把改动在本地完整跑一遍测试
4. 在 PR 说明里写清楚你的思考过程——不是为了通过审查，而是证明你真的理解你在做什么
AI 不会替你做最后一步。这一步省不得。