能力曲線（第 1/2 段）

🧑‍🏫 這支影片由 Anthropic 負責 Claude 寫程式能力的產品經理主講，談過去一年 AI 寫程式的能力進步了多少，以及使用者該怎麼改變用法。影片的重點不是分數，而是 AI 做事方式的轉變。如果你一年前試過之後覺得「AI 不太行」，這支影片會讓你想再試一次。

• 00:19 講者 Jeremy 是 Anthropic 研究團隊的產品經理，負責 coding 行為與能力，也就是讓 Claude 成為更好的軟體工程師
  ↳ Jeremy 在 Anthropic 研究團隊當產品經理，專門負責 Claude 寫程式的表現，目標是讓它更像可靠的軟體工程師。所以他講的是第一手的觀察。
• 00:19 他在 2025 年 3 月加入 Anthropic；去年 Code with Claude 大會前夕剛發表 Claude 4
  ↳ 他在 2025 年 3 月進公司，不久後就是去年 Code with Claude 大會前夕，Claude 4 剛發表，等於從頭看著這一年的變化。
• 00:56 當時 Opus 4 是 state-of-the-art，Claude Code 剛推出、還沒 GA，也還沒真正紅起來
  ↳ 當時最頂尖（state-of-the-art）的模型是 Opus 4。Claude Code 是讓 Claude 直接在電腦上寫程式的工具，那時還沒 GA（正式上線），知道的人也不多。
• 00:56 現在 Opus 4 幾乎像恐龍一樣過時；Claude Code 隨處可見，coding agents 徹底改變了開發軟體的方式
  ↳ 才過一年，Opus 4 就顯得很舊了。coding agent 是能自己讀檔、改程式、跑指令的 AI 助手，現在已經成為很多人開發軟體的日常方式。
• 01:29 現場調查：近半數聽眾上週發過完全由 Claude 寫的 PR；也有人發過完全沒看程式碼的 PR，講者提醒這很危險，必須小心、做好才行
  ↳ PR（pull request）是工程師把改好的程式送給團隊審核合併的申請。現場近半數人交過全由 Claude 寫的 PR；有人連看都沒看就交，講者提醒這樣有風險。
• 02:04 CEO Dario 說過 Anthropic 大部分軟體現在都是 Claude 寫的；Claude Code 的程式碼大多也是 Claude 寫的
  ↳ Dario 是 Anthropic 的執行長。他說公司大部分的軟體已經由 Claude 來寫，連 Claude Code 本身也多半是 Claude 寫的，等於自己的工具自己在用。
• 02:04 過去幾年衡量軟體工程進展最好的 benchmark 之一是 SWE-bench Verified（字幕拼作 SweeBench Verified），題目由 GitHub issues 組成
  ↳ benchmark 是業界用來比較模型的標準考卷。SWE-bench Verified 是其中很重要的一份，題目來自 GitHub（工程師存放程式碼的平台）上真實的 issue，也就是問題回報。
• 02:38 這個 benchmark 測模型能不能解決 GitHub issue，並正確通過所有測試
  ↳ 它的考法很實際：丟給模型一個真實的問題，看它改完程式後能不能通過所有自動測試。測試全部通過，才算真的修好。
• 02:38 Sonnet 3.7 去年約 60%，現在 Opus 4.7 已超過 87%；講者說模型能解的 issue 是過去的三倍
  ↳ 一年前 Sonnet 3.7 大約答對六成，現在 Opus 4.7 超過 87%。講者形容成能解的題目變成過去的三倍；換個角度看，解不出來的從四成降到一成多。
• 03:13 Anthropic 已不再使用 SWE-bench Verified，因為最前沿的 Mythos Preview 已經把它完全做飽和，沒有進步空間了
  ↳ saturate（做飽和）是指考卷被考到接近滿分，已經分不出高下。Anthropic 最新的 Mythos Preview 把這份考卷做滿了，所以公司不再用它。
• 03:13 模型進步的速度已經比新 benchmark 推出還快，因此進展越來越難衡量
  ↳ 意思是新考卷還沒出好，模型就又進步到把它考爛了。所以光看分數，外人很難知道模型實際強了多少。
• 03:13 12 個月內，Claude 從只能解一小部分 issue 的初階工程師，進步到幾乎能解任何規格明確 issue 的資深工程師
  ↳ 用人來比：一年前它像只能處理少數簡單問題的新手；現在只要把問題講清楚，它幾乎都能解，像個資深工程師。
• 03:46 瓶頸已不在解 PR，而是轉移到更棘手的地方；講者認為 demo 比 benchmark 更有說服力
  ↳ 「把一個講清楚的問題修好」已經不是難題，卡關的地方移到了更難處理的環節。所以講者改用實際示範來說服人，而不是再拿分數出來。
• 04:16 Demo 任務：請 Claude 一次（one shot）從零重建整個 Claude.ai 網站，並比較 Sonnet 4 和 Opus 4.7
  ↳ one shot 是只下一次指令、中途不再修正。他要 Claude 這樣從零做出整個 Claude.ai 網站，再比較舊的 Sonnet 4 和新的 Opus 4.7 做出來的成果。
