Claude Code 團隊如何使用 Claude Code（第 1/2 段）

🧑‍🏫 這支影片裡，Claude Code 團隊的成員分享他們自己怎麼用 AI 寫程式。重點是一年內工作方式的變化：從一步步盯著 AI，變成交代目標後放手讓它做。影片也講到，AI 模型進步很快，自己做的功能很快會過時，還有他們怎麼讓 AI 在雲端一直做事、怎麼審程式碼。你平常也用 AI 工具，看完可以想想自己是不是還在「逐步盯」，還是已經可以「交代目標」。

• 00:00 講者加入 Claude Code 快一年。一年前還在對 Claude Code 下 prompt、給回饋、按同意 permission prompts，到現在變化很大
  ↳ 講者在 Claude Code（Anthropic 做的 AI 寫程式工具）待了快一年。一年前要一句句下 prompt（給 AI 的指令），AI 每個動作都要按同意（permission prompts），現在不必這樣盯了。
• 00:30 講者現在很多工作都交給 Claude Tag 做。交辦的問題遠比早期的「實作這個 class」「寫這個 function」複雜、困難得多
  ↳ 以前交給 AI 的是「寫一小段程式」這種零件級的工作。現在講者把整個難題直接丟給 Claude Tag，交辦的範圍和難度都大很多。
• 00:30 Claude Tag 是住在 Slack 裡的 Slack native agent，能查到產品脈絡和團隊對產品做過的決策，所以判斷做得更好
  ↳ Claude Tag 是在 Slack（公司常用的聊天軟體）裡運作的 agent（能自己動手完成任務的 AI）。它看得到團隊討論過的產品背景和決定，所以判斷比較準。
• 01:00 另一位講者 70～80% 的工作在 Claude Tag 上完成，約 20% 會打開 TUI 或 desktop app 來精修，或是想細部盯著 Claude 的時候用
  ↳ 另一位講者七八成的工作直接在 Slack 交給 Claude Tag。剩下兩成才打開 TUI（在終端機裡用文字操作的介面）或桌面版 app，用來細修，或近距離看 Claude 怎麼做。
• 01:31 工作方式從在意 transcript、在意每一次 tool call 和模型的每個決策，轉成只看大方向：設定目標，交給模型去達成
  ↳ 以前會逐字看 transcript（AI 工作過程的完整紀錄），也會檢查每次 tool call（AI 叫用工具，例如讀檔案、跑指令）。現在比較像主管，講清楚目標就放手。
• 01:31 軟體開發生命週期變了很多。打造 Claude Code 時做的各種 primitives 最後串成 Claude Tag，從驗證、code review、腦力激盪到監控都靠它
  ↳ 寫軟體的整個流程都變了。做 Claude Code 時累積的 primitives（最基本的功能積木）後來組成 Claude Tag，檢查成果、審程式碼、發想點子到監控系統都用它。
• 02:03 產品背後的技術都有保存期限。以前是好幾年，現在 AI 模型大約每兩個月就徹底變一次，而且間隔可能越來越短
  ↳ 產品背後的技術都會過時。以前一套技術能撐好幾年，現在 AI 模型大約兩個月就大換一輪，而且可能越來越快，今天好用的做法很快就不適用。
• 02:33 做產品要站在最前線、甚至超前一點去摸那條邊界，同時也要讓現在用模型的人得到價值。這種平衡一半是藝術、一半是科學
  ↳ 做產品要一直去試最新模型做得到什麼，甚至提前押注；但也要顧到現在的使用者，讓他們用得有價值。怎麼拿捏沒有公式，一半靠直覺、一半靠驗證。
• 03:04 講者第一次有「乘上浪頭」的感覺是做 to do list，大約在 Sonnet 3.5 的時期，當時模型還做不了 long horizon work
  ↳ 講者第一次覺得自己跟上了模型進步的浪，是做 to do list（待辦清單）功能的時候，大約是 Sonnet 3.5（Claude 較早的一代模型）時期，那時模型還撐不了步驟多、耗時長的任務（long horizon work）。
