Claude Code 團隊如何使用 Claude Code（第 2/2 段） ☕ Buy me a coffee

🧑‍🏫 這是 Claude Code 團隊分享自己怎麼用 Claude Code 的後半段，主要講三件事：用 workflows 讓 Claude 分頭做事、再把結果收斂回來；在 Slack 上用 Claude Tag 跟 Claude 合作；以及工程師這份工作正在怎麼變。就算你不寫程式，也能學到「大問題先交給 AI 拆開做，再請它幫你篩選」的思路。

• 11:11 workflows 最早是從 code review 來的：做法很像自訂的 harness，讓 Claude 先 fan out 出去找 bug
  ↳ workflows（讓 Claude 寫程式指揮多個 AI 小幫手分工的做法）最早用在 code review（檢查程式碼有沒有問題）：先搭好一套固定流程（harness），再讓 Claude 分頭（fan out）大範圍找 bug。
• 11:11 每個找到的 bug 再做 adversarial review，也就是從三個不同觀點檢查這個 bug 是不是真的存在
  ↳ 找到的 bug 不會直接相信，要再做 adversarial review（刻意唱反調的審查），從三個角度去挑戰它，確認是真問題還是誤報。
• 11:41 這樣可以濾掉大量 bug，只留下最重要、真的需要你處理的那幾個
  ↳ 分頭找會冒出一大堆疑似問題，很多是假的或不重要。經過反方審查篩掉以後，你只需要看真正值得處理的那幾個。
• 11:41 同一套做法不只能用在 code review，也能處理效能問題，或做一般的 deep research
  ↳ 這套「先撒網、再嚴格篩」的方法不只能查程式錯誤，也能找程式變慢的原因，或做 deep research（大量蒐集資料、整理成報告）。
• 11:41 生活上的例子：下週要帶爸媽去 Tahoe，想知道住哪裡好，也可以用 fan out 來查
  ↳ 私人生活也用得上。例如下週要帶爸媽去 Tahoe（美國知名的湖區度假地）玩，要挑住宿，也能讓 Claude 分頭去查。
• 12:11 Claude 很會自己搭 harness：它能決定 fan out 的形狀和 topology、怎麼把一個 agent 的輸出接到下一層，最後再摘要給你
  ↳ 流程不用你自己設計。Claude 會決定分幾路、怎麼串接（topology，分工的結構），把一個 agent（會自己動手做事的 AI 助手）的結果交給下一層，最後整理成摘要給你。
• 12:11 旅遊的例子：先發大約十個搜尋請求（Tahoe 的 bathhouse、hotel、Airbnb 等）
  ↳ 拿旅遊來說，第一步先同時發出大約十個搜尋，每個查一類，像是 Tahoe 的泡湯澡堂、飯店、Airbnb（民宿出租平台），先把範圍拉大。
• 12:41 拿到一堆結果之後，交給一些 agents 排序、挑出最有趣的，再由其他 agents 驗證，最後產出結果
  ↳ 結果一大堆以後，先交給幾個 agents 評分排序、挑出最有意思的，再派另一批 agents 查證資料對不對，最後才把成品交給你。
• 12:41 fan out 之後資訊會多到看不完，必須再篩選收斂，本質上是個 MapReduce 問題，目的是整理成人讀得下去的量
  ↳ 分頭查的代價是資訊多到看不完，所以一定要再篩選收斂。這就像 MapReduce（先拆開大量處理、再彙整成結果的經典做法），目的是縮到人讀得完的量。
• 13:12 這種情況要建立信心，方法就是在問題上投入更多 test time compute
  ↳ 想信任這些結果，就讓 AI 多花力氣。test time compute 指 AI 回答問題時投入的運算量，多查幾遍、多驗證幾次，結果就比較可靠。
• 13:12 workflows 是由 agent 寫程式來 orchestrate subagents，所以同時具備 deterministic 程式碼的行為和 agentic LLM 的行為
  ↳ workflows 是 agent 寫程式去 orchestrate（指揮調度）一群 subagents（被分派子任務的 AI 小幫手）。它有程式的 deterministic（照步驟跑、結果可預期），也有 AI 的彈性判斷。
• 13:42 舉例來說，Claude 寫的 for loop 不會漏掉任何項目，每個項目都會套用同樣的做法，這點讓人更信任它
  ↳ 例如 Claude 寫一個 for loop（讓清單上每一項都做一次的程式指令），一百項就會確實做一百次，不會漏，而且每項處理方式都一樣，所以比較讓人放心。
