180,000 顆星與 150 個開放 PR：AI 貢獻者已經在排隊
開源專案最容易忽略的一個事實是：你的貢獻者待審清單裡，已經有 AI 了。GitHub 官方部落格的維護者專訪標題直白地問：你的貢獻者已經是 AI 優先，你的專案準備好了嗎？受訪者是 AutoGPT 維護者 Nicholas Tindle；專訪開頭給出的數字是：受訪當時，這個專案有超過 180,000 顆星、約 150 個開放 PR，其中一大塊至少有一部分是 AI 代理寫的。
AutoGPT 是什麼？官方儲存庫自述為讓使用者以白話描述成果、建立、部署並執行完整工作流的 AI 代理平台。換句話說，這個專案本身就是做代理的，它的貢獻者也大量使用代理，是最徹底吃自家狗糧的專案之一。它遇到的問題，就是所有熱門開源專案正在或即將遇到的問題。
面對這種待審清單，維護者有兩種極端選擇：全盤拒絕 AI 貢獻，或者照單全收然後被審查工作淹沒。專訪呈現的 AutoGPT 路線是第三種：不假設貢獻者是人，而是把儲存庫當成一個「代理也會經過」的環境重新設計——指令放在代理會讀到的地方，驗證交給自動化門控，需要真人的環節用流程卡位。這套做法可以拆成四道門：PR 範本、測試計畫、覆蓋率門檻、CLA 簽署。
起點：代理不會主動去讀文件
整套設計的起點，是一個反直覺的觀察：AI 代理不會主動去讀你的文件。傳統開源專案把貢獻規則寫在 CONTRIBUTING.md、wiki 或文件網站裡，預設貢獻者會先讀再動手。但代理的工作方式不同——它收到任務、掃描眼前可見的脈絡、開始改程式碼。放在遠處的文件，對代理而言等於不存在。
所以 AutoGPT 把指令搬進代理的必經之路：AGENTS.md 與技能檔，而且放在程式碼目錄旁邊。專訪對兩者的分工有一句精準描述：AGENTS.md 的作用範圍限於單一目錄，而技能可以在目錄之外被發現。這解決了兩個不同的問題：目錄內的規則——這個資料夾怎麼建置、怎麼測試——用 AGENTS.md 就地生效；跨目錄、可重複使用的完整流程，交給技能檔，讓代理在任何位置都找得到。
這不是 AutoGPT 的私有格式。AGENTS.md 已是開放標準，標準官網自述為引導編碼代理的簡單開放格式、已有超過 6 萬個開源專案採用，並把它比作給代理讀的 README。AutoGPT 自己的用法可以在儲存庫根目錄的 AGENTS.md 逐字看到：標題是「AutoGPT Platform Contribution Guide」，開頭明言這份指南是為修改 autogpt_platform 資料夾的編碼代理提供脈絡，接著是目錄結構總覽。規則不僅存在，而且就貼在代理要動的目錄旁邊。
第一道門：PR 範本，不符合就自動關閉
第一道門最便宜，也最直接。AutoGPT 強制使用 PR 範本，並在給代理的指示中明講：不符合範本的 PR 會被自動關閉，說法是「零猶豫」（with zero hesitation）地關閉。
這道門的聰明之處在於位置。範本不是文件，它直接出現在開 PR 的流程裡——代理要完成「提交 PR」這個動作，就必須經過範本欄位。你不需要說服代理去讀規則，規則就長在它要填的表格上。對人類貢獻者，這道門是最低限度的格式要求；對代理，它是一個明確的、可程式判斷的通過條件。
自動關閉之所以必要，是因為代理的失敗模式與人不同。人類貢獻者漏填欄位，多半是疏忽，提醒一下就會補上；代理則可能穩定地、大規模地產出同樣不合規的 PR。與其讓維護者逐一回覆，不如讓規則自己執行——門檻清楚、執行零成本、對所有貢獻者一視同仁。
第二道門：測試計畫觸發的 test PR 技能
範本裡有一個欄位特別關鍵：測試計畫（test plan）。專訪描述了一個巧妙的設計：範本的措辭本身就會觸發一個名為「test PR」的技能——這個技能會把整個應用跑起來、在取得權限後安裝代理用的瀏覽器，然後對這項貢獻執行自動化驗證。
換句話說，測試不再是「希望貢獻者自己測過」的道德呼籲，而是一個被寫進流程的觸發器。代理填寫測試計畫的動作，同時啟動了對它自己成果的檢查。這正是前述技能檔分工的實際應用：「測一個 PR」需要環境、步驟與權限，是一段完整流程，不適合塞在單一目錄的 AGENTS.md 裡，所以做成跨目錄可發現的技能，讓任何一個 PR 都能喚起同一套驗證。
值得注意的是權限設計：安裝瀏覽器這一步是在取得權限之後進行的。讓代理執行驗證，不等於給它無限制的執行環境；能自動化的部分自動化，需要授權的部分仍然明確卡關。這條界線在代理大量進入開發流程的現在，比效率更值得先想清楚。
第三道門：CI 覆蓋率門檻
第三道門在 CI。專訪提到 AutoGPT 把 Codecov 的覆蓋率門檻設為必要檢查，後端的規則是：覆蓋率達到 80% 才允許開啟 PR。
覆蓋率門檻對代理特別有效，原因很實際：代理寫程式很快，但主動補測試的傾向取決於指示是否明確。把覆蓋率變成開 PR 的前置條件，等於把「你要寫測試」從建議變成硬性規則——沒有測試，門就不開。這也是四道門裡最客觀的一道：通過與否由數字決定，沒有解釋空間，維護者不必逐一判斷，代理也不必猜測標準在哪裡。
當然，覆蓋率是必要條件而非充分條件。80% 覆蓋率不保證測試品質，更不保證程式碼符合專案方向。它的角色是把一批明顯不合格的 PR 擋在門外，讓後面的人工判斷聚焦在真正需要人類的問題上。
第四道門：CLA 簽署成了人類探測器
第四道門本來不是為 AI 設計的。CLA（貢獻者授權協議）簽署是法務需求，但它的流程特性意外地有用：簽署需要瀏覽器、需要 OAuth 登入流程——這兩件事恰恰是目前的代理做不到或不該做的。於是 CLA 簽署在實務上成了一個人類探測器：PR 要走完法務流程，背後就得有一個真人。
這道門的意義不在於技術強度，而在於流程位置。前三道門驗證的是 PR 的品質，第四道門確認的是責任的主體。AI 代理可以寫程式、跑測試、過覆蓋率門檻，但在「誰為這份貢獻負法律責任」這個問題上，流程設計迫使一個人站出來。
必須誠實地說，這是摩擦，不是身分證明。真人簽完 CLA 之後，後續的 PR 仍可能大量由代理完成；它增加的是成本與可歸責性，而不是絕對的人機界線。但作為一個幾乎零額外開發成本的副產品，它已經把「完全無人參與的貢獻鏈」擋在門外。
門控之後：PR 變可用，路線圖仍是人的判斷
四道門疊起來，效果是什麼？專訪給出的方向很清楚：AI 提交的 PR 從「不可用」變成「可用」。所謂不可用，是指維護者收到的是格式混亂、未經測試、無法驗證的改動，審查成本比自己重寫還高；所謂可用，是指 PR 已通過範本、測試、覆蓋率與法務四道門，維護者拿到的是一份機器已經檢查過的改動。
但「可用」不等於「符合路線圖」。一個 PR 可以格式完美、測試齊全、覆蓋率達標，卻在解決一個專案根本不打算解決的問題，或採用一個維護者不打算接受的架構。這種判斷沒有門控可以代勞——它需要對專案目標的理解，而這正是目前代理最缺的能力。門控做的，是把維護者的時間從機械檢查（格式、測試、覆蓋率）解放出來，集中花在只有人能做的判斷上。
對維護者來說，這是一次工作內容的移轉：審查 AI 的 PR，越來越不像改作業，越來越像當產品負責人——你不逐行挑錯，你決定方向。
其他專案能直接搬走什麼
AutoGPT 的具體工具鏈——技能系統、代理瀏覽器——是它自己的，但這套思路的四個元件都是可移植的。
第一，寫 AGENTS.md，而且按目錄寫。標準是開放的、超過 6 萬個專案在使用；從根目錄開始，為結構複雜的子目錄補上各自的作用範圍。個人開發者這一側，把說明檔寫進儲存庫的習慣，與終端機編碼代理的起手用法是同一件事：規則跟著程式碼走，而不是留在對話裡。
第二，把規則放進流程，而不是文件。範本會被填，文件不會被讀。任何你希望代理遵守的要求，都應該出現在它完成任務的必經路徑上：PR 範本、issue 範本、CI 的錯誤訊息。
第三，把覆蓋率門檻設為必要檢查。這是一道純數字、零裁量空間的門，對人對代理一視同仁，成本最低、爭議最小。
第四，善用既有的法務流程當人類探測器。如果你的專案已經有 CLA，你已經有一個免費的真人確認點。
最後是這套經驗的邊界。這是一個專案、一次專訪的經驗，不是基準測試：約 150 個開放 PR 是受訪時的快照，專訪並沒有提供門控上線前後的量化對比。AutoGPT 有平台團隊與完整的 CI 基礎設施，小專案未必負擔得起同等投資；後端 80% 這個數字也綁定它的程式結構，直接照抄沒有意義，重要的是「設一個客觀門檻」這個動作。值得追蹤的後續是：GitHub 是否把代理貢獻的身分與標記做成平台原生功能——在那之前，每個熱門專案都得像 AutoGPT 一樣，自己把門建起來。
