一份格式完整、測試齊全的 Pull Request，過去足以讓維護者相信作者花時間理解程式碼與設計。Rust 專案 8 月 5 日為 rust-lang/rust 主倉庫採用 LLM 使用政策：公開的模型內容要揭露，模型生成程式碼必須先約定範圍、完成測試與人工審查。官方認為，AI 讓程式碼更快產出，也讓「認真工作留下的痕跡」失去判斷力。台灣團隊使用 Coding Agent 時，PR 裡更要留下設計理由、測試結果與實際負責人。
| 項目 | 資訊 |
|---|---|
| 案例主角 | Rust 專案內五個團隊與 rust-lang/rust 主倉庫維護者 |
| 發生地區與日期 | 全球開源社群；2026 年 8 月 5 日 |
| 使用工具 | 大型語言模型（LLM）、Coding Agent、GitHub Pull Request |
| 應用產業 | 軟體開發與開源維護 |
| AI 完成任務 | 產生、分析、檢查與建議程式碼及文字內容 |
| 人工仍負責什麼 | 定義變更範圍、理解設計、執行審查、判斷是否合併與承擔維護責任 |
| 公開成果 | LLM 使用政策、Rust 官方說明與開發指南 |
| 台灣可用性 | 台灣團隊可在自家 GitHub／GitLab PR 流程採用相同的揭露與人工覆核做法 |
| 成本與門檻 | 需安排資深工程師審查時間、測試環境與程式碼外傳規則 |
| 成熟度判斷 | 可輔助但不可全自動 |
Rust五個團隊為主倉庫訂下LLM規則
Rust 官方說明，這份規則由專案內五個團隊採納，只管轄 rust-lang/rust 主倉庫，並未涵蓋所有 Rust 儲存庫。規則允許 LLM 回答問題、分析、摘要、潤飾、檢查、建議與協助審查；直接交給社群閱讀或合併的模型內容，則有更嚴格的條件。
公開文件、PR 說明與 GitHub 留言只要含有 LLM 內容，作者就要清楚揭露。機器翻譯、用 LLM 發現問題、用模型協助審查他人工作，也各有揭露要求。私下產生且未提交給他人閱讀或審查的內容，屬於另一種使用情境。
AI負責產碼，人仍要解釋設計與承擔審查
Rust 官方描述，完整 PR 原本是作者投入時間、理解程式碼與願意參與後續討論的訊號。LLM 讓一個人能快速產出數百行程式，也能同時送出多份表面完成度很高的 PR。維護者面對這些提交時，程式碼的格式與測試名稱已不足以判斷作者是否理解改動。
實際流程裡，AI 可以起草程式、整理說明或回應審查意見；人要說明為何選這個設計、有哪些替代方案、程式結構改變後如何維護。作者把 Review 意見交給模型，再把回答原封不動貼回 GitHub，會讓維護者多花時間確認真正的判斷者是誰。
1,281個未關閉PR與官方政策可直接核對
Rust 官方文章列出，rust-lang/rust 當時有 1,281 個未關閉 PR。這個數字反映主倉庫既有的審查工作量，不能寫成 AI 造成的結果。官方提出的問題是：產生程式碼變容易後，審查 API、相容性、安全邊界與長期維護的時間沒有同步增加。
模型生成程式碼若要提交，官方要求事先安排、避開關鍵變更、品質足夠、測試充分並完成審查，同時揭露 LLM 參與。涉及 Rust 健全性（soundness）的關鍵變更，非該領域專家的作者不得交由 LLM 產生；具備專業能力的作者也受到強烈勸阻。這些規定可直接在 Rust 的政策與開發指南核對。
台灣團隊先以一條低風險流程試跑
台灣團隊可先選一條不碰帳號權限、付款、個資與核心交易邏輯的內部工具流程。例如讓 Coding Agent 協助補測試、整理既有模組的說明，或修正已被明確定義的介面。PR 範本要列出變更目標、模型參與步驟、測試結果與作者的設計說明。
試跑期間可記錄審查等待時間、被退回原因、測試失敗與回復次數。這些資料屬媒角抵加的建議，並非 Rust 的官方指標；它們可讓團隊判斷 Agent 是否減少重複工作，或把更多確認工作交給資深工程師。
台灣團隊要先確認資料、帳號與程式碼外傳範圍
程式送進雲端模型前，團隊要先確認內容是否含客戶資料、內部 API、尚未公開的商業邏輯或金鑰。公司若使用企業版工具，仍要在內部規範寫清楚可傳送的儲存庫、可用帳號、資料保存條件與程式碼授權邊界。
開源專案與公司內部系統的責任也不同。Rust 的政策處理公開主倉庫協作；台灣企業還要依客戶合約、資安制度與資料處理要求，決定哪些程式可以交給模型處理。
安全與核心變更仍要由理解系統的人負責
模型可以協助找出重複程式、產生測試或整理文件，卻無法替團隊承擔合併後的事故、維護與對外責任。碰到身分驗證、付款、個資、資料刪除、權限提升或核心交易邏輯時，指定的工程負責人與審查者必須看懂改動、確認回復方式並留下決策紀錄。
維護者可以關閉不符合規則的 LLM PR；同時，程式碼風格不能當成使用 LLM 的證據。Rust 要求疑慮交由管理團隊私下處理，避免把「看起來像 AI」變成公開指控。
程式碼越便宜，判斷與責任越稀缺
Rust 的新規則沒有把焦點放在禁止開發者使用 AI。它處理的是另一個更靠近工作現場的問題：當一個人一天能產出多份 PR，誰來確認每份變更值不值得合併、誰能說明設計、誰在出錯後修復。
媒角抵加的判斷是，Coding Agent 的效益要同時看產出與審查負擔。能讓作者清楚說明設計、讓測試結果可重跑、讓維護者更快做出合併決定的工具，才會真正減少工程工作的總成本。
常見問題
Rust全面禁止AI寫程式了嗎？
沒有。政策允許 LLM 用於分析、檢查、建議與審查，也在特定條件下允許揭露後的 LLM 程式碼變更。政策目前只適用於 rust-lang/rust 主倉庫。
AI生成的PR一定不能合併嗎？
符合預先安排、非關鍵、品質、測試、審查與揭露條件的變更可以被接受。維護者仍可決定是否審查與合併。
團隊該怎麼開始使用Coding Agent？
先用低風險、範圍明確的任務試跑，並在 PR 裡留下模型參與步驟、作者設計說明、測試結果與審查者姓名。涉及敏感資料或核心系統的變更，先依公司資安與合約規範決定能否送進模型。
資料來源與更新紀錄
- Rust Inside Blog：rust-lang/rust is adopting an LLM policy
- Rust Forge：LLM usage policy
- 36氪／機器之心：AI写的PR堆成山，Rust已忍无可忍
更新時間：2026-08-09（Asia/Taipei）。
