我們在 Anthropic 怎麼用 Claude Code（第 3/3 段）

🧑‍🏫 這段示範怎麼讓 agent（能自己動手操作電腦、完成任務的 AI）自己檢查做出來的網頁 app 對不對，還會把檢查過程錄成影片當證據。重點在於不能只聽 AI 說「好了」，要讓它拿出看得到的證明。如果你常叫 AI 幫你做東西，這個觀念很實用。

• 21:08 驗證的過程可以錄成 clips，也就是擷取下來的影片，拿來當作驗證的證據。錄好後可以儲存、分享給同事，或放到 S3 之類的地方。
  ↳ 驗證過程可以錄成 clips（把畫面錄下來的短片），當成「真的測過」的證據。可以存檔、傳給同事，或放到 S3（亞馬遜的雲端檔案儲存服務）。
• 21:08 驗證結果的 summary 裡有一個案例是故意設計成失敗的。
  ↳ 驗證結果的總表（summary）裡，有一項是講者故意設計成會失敗的，用來示範失敗時長什麼樣子。
• 21:41 每個案例都能點開，看到這項驗證是怎麼執行的。
  ↳ 總表上每一項都能點開，看這項驗證實際做了哪些步驟，不會只給你一個「過」或「不過」。
• 21:41 重點是要加入 probes，讓測試不只走 happy path。
  ↳ 關鍵是加入 probes（刻意找碴的檢查），不要只測 happy path，也就是使用者照正常步驟操作、一切順利的那條路。
• 21:41 這些驗證有很多會由 Claude 替 Claude 產生，這是讓規模再擴大的一種方式。
  ↳ 很多驗證項目可以叫 Claude 幫 Claude 寫，不用人一條一條設計，能驗證的範圍才擴得大。
• 21:41 失敗的那個案例把「sums 不相符」寫死在程式裡，所以 state 對不起來：3 + 4 不等於 10。
  ↳ 故意失敗的那項，是在程式裡直接寫死一個錯的總和，所以數字對不起來：3 加 4 怎樣都不會等於 10。
• 22:13 改從 Claude 這邊執行 verify all，也會得到一樣的結果。
  ↳ 不從瀏覽器手動點，改叫 Claude 下指令一次跑完全部驗證（verify all），得到的結果也一樣。
• 22:50 核心概念：讓 agent native 的東西作為 DOM contract 被讀取。state 對 agent 是看得到的，agent 就能自己端到端跑完驗證。
  ↳ DOM 是網頁背後的結構。DOM contract 是事先約好，把 app 目前的狀態標在網頁結構裡讓 agent 直接讀，agent 就能自己從頭到尾驗證。
• 23:20 示範「破壞 contract，但不破壞 app」：刪掉 to-do app 底下的 total stats。
  ↳ 示範「弄壞約定、不弄壞 app」：把待辦清單 app 下方的統計數字區塊刪掉，但 app 本身照樣能用。
• 24:22 重跑後底部那些驗證全部失敗。原因不是 app 壞了，而是 contract 被破壞了，這正是 Claude 能原生驗證的東西。
  ↳ 重跑後，底下那些驗證全部失敗。不是 app 壞了，而是約好要讓 agent 讀的資訊不見了。Claude 能直接察覺的就是這種狀況。
• 25:10 請 Claude 說明那個故意失敗的案例是怎麼回事；在這之前先用 Ctrl+Z 復原剛才的修改，auto save 後重跑。
  ↳ 接著要請 Claude 解釋那個故意失敗的案例。開始前先按 Ctrl+Z 把刪掉的東西復原，等它自動存檔（auto save）後再重跑一次。
• 25:43 前面是手動操作，用來對照「agent 看到的」和「人會做的」；接著也可以讓 Claude 自己 headless 執行。重跑結果：只有故意弄壞的那個失敗，其他都通過。
  ↳ 前面手動操作，是為了對照 agent 看到的和人會做的。接著讓 Claude headless 跑（不開畫面，在背景執行），結果只剩故意弄壞的那項失敗。
• 26:13 講者提到先前介紹過的 fast mode、auto mode 和 /goal。這裡用 Opus 4.7 找出那個驗證失敗的原因，並事先連接好 Playwright MCP 讓它使用。
  ↳ 提到先前講過的 fast mode（加速模式）、auto mode、/goal（這段沒再解釋）。這次用 Opus 4.7 模型查原因，並先接好 Playwright MCP，讓它能操作瀏覽器。
• 26:13 Claude 回報的結果：Schema got rejected，4 + 3 不等於 10。
  ↳ Claude 查完回報：資料格式檢查（schema）沒過，因為 4 加 3 不等於 10，正好抓到那個故意寫錯的地方。
