Claude寫完代碼不直接交了：4個Skill自查一遍，改好再找你

新智元報道

寫代碼這件事，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

編輯：元宇