Rust 的 LLM 政策草案劃對了界線

2026年4月17日，有人向 Rust Forge 提出一個 pull request，為 rust-lang/rust 制定 LLM 使用政策。截至 2026年5月17日，該 pull request 仍為開放狀態，已有 65 則 issue 留言與 284 則 review 留言，因此這項提案尚未成為正式政策。¹

這份草案現在仍值得重視，因為它點出了多數 AI 程式撰寫指南迴避的界線：LLM 可以幫助人思考、學習、檢查與實驗，但在專案用來保留判斷力、品味、責任歸屬與共同理解的地方，不應取代人的作者身分。²

這項提案也符合 Rust 既有的貢獻規範。目前的 Rust Forge 貢獻指南已經要求貢獻者建立信任、尊重審查者時間、提交自己充分理解的工作、在提交前仔細檢查，並保持留言精簡。³ 編譯器審查政策也指出，審查者必須對受審程式碼有足夠理解，而審查時間有限。⁴ 這份 LLM 草案把這些既有期待，具體落實到 AI 輔助工作上。

重點摘要

Rust 草案允許私下使用 LLM 進行學習、摘要、私人審查、個人工具開發與實驗。² 它禁止由 LLM 起草的公開留言、issue 內容、pull request 說明、文件、編譯器診斷訊息，以及任何把 LLM 審查視為足以合併或拒絕程式碼的流程。² 它也為 LLM 產生的程式碼變更開了一個狹窄實驗空間：必須是受邀、非關鍵、已揭露、高品質、測試充分，且作者與審查者都完全理解。² 我的解讀是：這項政策之所以成立，是因為它優先保護智識責任，而不是產出量。

核心觀點

• 對維護者而言：政策應先保護審查量能、專案語氣與責任歸屬，再談生產力。
• 對 AI 程式團隊而言：應廣泛允許私人使用，但在公開作者身分、文件、診斷訊息與合併權限上劃下更硬的界線。
• 對貢獻者而言：揭露只有在人仍然承擔作品責任時才有意義。「模型寫的」不能變成藉口。
• 對工具建置者而言：審查 bot 需要獨立身分、可封鎖性、低誤報壓力，以及建議性地位。
• 對代理團隊而言：草案中最好的規則是文化性的，不是技術性的：用 AI 把東西寫得更好，而不是更快。²

草案把思考與作者身分分開

多數 LLM 政策會把兩種不同動作壓成同一類：使用 AI。Rust 草案則把它拆成私人認知與公開作者身分。

私人認知獲得廣泛許可。貢獻者可以向 LLM 詢問程式碼庫問題、為了私下理解而摘要留言、私下審查自己的程式碼或文字、建立個人開發者工具，也可以先產生可能解法供自己學習，再寫出自己的解法。²

公開作者身分則有明確紅線。草案禁止個人帳號張貼原先由 LLM 建立的留言。同一規則也適用於 issue 內容與 pull request 說明。² 草案也禁止原先由 LLM 建立的文件，包括非平凡的原始碼註解、文件註解、安全註解、多段落註解，以及編譯器診斷訊息。²

這個區分合理，因為公開產物承載的是專案語氣。編譯器診斷、安全註解與文件不只是傳遞資訊。它們在教使用者 Rust 如何思考，也會成為專案長期維護負擔的一部分。

LLM 生成的文字可能看似精緻，卻削弱這份負擔的承擔關係。審查者現在必須追問：誰選了這種措辭？誰理解其中含意？誰負責邊界案例？日後造成困惑時，誰會修正？草案拒絕讓貢獻者把這份責任外包，同時保留人類帳號的可信度。

最強規則：AI 審查不能成為合併權限

草案禁止把 LLM 審查視為合併或拒絕變更的充分條件。² 審查 bot 可以存在，但草案要求它們維持建議性角色。審查者必須明確認可 LLM 留言，該留言才能阻擋 pull request；作者仍然有自我審查義務。²

這條規則避開了一個誘人的失敗模式。團隊可以加入 AI 審查，然後宣稱工作流程更安全，即使新工具只是製造了第二股沒人有時間評估的主張。bot 可以找到真正的 bug，也可能提出瑣碎反對、過時風格建議、幻覺限制，或對自己沒有理解的程式碼發表自信評論。

Rust 草案從結構上處理這個問題：

重點不是 LLM 審查毫無價值。重點是，審查權限屬於人與專案流程。機器可以協助審查者，但不能成為正式審查者。

程式碼例外刻意收得很窄

草案並未禁止所有由 LLM 建立的程式碼。它為符合五項條件的程式碼變更加開實驗空間：受邀、非關鍵、高品質、測試充分、審查充分。²

每個詞都有實質作用。

受邀表示審查者事先同意審查由 LLM 建立的 pull request。新貢獻者若要走這條路，必須先與同一位被指派到該 PR 的審查者溝通。²

非關鍵讓 AI 建立的變更遠離錯誤可能造成 soundness 退步的區域。草案點名內部工具較可能適合，而 trait system、MIR 建置或 query system 等區域大概不合適。²

高品質表示程式碼至少必須符合其他變更的同等標準。草案明確拒絕會降低程式碼庫品質的 PR。²

測試充分則拉高門檻。由 LLM 建立的 PR 面臨更高的測試期待，因為 LLM 讓撰寫測試更容易。若沒有既有測試套件涵蓋該程式碼，作者就必須寫新的測試，否則關閉 PR。²

