太狠了！OpenClaw之父一夜屠光5000 Issue，GitHub服務(wù)器先跪了

新智元報道

編輯：犀牛 所羅門

【新智元導讀】2天搭建、不到1000美元、50個Codex并行掃描——OpenClaw創(chuàng)始人祭出ClawSweeper，一天關(guān)閉5000+無效Issue，GitHub API限流成唯一瓶頸，開源維護正式進入AI「自愈」時代。

AI產(chǎn)生的垃圾，就該AI自己來掃。

剛剛，OpenClaw創(chuàng)始人、OpenAI工程師Peter Steinberger干了一件瘋狂的事——

他花2天時間搭了一個叫ClawSweeper的工具，啟動50個Codex實例7×24小時并行掃描。

一天之內(nèi)把openclaw/openclaw倉庫里超過5000個無效Issue直接關(guān)閉，數(shù)千個還在管道里排隊等著被「處決」。

這個36萬Star的開源巨獸，積壓了上萬個Issue和PRs。

重復的、過時的、早就在main分支修好了沒人關(guān)的、AI灌水產(chǎn)生的slop——它們像數(shù)字墳場一樣堆在那里。

任何人類維護者看一眼都會頭皮發(fā)麻。

按人工處理速度，清完這些積壓大概需要整整一年。

Steinberger用AI，一天就清了一半。

有人問他這一輪掃描花了多少錢。他的回答輕描淡寫：不到1000美元。

5000多個Issue的深度審查加關(guān)閉，平均一個不到兩毛錢。

而唯一讓整套系統(tǒng)慢下來的，不是模型不夠聰明，是GitHub的API速率限制——服務(wù)器追不上AI的速度。

「冷面判官」的處決邏輯

別以為ClawSweeper是個無腦殺手。

恰恰相反，Steinberger對它的設(shè)計哲學可以用四個字概括——極致保守。

這套系統(tǒng)的核心運行在gpt-5.5上，采用high reasoning effort和fast service tier配置；每個待審條目的 Codex 審查超時為10 分鐘。

它只在以下7種情況下才會關(guān)閉一個Issue：：已經(jīng)在main實現(xiàn)、當前main無法復現(xiàn)、應歸屬 ClawHub 的 skill/plugin 而非 core、重復或已被更權(quán)威條目取代、在該倉庫內(nèi)具體但不可執(zhí)行、內(nèi)容過于混亂不可執(zhí)行、以及超過 60 天且缺少足夠數(shù)據(jù)驗證 bug。

除此之外，一律保持open。

還有一層保險，ClawSweeper不會去碰維護者自己發(fā)的條目。

它會先看 GitHub 里的身份標記，只要是項目主人、成員或協(xié)作者發(fā)的 issue，就直接跳過，不會自動關(guān)閉。

更謹慎的是，Codex 在審查時根本沒有寫權(quán)限。

它只能在只讀環(huán)境里看代碼、看上下文、做判斷，然后把結(jié)果整理成一份結(jié)構(gòu)化的 markdown 報告，存進items/ <編號> .md 。

真正的評論和關(guān)閉動作，并不會在審查那一步直接發(fā)生。

系統(tǒng)要等到進入apply_existing=true模式后，重新抓一遍最新上下文，再把快照哈希重算一次，確認這條 issue 在提案生成之后沒有發(fā)生變化，才會真正動手。

Steinberger自己人工抽檢了數(shù)百條關(guān)閉記錄，結(jié)果：準確率幾乎無誤。

README就是儀表盤

ClawSweeper最讓人拍案叫絕的設(shè)計，可能不是它的關(guān)閉邏輯，而是它的「監(jiān)控系統(tǒng)」。

傳統(tǒng)做法是什么？

搭個Grafana，配個Prometheus，弄一套精美的后臺Dashboard。

Steinberger說：不需要。README就是我的儀表盤。

ClawSweeper在運行過程中，會實時更新倉庫的README.md文件。

當前有多少open issue、本輪審查了多少條、提議關(guān)閉多少條、已執(zhí)行關(guān)閉多少條、GitHub限流到了哪一步——全部以表格形式明明白白地寫在README里。

任何人打開GitHub倉庫主頁，就能看到這個AI判官此刻正在干什么。

它讓整個清理過程變得完全透明、完全公開、完全可審計。

任何對「AI擅自關(guān)我Issue」有疑慮的貢獻者，都可以直接點進對應的items/71514.md查看Codex給出的完整審查理由。

當AI開始「自愈」

你可能會想，這不就是個自動化腳本嗎？

格局放大一點。

GitHub上有超過4億個倉庫，其中活躍的大型開源項目幾乎都面臨著同一個噩夢——Issue墳場。

Kubernetes有4萬多個已關(guān)閉Issue，Linux內(nèi)核的郵件列表積壓更是天文數(shù)字。

維護者的時間是世界上最稀缺的資源之一，而大量時間被浪費在「判斷這個Issue到底還需不需要存在」這種機械勞動上。

ClawSweeper的意義在于，它第一次在一個真實的、百萬Star級別的倉庫里證明了：用AI agent進行大規(guī)模的、保守的、可審計的Issue分診，是完全可行的。

5000多個Issue的深度審查+關(guān)閉，總花費不到1000美元。按單個Issue算，成本大約0.2美元。

而且它7×24小時不休息、不抱怨、不帶情緒。

唯一讓它慢下來的，只有GitHub API的速率限制。

從某種意義上說，這標志著開源項目從「人工維護」邁向「自愈」的起點。

未來，每一個大型開源倉庫可能都會跑著一個類似ClawSweeper的bot，持續(xù)監(jiān)控Issue質(zhì)量，自動過濾噪音，讓人類維護者只需要關(guān)注那些真正需要人類判斷的、高價值的問題。

Rate Limit是最后的防線

有個細節(jié)特別有意思。

ClawSweeper的Dashboard上赫然寫著：「State: Apply throttled」——GitHub的API限流把它卡住了。

50個Codex并行掃描的速度太快，快到GitHub的服務(wù)器開始說「你慢點，我跟不上了」。

在傳統(tǒng)軟件開發(fā)中，速率限制是為了防止攻擊。

但現(xiàn)在，它成了AI工作效率的唯一瓶頸。

不是模型不夠聰明，不是判斷不夠準確，純粹是基礎(chǔ)設(shè)施跟不上AI的速度。

這大概就是2026年最真實的寫照：管道追不上AI。

參考資料：

https://x.com/steipete/status/2047982647264059734

https://github.com/openclaw/clawsweeper