回顧 Claude Code 的這一年 ☕ Buy me a coffee

🧑‍🏫 這支影片是 Claude Code 團隊回顧這一年的變化。一年前它只會做簡單的程式工作，現在已經能讓一大群 AI 自己寫程式、自己測試、自己修 bug。影片也講到工作方式怎麼跟著變：不是工程師的人也開始寫程式，大家更看重的是點子好不好。就算你不寫程式，也能從中看出 AI 工具接下來的方向。

• 00:00 Claude Code 剛發布時只是一支小影片，貼到 Slack 只有大約兩個人回應；當時只擅長很簡單的工程任務，委婉說就是還不太好用
  ↳ Claude Code（讓 Claude 在電腦上幫你寫程式的工具）剛推出時只有一支小影片，貼到 Slack（公司內部聊天軟體）只有兩個人回應。那時它只會做簡單的程式工作，老實說不太好用。
• 00:31 才過一年，現在是成群的 agents：用 agent 去提示其他 agent，層層往下，形成上千個 agent 的樹狀結構
  ↳ 一年後變成一大群 agent（會自己動手完成任務的 AI 助手）。一個 agent 把工作分派給其他 agent，下一層再往下分，最後像組織圖一樣長出上千個。
• 00:31 最重要的觀念：Claude 犯錯時不是叫它改做法，而是叫它寫進 CLAUDE.md 或做成 skill，這樣 Claude 就能一直跑下去
  ↳ 最核心的心法：Claude 做錯時不要只當場糾正，要請它把正確做法寫進 CLAUDE.md（它每次都會讀的說明檔），或做成 skill（教它做某件事的一套做法）。這樣它就不會重犯同樣的錯，能一直自己做下去。
• 01:02 verification 非常重要。大家常誤以為指的是 unit tests、lint、type check，但這些本來就很好自動化，也早就自動化了
  ↳ verification（驗證，確認做出來的東西真的能用）很關鍵。但它指的不是 unit tests（測一小段程式）、lint（檢查寫法規範）、type check（檢查資料型別），這些早就自動化了。
• 01:32 對 agent 來說，驗證指的是「agent 能不能把東西實際跑起來」；要想清楚怎麼做得花點腦力，通常不直觀
  ↳ 對 agent 來說，驗證是指它能不能自己把做好的東西開起來、實際用用看，就像做完菜自己先嚐一口。至於怎麼讓它做得到，常常要花點心思才想得出來。
• 01:32 Opus 4 時期叫 Claude 做完功能後在 bash 自己測試，它開了一個 Claude CLI 測自己寫的功能，當時覺得很驚人
  ↳ 在 Opus 4（當時的 Claude 模型）時期，團隊請 Claude 做完功能後在 bash（輸入指令的文字視窗）自己測試。結果它開了一個 Claude CLI（指令列版本的 Claude）來測自己寫的東西，大家都很驚訝。
• 02:02 現在 iOS simulator、Android simulator、desktop 電腦都已經有這種自我測試迴圈，大家已經不覺得意外
  ↳ 現在這種「自己寫、自己開來測」的循環，在 iOS 和 Android 的 simulator（在電腦上模擬手機的軟體）和桌上型電腦都做得到，大家已經見怪不怪。
• 02:02 團隊工程師做了 desktop development skill，教 Claude 怎麼執行本機的 desktop app
  ↳ 團隊的工程師做了一個 skill，專門教 Claude 怎麼在本機把 desktop app（桌面版應用程式）開起來，這樣它就能測自己改過的地方。
• 02:32 碰到 staging 環境出問題時，讓 Claude 讀 Slack 判斷 staging 是不是掛了、有沒有人遇過；除錯完後叫它更新 desktop development skill
  ↳ staging 環境（正式上線前給團隊測試用的環境）出狀況時，讓 Claude 去翻 Slack，看是不是整個掛了、有沒有人遇過。問題排除後，再請它把這次的經驗補進 skill。