審查充分表示作者與審查者都承諾完全理解程式碼。專案成員的審查不能取代自我審查。²

這個實驗形狀很有用。它沒有假裝 AI 建立的程式碼不能幫上忙，也拒絕懶散版的「AI 輔助貢獻」：貢獻者生成補丁、請維護者代為整理，自己卻不花任何心力理解。

更好，而不是更快

草案最重要的一句話是：當人們用 LLM 把東西寫得更好，而不是更快時，效果最好。²

這句話應成為 AI 程式撰寫的預設標準。

只有更快，會把工作從作者轉嫁給審查者。貢獻者省下 1 小時生成補丁，維護者卻花 3 小時從有用程式碼、奇怪測試、臃腫註解、含糊診斷訊息與沒人負責的設計選擇中抽絲剝繭。即使 diff 最後能編譯，專案仍然輸了。

更好問的是另一個問題：工具是否幫助人形成更精準的理解？它是否找到作者已驗證的邊界案例？是否幫忙起草了作者真正理解的測試？最終貢獻是否更容易審查、維護與信任？

Rust 草案讓這個區分可執行。私人使用 LLM 可以改善作者理解；公開由 LLM 起草的作者行為可能削弱專案的共同理解。實驗性的 AI 建立程式碼，只有在邀請、範圍、品質、測試與審查都承擔額外負擔時才能前進。

這種組合勝過全面樂觀，也勝過全面禁止。它承認技術可能有幫助，但專案不會只因模型讓產出變便宜，就吸收低責任歸屬的成果。

管理章節避免獵巫

草案也相當謹慎地處理執行問題。它告訴貢獻者，無須扮演偵探追查 LLM 使用情況。若違規看起來明確，指向政策即可；若案例介於灰色地帶，回報給管理者後繼續前進。²

同一節把隱瞞 LLM 使用視為行為準則問題，但也明確表示，因他人使用 LLM 而騷擾貢獻者並不可接受。² 這兩者同樣重要。會鼓勵猜疑的政策，可能比它試圖阻止的 AI 生成內容更快毒化社群。

好的 AI 政策需要兩道界線：

草案把責任放在貢獻者身上，但沒有把每位審查者都變成調查員。這保護的不只是程式碼，也包括審查文化。

其他專案應該借鏡什麼

Rust 提案值得關注，因為它定義的是角色，而不是氛圍。

把 LLM 用作：

• 私人家教；
• 私人審查者；
• 協助自己理解的摘要器；
• 在人類驗證 bug 時的 bug 發現輔助；
• 審查者同意且範圍維持低風險時的實驗來源。

不要把 LLM 用作：

• 您公開留言的作者；
• 專案文件的聲音；
• 編譯器診斷訊息的作者；
• 人工審查的替代品；
• 未撰寫測試的藉口；
• 迫使維護者審查您不理解的程式碼的方法。

這份清單給維護者的，不是道德辯論，而是一套可操作政策。

我的解讀

這份草案切中了 AI 程式撰寫造成的品質問題。程式碼變得更便宜。審查注意力、品味、連貫性、專案語氣與社會信任卻沒有變便宜。稀缺性往上移了。

若專案最佳化的是產出量，維護者會被看似合理的 diff 淹沒。若專案最佳化的是責任歸屬，仍然可以使用 AI，但只能以讓人類作者更有能力、讓審查者負擔更輕的方式使用。

Rust 草案保護的是稀缺的那一層。它把診斷訊息、註解、文件與審查權限視為專案的一部分，而不是可替換文字。它把測試與自我審查視為義務，而不是配件。它給實驗一條路，但不是空白支票。

對嚴肅軟體專案而言，這是正確方向。Rust 正式採用前，具體規則可能還會變。但底層形狀不應改變：AI 可以幫人把工作做得更好，但人仍然必須擁有貢獻的責任。

FAQ

這項 Rust 政策已採用了嗎？

沒有。截至 2026年5月17日，這項政策仍是一個標題為「Add an LLM policy for rust-lang/rust」的開放 Rust Forge pull request。目前 rust-lang/rust-forge 的 main 分支尚未包含 src/policies/llm-usage.md。¹⁵

草案禁止所有 AI 使用嗎？

沒有。草案有條件允許私下使用 LLM 進行學習、摘要、審查、個人工具開發與想法產生。它也為已揭露、受邀、非關鍵、高品質、測試充分且審查充分的 LLM 建立程式碼，開了一個狹窄實驗空間。²

草案禁止什麼？

草案禁止由 LLM 起草的公開留言、issue 內容、pull request 說明、文件、編譯器診斷訊息，以及把 LLM 審查視為足以合併或拒絕程式碼。²

為什麼草案如此嚴格看待文件與診斷訊息？

文件與診斷訊息承載專案語氣、使用者指引與長期維護義務。草案在某些情況下允許 LLM 協助周邊邏輯，但禁止 LLM 建立訊息本身。²

AI 程式團隊應從這項提案學到什麼？

區分私人協助與公開作者身分。當 AI 影響他人時要求揭露。讓審查權限留在人手中。當 AI 協助建立程式碼時，提高測試與自我審查門檻。最佳化更好的工作，而不是更多產出。

參考資料