能力曲線（The capability curve）

🧑‍🏫 這場演講由 Anthropic 的 Alex Albert 主講，比較 Claude 一年前和現在寫程式的能力差多少，也現場示範兩代模型做同一件事的差別。重點是模型幾乎每個月都在變強，用 AI 做產品的人該怎麼調整做法。就算你不寫程式，也能從中學到怎麼更有效地使用 AI。

• 01:48 講者是 Anthropic 的 research PM Alex Albert。這場是當天最後一場演講，長度大約 15、20 分鐘
  ↳ 講者 Alex Albert 是 Anthropic 的 research PM，也就是負責把研究成果轉成產品方向的人。這場是當天最後一場，長度約 15～20 分鐘。
• 02:20 去年這場大會舉辦時，Claude Code 還沒 GA，才推出兩三個月，大家剛開始熟悉 agentic coding 這種工作方式
  ↳ 一年前 Claude Code（Anthropic 的 AI 寫程式工具）才推出兩三個月，還沒 GA（正式全面開放）。agentic coding 是讓 AI 自己動手完成整段寫程式的工作，當時大家才剛開始習慣。
• 02:20 講者觀察到，今年大家更信任 Claude，用它更快交付產品，也在做以前做不到的東西
  ↳ 一年下來，大家從半信半疑變成敢把事情交給 Claude：產品做得更快，也開始做出以前做不到的東西。
• 02:50 現場舉手調查：用了 Claude 之後比一年前快 10 倍的人，舉手的很多。接著又問了 5 倍、2 倍，以及有沒有在用 Claude
  ↳ 講者請觀眾舉手：覺得效率比一年前快 10 倍的人很多。接著又問 5 倍、2 倍，最後問誰有在用 Claude，藉此了解大家實際的感受。
• 03:20 SweeBench Verified 衡量模型自主完成軟體 PR 的能力，是 Anthropic 衡量 Claude 寫程式能力的方法之一
  ↳ PR 是工程師提交一份程式修改、等團隊審核合併的單位。SweeBench Verified 測驗看模型能不能獨力完成真實的 PR，是 Anthropic 檢驗 Claude 寫程式能力的指標之一。
• 03:20 大約一年前，當時的模型 Sonnet 3.7 在這個評測拿到 62%
  ↳ 一年前的模型 Sonnet 3.7 在這個測驗拿到 62%，這是後面比較的起點。
• 03:51 現在 Opus 4.7 拿到 87%，講者說這是一年多一點就「超過 25%」的躍進
  ↳ 現在的 Opus 4.7 拿到 87%，比一年前多了 25 個百分點。講者強調，這只花了一年多一點的時間。
• 03:51 換句話說，在 Sonnet 3.7 一年前失敗的困難 PR 上，Opus 4.7 成功的機率是它的三倍以上
  ↳ 換個角度看：一年前 Sonnet 3.7 搞不定的困難 PR，Opus 4.7 成功的機率是它的三倍以上。總分只差 25，在難題上的差距卻大得多。
• 04:24 Demo：在 Claude Code 裡給 Sonnet 4 和 Opus 4.7 同一個任務，兩者相隔 12 個月
  ↳ 現場示範：在 Claude Code 裡，把同一個任務交給相隔 12 個月的兩代模型 Sonnet 4 和 Opus 4.7，直接比成果。
• 04:56 任務是用一個 prompt 重做 Claude.ai。Sonnet 4 只做出一個普通的黑白聊天介面，一送出訊息就出錯，等於只有 UI
  ↳ 題目是只下一次指令（prompt）就重做一個 Claude.ai。Sonnet 4 做出陽春的黑白聊天畫面，但一傳訊息就出錯，只是個空殼。
• 05:26 Opus 4.7 的版本用了 Claude 配色，送出訊息能拿到 Claude API 的回覆，開新對話後也還記得舊對話
  ↳ Opus 4.7 的版本用了 Claude 的配色，傳訊息會透過 Claude API（讓程式呼叫 Claude 的管道）拿到真的回覆，開新對話也記得舊紀錄，是真的能用的產品。
• 05:56 Opus 4.7 還能像 Claude.ai 一樣在對話中直接顯示視覺化內容，也做了 dark mode，而且用的程式碼行數更少、更有效率
  ↳ 它還能像 Claude.ai 一樣在對話裡直接顯示圖表等視覺內容，也做了深色模式，程式碼反而寫得更少。功能做得更多，程式更精簡。