• 02:32 這個 skill 會啟動本機 desktop app，用 computer use 點來點去；加新 UX 時會點擊觸發、測 edge cases，有問題就修正再檢查一次
  ↳ 這個 skill 會開啟 app，用 computer use（讓 Claude 看螢幕、操作滑鼠鍵盤）實際點點看。加了新的 UX（使用者操作體驗）時，它會觸發看看、測 edge cases（少見的極端狀況），有錯就改完再測一次。
• 03:03 團隊裡人人都寫 code，連 PM 也寫；因為基本上是 Claude 在寫 code，重點變成你的點子是什麼
  ↳ 團隊每個人都寫程式，連 PM（產品經理，負責決定要做什麼）也寫。因為實際寫程式的是 Claude，差別已經不在會不會寫，而在你想做什麼、點子好不好。
• 03:34 掌握產品與商業脈絡、會思考設計和使用者的人更容易想出好點子，各種角色正在融合
  ↳ 所以懂產品、懂生意、會思考設計和使用者感受的人比較容易想出好點子。工程師、PM、設計師之間的界線正在變模糊。
• 03:34 設計師 Megan 一開始送 PR 修按鈕時讓人很震驚，但 code 品質不錯，現在已經完全是常態
  ↳ 設計師 Megan 第一次送 PR（把自己的修改交給團隊審核、合併的請求）修按鈕時，大家都嚇一跳，但程式品質不錯。現在設計師送 PR 已經是家常便飯。
• 04:04 在合作的企業裡，通常工程師先用 Claude Code，接著工程相關角色看到後也跟著試用
  ↳ 在合作的企業裡，通常是工程師先開始用，接著工作跟工程相關的同事看到效果，也會跟著試用。
• 04:04 設計師直接在 app 裡做原型和修改，不用找工程師；PM 也改 app；finance 團隊在 Claude Code 做財務預測（projections）
  ↳ 設計師直接在 app 裡做原型、改畫面，不必等工程師；PM 也自己改 app；連財務團隊都用它做財務預測。
• 04:34 資料科學家人人螢幕上都開著 Claude Code，它在不同角色間非常好用
  ↳ 資料科學家（分析數據的人）幾乎每個人螢幕上都開著 Claude Code。這表示它不只工程師好用，不同職務都用得上。
• 04:34 routines 案例：一位推出全產品 voice mode 的工程師設了 routine，監聽所有 voice mode 相關的 ticket、GitHub issue、bug report
  ↳ routines（設好後會自動盯著某類事情、叫 Claude 去處理的任務）的例子：負責 voice mode（用說話操作）的工程師設了 routine，專門盯相關的 ticket（工單）、GitHub issue（專案問題回報）、bug report（錯誤回報）。
• 05:07 他的 Claude 會主動接手、送出修正，再把 PR 通知給他；成功後他又加了 routine 監聽其他沒人回應的回饋
  ↳ 這位工程師的 Claude 看到問題會主動接手修好，再通知他去看 PR。效果很好，他又多設一個 routine，專盯其他沒人回應的使用者回饋。
• 05:37 他還有一個 routine 專找超過五小時沒人回應的 bug report 並送出修正，容易驗證的他就直接合併
  ↳ 他還有一個 routine 專找超過五小時沒人回的錯誤回報，並送出修正。修正內容容易確認對錯的，他就直接合併進程式碼。
• 05:37 講者自己出的 bug 還沒處理，就先被別人的 Claude 修好了；現在常常發生「已經有別人的 Claude 在處理」
  ↳ 講者自己弄出來的 bug 還沒動手處理，就已經被同事的 Claude 修好了。現在很常遇到「這個已經有別人的 Claude 在處理了」。
• 06:07 agent SDK 是第一次讓人以程式方式使用 Claude Code，但一開始不知道要拿來做什麼；routines 是第一個明顯的應用
  ↳ agent SDK（讓工程師用寫程式的方式操控 Claude Code 的工具包）推出時，大家一開始不知道要拿它做什麼，routines 是第一個明顯好用的應用。
