別再當 agent 的保母了（第 2/3 段） ☕ Buy me a coffee

🧑‍🏫 這段示範怎麼讓 Claude 自己檢查它寫的網頁是不是真的能用，你不必在旁邊一直盯著。重點是 verification loop，也就是讓 AI 自己把程式跑起來、實際操作、確認結果的一套流程，以及怎麼把它存成能重複用的 skill。看完你會知道「叫 AI 自己驗收」具體要先準備哪些東西。

• 12:22 前端 verification loop 第一步：先把應用程式跑起來，例如執行 npm run start，啟動 dev server
  ↳ 驗證的第一步是讓程式真的跑起來。dev server 是開發時在自己電腦上開的臨時網站伺服器，npm run start 是常見的啟動指令。程式沒跑起來，就沒有東西可以測。
• 12:22 dev server 啟動後，要讓 Claude 開瀏覽器，實際操作這個網頁應用程式
  ↳ 光看程式碼不算驗證。要讓 Claude 像真人使用者一樣開瀏覽器、點按鈕、打字，看網頁實際怎麼反應，才知道功能有沒有壞。
• 12:53 講者個人首選的工具是 Claude in Chrome MCP，在 Claude Code 裡輸入 /chrome 就能使用；也可以用 Playwright 或其他 browser control MCP
  ↳ MCP 是讓 Claude 接上外部工具的方式。講者愛用 Claude in Chrome，能操控你的 Chrome；在 Claude Code（寫程式用的 Claude）打 /chrome 就能用。Playwright 是另一種自動操控瀏覽器的工具。
• 12:53 Claude 能操作瀏覽器後，下一步是證明東西真的能用：如果是修 bug，就在修正前後各拍一張截圖，確認狀態正確
  ↳ Claude 能操作瀏覽器之後，要留下證據。例如修 bug（程式錯誤）時，修之前截一張圖，修之後再截一張，兩張對照，確認問題真的消失，而不是只聽 Claude 說修好了。
• 13:23 最後一步是排除阻礙。在正式環境的 app 建 verification loop 很快就會卡關，常見的 blocker 是 auth 和 state
  ↳ 真正上線的 app 通常一測就卡住。最常擋路的有兩個：auth（登入身分）和 state（資料狀態），下面兩點分別說明。
• 13:23 auth：給 Claude 一個可以登入你網頁應用程式的身分，它才能真正開始使用你的 app
  ↳ 多數網站要登入才能用。auth 就是登入驗證。你要準備一組測試帳號給 Claude，不然它連登入頁都過不去，更別說測功能。
• 13:53 state：預先設定好資料狀態。例如電商網站要先填好商店庫存，Claude 才能有意義地使用這個 app
  ↳ state 是 app 裡事先存在的資料。商店如果是空的，就沒東西可買，Claude 也測不出購物流程。所以要先把商品、庫存這些資料準備好。
• 13:53 傳統寫 end-to-end tests 時，寫 state 設定腳本本來就很常見。差別在於要讓 Claude 能使用這些腳本
  ↳ end-to-end tests 是從頭到尾模擬使用者操作的自動測試，工程師本來就常寫腳本先準備好資料。這次唯一不同的地方是，要讓 Claude 知道有這些腳本，而且能自己執行。
• 13:53 這些腳本要寫得動態，不要把腳本的行為規定得太死，這樣 Claude 能做的事會比用靜態腳本多很多
  ↳ 準備資料的腳本不要寫死成只能產生一種固定資料，要能依需要調整，例如指定幾件商品、哪一種帳號。這樣 Claude 就能自己組出更多測試情境。
• 14:23 要把 verification loop 分享給同事或未來的自己，最好的方式之一是做成 skill。skill 就是存放某個主題相關 context 的方式
  ↳ skill 是一份寫給 Claude 看的說明檔，把某件事的 context（背景知識、步驟、注意事項）集中存起來。把驗證流程寫成 skill，同事或下次的你直接拿來用就好。
• 14:53 skill 可以自我改進：在 skill 裡寫明「每次卡關就更新這個 skill」，它就會自己寫文件、自己變好，全隊都能一起貢獻
  ↳ 在 skill 裡寫一句「卡關就更新這份 skill」，Claude 每次遇到問題都會把解法補進去。文件會越用越完整，大家用到的也都是最新版。
• 15:23 Claude Code 團隊實際上也這樣做驗證：團隊只用一個 verification skill，並明確要求它持續記錄。有人卡關時它就修改自己，下次就不會再卡
  ↳ Claude Code 團隊自己就是這樣做：全隊共用一個驗證 skill，並要求它持續記錄。誰卡住了，它就修改自己，下一個人就不會再卡在同一個地方。
• 15:56 Demo 用的 app 是 MonkeyType，一個打字測試工具：畫面顯示一串單字，要打得又快又準，app 會記錄你的數據
  ↳ MonkeyType 是線上打字測驗：畫面會出現一串單字，你要打得又快又準，它會記錄你的打字數據。
• 16:29 選 MonkeyType 是因為它能代表真實世界的 full-stack app：用 TypeScript 寫、後端是 Express、持久層用 MongoDB 和 Redis，而且是開源的
  ↳ full-stack app 是前端、後端和資料庫都有的完整應用。MonkeyType 用 TypeScript（一種程式語言）寫，後端框架是 Express，資料存在 MongoDB 和 Redis 兩種資料庫，而且是開源的，很接近真實產品。