• 13:42 Robert 正在打造 Claude Tag，而且團隊非常積極地用 Claude Tag 來開發 Claude Tag 本身
  ↳ Robert 正在開發 Claude Tag（在 Slack 裡跟 Claude 協作的產品）。團隊也大量用 Claude Tag 來開發 Claude Tag 本身，等於自己的產品天天自己用。
• 14:12 Robert 的工作重點是讓開發環境和 dev loop 對 Claude 很好用，讓它能做完人類開發會做的所有事，並做 end to end 測試
  ↳ Robert 負責讓開發環境和 dev loop（寫程式、執行、測試、修改的循環）對 Claude 好上手，讓它能做完人類工程師會做的事，還能跑 end to end（從頭到尾實際走一遍）的測試。
• 14:42 軟體越來越複雜、整合程度越來越高，要讓 Claude 自己完成開發和測試也就越難，這是 Robert 的主要重點
  ↳ 軟體越複雜、跟越多系統串在一起，要 Claude 自己寫完又自己測好就越難。這個難題正是 Robert 主要在解決的。
• 14:42 Claude Tag 是第一次讓使用者介面和 transcripts 更完全地分開，等於在離 Claude 實際輸出的 tokens 多一層抽象的地方工作
  ↳ Claude Tag 第一次把介面和 transcript（Claude 完整的輸出紀錄）徹底分開。你看到的不再是 Claude 產生的每一個字（tokens），而是它整理過、決定要跟你說的話。
• 14:42 你在 Slack 看到的 Claude Tag 訊息，其實是它呼叫 tool 傳給你的
  ↳ 你在 Slack（職場常用的聊天軟體）看到 Claude Tag 的訊息，並不是它的思考直接跑出來，而是它主動用「發訊息」這個 tool（它能使用的功能）傳給你的。
• 15:14 它的內部獨白在 Slack 上看不到，不過有連結可以看完整 transcript；主要的介面是 messaging tool
  ↳ 它邊做邊想的內容不會出現在 Slack 上，想看的話可以點連結看完整 transcript。平常你跟它互動，主要就是透過這些訊息。
• 15:14 一開始覺得這層抽象有點可怕，因為看不到 Claude 當下在想什麼；但也很解放，因為由 Claude 自己決定要說什麼、什麼時候說
  ↳ 一開始會不安，因為看不到 Claude 當下在想什麼；但也很輕鬆，因為什麼時候回報、回報什麼，都由 Claude 自己判斷。
• 15:46 不再盯著它呼叫哪些 tools、傳什麼參數，等於被迫 let Claude cook，也因此發現模型已經好到不用細看 transcript 也能拿到好結果
  ↳ 以前習慣盯著它用了哪些功能、填了什麼參數，現在看不到了，只好 let Claude cook（放手讓它發揮）。結果發現模型已經強到不用盯細節，也能交出好成果。
• 16:16 講者開發新工具需要很多人支持：先問 Claude Tag 該找誰聊，找出 stakeholders，再請它做 mockups 和 implementation，全程在 Slack，用手機也能看
  ↳ 講者做新工具需要很多人支持。他先問 Claude Tag 該找誰談，列出 stakeholders（跟這件事有關的人），再請它做 mockups（畫面草稿）和實作，全程在 Slack 上，用手機也能跟進。
• 16:16 不確定工具到底好不好用，所以在裡面加了很多 events，部署到內部觀察大家怎麼用
  ↳ 他不確定工具到底好不好用，所以在工具裡埋了很多 events（記錄使用者做了哪些動作的追蹤點），先發給公司內部用，看大家實際怎麼操作。
• 16:47 Claude Tag 幫他監控使用狀況，有人給回饋時會 tag 他，讓他回應更快，也更有把握工具真的能用
  ↳ Claude Tag 幫他盯使用狀況，有人留回饋時會在 Slack 上 tag 他，他就能馬上回應。有真實的使用紀錄，他也更確定工具真的派得上用場。
• 16:47 想改善 funnel 時，他原本要叫 Claude 照自己的點子做，後來改成請 Claude 自己提想法，自己的點子只當範例，在更高的層次和它合作
  ↳ 想改善 funnel（使用者從開始到完成目標的步驟，每一步都有人流失）時，他不再叫 Claude 照他的點子做，而是請 Claude 自己提方案，他的想法只當參考。
• 17:18 這裡有三件事：verification、code review、取得回饋（接上 data store 或 event store，例如 metrics、Slack、GitHub issues），三者都是 Claude Code 的 primitives
  ↳ 這裡有三個關鍵：verification（驗證有沒有做對）、code review，以及收集回饋（接上數據、Slack、GitHub issues 等資料來源）。它們都是 Claude Code 的 primitives（基本積木功能）。