• 06:07 現在 routines 負責所有 code review、盯著每個 PR；以前要自己回 review 意見、修 CI、rebase，講者已經很久沒做了
  ↳ 現在 code review（審查程式修改）和盯每個 PR 都交給 routines。以前要自己回審查意見、修 CI（每次改動後自動跑的檢查）、做 rebase（把修改接到最新版本上），講者已經很久沒做了。
• 06:38 跟 Claude 同步在 CLI 工作時，講者以前常用 plan mode，現在改用 auto mode
  ↳ 講者在 CLI 裡跟 Claude 即時一起工作時，以前常用 plan mode（先列計畫給你看，同意後才動手），現在改用 auto mode（讓 Claude 一路做下去，權限交給另一個模型把關）。
• 06:38 新模型不再需要規劃步驟：這對 Opus 4 到大約 4.5 很重要，從 four six 開始、到 four seven 就確定不需要了
  ↳ 從 Opus 4 到大約 4.5，模型都需要先規劃步驟；到 4.6 開始不太需要，到 4.7 就確定不用了。模型夠聰明，可以邊做邊想。
• 07:09 有些人還是用 plan mode，因為想留下那份產出；講者全部用 auto mode，開一個 Claude 後就去開下一個，不用在旁邊盯
  ↳ 有些人還在用 plan mode，是想把那份計畫留下來。講者全部用 auto mode：交代完一個 Claude 就去開下一個，不用守在旁邊盯。
• 07:09 早期採用 permission prompts：每跑一個工具就問你要不要允許。一年半前沒有 classifiers，模型也沒現在 aligned，那已是當時最好的做法
  ↳ 早期靠 permission prompts：Claude 每做一步就問你准不准。一年半前還沒有 classifiers（自動判斷好壞的分類模型），模型也不像現在這麼 aligned（照人的意圖做事），所以這已經是當時最好的做法。
• 07:40 auto mode 把請求交給另一個模型做安全檢查；可疑或不安全的指令會被拒絕，你之後可以再手動允許
  ↳ auto mode 會把「這一步能不能做」交給另一個模型審查。看起來可疑或危險的就擋下，你之後覺得沒問題，可以再手動放行。
• 07:40 人性使然，99% 請求都按同意時眼睛就會放空；所以團隊認為 auto mode 比逐一看權限提示更安全，你只要注意最重要的事
  ↳ 一百次裡有九十九次都按「同意」，人自然會不看內容就按下去。所以團隊認為交給模型把關反而更安全，人只要留意真正重要的事。
• 08:11 安全要真正做對，就得持續 red teaming、pentesting、建立 threat model，思考會被怎麼攻擊、怎麼被 prompt injection
  ↳ 安全要做對，就要持續 red teaming 和 pentesting（找人扮成駭客實際攻擊自己的系統），建立 threat model（列出可能被攻擊的方式），並提防 prompt injection（在內容裡藏指令騙 AI 照做）。
• 08:41 正因為信任 agent，才能放手去開第二個 agent；不信任就做不到
  ↳ 敢同時開好幾個 agent，前提是信得過它們會安全地做事。如果不放心，就只能守著一個，沒辦法放手。
• 08:41 推出前先收集數千份完整 agent 軌跡加 permission prompt 的 transcript，讓 auto mode 判斷安不安全，結果表現極好
  ↳ 推出前，團隊收集了數千份 transcript（agent 的完整操作紀錄，包括每一次權限詢問），讓 auto mode 判斷每一步安不安全，結果表現非常好。
• 09:14 再請 red teamers 嘗試 prompt injection、入侵 codebase，據此做成 evals 確保全部被拒；內部團隊也來攻擊，再持續改進
  ↳ 接著找攻擊專家試著騙它、入侵程式碼，再把這些攻擊做成 evals（固定的測驗題，用來檢查模型表現），確保全部被擋下。內部同事也加入攻擊，團隊再持續改進。
• 09:14 目標不只防禦現有真實漏洞，也要擋住團隊能想到最聰明的攻擊
  ↳ 目標不只是擋下真實發生過的漏洞，也要擋下團隊能想到最聰明、最刁鑽的攻擊。