• 16:29 Demo 流程：叫 Claude 開 dev server、用 Chrome MCP 檢查成果、建立 verification skill，再做一個新功能，讓 Claude 用這個 skill 驗證自己
  ↳ 示範分四步：叫 Claude 開 dev server、用 Chrome MCP 確認畫面、把過程寫成驗證 skill，最後做一個新功能，看 Claude 能不能用這個 skill 自己驗收。
• 17:29 講者事前已在本機架好 MonkeyType、裝好相依套件，也準備好 Claude MD 檔
  ↳ 講者事先把 MonkeyType 裝到自己電腦、裝好它需要的套件，也準備好 Claude MD。Claude MD 是給 Claude 看的專案說明檔，裡面寫專案的規則和背景。
• 17:29 Claude 回報 dev server 已在執行。前端可以正常打字、會出現計時器；後端連結回傳 JSON，代表後端正常運作
  ↳ Claude 回報伺服器開好了。講者檢查：前端能打字，計時器也會跑；後端網址回傳 JSON（程式之間交換資料用的文字格式），代表後端也正常運作。
• 18:01 輸入 /chrome 確認 Chrome MCP 已啟用：畫面顯示 status enabled、extension installed。沒安裝的話會帶你走設定指南
  ↳ 打 /chrome 可以檢查連線狀態。畫面顯示 status enabled、extension installed，代表功能已開啟、Chrome 擴充功能也裝好了。還沒裝的話，它會一步步帶你設定。
• 18:34 請 Claude 用 Chrome MCP 確認前端正常。它呼叫了兩次 Chrome MCP 工具，按 Control-O 可以看到細節：先開 localhost 3000，再讀取分頁內容
  ↳ Claude 呼叫了兩次工具：先開 localhost 3000（你自己電腦上跑的網站網址），再讀取分頁內容。按 Control-O 可以展開，看它每一步實際做了什麼。
• 19:10 只看靜態網頁幫助不大，所以進一步叫 Claude 實際打字測試。它打了一些字，回報打字功能正常
  ↳ 網頁有顯示，不代表功能正常。所以講者要 Claude 真的去打幾個字。它照做後回報打字功能沒問題，這樣才算真的測到東西。
• 20:11 再叫 Claude 去設定頁改東西：它把 difficulty 改成 Expert，並確認設定有被保存
  ↳ 接著測設定功能：Claude 到設定頁把難度 difficulty 改成 Expert（專家），再確認這個改動真的有存起來。
• 20:42 到這裡為止都是手把手告訴 Claude 要做什麼（開 dev server、做幾件在意的事），這基本上就是驗證
  ↳ 到這裡其實都是講者一步步指揮：開伺服器、試幾個他在意的功能。但驗證本來就是這些事，接下來只是把它變成 Claude 能自己照著做的流程。
• 20:42 接著請 Claude 把這次 session 學到的所有東西寫成 skill 檔；講者自己指定了路徑，但其實不必給完整路徑
  ↳ 講者請 Claude 把這次學到的所有東西寫成 skill 檔。他自己指定了存放位置，但你其實不用給完整路徑。
• 21:44 產生的 skill.md 內容：1. 啟動整個 stack（含 Docker Compose 指令）；2. 載入 Chrome MCP 工具；3. smoke test，用瀏覽器工具檢查自己的成果
  ↳ 產出的 skill.md 有三步：啟動整套系統（含 Docker Compose 指令，用來一次開好多個服務）、載入 Chrome MCP 工具、做 smoke test（快速實測主要功能有沒有壞）。
• 22:15 建立 verification loop 很簡單。講者準備 demo 時遇過幾個 blocker，但認為自己動手大概 5 到 10 分鐘就能跑起來
  ↳ 講者準備 demo 時也遇過幾個卡關點，但他認為自己動手做，大概 5 到 10 分鐘就能讓這套驗證流程跑起來，門檻不高。
• 22:45 新功能：每次打錯字就顯示 confetti 動畫，並要求 Claude 用剛建好的 verification skill 驗證自己的成果
  ↳ 新功能是每打錯一個字就噴出 confetti（彩色紙花動畫），並要求 Claude 做完後，用剛建好的驗證 skill 自己檢查成果。
• 23:51 Claude 要寫檔時，講者開啟 auto mode，這樣每次編輯檔案都不必再經過他確認
  ↳ auto mode 開啟後，Claude 改檔案時不用每次停下來問你同不同意。它能一路做完再自己驗證，你不必守在旁邊一直按確認。
• 24:21 Claude 做完功能後發現幾個 lint errors，自己修好再重新驗證。這就是 verification loop 的實際運作：寫程式、遇到問題、修正、再驗證
  ↳ 做完後，Claude 發現幾個 lint errors（程式寫法不符合規範的錯誤），自己修好再重新驗證。寫程式、遇到錯誤、修正、再驗證，這個循環就是 verification loop。

講者提到，在正式環境的 app 建立 verification loop 時，常見的兩個 blocker 是什麼？