前言
OpenClaw 這個 AI agent 開源專案半年內衝上超過 38 萬顆星標，成長速度是 GitHub 史上少見的。爆量湧進的貢獻裡，很多根本不是人寫的，是丟一句提示詞給 AI 生出來的。GitHub Blog 訪談了創辦人跟六位維護者，講他們怎麼在雜訊裡挑訊號、信任的標準怎麼被迫重寫。這套驗收邏輯，我做客戶案子時也會遇到。
OpenClaw 是什麼
OpenClaw 是一個掛在使用者自己裝置上、能接進既有通訊頻道的個人 AI 助理，2025 年 11 月由 Peter Steinberger 當週末專案隨手開的。沒人料到半年多後它會衝到超過 38 萬顆星標、8 萬多次分支、8 萬多次提交，是 GitHub 史上成長最快的專案之一。它爆紅的原因，是剛好卡在 AI agent 熱潮跟開源社群的交會點，大量使用者不只是拿來用，還直接跳下去貢獻程式碼，貢獻量在短時間內暴增到維護者原本的審查方式完全撐不住。
AI 怎麼改變了貢獻和社群
PR 變成「prompt request」
維護者最先卡住的是量。Steinberger 說：「我根本不叫它們 pull request（也就是貢獻者提交修改申請的機制），我叫它們 prompt request。」意思是這些提交案背後根本不是人一行一行寫出來的，是丟一句提示詞給 AI agent 生出來的。Josh Lehman 觀察到更誇張的狀況，有些貢獻者同時跑著好幾百個提交案，背後其實是一套自動化軟體工廠，把專案裡所有待解決的問題（issue）都挖過一遍去生成提交案。
這種開發方式現在叫 Vibe coding：用自然語言描述需求、讓 AI 生成程式碼，人只負責定義目標跟驗收結果。它把寫程式碼的門檻拉到很低，代價是送出來的東西沒人保證作者真的懂。
這代表維護者的工作性質整個變了。以前愁的是沒人來貢獻，現在愁的是幾百個提交案裡到底哪幾個真的有價值，篩選成本從「怎麼吸引人來」變成「怎麼在雜訊裡挑出訊號」。
幫新手貢獻者留一道門
即使量爆炸，維護者還是刻意把門開著留給生手。Steinberger 記得自己多年前第一次提交案被接受時的感覺，Vincent Koc 也觀察到，第一次貢獻就被合併的人裡有不少根本不是開發者，就是遇到一個具體的問題、有個需求的一般使用者，靠 AI agent 生出提交案，然後跟維護者你來我往把它改到能用。提交案不完美，維護者也會把裡面有潛力的想法挑出來，陪貢獻者一起磨到能用。
Agent 代勞有利有弊
Val Alexander 看過有人太迷這件事，寧可今晚不睡也要把平常要花一週的量做完；但也有像 Josh Lehman 這樣的例子，靠著讓 agent 幫自己處理瑣事，換回陪三個小孩玩的時間。Sally O'Malley 提到社群裡甚至長出一種提醒文化，維護者會主動在頻道上說要先去曬點太陽、休息幾小時，這種習慣本身就說明大家都知道 agent 有多容易讓人捨不得放手。
📖 延伸閱讀：AI Agent 是什麼？用 AI 架構解析它如何從會聊天變成會自己做事
維護者怎麼跟著調整做法
找切入點換信任
沒有一條標準路徑能讓人變成 OpenClaw 的核心維護者，每個人切進去的角度都不一樣：Vincent Koc 是從資安幫起，因為一開始怎麼樣都無法讓 Steinberger 注意到自己，才想到用資安問題切入；Brad Groux 從自己熟悉的 Microsoft Teams 整合下手；Val Alexander 則是先在語音頻道裡回答別人的問題開始累積存在感。共通點不是誰的技術最強，是誰真的把一個具體缺口補上，並且願意為那件事負責。
信任信號變成攤開思路
當提交數量本身不再能說明什麼，維護者開始看別的東西：貢獻者跟 agent 討論的完整對話紀錄，能不能證明他是怎麼想到這個提交案的；有沒有附上測試截圖，能不能證明他真的測過。Steinberger 講得最直接：「沒人在乎程式碼是不是你自己寫的，但我們在乎你是不是真的想過這個功能。」
舊的信任信號和新的信任信號，差別整理成一張表比較清楚：
| 驗收方式 | 舊信任信號 | 新信任信號 |
|---|---|---|
| 看什麼 | 程式碼風格、提交數量、帳號資歷 | agent 對話紀錄、測試截圖、思路說明 |
| 回答的問題 | 這是不是你寫的？ | 你是不是真的懂這個功能？ |
會出現這個轉變，是因為 AI 讓「寫了多少」不再等於「懂了多少」，程式碼量跟提交次數這種舊指標對維護者來說已經失去意義。
用 agent 審查 agent 寫的 code
維護者也開始借助 AI 工具反過來審查 AI 生成的貢獻：Val Alexander 現在收到 AI 產出的提交案，習慣直接用 GitHub Copilot 跑一次審查，讓它把每個檔案的改動整理清楚。Josh Lehman 觀察到更根本的變化，這是他第一次看到有專案把「維護者直接動手改提交案」變成常態，貢獻者送出提交案後，維護者不是接受或退回，是直接改到對為止。現在維護者收到提交案，多半是拉著貢獻者跟 AI 工具一起把它改到能用，單純接受或退回反而少見。
AI agent 生態變化太快，維護者的驗收標準半年就被改寫一次。
安全挑戰：從信譽到供應鏈
信譽也能被複製攻擊
貢獻紀錄本身變成可以被動手腳的東西。Vincent Koc 揭露一個手法，有人會直接複製別人的提交案，藉此累積合併次數。OpenClaw 有徽章顯示每個人合併過多少次，合併次數對維護者來說本來是一種信任信號，複製別人成果的人就是想搭這個信號的便車。維護者得多花一道工去辨認哪一份提交案是複製來的、哪一份是原創，社交信號本身反過來成了需要重新驗證的東西。
「預設安全」因人而異
安全設定沒有一體適用的答案。Steinberger 講得坦白，要在對使用者方便跟預設就夠安全這兩件事之間抓平衡，其實常常很難。工作區限制設得緊一點，有人會抱怨綁手綁腳；設得鬆一點，又可能讓專案暴露在資安事件的風險裡。這件事沒有標準答案，只能持續調整。
搞懂依賴的套件背後是誰在維護
近期幾起供應鏈攻擊事件，逼著維護者重新盤點自己引用了哪些依賴套件。Vincent Koc 說：「我們把依賴清單用細齒梳徹底檢查了一遍。」這也逼著團隊實際去減少核心依賴的數量，同時跟依賴的那些套件的維護者建立起關係。Steinberger 補充一個現況，公司預設的做法通常不是回饋貢獻，而是維護自己的分支、不太在乎上游。供應鏈安全因此變成關係問題：你知道你引用的套件背後是誰在維護嗎？
GitHub 安全開源基金怎麼幫上忙
幾位維護者不約而同提到GitHub Secure Open Source Fund（GitHub 安全開源基金，針對開源專案資安提供資金與資源的計畫）帶來的幫助不只在錢，是安全意識跟人脈。Josh Avant 提到，課程一開始主講人就要大家先去倒杯咖啡、深呼吸，這種安排把維護者這個角色最人性的一面連了起來。Josh Lehman 講的則是怎麼跟 agent 對話的能力，現在 agent 幾乎什麼事都能做，但還是得知道該提出什麼要求，這個計畫讓他有能力知道該怎麼問。對很多獨立維護大型專案的人來說，光是知道還有其他人面臨一樣的處境，就是很實際的支持。
📖 延伸閱讀：GitHub Copilot Canvas 是什麼？讓你看得見 AI Agent 的工作流程
這套驗收邏輯，我在自己做的案子裡也會遇到
AI 解析錯了也像對的
我自己做了一套教師管理系統給自己用，核心功能是打一句「今天跟小明上了代數」，Groq 就把這句話解析成結構化的課程紀錄（學生、科目、日期），自動存進資料庫。這個功能上線後最容易踩的雷，不是 AI 解析不出來，是解析錯了但看起來像對的。我帶的學生裡如果剛好有兩個名字很像，或是打「上禮拜三」這種相對時間，AI 給出的答案不一定是我真正要的那筆，系統卻會直接把它當正確紀錄存下去。跟 OpenClaw 的提交案一樣，AI 生成的東西「看起來可以用」跟「真的對」是兩回事。
看過一眼才算數
後來這套系統多加了一個環節：AI 解析完之後，先把結果攤出來讓我自己確認一眼（哪個學生、哪一科、哪一天），按下確認才真的寫進資料庫，不是解析完就直接算數。這跟 OpenClaw 維護者堅持自己審過提交案才合併是同一個道理，AI 產出的東西再怎麼流暢，送進真正會被使用的系統之前，還是要有一道人親自看過的關卡。
📖 延伸閱讀：Claude Code 指令教學｜30 個必學指令與使用情境，打造高效 AI 開發流程
常見問題 FAQ
Q1：OpenClaw 是什麼？為什麼會突然爆紅？
OpenClaw 是一個能接進使用者既有通訊頻道、跑在自己裝置上的個人 AI 助理，2025 年 11 月由 Peter Steinberger 當週末專案開始寫。它在 GitHub 上的成長速度是史上少見的，半年多內衝到超過 38 萬顆星標，主要是因為它剛好卡在 AI agent 熱潮跟開源社群的交會點，很多人願意直接參與貢獻，而不只是使用。
Q2：什麼是「prompt request」？跟一般的 pull request 有什麼不同？
Pull request 是開源專案裡貢獻者提交程式碼修改的申請，傳統上由人一行一行寫出來。「Prompt request」是 OpenClaw 維護者的戲稱，指的是貢獻者只丟一句提示詞給 AI agent、由 agent 生成整個提交案，人幾乎沒動手寫程式碼。差別在於審查的重點從「程式碼寫得好不好」變成「這個人是不是真的懂自己送出來的東西」。
Q3：我沒有工程師背景，也要擔心 AI 產出的信任問題嗎？
要擔心，但擔心的方式不一樣。你不需要懂程式碼細節，但要能講清楚這個東西為什麼這樣設計、測過哪些情況。OpenClaw 的案例剛好證明，維護者現在看重的正是這種思路說明，而不是你會不會寫程式碼，這對非工程師背景、用 AI agent 做事的人反而是機會，不是門檻。
Q4：AI 生成的系統或工作流，要怎麼驗收才不會出包？
至少做三件事：實際跑過一輪測試資料，尤其是邊界情況（同名、模糊時間、重複輸入）；把「為什麼這樣設計」的討論或筆記留下來，方便日後除錯；涉及會直接寫進資料庫或對外發送的環節，一定要留一道人工確認的關卡，不要讓 AI 解析或生成的結果直接跳過人自動存檔。
Q5：像 OpenClaw 這類 AI agent 開源專案安全嗎？能直接拿來用嗎？
可以用，但要知道自己在用什麼。這類專案的維護者自己也在講，安全設定沒有一體適用的答案，便利性跟安全性永遠在拉扯。實際使用前，先看專案有沒有持續在處理資安回報、依賴套件有沒有定期檢查，這些比星標數多不多更能反映一個開源專案值不值得信任。
總結
OpenClaw 這半年走過的路，本質上是整個開源生態在 AI agent 時代重新學怎麼建立信任：貢獻量爆了，舊的信任信號失靈了，維護者換成看思路過程跟測試證據；安全上連信譽本身都能被複製攻擊，供應鏈得重新用細齒梳檢查一遍。這套邏輯套進任何用 AI 生成成果的工作裡都成立，真正決定成果能不能用的，是有沒有人想清楚、有沒有人在送出去之前把關。我始終相信，AI 該做的是幫你精準表達想法，判斷還是要留給人。
如果你也在思考怎麼把 AI 生成的系統或工作流交付得更放心，歡迎看看我們的自動化服務怎麼設計人在迴路的把關機制。
