AI Slop 的兴起：为什么 RPCS3 和开源维护者正在反击

开源社区目前正面临一种新型的噪音：“AI slop”（AI 垃圾内容）。最近，顶尖的 PlayStation 3 模拟器 RPCS3 的团队发布了一项公开请求，要求用户停止向其 GitHub 仓库提交 AI 生成的代码 pull requests (PRs)。其信息非常明确：停止生成你不理解的代码，并将其提交给需要极高精确度的项目。

这并非孤立事件。从 Godot Engine 到各种规模较小的 FOSS (Free and Open Source Software) 项目，维护者们都在报告低质量、AI 生成的贡献正激增，这些贡献带来的工作量比它们解决的问题还要多。

模拟器开发的复杂性 vs. “氛围编程” (Vibe-Coding) 趋势

模拟器开发是软件开发中最具挑战性的学科之一。为了让 PS3 模拟器正常工作，开发者必须对极其复杂且晦涩的架构进行逆向工程。正如一位社区成员所指出的，PS3 是现存最难模拟的目标之一，这使得 RPCS3 的成就——已实现约 70% 的游戏库可玩——显得更加令人印象深刻。

在这种环境下，“氛围编程” (vibe-coding) 出现了：这是一种利用 AI 根据一个模糊的想法或“氛围”来生成代码的做法，而无需深入理解底层的逻辑、调试过程或系统约束。对于 RPCS3 的维护者来说，这导致了“slop”——代码在语法上可能看起来正确，但在模拟器的特定需求背景下，逻辑上存在缺陷、未经测试，或者完全无法运行。

"There are plenty of resources online to learn how to debug and code instead of generating slop that you don’t understand and that doesn’t work."

维护者的负担： “免费”帮助的代价

AI 生成的 PR 最令人沮丧的一点在于，人们假设它们是有帮助的。许多贡献者是出于好意，认为自己在加速项目的进度。然而，在专业的开源工作流中，最昂贵的资源不是编写代码，而是对代码进行 review（审查）。

当维护者收到一个 PR 时，他们必须花费时间审计其安全性、性能退化以及架构适配性。如果该 PR 是“slop”，维护者的时间就被浪费了。这在开发者社区内引发了关于几种方案的讨论：

• 更严格的贡献政策： 一些项目正转向一种模式，即除非贡献者在白名单中，或者 PR 符合严格的初始标准，否则 PR 将被自动关闭。
• “责任”模型： 借鉴 Linux kernel 的方法，有人建议贡献者必须对自己的代码承担全部责任，包括使用 "Assisted-by:" 标签来披露 AI 的使用情况。
• 门槛机制： 关于回归“仅限邀请”的贡献模式，或者实施声誉系统以防止低质量提交的“洪水”式涌入，讨论正日益激烈。

“本地分支” (Local Fork) 的伦理困境

社区中出现了一个有趣的对比点，即关于将 AI 用于个人用途。一些开发者使用 AI 为他们自己本地的开源软件 fork 分支添加功能。因为这些代码对于他们的特定用例“有效”，但并未达到项目的工程标准，他们面临着一个困境：是向社区分享一个功能完备但杂乱无章的功能，还是保留这些改进以避免被贴上“slop-submitter”的标签。

这突显了一个关键差距：AI 目前非常擅长为个人使用创建“足够好”的原型，但对于构建稳定、共享的基础设施所需的严谨工程学来说，它仍然是一个糟糕的替代品。

结论：AI 时代 FOSS 的未来

RPCS3 与 AI 生成的 PR 之间的紧张关系是软件开发领域更大变革的一个征兆。虽然 LLMs 可以成为那些已经懂得如何编程的人的强大助手，但对于那些希望在不学习基础知识的情况下就向复杂项目做出贡献的人来说，它们正成为一种准入门槛。

为了让开源生态系统从这种“slop”的涌入中幸存下来，重点必须从贡献的数量转向过程的质量。正如 RPCS3 团队所指出的，真正帮助一个项目的途径不是通过 prompt，而是通过学习如何调试、测试并理解自己试图修改的代码。