• 26:44 如果執行 bun verify，測試反而會通過，因為這個驗證是為了示範而故意寫錯的，測試指標本身沒問題。
  ↳ 如果改跑 bun verify（專案裡用來跑驗證的指令），測試反而會通過。錯的是示範用的那一項，檢查的標準本身沒有問題。
• 26:44 目的是把三種執行方式分開：人類手動能做的、agent 直接在瀏覽器用這些指令能做的，以及從 CLI headless 執行的。
  ↳ 重點是把三種跑法分清楚：人自己手動點、agent 直接在瀏覽器裡用同一套指令跑，以及從 CLI（打指令的文字介面）在背景自動跑。
• 27:14 執行的結果可以錄下來當作證據，證明它確實有效，然後儲存起來。
  ↳ 每次跑的過程都能錄下來，證明這個改動真的能用，再存起來備查。
• 27:45 這種做法現在很常見：團隊（字幕拼作 cloud code team）基本上會把所有程式變更這樣錄下來，至少前端變更是如此，尤其在目前的出貨速度下更是這樣。
  ↳ 講者說這個做法現在很普遍：Claude Code 團隊幾乎每個程式改動都會這樣錄，至少畫面相關的前端改動會錄，因為現在出貨的速度實在太快。
• 28:16 錄下來的影片可以放 S3 或分享給同事。他們內部有一套比示範更自動化的版本，錄製是固定節奏的一部分；講者不確定影片保存多久、在什麼情境下使用。
  ↳ 影片可以放 S3 或分享給同事。他們內部有比示範更自動化的版本，錄影是固定流程；不過影片存多久、用在什麼場合，講者也不確定。
• 28:46 每個 clip 都可以單獨下載，也可以全部下載；這整組 clips 就是證明驗證有效的 bundle。
  ↳ 每段影片都能單獨下載，也能一次全部下載；整組影片就是一包（bundle）證明驗證有效的證據。
• 29:17 總結三種 surface：給人類用的、agent first 從瀏覽器以同樣方式執行的，以及在 CI 裡直接跑 bun verify。
  ↳ 總結三種使用場合（surface）：給人看的、讓 agent 在瀏覽器用同樣方式跑的，以及在 CI（程式一改動就自動檢查的系統）裡跑 bun verify。
• 29:17 最終目標是想辦法把驗證嵌入 artifact 本身。
  ↳ 最終目標是把驗證直接放進 artifact（做出來的成品）本身，不要另外放在別的地方。
• 29:48 講者鼓勵大家去看 repo、親自跑範例和測試，例如改程式、看哪裡壞掉、再重跑。repo 內容很詳細，Tariq 和團隊已經在工作中使用；大約一週半前才被整理進這個 demo。
  ↳ 講者鼓勵去看 repo（放程式碼的專案庫），自己跑範例：改一點程式、看哪裡壞掉、再重跑。Tariq 團隊平常就在用，大約一週半前才整理成示範。
• 30:20 真正新的地方是把大家已經熟悉、正在用的 primitives 重新組合和安排，讓它們對 agent first 可用。
  ↳ 真正新的不是工具，而是把大家早就在用的 primitives（基本組件）重新搭配，讓 agent 也能直接拿來用。
• 30:20 repo 有很好的文件，搭配 Opus 4.7 能得到很多收穫。Opus 4.7 表現好是因為它的 vision model 更好，這正是這個做法最能發揮的地方。
  ↳ repo 文件寫得很完整，搭配 Opus 4.7 能學到很多。它表現好是因為看圖、看畫面的能力（vision model）更強，這個做法正好需要這種能力。
• 30:50 講者不建議用 Sonnet 做這件事，建議改用 Opus 4.7。
  ↳ 講者不建議用 Sonnet（Claude 的另一個模型）做這件事，建議改用 Opus 4.7。
• 30:50 fast mode 很好但比較貴，適合快速迭代 specs。
  ↳ fast mode 很好用但比較貴，適合在反覆修改 specs（規格文件）時加快速度。
• 30:50 有人問 HTML spec 會不會比較耗 token？答案通常是不會。雖然單次生成要花較多 token，但有好又豐富的 HTML spec，長期下來需要迭代的次數比較少。
  ↳ 有人問 HTML spec（用網頁格式寫的規格）會不會比較耗 token（AI 計算用量和費用的單位）？通常不會。單次花得多，但規格清楚，之後要修改的次數會比較少。
• 31:20 講者的建議：可以試著搭配 fast mode 來用。
  ↳ 講者建議，可以把這套做法搭配 fast mode 一起試試看。

講者說 Opus 4.7 在這套驗證做法上表現特別好，原因是什麼？