反向半人馬的崛起：LLM Slop 與開源維護危機

反向半人馬的負擔

開源維護者正日益面臨一種被稱為「反向半人馬」（reverse centaur）的現象：資深工程師的時間不再是用於創造程式碼，而是花在審查與合併由機器產出的程式碼。這個術語由 Cory Doctorow 所提出，描述了「脆弱且易受攻擊的人們正被冷漠且無情的機器所操縱」。

對於像 Miguel Grinberg 這樣的維護者來說，LLM 生成的貢獻湧入，改變了接收 Pull Request (PR) 的體驗。過去，一個未經請求的 PR 是一個社群投入與自豪感的象徵；現在，它往往是低品質「slop」的「紅旗」警訊，這些內容是由使用者透過提示 LLM 來改變專案行為以滿足其特定需求，卻未考慮對程式碼庫更廣泛影響的使用者所產生的。

抵制 AI 生成 Slop 的策略

為了對抗機器生成的程式碼洪流，一些維護者正在實施更嚴格的貢獻流程，以確保人類的參與。

Issue-First 要求

一個有效的策略是強制要求所有變更必須在提交 PR 之前，先透過 GitHub issue 提出。這個流程可以確保：

• 維護者可以在任何一方投入大量時間之前，先對提案進行審查。
• 貢獻者展現出對專案健康的真實興趣，而非僅是隨手提交。
• 維護者可以與貢獻者建立人與人之間的聯繫。

立即拒絕未經討論的 PR

當 PR 在沒有事先討論的情況下送達時，維護者現在可能會立即關閉它們，如果沒有證據顯示有人類參與。這種轉變承認了審查一個可能有用但由 AI 生成的補丁的成本，現在已超過了其帶來的效益，因為低品質提交的數量使得手動過濾變得難以持續。

對開源生態系統的影響

AI 輔助編碼的興起，正在快速修復的需求與專案維護的可持續性之間創造出一種根本性的緊張關係。

貢獻者的困境

現在出現了一群「非編碼者」或來自無關領域的工程師，他們現在可以識別 Bug 並使用 LLM 來生成他們原本無法撰寫的修復程式碼。雖然這些使用者意圖提供幫助，但他們的貢獻往往缺乏專案所需的架構上下文，導致維護者精疲力竭。

寫作的社會契約

社群討論強調了技術貢獻中「隱含社會契約」的崩解：即作者應該在工作中投入比讀者審查時所需花費更多的努力。AI 顛倒了這個比例，使得產出一個只需幾秒鐘生成的 PR，卻需要花費數小時進行審核的過程變得輕而易舉。

開源的未來

目前對於傳統開源模式是否仍然可行仍存在爭議。一些觀察者提出了幾種新興趨勢：

• 中心化： AI 可能會將新使用者引向少數幾個關鍵專案，進一步增加這些特定儲存庫的 PR 洪流。
• 信號與雜訊比下降： 低品質 AI 函式庫的激增，使得開發者更難以尋找高品質、由人類策劃的工具。 n- 替代性分發： 一些人建議轉向「非規範軟體」（noncanonical software）或基於生態系統的集群，在這些地方，功能是由社群共同分享與演進，而不依賴於單一、精疲力竭的維護者。

社群觀點

開發者社群的見解反映了 AI 在工作流程中如何被看待的深刻分歧：

"The Pavlovian PR notification response has gone from, 'Oh! What do we have here?' to 'Groan. Do we have anything here?'"

"AI has just increased the amount of crap... the 10% of code created by AI will be valuable, and only 10% of human-written code was valuable."

雖然有人認為維護者應該使用 LLM 來過濾與審查即將到來的 PR，但其他人則堅持認為，傳統開源的智力交流與人類推理能力，正是這項技術正在侵蝕的價值所在。