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

🧑‍🏫 這段講兩件事。第一，用 Claude 做設計時，請它直接做出能點開來看的網頁，比寫一大份文件好用。第二，也是講者說更重要的：把「檢查有沒有做對」直接做進程式裡，讓 AI 自己驗收，人不用一項一項盯。如果你常請 AI 幫你做東西，卻不知道怎麼確認它真的做對，這段值得看。

• 10:35 HTML 檔可以搭配截圖，之後也能用 Playwright MCP 操作，比一份很長的 markdown 檔能做更豐富的互動
  ↳ HTML 就是網頁檔，點開就看得到畫面，還能配截圖。再加上 Playwright MCP（讓 Claude 自己開瀏覽器、點按鈕的工具），能做的事比一份長長的 markdown（用符號排版的純文字檔）多。
• 10:35 markdown 檔超過大約 200 行，你自己多半不會讀，同事就更不可能讀
  ↳ 規格文件寫太長，最後就是沒人看。超過兩百行左右，連寫的人自己都懶得讀完，同事就更不可能認真看，等於白寫。
• 10:35 講者事前請 Claude（Opus 4.7）用他的分帳 app（bill splitting app）產生幾個範例
  ↳ 講者上課前，拿自己做的分帳 app（幫大家算誰該付多少錢的工具）當題材，先請 Claude 的 Opus 4.7 模型做出幾個範例。
• 11:07 用的 prompt 放在 repo 裡：請 Claude 提出四種不同設計方向，做成 HTML，方便互相比較
  ↳ 他用的 prompt（給 AI 的指令）放在 repo（存放程式碼的專案資料夾）裡。內容是請 Claude 提出四種設計方向，各做成一個網頁，方便放在一起比。
• 11:07 Claude 產生的方向風格差很多，例如一種 brutalist、一種 Tokyo fintech
  ↳ 四個方向不是改改顏色而已，風格差很多。例如一種是刻意粗獷、原始感的 brutalist 風，另一種是走東京金融科技 app 路線的風格。
• 11:37 直接點開 HTML 看，比從 markdown 推想成品長相更容易給 Claude 回饋
  ↳ 看文字描述得自己腦補，每個人想像的畫面都不一樣。直接打開網頁看，喜歡哪裡、哪裡不要，一眼就講得出來，給 Claude 的意見也更準。
• 11:37 講者鼓勵大家常截圖給 Claude，尤其做前端時，「有點歪」「沒對齊」這種問題很難用文字講清楚
  ↳ 做前端（使用者看得到的畫面）時，「好像歪一點」「沒對齊」這種感覺很難用文字講清楚。講者建議養成習慣，直接截圖丟給 Claude，比打一大段說明有用。
• 12:07 Opus 4.7 的視覺模型比以前好很多，更能從截圖找出問題，還會主動指出
  ↳ 新的 Opus 4.7 看圖的能力進步很多。給它截圖，它更能看出畫面哪裡不對，連你沒提到的問題也會主動指出來。
• 12:07 Tariq 的 repo 裡有更多範例，線上 repo 也找得到
  ↳ 課堂上看到的只是一部分，Claude Code 團隊的 Tariq 在他的 repo 裡放了更多範例，網路上公開的 repo 也找得到，想看實例可以去翻。
• 12:07 回顧：讓 Claude 當面試官訪談你、把需求問出來；agent 跑得越久，spec 越需要完整
  ↳ 回顧前面：讓 Claude 像面試官一樣一題一題問你要什麼。agent（會自己連續做很多步的 AI）放手跑得越久，spec（規格說明）就要寫得越完整。
• 12:37 需求很難一開始全部定義清楚，所以比較好的做法是和 Claude 用這種方式反覆來回修正
  ↳ 沒有人能一開始就把需求想清楚，很多事要看到東西才發現。所以與其硬寫一份完美規格，不如和 Claude 一來一回，邊看邊改。
