航向 AI 前沿：Rust 編譯器的 LLM 政策

將大型語言模型 (LLMs) 整合進軟體開發生命週期，為關鍵開源基礎設施的維護者帶來了一個悖論。雖然 AI 可以加速編碼，但它往往將驗證的負擔從作者轉移到了審查者身上。Rust 編譯器團隊正透過一項擬議的 LLM 政策正面應對這一問題，這在開發者社群中引發了關於速度與正確性之間平衡的重要辯論。

Rust LLM 政策的核心

這項擬議的政策託管於 Rust Forge，其設計為一份動態文件，而非靜態的 RFC。其核心在於，該政策建立了一個明確的界限：LLM 的使用者必須對其提交的輸出負全責。

這些指南基本上可以歸納為幾個關鍵原則：

問責制： 如果使用 LLM 來生成代碼或註釋，提交者（人類）須對其正確性和品質負責。
揭露： 要求貢獻者在建立 PR 或錯誤報告 (bug report) 時，若使用了 LLM，應予以揭露。
品質控制： 低品質的 PR——通常以「AI 廢料」(AI slop)（幻覺邏輯或通用、缺乏上下文的註釋）為特徵——將會被拒絕。

一些貢獻者認為這只是「基本標準」，並指出這僅僅是將「作者在提交給具有高穩定性要求的專案之前，必須審查自己的工作」這一預期正式化。

維護者的負擔：為何需要政策

社群討論中一個反覆出現的主題是「驗證責任」。傳統上，維護者可以依賴一種社會建構：如果是一位受信任的貢獻者提交了 PR，審查過程可以專注於架構契合度與邊緣案例，而非基礎的正確性。

隨著 LLM 使得提交複雜且功能豐富、但可能包含細微幻覺的 PR 變得容易，這種信任感正在被侵蝕。一位評論者指出維護者日益增加的負擔：

"在現在的 PR 中，儲存庫維護者必須做更多的工作，因為他們無法再依賴『OptionOfT 寫了這個... 所以我們可以從這個角度來看待 PR』這種社會建構。... 這現在增加了 PR 作者的工作量，如上所述。我們需要進行驗證，而不能依賴社會建構。"

對於像 Rust 編譯器這樣「承載著全球經濟」的專案來說，錯誤的代價是天文數字。建立一個嚴密 (hermetic) 代碼庫的必要性，超過了對快速、AI 驅動的功能擴張的渴望。

社群摩擦與批評

儘管這份文件經過深思熟慮，但該政策並非沒有批評。有些人認為指南過於規範，甚至帶有「保姆式」色彩，特別是關於是否明確允許使用 LLM 來總結註釋或詢問有關代碼庫的問題。

批評者認為這些許可在實務上是無法驗證的。正如一位使用者所指出的：

"如果有人事後承認他們是用 LLM 找到的，他們會回去並拒絕一個錯誤報告嗎？"

其他人則持有更激進的觀點，認為 Rust 團隊是在出於一種「盧德分子」(Luddite) 式的恐懼，擔心被取代。有些人推測，如果主儲存庫保持過於限制，可能會出現「親 LLM 的分支」(pro-LLM forks)，利用 AI 代理 (agents) 來審查 PR，並可能在開發速度上超越主專案的範疇。

AI 治理的替代方案

討論中強調了專案處理 AI 生成內容湧入的幾種替代方式：

擔保系統 (Vouching Systems)： 有些人建議實施類似 vouch 的系統，貢獻者在與專案的敏感部分互動之前，必須由受信任的成員擔保。
嚴格的「AI 廢料」過濾器： 一些專案已經在採用激進的政策，立即關閉並封鎖提交明顯 AI 生成雜訊的使用者。
基於規範的演進： 部分社群成員認為專案應該忽略這種情況，並讓社會規範有機地發展，而不是試圖將其編碼成政策。

結論：求好，而非求快

Rust 編譯器的做法反映了「求好，而非求快」的哲學。透過堅持人類問責制與揭露，該專案旨在保護維護者免受 AI 生成貢獻的雜訊干擾，同時確保語言能持續安全地演進。這項政策是否能達成完全共識——或者它是否會成為專案成員之間的爭議點——仍有待觀察，但它為關鍵基礎設施專案如何管理向 AI 時代的轉型設定了重要的先例。