• 17:49 團隊特別重視 verification：Claude 幫 Claude Code 開 PR 時會先測試，並傳來預期畫面的截圖
  ↳ 團隊特別重視驗證。Claude 幫 Claude Code 開 PR（送出一份程式修改、請人審核）之前會先自己測試，還會附上改完後畫面應該長怎樣的截圖。
• 17:49 驗證時，講者先請 Claude 錄下自己操作 TUI 的過程，之後為了保險又自己 clone 下來試用；他覺得以後可能連 clone 都不用
  ↳ 驗收時，講者先請 Claude 錄下自己操作 TUI（終端機裡的文字介面）的過程。為了保險，他又 clone（把程式碼下載到自己電腦）親自試用，但他覺得以後可能連這步都省了。
• 18:20 回顧過去一年：從 Claude Code 開始，陸續加入 auto mode、memory、workflows 等 primitives，開發者要追的東西很多
  ↳ 回顧這一年：從 Claude Code 開始，陸續多了 auto mode（不必每一步都等你確認）、memory（記住過往資訊）、workflows 等功能，工程師要跟上的東西很多。
• 18:51 現在當軟體工程師的難處在於要不斷想：現在做得到什麼？怎麼自動化更多？怎麼退一步想得更大？
  ↳ 現在當工程師最難的不是寫程式，而是要一直問自己：AI 現在做得到哪裡？還有什麼能自動化？能不能退一步，想更大的目標？
• 19:22 被問到懷念什麼：講者以前很享受 performance engineering，現在 Claude 做得比他好，但他仍然享受得到效能提升的成果
  ↳ 被問到懷念什麼，講者說他以前很愛 performance engineering（深入研究系統、讓它跑得更快）。現在 Claude 做得比他好，他雖然不自己動手，還是享受得到變快的成果。
• 19:22 他現在更專注在快速產生新點子：從 idea 到 prototype 再到 production 快很多
  ↳ 他現在把力氣放在多想新點子。從想法到 prototype（能動的雛形），再到 production（正式上線給人用），速度都快了很多。
• 19:52 思維從深入鑽研細節，轉成站得更遠看全局；對單一領域的精通程度相對降低
  ↳ 他的思考方式從鑽進細節，變成站遠一點看全局。代價是對單一領域不再鑽得那麼深。
• 20:23 另一位講者很注重細節，曾為個人網站用 CSS 重現 Mac OS 10.4 aqua 按鈕，疊了好幾層 radial gradients，大概花了一天
  ↳ 另一位講者很講究細節，曾經為個人網站用 CSS（控制網頁外觀的語言）重現 Mac OS 10.4 的水亮 aqua 按鈕，疊了好幾層 radial gradients（由中心往外擴散的漸層），大約花了一天。
• 20:23 像這種事現在 Claude 就能代勞，他不會再自己手動做
  ↳ 像這種要磨很久的細工，現在交給 Claude 就能做出來，他不會再自己一層一層手動調。
• 20:54 他想起 7、8 歲時很想做電玩，那時還不會寫程式，就用 PowerPoint 畫圖形、做可以點的東西
  ↳ 他想起七、八歲時很想做電玩，但那時還不會寫程式，只好用 PowerPoint 畫圖形、設定點擊效果，做出可以點來點去的東西。
• 20:54 現在 Claude 讓整個軟體工程都變得可以碰得到：不再因為技術能力不夠而卡住，只要說出目標、拆解問題，再和 Claude 一起完成
  ↳ 現在有了 Claude，寫軟體變得人人都碰得到：不會因為技術不夠就卡住，只要講清楚目標、把問題拆小，再跟 Claude 一起完成就好。
• 21:25 軟體工程是一直在變的職業：10 到 20 年前是不用任何框架手寫 JavaScript，後來才有了框架、compilers 等工具
  ↳ 軟體工程本來就一直在變。十到二十年前做網頁要手寫 JavaScript（讓網頁能互動的程式語言），不用任何框架（現成的開發骨架）；後來才有框架、compilers（把程式碼轉成電腦能執行的格式）等工具。
• 21:56 現在變得更快，但本質沒變，還是用工具打造好軟體、解決問題，只是要解的問題不同了
  ↳ 現在變得更快，但核心沒變，一樣是用工具做出好軟體、解決問題，只是要解決的問題不一樣了。

在 code review 的 workflow 裡，對每個找到的 bug 做 adversarial review 時，會請 Claude 從幾個不同觀點檢查？