• 12:37 呈現設計時，HTML 檔是更有效率、也更好用的形式
  ↳ 小結：要給人看設計時，給一個點得開的網頁，比給一份文件更省時間，也更方便討論。
• 12:37 講者認為更重要的是：怎麼驗證 Claude 做了什麼，以及怎麼讓驗證變成 agent native
  ↳ 講者說比設計更關鍵的是：怎麼確認 Claude 真的做對了。還有，讓這個檢查一開始就設計成 agent 自己能做（agent native），不用靠人盯。
• 13:07 做法是把驗證變成成品（artifact）本身的一部分
  ↳ 意思是檢查機制不是做完才另外補上，而是直接做進成品（artifact，也就是做出來的東西）裡，成品本身就帶著驗證的功能。
• 13:38 今天會在 React app 裡用 Storybook fixtures、testing library、data 屬性輸出和 Playwright MCP
  ↳ 會用到的工具：React（常用來做網頁介面）、Storybook fixtures（先設定好的畫面狀態範本）、testing library（寫測試的工具）、網頁上的 data 標記，還有 Playwright MCP。
• 13:38 目的是讓 Claude 這個 agent 能從 DOM 讀出資料約定（data contract）、執行驗證，甚至把驗證過程錄下來
  ↳ 目的是讓 Claude 從 DOM（瀏覽器裡網頁的結構）直接讀到事先約定好格式的資料（data contract），自己跑檢查，還能把過程錄下來。
• 13:38 Tariq 所在的 Claude Code 團隊就是這樣做的，他做的 demo 也是在示範這套流程
  ↳ 這不是紙上談兵。Tariq 所在的 Claude Code 團隊平常就是這樣工作，他的 demo 示範的也正是這套流程。
• 14:08 流程：產生驗證步驟並逐一執行、錄影，再放到 S3 或其他地方分享給同事
  ↳ 流程是：agent 自己列出要檢查的步驟，一步一步執行並錄影，再把影片放到 S3（Amazon 的雲端儲存空間）之類的地方，分享給同事看。
• 14:08 這樣驗證步驟就由 agent 產生，人需要介入的地方越來越少；關鍵是做好模組化
  ↳ 檢查步驟交給 agent 產生，人要插手的地方就越來越少。關鍵是把程式拆成一塊一塊獨立的模組。
• 14:39 今天這堂課的 repo 叫 how we Claude Code；第一階段是請 Claude 追問分帳 app 的需求，避免描述時漏掉
  ↳ 課程的 repo 叫 how we Claude Code。第一階段是請 Claude 針對分帳 app 反過來問你需求，補上你描述時漏掉的地方。
• 15:10 第二階段：產生四種 HTML 設計方向，讓講者比較、給回饋、做決定
  ↳ 第二階段：Claude 做出四種網頁版設計，講者並排比較、說哪裡要改，最後決定走哪個方向。
• 15:10 第三階段是驗證框架，換成另一個例子：用 React 寫的小型待辦清單 app（to-do app）
  ↳ 第三階段講驗證，換一個例子：一個用 React 寫的小型待辦清單 app，拿來示範檢查機制。
• 15:42 第三階段的 readme 和另一份驗證細節文件都有詳細說明，想深入了解可以去讀
  ↳ 第三階段的說明寫在 readme（專案說明檔）和另一份驗證細節文件裡，影片只帶過重點，想深入可以去讀。
• 16:12 待辦 app 示範：新增項目、打勾完成、刪除、清除已完成項目，過程中有很多狀態變化
  ↳ 這個待辦 app 可以新增、打勾完成、刪除、一次清掉已完成的項目。每做一個動作，數量和狀態就跟著變，這些變化正是要檢查的地方。
• 16:12 目標是在既有測試之外，也確認這些功能都正常，而且驗證步驟要由 agent 來驅動
  ↳ 原本就有的自動測試照跑，另外還要確認這些功能真的正常；而且檢查要由 agent 來主導，不是靠人一個一個去點。
