別再當 agent 的保母了（第 1/3 段）

🧑‍🏫 這是 Claude Code 早期工程師講的進階課第一段。他談的是現在很多人用 AI 寫程式的狀態：一直坐在旁邊等它做完，做完再親手幫它測試。他的解法是教 Claude 自己檢查成果，並讓它自己重複「寫、檢查、修」直到成功，你就能把時間拿回來。

• 00:00 講者 Sid Bindisaria 是 Claude Code 的創始工程師之一，這場的主題是怎麼不用再一直盯著（babysit）你的 agents
  ↳ 講者是 Claude Code 最早期的工程師之一。Claude Code 是讓 Claude 直接在電腦上寫程式、跑指令的工具。agent 指會自己動手做事的 AI。這場主題是別再一直顧著它。
• 00:00 問題：模型越來越聰明，我們花越來越多時間盯著螢幕等 Claude 做完，或只是在幫 Claude 當 QA 測試員
  ↳ 模型變強，人反而更累。你不是坐著等它跑完，就是它做完後得親自點、親自測，等於在當它的 QA，也就是負責找 bug 的測試員。
• 00:37 這樣做不但讓人沒成就感，也很浪費時間。這場的目標是提供策略，把時間拿回來、把 agents 管得更好
  ↳ 一直盯著它沒成就感，又耗時間。這場要給的是方法：讓你少花時間在旁邊看，同時讓 agent 做得更穩、更好掌控。
• 00:37 講者把這場定位成進階版的 Claude Code 課，也就是「Claude Code 301」，有幾個先備條件
  ↳ 「301」借用美國大學的課號，數字越大越進階。意思是這不是入門課，預設你已經會用 Claude Code，也做好幾件基本功。
• 01:11 先備條件一：一份高品質的 CLAUDE.md（字幕寫作 CloudMD），講者說這是改善 Claude Code 體驗「槓桿最高的一件事」
  ↳ CLAUDE.md 是放在專案裡的說明檔，Claude 每次開工都會先讀，像一份交接筆記，寫專案怎麼跑、有哪些規矩。講者說把它寫好，是最划算的改善。
• 01:11 先備條件二：把你的工具接上 Claude Code
  ↳ 讓 Claude Code 直接連到你平常工作用的服務。它就能自己去查資料、看狀況，不用你一直複製貼上給它。
• 01:43 經驗法則：平常對你有用的工具，對 Claude 也有用。例如 Slack、Asana、Linear、Datadog、BigQuery，能幫 Claude 拼出更完整的 context、表現更好
  ↳ Slack 用來聊天，Asana 和 Linear 管任務，Datadog 看系統監控，BigQuery 查資料。接上這些，Claude 能拿到更完整的 context，也就是背景資訊，判斷會更準。
• 01:43 先備條件三：在 Claude Code Web 上設定 remote environment
  ↳ Claude Code Web 是在瀏覽器裡用的版本。remote environment 是讓它在雲端的電腦上執行，不佔用你自己的筆電。
• 02:13 這樣執行 Claude Code 的運算就跟筆電分開：闔上筆電、筆電沒電或潑到水，session 都會繼續在雲端跑
  ↳ 好處很實際：工作在雲端跑，筆電闔上、沒電甚至壞掉，進行中的 session（一次工作階段）都不會斷。回來接著看就好。
• 02:43 現場舉手調查：幾乎每個人都天天用 Claude Code，大約 50% 做到前兩項。講者建議先把這三件事做好
  ↳ 現場幾乎人人天天用，但只有約一半寫好了 CLAUDE.md、也接好了工具。講者的意思是這三件是地基，先補齊，再談後面的進階玩法。
• 03:17 為什麼工具鏈要改：linters、IDEs、prettiers、type checkers、compilers 多半是為人類設計的，但現在大部分程式碼是 agents 寫的
  ↳ 工具鏈是寫程式用的一組輔助工具。linter、prettier 抓錯並整理寫法，IDE 是寫程式的編輯器，type checker、compiler 負責檢查並轉成能跑的程式。這些原本為人設計。