• 09:45 在模型上做產品很特別，很多過去的工程經驗要丟掉重學；許多功能講者一開始覺得行不通，結果常是自己錯了
  ↳ 在 AI 模型上做產品很不一樣，很多以前的工程經驗得丟掉重學。講者坦承，好幾個一開始覺得行不通的功能，後來都證明是自己看走眼。
• 10:16 auto mode 就是例子：一開始覺得把 prompt 交給模型判斷不可能行，結果實測效果非常好
  ↳ auto mode 就是一個例子：一開始覺得讓 AI 判斷指令安不安全根本不可能行得通，實際測下來效果卻非常好。
• 10:16 講者愛用 loop。一年半前的轉變：工程師互動的對象不再是 source code，而是 agent，由 agent 寫 code
  ↳ 講者很愛用 loop（讓 Claude 反覆自動執行某件工作的機制）。一年半前出現第一次轉變：工程師不再直接改程式碼，而是跟 agent 溝通，由 agent 去寫。
• 10:47 現在是下一次躍進：不再直接跟 agent 講，而是跟 loop 或 routine 講，由它們替你提示 Claude；一年半內兩次大躍進
  ↳ 現在是第二次轉變：你不直接跟 agent 講，而是交代給 loop 或 routine，由它們替你指揮 Claude。一年半內工作方式就換了兩次。
• 10:47 引用 90 年代 Harvard Business Review 案例：電腦都來了，為什麼看不到生產力提升？
  ↳ 講者引用 90 年代《哈佛商業評論》的案例：公司都買了電腦，為什麼整體生產力卻看不出提升？
• 11:18 企業從 mainframes 換到個人電腦時也在摸索；要拿到效益得丟掉檔案櫃和紙筆，讓電腦成為每個業務流程的中心
  ↳ 企業從 mainframes（整間公司共用的大型主機）換成個人電腦時也在摸索。要真正看到效益，得丟掉檔案櫃和紙筆，讓電腦成為每個業務流程的核心。
• 11:48 Anthropic 新人 onboarding 不問人、直接問 Claude；提問、寫 code、code review、security review 都靠 Claude，填表格則交給 Co-work
  ↳ Anthropic 的新人 onboarding（到職上手期間）不問同事，直接問 Claude。寫程式、審程式、security review（安全審查）都靠它，填表格交給 Co-work（影片中的另一款 Claude 工具）。
• 12:18 真正想通的公司都把 Claude 放在中心；電腦的轉型花了 10 到 15 年，AI 因為工作多已數位化、Claude 又會用電腦和寫跑 code，轉型快得多
  ↳ 想通的公司都把 Claude 放在工作的核心。電腦轉型花了 10 到 15 年，AI 會快很多，因為工作大多已經數位化，Claude 又能自己操作電腦、寫程式並執行。
• 12:49 現在不必為了需求去麻煩別人，跟人互動是為了樂趣與共同創作；工程上不用做繁瑣的部分，是最好玩的時候
  ↳ 現在不必為了一件事去麻煩別人，跟人互動變成是為了好玩、一起創作。繁瑣的工程雜事不用自己做，講者覺得這是最好玩的時候。
• 13:19 講者已沒有 to-do list，Claude 把東西都做出來，自己的工作是想點子、跟客戶聊
  ↳ 講者已經沒有待辦清單，因為想做的東西 Claude 都做出來了。自己的工作變成想點子、跟客戶聊。
• 13:19 未來人人都是 PM 還是工程師？答案是兩者都是。產品、Devrel、設計團隊全都寫 code
  ↳ 未來大家會變成 PM 還是工程師？答案是兩者都是。產品、Devrel（負責跟外部開發者溝通的團隊）、設計團隊現在全都在寫程式。
• 13:50 很多工程師端到端交付產品：想點子、動手做，再跟 legal、marketing、security 合作對外溝通並確保安全
  ↳ 很多工程師一手包辦整個產品：自己想點子、自己做，再跟法務、行銷、資安團隊合作，把產品安全推出、對外說明清楚。