• 05:56 這場演講的主題不是特定哪個模型，而是：當你用的模型每個月都明顯變強，開發產品時該怎麼做
  ↳ 這場的重點不是哪個模型最強，而是模型幾乎每個月都在變強，所以做產品的方式也要跟著改，不能一直沿用一年前的做法。
• 06:30 進步一：規劃能力。舊模型常常先做再想，講者比喻成先組 IKEA 家具，弄亂了才回頭看說明書
  ↳ 第一個進步是會規劃。舊模型像組 IKEA 家具不看說明書，先組再說，組歪了才回頭翻說明書，常常得拆掉重來。
• 07:01 新模型會先花時間思考問題、擬策略、做規劃，再開始寫程式
  ↳ 新模型會先把問題想清楚，定好做法和步驟才開始寫程式，比較少走冤枉路。
• 07:01 建議給 Claude 思考的時間，不要逼它直接動手，否則可能拖累後面的表現
  ↳ 所以不要催它馬上動手。先讓它想一下，後面的成果通常比較好；硬逼它直接做，反而可能拖垮品質。
• 07:34 進步二：錯誤修正能力。舊模型會陷入 doom loop：提出的解法沒用就卡住、一直打轉，最後 context 撐不下去，只能全部清掉重來
  ↳ doom loop 是舊模型的鬼打牆：方法沒用就一直重試、原地打轉，直到 context（模型一次能記住的內容）塞爆，只能全部清掉重來。
• 08:05 新模型碰到問題能退回來、換個角度想、改走其他路。對開發者來說，任務表現更好，浪費的 token 也更少
  ↳ 新模型卡住時會退一步，換個思路走別條路。對開發者來說，結果更好，token（模型計算文字量和費用的單位）也浪費得少。
• 08:05 進步三：長時間運作時的注意力。舊模型做著做著會失焦、忘東忘西，system prompt 裡的指示也漸漸不被遵守
  ↳ 第三個進步是能長時間專注。舊模型做久了會分心、忘東忘西，連 system prompt（開發者事先給模型的基本規則和角色設定）都慢慢不遵守。
• 08:35 新模型在數十萬甚至一百萬 token 的過程中都能保持連貫、記得 system prompt 指示
  ↳ 新模型就算處理幾十萬到一百萬 token 的長任務，也能保持前後一致，一直記得一開始交代的規則。
• 08:35 所以開發者不必一直盯著 context window、不必把工作切成小塊，可以放心讓 Claude 長時間自主執行
  ↳ context window 是模型一次能看到的內容範圍。以前得盯著它，把工作切成小塊餵給模型；現在可以放手讓 Claude 自己長時間做下去。
• 09:05 規劃更好更有效率、失敗更少、agent 跑得更久，這三點加在一起，會讓端到端的任務表現更好
  ↳ 想得清楚、少出錯、撐得久，三點加在一起，整件任務從頭到尾的成果就會明顯更好。
• 09:05 客戶案例：Vercel 看到 Opus 4.7 在寫任何程式碼之前，會先替系統程式碼寫證明（proofs）
  ↳ Vercel（一家網站部署平台公司）發現，Opus 4.7 在寫任何程式之前，會先寫證明來確認系統程式的邏輯正確。這就是「先規劃再動手」的實例。
• 09:05 客戶案例：Windsor 的評測顯示，Claude 在他們最長的 agentic 任務中都能維持注意力
  ↳ Windsor 的測試顯示，即使是他們最長的 agentic 任務，Claude 也能從頭到尾維持注意力，對應「長時間專注」這項進步。
• 09:35 客戶案例：Shopify 發現模型寫程式時會回頭、反覆修正自己的輸出
  ↳ Shopify 發現模型寫程式時會回頭檢查，一改再改自己的成果，對應「自我修正」這項進步。
• 09:35 建議一：先從 eval 下手，而不是從產品本身。能衡量才能改進，所以要有 eval，而且 eval 要貼近你產品實際的任務分佈
  ↳ eval 是用來衡量產品表現的一套測試。要先有 eval 再改產品，因為量不到就不知道有沒有進步；而且題目要貼近用戶實際會遇到的任務。
• 10:05 常見錯誤：拿相近但不同的東西做評測，例如 coding agent 不用真實使用者流量或類似模式的資料，而是跑學術 coding benchmark
  ↳ 常見的錯誤是測錯東西。例如做寫程式助理，卻不拿真實使用者的請求來測，而是跑學術界的公開題庫，分數好看不代表產品好用。