• 04:16 Sonnet 4 事前幾乎不規劃、過程中也不修正方向，寫了 2,000 行，UI 很陽春，聊天功能完全沒反應
  ↳ Sonnet 4 幾乎沒想就開始寫，走偏了也不回頭調整。它寫了兩千行，畫面很簡陋，最核心的聊天功能甚至完全沒反應。
• 04:46 Opus 4.7 用同一個 prompt，會使用一堆工具，只寫了 1,700 行，外觀更像 Claude.ai，也真的能產生回覆
  ↳ 給同一段 prompt（給 AI 的指示），Opus 4.7 會主動用各種工具查看和測試，程式反而寫得比較少，成品卻更像真的 Claude.ai，也真的會回話。
• 05:16 Opus 4.7 版本有聊天側欄、聊天紀錄、格式化輸出，還能在對話裡畫 mermaid 圖，甚至自己加了 dark mode
  ↳ 它還做出側邊聊天列表、歷史紀錄和排版好的回覆，能在對話裡畫 mermaid 圖（用文字產生流程圖的工具），甚至沒人要求就自己加了深色模式。
• 05:46 建議：把 12 個月前模型做不好的任務再試一次，會看到巨大差異；腳下的基礎正在變動，開發者必須跟著調整
  ↳ 很多人一年前試過，覺得「AI 做不到」就放棄了。講者的意思是這些結論可能已經過期，應該重新測一次，工作方式也要跟著更新。
• 06:16 進步領域一：行動前先規劃與推理。Sonnet 3.7 像講者組 IKEA 家具，直接動手，失敗後才去看說明
  ↳ 第一項進步是「先想再做」。以前的模型像不看說明書就組 IKEA 家具，組壞了才回頭去翻說明書。
• 06:16 過去多數模型的失敗模式是「先行動、後思考」
  ↳ 也就是說，過去模型最常失敗的原因不是能力不夠，而是太急著動手，還沒搞清楚狀況就開始改。
• 06:50 現在不必再小心搭 scaffold 逼模型規劃，模型會自己先讀、先調查，再擬出成功機率高的計畫
  ↳ scaffold（鷹架）是以前工程師在模型外面搭的流程，用來硬逼它先規劃。現在模型會自己先讀資料、查清楚，再訂出可行的計畫。
• 06:50 模型擬計畫時會自己抓錯，推理中常出現「actually」「never mind」並改變做法
  ↳ 它的思考過程裡常出現「actually（其實）」「never mind（算了）」這類字眼，代表它發現自己想錯，當場換方向，而不是一路錯下去。
• 07:24 因為模型像資深工程師一樣先把 spec 想好，實作時需要反覆修改的次數就變少
  ↳ spec（規格）是事先講清楚要做什麼、怎麼做。模型像資深工程師一樣先把這些想好，開始動手後就不用一直打掉重練。
• 07:24 實務建議：給 Claude 時間思考與規劃，不一定要強迫它；只要選高 reasoning effort，讓它自己擬計畫
  ↳ reasoning effort 是可以調整的「思考力道」設定，調高就會多花時間想。講者建議直接調高，讓它自己規劃，不用你一步一步教。
• 07:56 進步領域二：錯誤恢復與面對失敗的調適
  ↳ 第二項進步是遇到失敗時的應對：出錯後能看懂原因、換個方法，而不是卡住不動或亂試一通。
• 07:56 約 12 個月前各家模型都有 doom looping 問題：說「我修好了」，其實只是重複同一個解法或小幅變化
  ↳ doom looping（死亡循環）是模型一直說「修好了」，其實只是重複同一招或稍微改一點，一直在原地打轉。一年前各家模型都有這個毛病。
• 08:31 doom looping 現在基本上不會發生了：模型試一個 tool call，從環境拿到 tool results，再據此決定下一步
  ↳ tool call 是模型實際去做一個動作，例如執行程式；tool results 是做完之後拿回來的結果。現在它會先看結果再決定下一步，不會再盲目重複。
• 08:31 模型會用 thinking tokens／test time compute 多花算力，想清楚該怎麼應對失敗
  ↳ thinking tokens／test time compute 指模型在行動前多花的「思考量」。遇到失敗時，它會多想一下，搞懂問題再出手。
• 08:31 遇到錯誤後，模型會改變做法、在失敗中持續執行直到完成任務
  ↳ 所以出錯不再代表結束：它會換個做法繼續往前推，一路做到任務完成，而不是半途放棄或停在錯誤裡。
• 09:01 好處：任務表現更好、浪費的 tokens 更少，只試幾次、從失敗中迭代就能達成結果
  ↳ token 是模型處理文字的計量單位，也關係到費用和時間。少走冤枉路，成功率就更高、花費更少，試幾次就能收斂出結果。
• 09:01 實務建議：讓模型能從失敗迭代、能從環境取得回饋、能根據回饋推理，結果會比 12 個月前好
  ↳ 換句話說，不要只讓它寫完就結束，要讓它能自己執行、看到錯誤訊息或測試結果，再根據這些回饋自己修正。