• 03:48 好消息：很多為人類做的工具，像 prettiers、linters、symbol servers，Claude 和 agents 也能用得很好
  ↳ 好消息是很多現成工具 Claude 直接就能用。例如 symbol server，能幫忙查某個函式定義在哪、被誰用到。不必全部重做。
• 04:18 壞消息：人類對工具鏈有一些理所當然的假設，Claude 卻沒有，所以存在盲點
  ↳ 麻煩在於人會自動補上很多沒寫下來的前提，例如「改完要重新整理頁面看看」。Claude 不知道這些，就可能卡住或做錯。
• 04:18 核心問題：你的 codebase 裡，有哪些東西是人類視為理所當然、但 agent 需要的？講者請大家整場都記著這個問題
  ↳ 這是整場的主軸：找出你團隊裡「大家都知道所以沒寫下來」的事，把它們變成 Claude 看得到、用得到的東西。
• 04:50 今天的路線圖有三個層層堆疊的主題：一、verification，也就是教 Claude 檢查自己的成果
  ↳ 三個主題一層疊一層。第一層是 verification（驗證）：讓 Claude 做完自己檢查對不對，不必每次都等你來測。
• 05:20 二、Claude 能自我檢查、變得更可靠之後，就能同時跑很多個 Claude，平行處理工作（multi-clauding）
  ↳ 第二層：Claude 會自己檢查、變得可靠之後，你才敢放手同時開好幾個 Claude，各做各的事。這就叫 multi-clauding。
• 05:20 三、Background Loops：把你的鍵盤從 hot path 拿掉，鍵盤不再是瓶頸，Claude 在背景持續跑 loop 做有用的事
  ↳ 第三層是 Background Loops。hot path 指流程中每次都得經過、最拖慢速度的那一段。以前每一步都要你敲鍵盤，現在讓 Claude 在背景自己一直跑。
• 05:56 練習：花 30 秒回想你上一個專案或功能是怎麼驗證的。不只是驗最後的成果，也包括迭代過程中怎麼確認方向對
  ↳ 小練習：回想上次完成一個功能時，你怎麼確認它是對的？不只看最後驗收，也想想做到一半時，你靠什麼判斷方向沒走偏。
• 07:08 講者認為大部分軟體工程任務，都可以拆成一連串步驟（或其中幾步的組合）來檢查成果。第一步是設計並撰寫程式碼
  ↳ 講者認為多數軟體工作都能照一套固定步驟檢查，不一定每一步都要做。第一步很直覺：想好怎麼做，把程式寫出來。
• 07:39 接著 build：跑 compilers、type checkers 等，失敗就回頭改程式碼再跑，反覆循環
  ↳ build 是把程式組裝成能執行的東西，過程中會自動抓錯。有錯就回去改、再 build，直到過關。這本身就是一個小循環。
• 07:39 然後執行產物，例如 Docker container、CLI 應用程式或 web server
  ↳ build 過了，就實際跑起來看看。Docker container 是打包好的執行環境，CLI 是在命令列操作的程式，web server 就是網站後台。
• 07:39 再檢查副作用（side effects）：例如打開瀏覽器，看 UI 元素有沒有出現在正確位置
  ↳ side effects 指程式執行後在外面造成的變化。例如打開網頁，看按鈕和欄位有沒有出現在該出現的位置。
• 08:10 也會查 logs 裡有沒有特定紀錄，或查資料庫，看資料狀態有沒有被正確修改
  ↳ 也可以看 logs，也就是程式執行時留下的紀錄，確認該出現的訊息有沒有出現。或者去資料庫看資料有沒有真的被改對。
• 08:10 跑 unit tests 確認沒有 regression、新功能沒弄壞其他功能，也最好幫這次的功能加新的 unit test
  ↳ unit test 是針對一小段功能的自動檢查。跑一遍能確認沒有 regression，也就是新東西沒弄壞舊功能。這次做的新功能也最好補一個測試。