• 13:50 AI 特別有利於好奇心強、有產品品味、喜歡端到端 ownership 的人
  ↳ AI 特別有利於三種人：好奇心強的人、對產品有品味的人、喜歡從頭到尾自己負責的人。
• 14:22 講者以前開 6 個 terminal 分頁，同一個 repo 開 6 個 git checkout 輪流切；現在只開一個分頁，用新推出的 agent view
  ↳ 講者以前開 6 個 terminal（指令視窗）分頁，同一個專案開 6 份 git checkout（獨立的工作副本）輪流切換。現在只開一個分頁，用新推出的 agent view（一次管理多個 agent 的畫面）。
• 14:22 也用 desktop app，因為它會自動建立 work trees，不必自己處理 checkout
  ↳ 講者也用 desktop app，因為它會自動建立 work trees（讓每個 agent 在各自的副本上工作、互不干擾），不用自己管理那些副本。
• 14:53 沒想到現在大約一半工程工作在手機上做：用 remote control 從手機接手電腦上的工作，買咖啡時查看 agent、開新 agent
  ↳ 意外的是，現在大約一半的工程工作是在手機上完成。講者用 remote control（從手機接手電腦上正在跑的工作），在買咖啡時看進度、開新 agent。
• 15:23 跟人聊到新點子時就當場開 agent，用 voice mode 對它說要做什麼，完全不用回電腦前
  ↳ 跟人聊出新點子時，就當場用手機開一個 agent，用 voice mode 口頭交代要做什麼，完全不用回到電腦前。
• 15:23 同事發現講者電腦留在辦公桌上，人卻一直在合併 PR；原來是在沙發上寫 code，那週正好是 remote control 變好用的時候
  ↳ 同事發現講者的電腦留在辦公桌上，人不在，PR 卻一直被合併。原來講者在沙發上用手機寫程式，那週正好是 remote control 變好用的時候。
• 15:54 以前講 prompt engineering、後來講 context engineering，都對應當時模型的程度：Sonnet 3.5 時代要 prompt engineer，Opus 4 時代要 context engineer
  ↳ 以前講 prompt engineering（琢磨提問的措辭），後來講 context engineering（安排要給模型的背景資料），都是配合當時模型的程度：Sonnet 3.5 時代需要前者，Opus 4 時代需要後者。
• 16:25 現在的模型不必這樣：給最精簡的 system prompt、最少的 tools，讓模型自己想辦法；最重要是給它取得 context 的方式
  ↳ 現在的模型不用這麼費工：system prompt（事先給模型的基本指示）越精簡越好，tools（可用的工具）越少越好，讓它自己想辦法。最重要的是讓它有管道自己取得需要的資料。
• 16:25 另一位是 context minimalist：只告訴模型需要知道的；給太多 context 像在 micromanage，模型可能知道更好的路
  ↳ 另一位講者是 context minimalist（背景資訊極簡派），只告訴模型非知道不可的事。給太多就像 micromanage（事事管太細），而模型可能知道更好的做法。
• 16:56 團隊也在讓 harness 更精簡，留更多空間給你自己的 prompt，也讓它更遵循你的 prompt
  ↳ 團隊也在把 harness（包在模型外面、讓它能使用工具的那層程式）做得更精簡，把空間留給你自己的指示，也讓 Claude 更照你的話做。
• 16:56 一年後用 Claude 的方式會是一套全新的東西；趨勢是 agent 跑更久、更自主，通常同時跑數個到上千個
  ↳ 一年後使用 Claude 的方式會完全不一樣。方向是 agent 跑得更久、更自主，通常同時跑好幾個到上千個。
• 17:27 新的產品形態還不知道長什麼樣，要靠團隊人人提點子、常跟使用者聊，也靠一起開發的社群
  ↳ 新的產品會長什麼樣還沒人知道，要靠團隊每個人提點子、常跟使用者聊，也要靠一起開發的社群。

影片提到一位工程師設了一個 routine，會自動處理多久沒人回應的 bug report？