寫程式碼這件事，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的那天，它才算真正開始替你扛活了。 (新智元)