• 08:10 最後部署到 staging，或者「很勇敢的話」直接上 prod
  ↳ staging 是正式上線前的預演環境，prod 是真正給使用者用的正式環境。跳過 staging 直接上 prod 風險高，所以講者才說「很勇敢」。
• 08:43 Claude 也能用一模一樣的流程驗證自己的成果、開發軟體。只要給它對的工具和指令，用你自己的做法去教它
  ↳ 重點是這套步驟不是人類專屬。你平常怎麼驗證，就把同樣的工具和做法交給 Claude，它就能照著自己檢查。
• 09:18 講者說 loop 是讓整件事運轉起來的關鍵，也是整場最重要的一張投影片
  ↳ 講者特別強調，前面那些驗證步驟要串成 loop（循環）才會發揮效果。這是整場最關鍵的觀念。
• 09:18 loop 是你幫 Claude 接通的一條自主迴路，讓它能針對某個任務或成功標準 hill climb
  ↳ loop 是你幫 Claude 搭好的自動循環。hill climb 原意是爬山，這裡指朝目標一步步改進。目標就是你訂的成功標準（success criteria）。
• 09:48 運作方式：Claude 寫程式 → 檢查有沒有失敗 → 失敗就 debug、再寫 → 一直循環到成功為止
  ↳ 流程很單純：寫程式、檢查，沒過就找原因修，再檢查，一直重來到過關為止。中間不需要你插手。
• 09:48 到達成功狀態時，你可以有信心它送來的 PR 品質比較高、而且真的能用
  ↳ 它送出前已經自己確認過能用，所以交來的 PR 比較可靠。PR 是改動申請，要經人審核才併進程式碼。你收到後不必從頭測起。
• 10:20 例子：講者個人網站的 signup 按鈕壞了，他只跟 Claude 說「讓 signup 按鈕能用」
  ↳ 實例：講者個人網站的註冊按鈕壞了。他沒解釋哪裡壞、該怎麼修，只丟一句「讓註冊按鈕能用」。
• 10:20 Claude 先寫程式、build app，然後點 signup 按鈕、打開瀏覽器
  ↳ Claude 先改程式、build，接著像真人一樣打開瀏覽器，自己去點那個按鈕看結果。
• 10:51 Claude 發現點了沒反應，就去讀 logs 找出問題，修程式、重新載入 app，反覆做到成功，最後交出一個真的能用的 PR
  ↳ 點下去沒反應，它就去翻 logs 找原因，然後修改、重新載入、再點，直到真的能用才交出 PR。
• 10:51 這張投影片的重點：只要做得到，就給 Claude 需要的工具和指令，讓它進入 loop
  ↳ 結論很簡單：能給的工具和指令就盡量給，讓 Claude 自己跑循環，不要每一步都等你確認。
• 11:23 verification 有很多種：UX 驗證、後端驗證，或包含 infra 的整個 app end-to-end 驗證。核心概念都一樣：給工具和指令，讓它進 loop
  ↳ 驗證分很多種：UX 看介面操作順不順，後端看背後的資料和邏輯，end-to-end 則從頭到尾連伺服器等 infra（基礎設施）一起測。做法都一樣。
• 11:54 只要 Claude 有對的工具和指令，你不用把指令寫得很細，它就能驗證上面這些面向
  ↳ 工具和指令備齊之後，你只要講出目標，不必寫詳細步驟，Claude 會自己去確認上面這些面向。
• 11:54 具體來說，要給 Claude 工具和指令讓它跑 loop，通常可以歸納成四件事（本段在此結束，細節在下一段）
  ↳ 要讓 Claude 跑得起 loop，需要準備的東西大致分成四類。這段先停在這裡，具體是哪四件要看下一段。

講者說，改善 Claude Code 體驗「槓桿最高的一件事」是什麼？