Claude Code 實戰：讓 AI 驗證結果，形成反饋閉環，親測提效
整理版優先睇
透過驗證閉環，讓 Claude Code 自我檢查與修復，將代碼質量提升 2-3 倍
呢篇文章係作者彭濤分享佢用 Claude Code 實戰嘅經驗。佢發現雖然 Claude 寫代碼好叻，但成日自信交出有 bug 或兼容問題嘅代碼，要手動測試再來回修改，浪費時間。佢提出一個關鍵思路：唔好淨係當 Claude 係寫代碼工具，而係要佢自己驗證結果，形成「寫完 → 驗證 → 失敗 → 修復 → 再驗證」嘅閉環。整體結論係建立呢個閉環可以令代碼質量明顯提升，而且有幾種實際方法做到。
作者先解釋點解驗證咁重要——冇驗證嘅話，問題要等到手動測試先發現，來回改動好低效。然後佢列出常見嘅驗證方式：運行測試、構建檢查、Lint 檢查、瀏覽器測試同手動確認。關鍵係要根據任務類型揀合適方式。
之後佢詳細介紹四種實作驗證閉環嘅方法：直接喺指令加驗證要求、用 Subagent 封裝驗證邏輯、用 Stop Hook 自動驗證、同埋用 Playwright 或 Claude in Chrome 做瀏覽器自動化測試。作者個人偏好 Subagent，因為可以控制驗證時機，而 Stop Hook 適合每次改動都要驗證嘅工作流。最後佢總結冇驗證嘅 Claude 只係「寫手」，有驗證先似「工程師」。
- Claude Code 寫完代碼後常帶 bug，需要驗證閉環先可以將質量提升 2-3 倍。
- 驗證方式包括運行測試、構建檢查、Lint、瀏覽器測試、手動確認，要按任務揀。
- 直接喺指令加驗證要求最簡單，但每次都要寫容易遺忘；Subagent 可固化驗證邏輯，靈活性更高。
- Stop Hook 可實現自動驗證，但只適合每次改動都要驗證嘅場景，否則會浪費時間。
- 瀏覽器自動化測試（Playwright / Claude in Chrome）係前端 UI 驗證嘅關鍵，建議用 Subagent 封裝成專用工具。
Stop Hook 自動驗證配置
喺 claude_code_config.json 加入以下配置，每次 Claude 完成響應後自動執行測試指令：{"hooks":{"Stop":[{"hooks":[{"type":"command","command":"cd /你的項目 && npm run test 2>&1 | head -50"}]}]}}
內容片段
{ "hooks": { "Stop": [ { "hooks": [ { "type": "command", "command": "cd /你的項目 && npm run test 2>&1 | head -50" } ] } ] }}點解驗證閉環咁重要
平時用 AI 編程嘅朋友應該體會到，Claude 會好自信咁俾一段代碼，但可能隱藏 bug、跑唔通或者同項目唔兼容。如果冇驗證，呢啲問題要等你手動測試先知，然後再同 Claude 來回修改，浪費唔少時間。
Claude 寫完代碼自己跑測試或檢查效果，發現問題自己修，修到啱先話你知，你拎到嘅係已經驗證過嘅結果。
作者指出，關鍵係將「寫完 → 驗證 → 失敗 → 修復 → 再驗證」呢個循環自動化。冇驗證嗰陣，Claude 只係「寫手」；有咗驗證，先似返個「工程師」。
四種實戰驗證方法
作者分享咗四種令 Claude 自我驗證嘅方式，各有優劣，可以按情境組合使用。
- 1 直接下達指令：喺 prompt 直接寫明驗證要求，例如「完成後請驗證：1. 運行 npm run test。2. 運行 npm run build。如果失敗就分析原因並修復」。好處係靈活，但每次都要寫，容易忘記。
- 2 用 Subagent 驗證：將驗證邏輯封裝成 Subagent，例如 verify-work 或 verify-ui。用嘅時候只需要講「幫我實現呢個功能，完成後用 verify-work 驗證一下」。驗證喺獨立上下文執行，唔會搞亂主對話。
- 3 Stop Hook 自動驗證：喺 claude_code_config.json 配置 Stop Hook，每次 Claude 完成回應後自動跑測試。適合每次改動都要驗證嘅工作流，但未必所有回應都需要驗證。
- 4 瀏覽器自動化測試：前端 UI 需要用瀏覽器實際檢視效果。可以用 Playwright MCP 或 Claude in Chrome 打開瀏覽器、操作頁面、擷取截圖。Playwright 適合 API 用戶，Claude in Chrome 可以用已登入賬號狀態。
作者個人偏好用 Subagent 控制驗證時機，Stop Hook 只用嚟發通知，唔會用嚟自動跑測試。
佢日常開發主要用 verify-work 代理，前端 UI 改動會單獨調用 verify-ui，重要改動就喺指令明確要求驗證。
實戰經驗與工具取捨
作者根據自己嘅經驗，分享咗點樣揀選驗證方式。如果項目有單元測試，直接跑測試最直接；構建檢查發現類型錯誤；Lint 保證代碼風格；瀏覽器測試針對 UI；手動確認視覺效果。
關鍵係根據任務類型選擇合適驗證方式，唔好一刀切。
- 後端邏輯、工具函數：適合用單元測試驗證。
- 幾乎所有代碼改動：適合用構建檢查同 Lint。
- 前端 UI 改動：必須用瀏覽器實際測試，Playwright 或 Claude in Chrome 係必備。
- 視覺效果、用戶體驗：冇得自動化，一定要自己用嚇感受嚇。
如果而家仲未加入驗證環節，建議由最簡單嘅開始：就喺指令加一句「完成後跑嚇測試」。然後再考慮用 Subagent 或者 Hook 自動化。
㩒上面張卡關注我
Claude寫code能力無可否認仲係大佬級，如果俾Claude一個驗證工作嘅方式，等佢有個反饋閉環，最終結果嘅質素可以提升2-3倍。
算係一個提升效率嘅小技巧。
好似用Chrome擴充功能測試每個改動，開瀏覽器、測試UI、發現問題就不斷執返好，直到code正常運作。
如果之前淨係將Claude當做一個寫code嘅工具，寫完code自己測試。而家可以轉個諗法，諗辦法等Claude自己驗證，形成閉環。
點解驗證咁重要
成日AI編程嘅朋友應該有體會，佢會好有信心咁俾你一段code，但呢段code可能有bug、可能行唔通、可能同項目其他部分唔兼容。
如果冇驗證，呢啲問題要等你手動測試先發現。發現問題再叫Claude執返，執完再測試，來回幾轉測試時間都幾浪費。
如果Claude寫完code自己行嚇測試或者檢查嚇效果，發現問題自己執返，執到啱先話你知。你拎到嘅係已經驗證過嘅結果，會比較省心，體驗感都會好啲。
驗證方式分享
唔一定適合每一種情況，大家成日用咩方式檢驗AI編程嘅結果，歡迎留言分享嚇。
比如
行測試：最直接嘅驗證方式。如果項目有單元測試，行一次測試就知code啱唔啱。適合後端邏輯、工具函數呢類有明確輸入輸出嘅code。
Build檢查：行build命令檢查能否成功編譯。可以發現類型錯誤、語法錯誤、依賴問題。適合幾乎所有code改動。呢種係比較基本嘅。
Lint檢查：行eslint/prettier檢查code規範。可以發現風格問題、潛在嘅code質素問題。
瀏覽器測試：用Playwright或Claude in Chrome開瀏覽器，實際操作頁面驗證功能。適合前端UI改動。
手動確認：有啲嘢冇得自動驗證，例如UI嘅視覺效果、用戶體驗。呢啲就必須要自己用嚇感受嚇。
關鍵係根據任務類型揀啱嘅驗證方式，唔係一刀切。
方式一：直接落指令
最簡單嘅方式係俾Claude嘅指令入面直接講明驗證要求。
比如：
幫我實現用戶註冊功能。
完成後請驗證：
1. 運行 npm run test 確保測試通過
2. 運行 npm run build 確保構建成功
3. 如果測試失敗，分析原因並修復
最後告訴我驗證結果。
呢種方式靈活，可以根據具體任務自訂驗證內容。缺點係每次都要寫，容易唔記得。
方式二：用Subagent驗證
將驗證邏輯封裝成Subagent，需要嘅時候叫佢。Claude Code進階玩法之Subagent，俾自己配一個專屬AI助手團隊
之前介紹過verify-work同verify-ui兩個代理。verify-work係通用嘅驗證代理，可以跟據檔案類型自動揀驗證方式；verify-ui專門做前端UI測試，可以用Playwright開瀏覽器驗證。
用嘅時候可以話：
幫我實現這個功能，完成後用 verify-work 驗證一下
或者功能實現完咗之後單獨叫：
用 verify-ui 測試一下剛才改的頁面
Subagent嘅好處係驗證邏輯固化咗，唔使每次寫。而且驗證喺獨立嘅上下文執行，唔會搞到主對話好長。
方式三：Stop Hook自動驗證
如果想等每次Claude完成都自動驗證，可以用Stop Hook。玩轉Claude Code Hooks：等自動化滲透到每個環節
{
"hooks": {
"Stop": [
{
"hooks": [
{
"type": "command",
"command": "cd /你的項目 && npm run test 2>&1 | head -50"
}
]
}
]
}
}
每次Claude完成響應，自動行測試。如果測試失敗，Claude可以見到失敗信息，可以繼續執返。
呢種方式最自動化，但有個問題：唔係每次響應都需要驗證。你可能只係問個問題，冇必要行測試。所以我個人傾向用Subagent，可以控制幾時驗證。
如果你嘅工作流係每次改動都要驗證，Stop Hook會好方便。如果驗證需求唔固定，Subagent更靈活。
方式四：瀏覽器自動化測試
前端UI嘅驗證需要實際睇頁面效果。
Claude Code支援嘅瀏覽器自動化方式：
Playwright MCP：經MCP協議連接Playwright，可以開瀏覽器、導航頁面、㩒元素、填表單、攞頁面截圖。適合API用戶，唔需要Claude賬號，好似我同我哋團隊而家一直用緊嘅 aigocode.com 中轉。
Claude in Chrome：Anthropic官方嘅Chrome擴充功能，Claude Code可以直接控制你嘅Chrome瀏覽器。好處係可以用你登入咗嘅賬號狀態，測試需要登入嘅頁面好方便。需要開通會員。
我用Playwright比較多。
日常開發主要用verify-work代理。佢可以跟據檔案類型自動判斷用咩驗證方式，大部分情況夠用。
前端UI改動單獨叫verify-ui，等Playwright開瀏覽器實際睇嚇效果。
特別重要嘅改動，喺指令入面講明驗證要求。
Stop Hook我目前淨係用嚟發通知，冇用嚟自動行測試。主要係覺得唔係每次響應都需要驗證，手動控制更靈活。
成個邏輯就係咁：
寫代碼 → 驗證 → 失敗 → 分析原因 → 修復 → 再驗證 → 成功
關鍵係將「失敗 → 執返 → 再驗證」呢個循環自動化。
小結
冇驗證嘅時候，Claude似個淨係寫唔理啱唔啱嘅「寫手」。有咗驗證，Claude就越嚟越有工程師嘅意思。
具體用邊種驗證方式唔重要，重要係形成閉環：寫完 → 驗證 → 發現問題 → 執返 → 再驗證。呢個循環行得順，產出嘅code質素會明顯提升。
如果你而家用Claude Code仲未有驗證呢個環節，建議由最簡單嘅開始，就加一句指令：完成後行嚇測試。再考慮用Subagent或者Hook將佢自動化。
歡迎關注，呢個賬號仲會持續分享更多出海工具、實戰經驗、踩坑記錄。
關於編程工具使用，推薦第三方共享平台 aigocode.com，支援Codex / Claude Code / Gemini 3三大頂尖模型。https://aigocode.com/invite/K68YB6K7 經呢條連結註冊可以得到 5% 首單充值福利！！
由海外公司註冊到Stripe收款，行曬出海收付款成個流程（實戰分享）
出海效率提升：一個Skill等Claude Code接入你嘅NotebookLM知識庫
點擊上方卡片關注我
Claude 代碼能力毋庸置疑還處於大哥級別，那如果再給 Claude 一個驗證工作的方式，讓它有一個反饋閉環，最終結果的質量可以提升 2-3 倍。
算是一個提效的小技巧。
比如用 Chrome 擴展測試每一個改動，打開瀏覽器、測試 UI、發現問題就迭代修復，直到代碼正常工作。
如果之前只是把 Claude 當作一個寫代碼的工具，寫完代碼自己測試。現在可以換個思路，想辦法讓 Claude 自己驗證，形成閉環。
為什麼驗證這麼重要
平常經常AI編程的朋友應該有體會，它會很自信地給你一段代碼，但這段代碼可能有 bug、可能跑不通、可能和項目的其他部分不兼容。
如果沒有驗證，這些問題要等你手動測試的時候才能發現。發現問題再讓 Claude 修，修完再測試，來回這幾輪測試的時間也挺浪費的。
如果Claude 寫完代碼自己跑一下測試或者檢查一下效果，發現問題自己修，修到對了再告訴你。你拿到的是已經驗證過的結果，會比較省心，體驗感也會更好。
驗證方式分享
不一定適合每一種情況，大家常用什麼方式來檢驗AI編程的結果，歡迎留言分享哈。
比如
運行測試：最直接的驗證方式。如果項目有單元測試，跑一遍測試就知道代碼對不對。適合後端邏輯、工具函數這類有明確輸入輸出的代碼。
構建檢查：運行 build 命令檢查是否能成功編譯。可以發現類型錯誤、語法錯誤、依賴問題。適合幾乎所有代碼改動。這種是比較基礎的。
Lint 檢查：運行 eslint/prettier 檢查代碼規範。可以發現風格問題、潛在的代碼質量問題。
瀏覽器測試：用 Playwright 或 Claude in Chrome 打開瀏覽器，實際操作頁面驗證功能。適合前端 UI 改動。
手動確認：有些東西沒法自動驗證，比如 UI 的視覺效果、用戶體驗。這些就必須要自己使用感受一下了。
關鍵是根據任務類型選擇合適的驗證方式，而不是一刀切。
方式一：直接下達指令
最簡單的方式是在給 Claude 的指令裏直接說明驗證要求。
比如：
幫我實現用戶註冊功能。
完成後請驗證：
1. 運行 npm run test 確保測試通過
2. 運行 npm run build 確保構建成功
3. 如果測試失敗，分析原因並修復
最後告訴我驗證結果。
這種方式靈活，可以根據具體任務定製驗證內容。缺點是每次都要寫，容易忘。
方式二：用 Subagent 驗證
把驗證邏輯封裝成 Subagent，需要的時候調用。Claude Code 進階玩法之 Subagent，給自己配一個專屬 AI 助手團隊
前面介紹過 verify-work 和 verify-ui 兩個代理。verify-work 是通用的驗證代理，能根據文件類型自動選擇驗證方式；verify-ui 專門做前端 UI 測試，可以用 Playwright 打開瀏覽器驗證。
使用的時候可以說：
幫我實現這個功能，完成後用 verify-work 驗證一下
或者功能實現完了之後單獨調用：
用 verify-ui 測試一下剛才改的頁面
Subagent 的好處是驗證邏輯固化了，不用每次寫。而且驗證在獨立的上下文裏執行，不會把主對話搞得很長。
方式三：Stop Hook 自動驗證
如果想讓每次 Claude 完成都自動驗證，可以用 Stop Hook。玩轉 Claude Code Hooks：讓自動化滲透到每個環節
{
"hooks": {
"Stop": [
{
"hooks": [
{
"type": "command",
"command": "cd /你的項目 && npm run test 2>&1 | head -50"
}
]
}
]
}
}
每次 Claude 完成響應，自動跑測試。如果測試失敗，Claude 能看到失敗信息，可以繼續修復。
這種方式最自動化，但有個問題：不是每次響應都需要驗證。你可能只是問個問題，沒必要跑測試。所以我個人更傾向於用 Subagent，可以控制什麼時候驗證。
如果你的工作流是每次改動都要驗證，Stop Hook 會很方便。如果驗證需求不固定，Subagent 更靈活。
方式四：瀏覽器自動化測試
前端 UI 的驗證需要實際看頁面效果。
Claude Code 支持的瀏覽器自動化方式：
Playwright MCP：通過 MCP 協議連接 Playwright，可以打開瀏覽器、導航頁面、點擊元素、填寫表單、獲取頁面截圖。適合 API 用戶，不需要 Claude 賬號，就像我和我們團隊現在一直都在用的 aigocode.com 中轉。
Claude in Chrome：Anthropic 官方的 Chrome 擴展，Claude Code 可以直接控制你的 Chrome 瀏覽器。好處是可以使用你登錄的賬號狀態，測試需要登錄的頁面很方便。需要開通會員。
我用 Playwright 比較多。
日常開發主要用 verify-work 代理。它能根據文件類型自動判斷用什麼驗證方式，大部分情況夠用。
前端 UI 改動單獨調用 verify-ui，讓 Playwright 打開瀏覽器實際看一下效果。
特別重要的改動，在指令裏明確驗證要求。
Stop Hook 我目前只用來發通知，沒有用來自動跑測試。主要是覺得不是每次響應都需要驗證，手動控制更靈活。
整個邏輯就是這樣的：
寫代碼 → 驗證 → 失敗 → 分析原因 → 修復 → 再驗證 → 成功
關鍵是把"失敗 → 修復 → 再驗證"這個循環自動化。
小結
沒有驗證的時候，Claude 像個只管寫不管對的"寫手"。有了驗證，Claude 越來越有工程師的意思了。
具體用哪種驗證方式不重要，重要的是形成閉環：寫完 → 驗證 → 發現問題 → 修復 → 再驗證。這個循環跑起來，產出的代碼質量會明顯提升。
如果你現在用 Claude Code 還沒有驗證這個環節，建議從最簡單的開始，就加一句指令 完成後跑一下測試。再考慮用 Subagent 或者 Hook 把它自動化。
歡迎關注，這個賬號還會持續分享更多出海工具、實戰經驗、踩坑記錄。
關於編程工具使用，推薦第三方共享平台 aigocode.com，支持 Codex / Claude Code / Gemini 3 三大頂尖模型。https://aigocode.com/invite/K68YB6K7 通過這個連結註冊可以獲得 5% 首單充值福利！！
從海外公司註冊到 Stripe 收款，跑通了出海收付款全流程（實操分享）
出海效率提升：一個 Skill 讓 Claude Code 接入你的 NotebookLM 知識庫
出海建站必備：告別AI味，這兩個頁面設計 Skills 太牛了！
玩轉 Claude Code Hooks：讓自動化滲透到每個環節