新智元報道

388個PR，180個被合併。

寫這些代碼的全是AI。

Claude之父Boris Cherny最近在X上貼出了這組數字。它們來自他過去幾周一直在做的一個「奇怪實驗」：讓Claude接管自家App的日常維護。

他說，從一些早期跡象看來，這條路也許真能走通。

實驗現場，是一個名叫「proj-claude-maintains-apps」的Slack頻道。

在這個頻道里，Claude Tag每天跑一組例行任務，覆蓋iOS、Android、桌面端、Web、CLI和Agent SDK六類環境，每條線一個獨立Routine，進展各自發進頻道的頂層線程。

它像一個真正的同事一樣，不等人派活，到點自己上班，找問題，改代碼，提PR，然後等人來審。

定期發現問題、提交修改、接受審查、再根據反饋調整任務規則，這樣一個閉環，在Anthropic內部已經轉了幾周。

工程師需要做的，只剩下一個決定是否合併的按鈕。

Claude每天上班

乾的都是髒活

Boris都給Claude安排了哪些活？先看清單。

崩潰巡檢。

在模擬器裏把App打開一通亂點，點到它崩為止，然後定位原因、開修復PR，每個PR還得附上覆現步驟和一張真值表。

Boris還在Claude的原始指令裏特意寫了一句：跑起來的必須是真的App，不許拿假的替身糊弄過去。

重複抽象合併。掃描代碼庫裏那些長得像、又不完全一樣的實現，提PR把它們併成一個。

死代碼清理。這一條最見功夫：靜態能確定跑不到的代碼直接刪；只是「疑似」跑不到的，先埋一段日誌觀察一天，確認真沒人走過，第二天再刪。

抽象泄漏修復。誰把不該露的層次露出來了，它去補。

再往下還有：清掉那些怎麼跑都通過的測試、揪出時好時壞的測試到底壞在哪、把全量上線的開關從代碼裏拿掉、那些做完就被遺忘的內部功能，按使用量決定是發出去還是刪掉。

先加個日誌觀察一天再刪，這是老工程師纔有的手感。

這張清單從頭掃到尾，Claude接管的十一項活，沒有一項是「做個新東西」。

全是平時最不願意幹、幹完也不出績效、拖到下個季度也沒人催的那種活。

寫代碼變便宜了

審代碼就變貴了

一個團隊幾周內多出388個AI生成的PR，誰來看？

Anthropic在今年3月的Code Review公告裏給過一個數字：過去一年，公司人均代碼產出增長了200%，代碼審查隨之成了瓶頸。

而且，這並非Anthropic一家的問題。

工程數據平台Faros AI在2026年放出一份報告，兩年遙測，覆蓋2.2萬名開發者、4000多個團隊。

Faros AI《The Acceleration Whiplash》：高AI採用度下，人均epic完成量漲66.2%，每周部署數反而降11.7%。

產出側確實漲了：人均完成的epic數漲66.2%，任務吞吐漲33.7%，PR合併率漲16.2%。

但每周真正部署上線的次數，降了11.7%。

合併得更多，發出去的反而更少。中間的環節，都堵在審查上。

代價，還得開發者來扛。

落在每個開發者身上的bug數，漲了54%；

每個PR對應的線上事故漲242.7%；合併進去又被刪掉的代碼，比值漲了861%；PR的平均體積漲51.3%；

最要命的是等待。

等一個人來審的中位時長，漲了441.5%，還有多出31%的PR，一次審查都沒經過就合了進去。

這些數字堆下來，就是開發者的一天：按一下按鈕，五分鐘生成上千行；然後花掉一整個下午，把這上千行一行一行讀完。

寫代碼那部分被AI拿走了，但看代碼那部分還得開發者來幹。

Code Review就是為這個問題造的，Anthropic公開過一組效果和成本數字：

上線之前，只有16%的PR能拿到實質性的審查意見，上了之後這個數字是54%。

超過1000行的大PR，84%能被查出問題，平均7.5個；50行以下的小改動，比例降到31%，平均0.5個。

工程師標記為「找錯了」的發現不到1%。

審一個PR平均要跑20分鐘，燒掉15到25美元的token。

這份公告裏還提到：這套系統不批准PR，批准是人的事。

它劃定的邊界是：AI可以主動找問題、改代碼、開PR，全程不用人批准。但每一處變更都停在PR裏，合不合進主分支、上不上線，最後一下點確認的必須是人。

Boris在帖子裏寫了下一步：想辦法降低這類機械性改動的合併成本。

他要降的是合併成本，因為卡點已經不在生成那一頭了。

Boris修的不是PR

是Routine

再看這套系統是怎麼搭起來的，三個部分分工很清楚。

Claude Tag是入口。它掛在Slack頻道里，被@時響應，也會在權限和指令允許的範圍內主動接活。

Anthropic在8月13日剛給它做過一次升級，讓它結合整個頻道的上下文判斷什麼時候該出手、什麼時候該不動。

Routines（例行任務）是執行層。

這是4月14日推出的功能：一次性配好提示詞、代碼倉庫和連接器，之後按時間表跑、由API調用觸發，或者響應GitHub事件自動啓動。

它跑在Claude Code的雲端設施上，不依賴本地設備。

Claude Code Routines運行機制：定時、API調用與GitHub事件三種觸發方式，跑在雲端。

Claude Code Review是審查層，人類是批准層。

四層串起來，纔有了那個每天早上自動開工的頻道。

但最值得學的，是Boris的調優方式。

某一類PR老是不過關，他不去一個一個改那些失敗的PR，而是回頭改生成它們的Routine，然後觀察接下來幾天的表現。

有時候一類任務要連着調好幾天，才穩下來。

一句話：不修結果，修規則。

提示詞在這裏不再是一次性的輸入，而是一套要長期運維的資產：寫好、上線、觀察、迭代，跟養一個線上服務沒區別。

這也是為什麼這套東西能越跑越順。

每一次調整都沉澱進規則裏，第二天生成的那批PR裏，就會少幾個不該出現的。

想復刻

先過這幾關

工具這一層是公開的。

Routines對Pro、Max、Team和Enterprise開放，Pro每天5個，Max 15個，Team和Enterprise 25個，在claude.ai/code裏點幾下就能建，或者在CLI裏敲一個/schedule。

但真正的門檻在別處：

倉庫權限敢開到什麼程度，測試覆蓋兜不兜得住，有沒有能跑真機的模擬器環境，審查按次燒錢喫不喫得消，以及最難的：有沒有人願意為一個AI提的PR按下合併鍵。

同樣是這個月，Rust項目剛給AI貢獻立了規矩：AI生成的代碼得事先打招呼、不能碰關鍵路徑、測試要充分、還得如實披露用了大模型；涉及soundness的關鍵改動，強烈不建議交給大模型生成。

最要緊的，是維護者沒有義務審查AI提交的PR，可以直接關掉。

個體開發者能從Boris這個實驗裏抄走的，也是這一條規則：先把驗收條件最明確的那類活兒交出去。

能驗出對錯的活，AI現在接得住：這個操作能不能把App點崩、兩處寫法是不是同一件事、這條測試是不是永遠不會掛，都能當場驗一遍。

那些說不清怎麼算做對的，AI還接不住：「這個抽象層算不算過度設計」「這次重構方向對不對」，驗收標準全憑品味，寫不進提示詞。

所以它接走的第一批活兒，並非創造，是打掃。

生成側已經不缺產能了，缺的是審查側：誰先看、哪些重複、以及最後誰簽字。

工程師的身價，也換了一套算法：以前看寫得多快，現在看審得多快。