在 Claude Code 中建立驗證迴圈（verification loops） ☕ Buy me a coffee

🧑‍🏫 這支影片教你讓 Claude Code 自己檢查自己的成果，不用每次都由你打開來點點看。影片的核心是 verification loop（驗證迴圈：Claude 自己跑檢查、發現問題就修、修完再檢查一次）。學會之後，你就不用一直當 AI 的人工測試員。

• 00:00 你送出的每個 prompt，Claude Code 都會跑一個迴圈：收集脈絡、採取行動、驗證成果、回應。
  ↳ 你每次送出 prompt（給 AI 的指令），Claude Code 都走同一套流程：先搞懂狀況、動手改、確認改對沒、再回報你。這支影片講的是「確認」這一步。
• 00:00 目前驗證步驟有一部分是你自己在瀏覽器裡點來點去、看 console，再告訴 Claude 要修什麼；但這部分不一定都要由你來做。
  ↳ 現在「確認」常常靠你自己：打開網頁點一點，看 console（瀏覽器裡顯示錯誤訊息的地方），再回頭告訴 Claude 哪裡壞了。影片的意思是，這份苦工其實可以交出去。
• 00:00 Claude 本來就擅長對照 code base 檢查成果：會跑測試、type check、linter，並修正它們抓到的問題。
  ↳ 程式層面的檢查，Claude 本來就很會做：跑測試、type check（檢查資料型別有沒有用錯）、linter（抓出寫法錯誤的工具），抓到錯就自己修。
• 00:34 但全部通過不代表改動符合你的本意；真正能證明的，是你事後手動做的檢查。
  ↳ 但這些檢查只能證明「程式沒寫錯」，不能證明「做出來的東西是你要的」。就像文章沒有錯字，不代表內容切題。最後還是要實際用用看，才算真的確認。
• 00:34 手動檢查例子：web app 打開頁面點一點、看 console；後端呼叫 endpoint 讀回應；行動 app 在模擬器裡逐一點過畫面。
  ↳ 「實際用用看」是這樣做的：網頁 app 就打開頁面點一點；後端就呼叫 endpoint（伺服器接收請求的網址）看它回什麼；手機 app 就在 simulator（電腦上模擬手機的程式）裡一頁一頁點。
• 00:34 把這些步驟寫進專案（codify），Claude 就能用瀏覽器、terminal、iOS simulator 等工具自己執行。
  ↳ codify 就是把「你平常怎麼檢查」寫下來，存進專案裡。有了這份說明，Claude 就能自己操作瀏覽器、terminal（輸入指令的視窗）、iOS simulator，照著步驟做。
• 01:05 發現問題時，Claude 可以自己修正並重新執行這些檢查。
  ↳ Claude 檢查出問題後，不用等你開口，會自己修，修完再跑一次同樣的檢查，一直做到通過為止。
• 01:05 好的起點是 Claude Code 內建的 verify skill：第一次使用時，它會執行你的 app，並在 app 本身檢查你的改動。
  ↳ Claude Code 內建一個 verify skill 可以當起點。skill 是存在專案裡、Claude 會照著執行的一套步驟。第一次使用時，它會真的把 app 跑起來，在 app 上確認你的改動。
• 01:05 接著它會把成功的步驟存成專案裡的一個 skill。
  ↳ 跑完之後，它會把這次成功的檢查步驟存成你專案自己的 skill。下次就能直接照著跑，不用重新摸索。
• 01:05 產生出來的 skill 應當作起點，再自行擴充 Claude 要檢查的項目。
  ↳ 自動產生的 skill 只是初稿。你平常還會看什麼、在意什麼，要自己補進去，Claude 才會連這些一起檢查。
• 01:37 講者在 web app 上一定會看 layout shift，也就是內容載入時頁面部分區塊跳動。
  ↳ 舉個例子：講者做網頁一定會檢查 layout shift，也就是頁面載入時區塊突然跳位。像你正要點按鈕，上方突然冒出一張圖片，把按鈕往下擠，結果點錯。
• 01:37 可透過 Google Chrome 的 DevTools MCP 把它寫成 performance trace，它會把 layout shift 當作 Core Web Vitals 之一來量測。
  ↳ 講者用 DevTools MCP（讓 AI 能操作 Chrome 開發者工具的連接工具）跑 performance trace（記錄頁面載入過程的效能紀錄）。layout shift 會被當成 Core Web Vitals（Google 的網頁體驗指標）之一，量出分數。
• 01:37 在 skill 裡可以寫明：Claude 何時該執行、檢查失敗時該怎麼做、以及什麼能證明每項檢查通過。
  ↳ skill 裡可以寫清楚三件事：什麼時候要跑（例如改到畫面就跑）、沒通過要怎麼處理、看到什麼才算通過。寫得越清楚，Claude 越不需要自己猜。
• 01:37 檢查越可量測，Claude 越容易判斷是否通過。
  ↳ 「頁面看起來正常」很難判斷；「分數在某個標準內」就很明確。能用數字或「有沒有出現」來判定的檢查，Claude 最容易判斷過了沒。
• 02:12 示範：請 Claude 在一個頁面加上 like button，該頁面還有尚未修好的 layout shift。
  ↳ 示範開始：講者請 Claude 在某個頁面加一個 like button（按讚按鈕）。這個頁面本來就有一個還沒修好的 layout shift。
• 02:12 因為是 UI 改動，Claude 改完後會自行執行 skill：啟動 dev server、開啟頁面、點 like button、截圖證明它能用。
  ↳ 因為這次動到 UI（使用者看得到、會操作的畫面），Claude 改完就自動跑 skill：先啟動 dev server（在自己電腦上跑網站的測試用伺服器），再打開頁面、按讚，最後截圖證明按鈕能用。
• 02:12 接著執行 performance trace，找到了 layout shift。
  ↳ 接著 Claude 跑 performance trace，發現頁面載入時有 layout shift。
• 02:45 Claude 修正後再跑一次檢查，這次通過。
  ↳ Claude 自己把問題修掉，再跑一次檢查，這次通過了。
• 02:45 最終拿到：能用的 like button、載入時不再跳動的頁面，以及作為證明的截圖與分數。
  ↳ 講者最後拿到三樣東西：能用的按讚按鈕、載入時不再跳動的頁面，以及截圖和分數當證據。他不必只聽 Claude 說一句「改好了」。
• 02:45 整個驗證迴圈由 Claude 自己完成，講者不需要指出任何問題。
  ↳ 整個過程講者沒有指出任何問題。連頁面原本就有的 layout shift，也是 Claude 自己發現、自己修好的。這就是「把驗證交出去」的意思。

根據影片，第一次使用 Claude Code 內建的 verify skill 後，它會做什麼？