• 03:04 那時給模型五件事，它做完三件就放棄；給它一份 to do list 後表現就變得很好
  ↳ 當時交代五件事，模型常常做完三件就停了。讓它先列一份待辦清單，再一項項完成，就比較不會漏，表現明顯變好。
• 03:34 一年後 to do list 已經不太需要了，因為有更複雜的記憶狀態等東西可以依靠。所以對自己做出來的東西不要太執著，它們很快就會消失
  ↳ 一年後，模型有更完整的方式記住自己做到哪裡，待辦清單就沒那麼必要了。講者的提醒是：自己做的功能別太捨不得，它可能很快就被淘汰。
• 04:04 放進 Claude Code harness 的很多功能是為了彌補模型目前的失敗模式；模型變強後，這些功能就能拿掉
  ↳ harness 指包在模型外面的那一層程式和功能。裡面很多功能是為了補模型目前容易出錯的地方，模型變強後，這些補丁就可以拆掉。
• 04:04 另一方面，Claude Code 做的任務越來越大、越來越難，模型需要不同的工具才能保持連貫、做好，工具會隨任務範圍改變
  ↳ 反過來說，交給 AI 的任務越來越大、越來越難，模型需要新工具才能從頭到尾不走偏。所以工具不是只會越拆越少，也會跟著任務大小一直換。
• 04:35 Claude Code 團隊的特別之處是要緊跟模型進度，有時得很快做大改動，例如由小團隊做全新的 proactive agent，同時還在改寫 permission 系統、做 artifacts
  ↳ 團隊得跟著模型進度快速轉向。例如派一個小組從零做 proactive agent（會主動做事、不用等人叫的 AI），同時還在改寫權限系統、做 artifacts（後面會講）。
• 05:06 講者形容團隊像軟體開發未來走向的「精神時光屋」（hyperbolic time chamber），大多數產品的保存期限沒這麼短
  ↳ 講者把團隊比作《七龍珠》的精神時光屋（hyperbolic time chamber）：外面一天，裡面一年。他們很短時間內就遇到別人要很久才碰到的變化，大多數產品不會汰換得這麼快。
• 05:06 身為工程師也要掌握模型能力往哪裡發展，並持續更新自己對 Claude 的心智模型（mental model）
  ↳ 工程師不只要會寫程式，也要知道模型接下來會在哪些地方變強，並持續更新自己的 mental model，也就是心裡對 Claude 擅長和不擅長什麼的認識。
• 05:37 ask user question tool：想讓 Claude 能和使用者互動。一開始放在規劃之後，後來改成 Claude 可以呼叫的工具
  ↳ ask user question tool 是讓 Claude 在做事途中向使用者發問的工具。原本只在規劃完成後問，後來改成 Claude 覺得需要時，自己決定叫出這個工具來問。
• 05:37 設計這個工具花了很久，要讓 Claude 把它呼叫好很難；做出來之後 Claude 才開始呼叫得很好
  ↳ 這個工具花了很久設計，難在讓 Claude 在對的時機、用對的方式發問。調好之後，Claude 才真的用得好。
• 06:08 最近講者反而不常用這個工具，改成讓 Claude 做一個 artifact 來問問題；artifact 是 HTML，裡面有圖表和 mockup
  ↳ 最近講者反而少用這個工具，改請 Claude 做一個 artifact 來提問。artifact 是一個網頁（HTML 格式），裡面可以放圖表和 mockup（畫面草圖）。
• 06:08 團隊的做法是先建立各種 primitives（例如 permissions 怎麼運作、視覺化怎麼運作），再把它們一層層疊起來
  ↳ 團隊的做法是先把最基本的功能做好，例如權限怎麼管、東西怎麼顯示，再一層層往上疊，組成更大的功能。
• 06:39 loops 的由來：以前 agent 都在自己筆電上跑，下班回家要關筆電，agent 就停了
  ↳ loops（讓 AI 持續循環工作的做法）起點很實際：以前 agent 都在自己的筆電上跑，下班闔上筆電，它的工作就停了。
• 07:10 接著改用公司遠端託管的開發機（remote hosted developer boxes），筆電不用一直開著；缺點是要 ssh 連回去
  ↳ 後來改用公司在遠端架好的開發電腦（remote hosted developer boxes），筆電關了也照樣跑。缺點是每次都要用 ssh（從遠端登入別台電腦的方式）連回去。
