北京
新智元報道
寫代碼這件事，AI已經替你干了。可驗收這件事，還壓在你身上。
一段代碼到底寫沒寫對，AI不負責，最后還得你自己一行行看過去：這道坎，卡住了許多人。
最近，Anthropic把AI驗收也做進了循環。
他們讓Claude寫完代碼之后，不直接交差，而是自己接著跑四道檢查：
/code-review先揪bug，/simplify把冗余的實現清理干凈，/verify做一遍端到端驗證，如果這次動了界面，再用/design對著DESIGN.md核一遍視覺。
四道跑完，才算交付。
7月22日，Claude Code團隊公開了這套內部的「驗證循環」。
換句話說，Claude寫完代碼，會自己先找錯，改到沒問題再回來找你。
這意味著AI開始從「會寫代碼」，進化到「會檢查自己寫的代碼」。
智能體干活的閉環
多了一個驗證
Anthropic給這套東西起了個名字，叫驗證循環（verification loop）。
官方的定義很簡單，它是一個Claude檢查并嘗試修復自己工作的迭代過程。
它改動的，是智能體干活的閉環。
以前是「收集上下文→執行動作→人工檢查」，最后那一步卡在人身上：AI把活兒交出來，你得自己一行行看。
現在這條線，被拉長成了「收集上下文→執行動作→自動驗證→修復→再驗證」，檢查和修復，被塞回了循環里面。
Anthropic官方的智能體循環示意圖：提示進來后，Claude收集上下文、執行動作、驗證結果，驗證不過就打回重跑，通過才返回。
有些檢查Claude本來就會做。代碼庫里那些確定性的信號，比如type checker、linter、跑測試、運行時報錯，它讀得懂，也會順手改掉。
真正麻煩的是另一類：界面改得對不對、用戶流程順不順、這次改動有沒有埋下看不見的坑……
這些過去只能靠人盯著，同樣的檢查做上幾十上百次。
Anthropic的解法，是把你每次都要手動做一遍的那些檢查，一條條寫下來，封裝成Skill，交給Claude在每次任務里自動執行。
過去幾十年，軟件工程所有的流程：寫需求、做規劃、層層評審、開不完的會，本質上都是因為：寫代碼太慢，工程師的時間太值錢。
可當AI把寫代碼這一環變快、變便宜，這個前提就不復存在了。
Claude Code團隊自己的判斷是：瓶頸沒有消失，它只是轉移了：從「寫代碼」轉移到了驗證、代碼評審、安全這些環節。
代碼生成得太快，新的問題變成了這些代碼到底對不對，誰來維護，人還跟不跟得上審代碼的節奏。
面對這個新瓶頸，Claude Code團隊先在自己身上做了實驗。
Claude Code團隊
每天在用的4個自查Skill
Claude Code團隊內部，每天都在用這四個自查的Skill。
/code-review，專審代碼改動，把潛在的bug揪出來，順帶給一份review意見。
這等于給自己配了個不知疲倦的審稿人。
/simplify，清理這次改動的diff，把繞來繞去的復雜實現刪掉，讓結構變簡單。
它不給你加功能，而是清掉冗余、簡化實現，把日后的維護成本向下壓。
這一點很重要，也最見功力。多數人寫代碼都是往上堆，能主動做減法的工具，尤為難得。
/verify，做端到端驗證，真刀真槍跑一遍，確認功能是真的完成了，而非「看起來完成了」。
/design，只在動了UI時上場。它對著倉庫里的DESIGN.md，逐條核對你的視覺實現有沒有跑偏。
這4個Skill不是憑空長出來的。
它們的底層，Claude Code已鋪了一層現成的驗證支持：
內置的/verify能把應用跑起來觀察變化，你在CLAUDE.md里寫清楚構建和測試命令，它就照著執行；還有專門在PR上做多智能體審查的Code Review、能在每次提交時自動開火的GitHub Actions。
團隊那4個Skill，等于在這層通用地基上，又加了一道自己的工序。
怎么寫一個自己的驗證Skill？
Anthropic給的辦法也很簡單：
把你每次都要手動做的那一步，用大白話寫下來，就當你在給一個第一天入職的新同事交代注意事項。
要是你連這步檢查該怎么描述都卡殼，可以先讓Claude給一版通用最佳實踐，再在上面改。
你的版本大概率會在某幾個點上跟通用做法不一樣，而那幾處不一樣，恰恰就是最該被記下來的東西。
檢查也不一定非得是「感覺對不對」這種模糊判斷。
舉個例子：任何刪掉數據庫字段、卻沒配套數據遷移步驟的改動，一律打回。這是一條通用linter永遠抓不到、卻是你項目專屬的「土規矩」。
凡是你一直靠手動死盯才守得住的紅線，都值得寫成一個循環。
寫完怎么辦？
丟給skill-creator讓它反過來采訪你幾句，或者干脆自己往.claude/skills/里扔一個Markdown文件。
最簡單的驗證Skill，就是幾行說明加一段正文。然后在一個新任務上調一次，確認這步檢查真的跟著跑了，不對再改。
碰到那些你改不動的Skill，比如內置的、插件托管的，也有應對辦法：寫一個外殼Skill，讓它先調原來的，再調你的驗證。繞一下，照樣把檢查嵌進去。
驗證不是一刀切
它有4檔
檢查封裝成Skill之后，下一個問題是：這玩意兒什么時候觸發？
Anthropic給了4檔自動化程度，從松到緊。
Standalone：你自己想起來，手動調一下。
Embedded：嵌進某個任務流程，跟著一起跑。
Chained：好幾個驗證Skill串成一條鏈，一個接一個自動跑完。
On every PR：最狠的一檔，每次提交代碼都自動過一遍。
官方管中間這層躍遷，叫「從習慣到契約」。
本來是「我每次都記得在/simplify后面補跑一次/verify」的個人習慣，串成鏈之后，就變成「/simplify跑完，自動就調/verify」的固定契約。
整條鏈自己把開發循環走完，只在需要你拍板時才回來找你。
鏈條拉得越長，可靠性越高，但官方特意囑咐了一句：鏈式驗證會實打實地燒token。
所以別一上來就把所有檢查都設成PR gate、每次提交必卡，正確姿勢是先看它穩不穩，再一步步往上加。
4個Skill背后
AI編程正在換賽道
4個Skill背后，AI編程的競爭，正在從生成轉向驗證。
Claude Code之父，也給過同一個判斷。
今年6月9日，他發推說：在強大模型能長時間自主運行的時代，自我驗證是讓模型跑得更久、結果更貼近你預期的關鍵：你不必守在一旁頻繁盯著Claude，就能把更多活兒交出去。
說白了，驗證做得越扎實，智能體才敢放開了跑；跑得越久，人越省心。
過去我們靠提示詞，可它也有個天花板：只解決這一次的任務，下次還得從頭再來。
這里先糾正一個常見的誤解：Skill不是一段Markdown提示詞。
它是一個能力模塊，里面裝著指令、文件結構、腳本、工具調用、配置和一整套工作流程，是把團隊的檢查步驟、設計規范、踩過的坑，沉淀成一個隨叫隨到的包，Claude需要時自己去翻。
更關鍵的是，Skill正在從Claude Code的一個特性，變成跨廠商的開放標準。
據業界的梳理，GitHub Copilot、Cursor、OpenAI Codex、Gemini CLI都已經采用同一套格式。
這意味著，你為團隊沉淀的那些Skill，不會被鎖死在某一家工具上，它會把團隊的經驗、規范、檢查流程沉淀下來，變成一塊能反復調用的能力。
這也引出這樣一個扎心的現實：同一個Claude，不同團隊用出來的效率，可能差出好幾倍，造成這個差距不在模型，而在于工作流：
你有沒有把檢查寫成Skill，有沒有搭起驗證循環，有沒有讓智能體自己把反饋閉環跑通。
說到底，智能體的能力，就是一道加法題：模型，加工具，加驗證機制，加工作流程。
模型這一項，各家越來越接近。真正拉開距離的是后面那三項，它們全掌握在用戶手里。
當然，這篇博客所展示的，是AI輔助開發的流程優化，而非「AI已經能獨立寫軟件」。它仍離不開工程師，也沒法脫離人去做生產級交付。
因此，它不是智能體要來搶人類工程師的飯碗，但方向已經很清楚了。
過去，我們一直在教AI怎么寫代碼，現在要開始教它驗證自己寫得對不對。
對于一個天天要用AI寫代碼的人來說，等到「下班前還得手動復查一遍」這件事終于能安心交給AI的那天，它才算真正開始替你扛活了。
參考資料：
https://claude.com/blog/building-verification-loops-in-claude-code-with-skills
https://claude.com/blog/getting-started-with-loops?utm_source=chatgpt.com
編輯：元宇
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