• 10:36 eval 不能飽和。模型越來越強，eval 也要跟著變難，才能從前沿模型得到有用的訊號
  ↳ eval 太簡單的話，新模型每題都做對，這叫「飽和」，就看不出誰好誰壞了。模型變強，題目也要跟著變難。
• 10:36 有了沒飽和的 eval 之後，要拿最新的前沿模型來測
  ↳ 有了夠難的 eval，就拿最新的 frontier model（當下最前沿、最強的模型）來跑一遍，看它實際表現如何。
• 11:08 講者發現，有時候最好的優化就是直接換上最新模型，所以值得花時間測試新模型
  ↳ 講者說，有時候最有效的優化不是改程式，而是直接換上最新模型。所以新模型一推出，就值得花時間測試。
• 11:08 建議二：重新檢視 scaffolding，也就是模型周圍的程式碼、prompt、skill、工具設定等引導它達成目標的東西
  ↳ scaffolding 指包在模型外面、引導它完成任務的東西，包括程式碼、prompt（給模型的指令）、skill、工具設定等。模型換代後要重新檢查一遍。
• 11:39 新模型可能不再需要某些舊設計，例如把多步驟 workflow 改成讓模型在同一個 thread 裡完成。很多時候拿掉東西反而表現更好
  ↳ 以前為了遷就模型，會把工作拆成好幾個步驟；新模型可能在同一段對話裡就能一次做完。很多時候拿掉舊設計，效果反而更好。
• 11:39 也要重新檢視 prompt。prompt 會隨著一代代模型越堆越多，最後變成一團亂的規則，連自己都不知道當初為什麼加
  ↳ prompt 會隨著模型換代越加越長，每遇到問題就補一條規則，最後變成一團亂，連自己都忘了當初為什麼要加。
• 12:10 每出一個新模型，就回頭檢查 prompt、刪掉不再需要的部分，既提升任務表現也省 token
  ↳ 所以每出一個新模型，就回頭整理 prompt，刪掉用不到的規則。這樣任務表現更好，也更省 token。
• 12:10 建議三：給模型發揮空間。讓 Claude 自己決定何時思考，使用 adaptive thinking，並用 effort parameter 調整思考 token 數量和行動量
  ↳ 第三招是給它發揮空間。用 adaptive thinking 讓 Claude 自己判斷什麼時候該多想；再用 effort parameter（努力程度設定）調整它想多少、做多少。
• 12:42 在可控的前提下開放更多工具給 agent。講者說不是讓它為所欲為，而是用安全的方法讓 Claude 在更多系統上執行
  ↳ 在管得住的範圍內，給 agent（能自己動手完成任務的 AI）更多工具。這不是放任它亂來，而是用安全的方式讓它能操作更多系統。
• 12:42 例子是 Claude Code auto mode，Anthropic 最近一篇工程部落格文章有介紹
  ↳ 例子是 Claude Code 的 auto mode（自動模式），Anthropic 最近的工程部落格有一篇文章專門介紹。
• 13:13 auto mode 會用 classifier 檢查 Claude 提出的 tool call，判斷是否需要人類明確批准，讓 Claude 能在背景跑更久、更自主
  ↳ tool call 是模型要求使用工具（例如執行指令）的動作。auto mode 用 classifier（自動分類、把關的程式）判斷哪些動作要人批准，讓 Claude 能在背景自己跑更久。
• 13:13 建議四：幫 agent 形成回饋迴圈（closing the loop），設計成讓 Claude 能檢查自己的輸出並反覆改進
  ↳ 第四招是 closing the loop（形成回饋迴圈）：讓 Claude 做完之後能自己檢查結果，發現問題再修改，一輪一輪變好，而不是做完就交差。
• 13:46 例如做前端的 coding agent 可以給它 computer use 工具，讓它在網站上點來點去，測試自己寫的功能和 bug
  ↳ 例如負責做網頁的 AI，可以給它 computer use（讓 AI 看畫面、操作滑鼠鍵盤的能力），讓它自己到網站上點點看，測試功能、抓出 bug。
• 13:46 模型驗證和改進自身輸出的能力持續進步，所以要給它能做到這件事的條件
  ↳ 模型檢查和改進自己成果的能力越來越好，你要做的是提供工具和環境，讓它真的有辦法自己驗收。

根據講者，Claude Code 的 auto mode 怎麼讓 Claude 在背景自主跑更久？