技术深度解析
RPCS3的禁令并非针对AI本身；而是关于LLM生成代码的方式与复杂模拟器构建方式之间的根本性不匹配。RPCS3是一个C++项目，拥有超过50万行代码，针对一个异构架构平台：基于PowerPC的主CPU、八个协同处理单元（SPU）以及RSX GPU。该模拟器必须处理动态重编译、精确计时和硬件精确的内存映射——同时保持与数千款商业游戏的兼容性。
AI生成补丁的问题
当GitHub Copilot或基于GPT-4o或Claude 3.5构建的自定义代理等AI工具生成拉取请求时，它通常通过分析即时上下文来操作：函数签名、附近的注释以及最近的更改。它不理解项目长达十年的错误修复历史、在晦涩论坛帖子中记录的特定硬件怪癖，或在已关闭问题中讨论过的性能权衡。对于RPCS3，一个“看起来正确”的补丁可能：
- 在SPU线程调度器中引入竞态条件。
- 破坏针对特定游戏计时错误的变通方案。
- 使用与项目自定义内存分配器不兼容的标准C++模式。
隐藏成本：审查开销
维护者报告称，审查AI生成的PR比审查人类编写的PR花费的时间*更长*。人类贡献者可以解释他们的推理，回答后续问题，并根据反馈进行迭代。AI代理只提供一个静态差异。维护者必须从心理上重建推理过程，验证边界情况，并经常在真实硬件上测试补丁——这个过程可能需要数小时。随着每周有数十个这样的PR涌入，负担变得不可持续。
相关开源工具
- GitHub Copilot：最广泛使用的AI编码助手。虽然它在样板代码和单文件更改方面表现出色，但其对复杂的多文件重构的贡献往往很肤浅。
- Cursor：一个AI优先的IDE，可以处理更大的代码上下文，但仍然难以应对项目特定的习惯用法。
- Sweep AI：一个自主从GitHub问题创建PR的代理。它已被多个项目禁止，因为生成低质量、不可测试的代码。
- Aider（GitHub: paul-gauthier/aider）：一个流行的开源编码代理，拥有超过2.5万颗星。它使用仓库地图进行更改，但对非文本约束（例如硬件计时）的理解为零。
数据表：AI代码质量在复杂项目与简单项目上的对比
| 项目类型 | 示例 | AI PR接受率 | 平均审查时间（人类） | 平均审查时间（AI） |
|---|---|---|---|---|
| 简单工具库 | `lodash` | 45% | 15分钟 | 30分钟 |
| Web框架 | `React` | 20% | 45分钟 | 90分钟 |
| 模拟器 | `RPCS3` | <5% | 2小时 | 4小时以上 |
| 内核模块 | `Linux DRM` | <1% | 3小时 | 6小时以上 |
数据要点： 随着项目复杂性的增加，接受率急剧下降，审查时间翻倍。对于RPCS3，AI PR是净负值——它们消耗的维护者时间多于节省的时间。
关键参与者与案例研究
RPCS3团队
由Nekotekina、kd-11和elad335等开发者领导，该团队花费了十多年时间精心逆向工程PS3。他们禁止AI代理的决定并非轻率做出。在公告中，他们强调禁令适用于*自主*代理——而非使用AI作为打字助手的人类开发者。这一细微差别至关重要：他们针对的是数量问题，而非工具本身。
其他采取立场的项目
- Linux内核：维护者长期以来一直抱怨AI生成的补丁。2024年，一项要求“人类签名”补丁的提案被讨论但未采纳。内核的编码风格和深度硬件依赖性使AI贡献尤其危险。
- Homebrew（macOS包管理器）：2025年初，Homebrew维护者报告PR数量增加了300%，主要来自AI代理，并开始要求贡献者通过“人类验证”测试。
- Godot引擎：这个开源游戏引擎看到AI生成的PR激增，这些PR“修复”警告但引入细微错误。该团队正在考虑类似RPCS3的政策。
对比表：主要开源项目的AI禁令政策
| 项目 | AI禁令政策 | 执行机制 | 实施日期 |
|---|---|---|---|
| RPCS3 | 全面禁止自主AI代理 | 标记为“AI生成”的PR自动关闭 | 2025年5月 |
| Linux内核 | 无正式禁令，但强烈不鼓励 | 维护者酌情处理；来自未知机器人的补丁常被忽略 | 持续进行 |
| Homebrew | 需要人类验证 | 新贡献者必须通过CAPTCHA式测试 | 2025年3月 |
| Godot | 正在讨论中 | 可能要求贡献者协议声明未使用AI | 待定 |
| Mozilla | 无禁令，但有AI使用指南 | 贡献者必须披露AI辅助 | 2024年 |
数据要点： 趋势