• 16:42 三種驗證方式之一：人看得懂的 dashboard
  ↳ 第一種檢查方式是 dashboard（一眼看完所有狀態的儀表板頁面），給人看的，哪項通過、哪項失敗一目了然。
• 16:42 之二：同一套東西以 agent 優先的方式驗證，例如從 Claude Code 驅動（由 Paul 另外示範）
  ↳ 第二種是同一套檢查改成以 agent 為主，例如直接在 Claude Code 裡叫 agent 去跑。這部分由另一位講者 Paul 示範。
• 16:42 之三：在 repo 直接執行 verify 跑測試矩陣，是 headless 的做法，就像在 CI 裡跑
  ↳ 第三種是在 repo 裡執行 verify，把所有檢查組合一次跑完。這是 headless（不開畫面、在背景跑）的做法，就像在 CI（程式碼一更新就自動跑檢查的系統）裡執行。
• 16:42 從 repo 跑和從這裡跑，結果會略有不同，但原理一樣
  ↳ 從 repo 跑和從畫面上跑，出來的結果會有一點差異，但背後檢查的邏輯是同一套。
• 17:12 在瀏覽器 elements 面板可以看到元件輸出的 data 屬性，例如 data verify unit、total、done、active
  ↳ 打開瀏覽器開發者工具的 elements 面板（查看網頁結構的地方），可以看到元件上掛著 data 屬性，記錄總數、已完成數、未完成數等等。
• 17:42 元件把自己的狀態發布到 DOM，新增或刪除項目時，這些值會即時更新
  ↳ 也就是說，每個元件會主動把自己現在的狀態寫在網頁結構上。新增或刪除一筆，這些數字馬上跟著更新。
• 17:42 agent 之後可以直接讀這些值，不用去爬 DOM
  ↳ 這樣 agent 想知道現在有幾筆、完成幾筆，直接讀那幾個值就好，不用自己在整個網頁裡翻找、猜哪個是哪個。
• 17:42 狀態和 React 內部分開發布，驗證就能獨立執行，不受 app 當下狀態影響
  ↳ 這些狀態是另外公開的，不跟 React 內部的運作綁在一起，所以檢查可以單獨跑，不會被 app 當下的狀態影響。
• 18:13 每個元件都有 schema、fixture（已知狀態）和 invariant（永遠要成立的條件），並用 probe 來測試
  ↳ 每個元件都有三樣東西：schema（資料格式的規定）、fixture（事先準備好的已知狀態）、invariant（任何時候都必須成立的規則），再用 probe（小型檢查）去測。
• 18:47 他們在程式裡故意寫死一個會讓驗證失敗的例子，看人用的 dashboard 和 agent 做法能不能抓到
  ↳ 他們故意在程式裡寫死一個錯誤，看看給人看的 dashboard 和給 agent 用的做法，能不能都抓到它。
• 18:47 也可以讓 Claude Code 找出這個問題並診斷原因
  ↳ 也可以直接叫 Claude Code 去找出這個錯誤，並說明錯在哪裡、為什麼會發生。
• 19:17 dashboard 可以單獨執行每個 invariant，也能全部一起跑；全部跑時，預先埋的那個失敗會被觸發
  ↳ dashboard 上可以一條一條單獨跑規則，也能全部一起跑；全部一起跑時，那個故意埋的錯誤就會被抓出來。
• 19:48 給 agent 用的做法：所有驗證步驟的 manifest 以狀態的形式放在 DOM 裡，可以用同樣方式取得
  ↳ 給 agent 用的版本：所有檢查步驟的 manifest（清單）也用狀態的形式寫在網頁結構裡，agent 用讀數字的同一招就能拿到整份清單。
• 20:38 這裡執行驗證步驟不是為了驗證本身，而是為了留下驗證證據，之後還可以錄下來
  ↳ 這裡跑檢查的重點不只是跑過，而是留下證據：做了哪些檢查、結果怎樣都有紀錄，之後還能錄成影片給別人看。

在待辦 app 示範中，為什麼要讓元件把狀態發布到 DOM？