AI Slop 的崛起：為什麼 RPCS3 與開源維護者正在反擊

開源社群目前正遭遇一種新型態的噪音：「AI slop」。最近，頂尖的 PlayStation 3 模擬器 RPCS3 的團隊發布了一項公開請求，要求使用者停止向其 GitHub 儲存庫提交 AI 生成的程式碼拉取請求 (PRs)。其訊息非常明確：停止生成你不理解的程式碼，並將其提交到需要極高精確度的專案中。

這種衝突並非孤立事件。從 Godot Engine 到各種規模較小的 FOSS (Free and Open Source Software) 專案，維護者們都在報告低品質、AI 生成的貢獻正大幅增加，這些貢獻對開發者而言，造成的負擔往往比解決的問題還要多。

這項現象揭示了現代 LLMs 與高階系統工程實務之間的根本脫節。

模擬器開發的複雜性 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 生成的 PRs 最令人沮喪的一點是，那種認為它們「很有幫助」的假設。許多貢獻者是出發點良好的使用者，他們相信自己正在加速專案的進展。然而，在專業的開源工作流程中，最昂貴的資源並非編寫程式碼，而是對程式碼的 review (審查)。

當維護者收到一個 PR 時，他們必須花時間審查其安全性漏洞、效能退化以及架構契合度。當該 PR 是「slop」時，維護者的時間就被浪費了。這導致開發者社群內部提出了幾種解決方案：

• 更嚴格的貢獻政策： 一些專案正轉向一種模式，除非貢獻者在白名單中，否則 PRs 將會被自動關閉 (autoclosed)，或者 PRs 必須符合嚴格的初步標準。
• 「責任制」模式： 借鑒 Linux kernel 的做法，有人建議貢獻者必須對其程式碼負起全責，包括使用 "Assisted-by:" 標籤來揭露 AI 的使用情況。
• 把關機制： 社群對於回歸「僅限受邀」的貢獻模式，或是實施聲譽系統以防止低品質提交的「洪水」式湧入，討論日益增加。

「在地分叉 (Local Fork)」的倫理困境

社群中出現了一個有趣的對比觀點，關於將 AI 用於個人用途。一些開發者使用 AI 為自己本地的開源軟體分叉版本 (local forks) 添加功能。因為這些程式碼對他們的特定用途「有效」，但並非按照專案標準進行「工程化」設計，他們面臨一個困境：是要將一個功能完備但雜亂的特性分享給社群，還是將改進保留在自己手中，以避免被貼上「slop-submitter」的標籤。

這突顯了一個關鍵差距：AI 目前非常擅長為個人使用創建「足夠好」的原型，但對於穩定、共享的基礎設施所需的嚴格工程實務，它仍然是一個糟糕的替代品。

結論：AI 時代下 FOSS 的未來

RPCS3 與 AI 生成的 PRs 之間的緊張關係，是軟體開發領域更大規模轉變的徵兆。雖然 LLMs 可以成為那些已經懂得如何編碼的人的強大助手，但對於那些希望在不學習基礎知識的情況下就貢獻於複雜專案的人來說，它們正成為一種進入門檻的障礙。

為了讓開源生態系統能從這波「slop」的湧入中生存下來，焦點必須從貢獻的「數量」轉向處理過程的「品質」。正如 RPCS3 團隊所指出的，路徑並非透過一個 prompt，而是透過學習如何除錯、測試並理解自己試圖修改的程式碼。