• 09:39 進步領域三：長時間 agentic run 中持續保持注意力
  ↳ 第三項進步是專注力。agentic run 指模型自己連續做事很長一段時間；現在它在長任務裡比較不會分心走樣。
• 09:39 12 個月前讓模型花幾十萬 tokens 重構整個 codebase，做到一半會「失去主線」、忘記細節，複雜 spec 裡的幾十條指示也常漏掉
  ↳ codebase 是一個專案的全部程式碼。以前叫它花幾十萬 tokens 整理整個專案，做到一半就忘了目標，幾十條要求也常漏掉好幾條。
• 10:17 現在模型能在一百萬 tokens 甚至更多的範圍內保持 coherence，開頭給的 spec 不會做到一半就忘記
  ↳ coherence（連貫性）是從頭到尾都記得要做什麼、前後一致。現在就算處理超過一百萬 tokens，開頭交代的規格也不會做到一半就忘掉。
• 10:17 在一定的複雜度上限內，模型能記住 spec，並在數百萬 tokens 的過程中執行到底
  ↳ 前提是任務的複雜度不能超過它的能力範圍。在這個範圍內，它能記住規格，在非常長的過程中一路執行到結束。
• 10:17 實務建議：不一定要把任務切成很小的片段，也不一定要拆成多個獨立 context window
  ↳ context window 是模型一次能「記在腦中」的內容上限。以前常把大任務切碎、分成好幾段各自處理，現在不一定需要這樣做。
• 10:47 不必一直盯著，例如擔心「已經 200,000 tokens 了要停下來」；可以讓模型和 harness 跑到數百萬 tokens
  ↳ harness 是包在模型外面、讓它能讀檔和跑指令的執行環境。不用看到用量到二十萬 tokens 就緊張喊停，可以讓它跑到數百萬 tokens。
• 10:47 講者坦言還沒做到在數百萬 tokens 中完美保持 coherence，但比 12 個月前接近很多
  ↳ 講者也老實承認，在數百萬 tokens 裡完全不走樣還沒做到，只是比一年前好很多。所以長任務還是值得抽查。
• 10:47 實務建議：對任務更有野心，別因為任務會跑很久就假設 Claude 做不到
  ↳ 過去的經驗讓人習慣把事情縮得很小才敢交給 AI。講者建議反過來想：任務很大、要跑很久，不代表 Claude 就做不到。
• 11:17 可以直接把整個 codebase 交給它看看成果，不要在開始前就先限縮自己的野心
  ↳ 與其一開始就假設它不行、先自己拆解，不如直接把整個專案交給它試試，看了成果再決定怎麼調整。
• 11:17 三項進步疊加起來就是更自主的 agents；自主性由這些能力組成：事先規劃、計畫能帶來成功
  ↳ 前面三項加起來，就是更自主的 agent（能自己完成一連串步驟的 AI）。自主的第一塊是事先規劃，而且計畫本身要能帶來成功。
• 11:47 自主性也包括：遇到失敗能恢復並在錯誤中繼續工作，做到一半還記得自己在做什麼
  ↳ 另外兩塊是：出錯後能自己恢復、繼續做下去，還有做到一半仍記得原本的目標。少了任何一塊，就還是得有人在旁邊盯著。
• 11:47 規劃、失敗恢復、長時間 coherence 結合起來，就能做到端對端完成任務；agents 現在能跑好幾個小時，而不只是幾分鐘
  ↳ 端對端指從接到任務到交出成果都自己完成。三項能力合在一起，agent 現在能自己連續工作好幾個小時，不再只能撐幾分鐘。
• 12:17 long horizon agent 迴圈：先規劃、再執行，接著用環境驗證成果，例如跑測試
  ↳ long horizon agent 指能處理長時間任務的 agent。它先規劃、再動手，然後用真實環境檢查成果，例如跑測試看有沒有通過。
• 12:17 測試沒過就想辦法迭代直到通過，可以持續很長時間；每隔幾個 checkpoint 對照目標驗證一次
  ↳ 沒通過就繼續修到通過為止，這樣的循環可以持續很久；每到一個階段，就回頭對照原本的目標，確認沒有做偏。
• 12:49 例子：講者的同事是 Bun（字幕拼作 Bunn）的創辦人，Bun 是 Claude Code 背後的核心基礎設施之一
  ↳ Bun 是一套讓 JavaScript 程式在電腦上執行的工具，也是 Claude Code 背後的核心基礎之一。講者用 Bun 創辦人的經歷當實際案例。
• 12:49 他受夠了 Bun 背後 JavaScript engine 一直出現 memory errors，想用 Rust 這種 memory-safe 語言重寫整個 engine（本段到此結束）
  ↳ engine 是實際執行程式的核心。memory error 是程式管理記憶體時出錯，常導致當機。Rust 在設計上就能避免這類錯誤，他想用它重寫整個 engine。本段到此結束。

根據講者，Opus 4.7 在 SWE-bench Verified 上的成績是多少？