• 07:10 之後出現 Claude Code on the web：託管的 container，可以一直在背景執行
  ↳ 再來出現 Claude Code on the web：程式跑在雲端的 container（打包好、獨立的執行環境）裡，可以一直在背景做事，不必有人守著。
• 07:42 用 container 跑開發環境要先開通存取權限，設定有點麻煩，但講者認為很值得，生產力提高了 10 倍
  ↳ 要讓 container 裡的開發環境能動，得先開好各種存取權限，設定有點麻煩。但講者覺得很值得，生產力提高了約 10 倍。
• 07:42 這就是從「Claude 在本機跑」走到「Claude 需要在雲端跑」的過程
  ↳ 整個過程就是：Claude 從「在你電腦上跑，你關機它就停」，變成「在雲端跑，不受你的電腦影響」。
• 08:12 在雲端跑就能做 routines。例如每天看所有收到的回饋，依重要程度分類，再把有高度把握的問題修掉
  ↳ 在雲端跑，就能設定 routines（定期自動執行的例行任務）。例如每天把收到的使用者回饋全看過、依輕重分類，再把有把握的問題直接修掉。
• 08:12 這就是 Boris 常講的 loop 歷程：打破單一 session 的界線，改成對更高一層的東西下 prompt，由它去修 bug、替你辦事
  ↳ 這就是 Boris 常講的 loop：不再一段對話（session）一段對話地盯著 AI，而是對更上一層下指令，讓它自己去修 bug、替你辦事。
• 08:43 code review 與安全：現在產生的程式碼越來越多，沒人想把工作變成只在 review code；團隊目前有 code review bot
  ↳ 講到 code review（程式碼合併前由別人檢查）和安全：AI 寫出的程式碼越來越多，但沒人想整天只在審程式碼，所以團隊現在有負責審查的 bot（自動程式）。
• 09:16 Claude 幫人類 reviewer 決定時間和精力要花在哪。傳統人工 review 常挑三個小 nit pick，只是為了表示自己有讀過
  ↳ Claude 幫人類審查者判斷力氣該花在哪。傳統人工審查常挑三個 nit pick（雞毛蒜皮的小毛病），多半只是為了表示「我有看過」。
• 09:47 這些小地方現在可以交給 Claude 找出來並自動處理，已經不是人工 review 的重點
  ↳ 這類小毛病現在可以交給 Claude 找出來並自動處理，已經不是人工審查的重點。
• 09:47 人工 review 的重點是大局，例如 API 為什麼這樣設計、service 邊界為什麼畫在那裡，這些 Claude 寫 PR 時可能還沒完全理解
  ↳ 人要看的是大方向：API（程式之間溝通的介面）為什麼這樣設計、service（系統裡各自分工的服務）的界線為什麼這樣劃。Claude 寫 PR（交給別人審的程式修改）時未必懂這些原因。
• 10:17 Claude 可以把這類資訊整理進 code review 交給人類，讓人不必逐行挑小毛病，思考的抽象層次也跟著提高
  ↳ Claude 會把這些需要人判斷的重點整理進審查內容，人就不必逐行挑錯，可以把腦力花在更高層次的問題上。
• 10:17 code review 是團隊第一次做大規模 fan out：大範圍搜尋可能的 bug，再彙整（coalesce）結果
  ↳ code review 是團隊第一次大規模 fan out：分成很多路，同時大範圍找可能的 bug，再 coalesce（彙整）成一份結果。
• 10:47 這種做法就是他們說的 test time compute：用大量推論時間把思考和運算投入一個問題
  ↳ 這就是他們說的 test time compute：在模型處理問題的當下，投入大量時間和運算讓它多想幾輪，而不是只想一次就回答。
• 10:47 這個做法後來發展出 workflows，Sid 表示 code review 是 workflows 誕生的重要原因
  ↳ 這種「分頭找、再彙整」的做法，後來發展成他們稱為 workflows 的東西。團隊成員 Sid 說，code review 是 workflows 誕生的重要原因。

影片中一位講者說，自己現在大約有多少比例的工作是在 Claude Tag 上完成？