有請 Anthropic 技術成員,Theo Chu 上台。

兩年來模型走了多遠

大家好。大家好,我叫 Theo,是 Anthropic 的研究產品經理。我負責我們的長視野能力,例如模型的長 context 與記憶能力。我大約兩年前加入,正好是 Sonnet 3.5 剛推出的時候。那時候,「agent」幾乎還不是人們在用的詞。模型「居然能寫程式」這件事才剛出現生命跡象。人們還聚焦在 chat completion。自主性、agent 的自主性,還是個相當新的概念。去年差不多這個時候——回想去年的 Code with Claude——Opus 4 剛發布。Claude Code 甚至還沒 GA,還是個相當初生的東西。我們不知道它會不會真的起飛。「模型能用於自主寫程式」這件事還很新。當然,現在我們有 Fable、有 Mythos,最近也發布了 Opus 4.8。

在進入能力曲線、模型如何隨時間進步的主題之前,我想請大家舉手:聽過 Claude 的請舉手。好。用過 Claude 的再舉一次。如果你覺得 Claude 讓你效率翻倍,手繼續舉著。好,如果你覺得 Claude 讓你效率變十倍,手再繼續舉著。好,相當不錯。去年這個時候,很多人甚至不知道 Claude 是什麼。

去年我在 Code with Claude 時,還有人問我:跟我多講講大型語言模型吧,它們是做什麼的?我要怎麼善用它們?

所以,走在這場大會裡,看到大家對 AI 的認知多了多少、有多少人把它用進日常生活,而且不只是用,還在自己的生產力和效率上看到實際增益——真的很瘋狂。每年由 Claude 寫出的程式碼越來越多。我們最近發布了一篇關於遞迴自我改進的部落格文章:Anthropic 內部超過 80% 的程式碼是由 Claude 合併的。所以你可以看到,隨著模型進步,我們非常確信能力與能力的天花板只會從這裡繼續往上。這場演講要談的,就是你如何適應這個新世界,以及身為開發者,如何真正為未來而建,而不是為過去而建。

這張投影片上,你可以看到一系列模型在 SWE-bench Verified 上的表現。這是我們內部用來檢視 Claude 程式能力進步、值得信賴的評測。這個評測由一系列 GitHub issue 組成:Claude 要解掉這些 issue,然後跑測試,看它是否真的解決了。回頭看 Sonnet 3.7,分數才剛過 60%。Opus 4.8 現在拿到 88%。而 Mythos 和 Fable 模型,我們看到這個基準其實已經飽和。這是相當瘋狂的進步。我覺得那條線根本沒有完整呈現這有多瘋狂:12 個月內從 62% 到 88%,意味著 Sonnet 3.7 在這些任務上的失敗率是現在的三倍。請花一秒想想這件事。這就是過去一年模型進步的速度。而且模型只會越改越快。

接下來我要給大家看的,是同一個任務、由相隔 12 個月的兩個模型完成。先看 Sonnet 4 做這個任務,再看 Opus 4.8 做完全相同的任務。這個任務是:一次到位地重建 claude.ai——我們的 Claude 網站。Sonnet 4,你可以看到,寫了非常多行程式碼,呼叫一大堆工具,直接埋頭就上——先做再想。實際把 UI 跑起來,你可以看到它其實不能動。看起來合理,但不完全可用。Opus 4.8 會怎麼做。Opus 4.8 會做出一模一樣的 UI,但顏色會跟 claude.ai 網站真正的配色一致,你會看到側欄、看到聊天介面,你真的可以發訊息,而且會正確回覆。而且它會先規劃再行動。不只先規劃再行動,那個規劃最終會帶來少得多的工具呼叫、少得多的程式碼行數。所以歸根結柢,你看到的是:Opus 4.8 不只把任務做得更成功,還更快、更便宜。

智慧增益落在哪裡

在進入「這個新世界怎麼建」的戰術之前,我想談談智慧的增益實際落在哪裡。

第一件事,如我提過的,是「先規劃再行動」這個概念。

舊模型就像我面對 IKEA 家具:直接埋頭就拼,不看說明書,拼到一半失敗,才發現得回頭看說明書。它們就是直接跳進去、先做再想。現在的模型會先規劃,也就是在真正執行之前,先想清楚規格(spec)應該是什麼。這麼做——就像你在 Opus 4.8 上看到的、或如果 Wi-Fi 爭氣你本來會看到的——模型靠著預先規劃規格而變得更有效率。在預先規劃規格的過程中,它還能抓到自己的錯。你可能會看到模型說出「actually(其實)」「never mind(算了)」這類詞。靠著抓到那些錯,它第一次就能更有效率地執行計畫。

對你的意義是:你應該允許模型先思考、再做任務。

把產品設計成「思考」被允許存在於使用者體驗中——實際給模型更高的 effort 與 adaptive thinking,讓它能把規劃放在前面。

我們看到大量智慧增益的第二個領域,是錯誤恢復與自我修正。

我的意思是:舊模型常做一件叫 doom looping 的事。doom looping 是:模型拿到任務、去做、可能失敗;你告訴它「嘿,我覺得你該做另一件事」,或環境給了它「該做別的」的回饋;它說「好,我再試一次」;然後再試的時候,又一頭撞回原本那個一模一樣的解法,不改變方法。現在的模型真的能看著回饋作出反應,真的會換個做法再試。而這往往帶來更好的結果。

對你的意義是:你應該把環境設計成能把回饋給到模型,讓它能從一路上撞到的錯誤裡恢復。這也意味著:不再 doom looping、不再浪費 token,模型整體能用更少的 token 完成任務。

最後,模型在「跑得更長」這件事上持續進步。

意思是:模型現在能維持注意力、保持連貫,常常到一百萬 token,有時更多。舊模型會中途掉線:可能忘了任務。你可能聽人說過,模型有時會「失去劇情(losing the plot)」——通常就是指模型在過程中忘了任務、也許忘了指示,開始偏離你預期的路線。現在這一點已經大幅改善。當然,在更長的 context 長度上仍有改進空間,但你現在真的可以讓模型跑滿一百萬 token。

對你的意義是:你不必再做那麼多 context 管理。你不需要像以前那樣把 context window 切塊。當然,如果你要跑遠超過一百萬 token,可能還是得做一些。

所以我建議:當你思考模型能跑越來越長的視野時,就做更有野心的夢、給它更長的任務——你可以把一整個 codebase 交給它,而不只是一個檔案。

這一切意味著:模型現在規劃得更好,因此撞上的失敗更少;但真的撞上失敗時,恢復得更快;最後,它們能跑越來越長的視野。這一切複合起來,就成了能更自主運作的 agent。

它們能隨時間做越來越長的任務,因此也能做越來越聰明的任務。

它的樣子大概像你看到的這張圖:agent 先規劃;規劃後執行;你可能給它某種對照計畫做驗證的方式——也許是對話中的人類回饋,也許是 agent 能呼叫來驗證輸出的某個工具;然後它用那個驗證去調整計畫,如此來回循環,直到對最終結果滿意為止。

但別只聽我說——也聽聽我們的使用者怎麼說。這裡有一段 Shopify 的話:他們看到 Claude Opus 4.8 在錯誤恢復、在先規劃再行動上明顯更好。Cursor 看到我們模型的工具呼叫與 token 效率大幅改善,而且 Opus 4.8 比他們測過的所有 Opus 模型都好。同樣地,Cognition 也看到 Opus 4.8 更自主、能跑更長的視野,而且同樣更省 token。所以再說一次:隨著模型越來越聰明,你大可放手讓它們跑更長的時間,它們會比以前更有效率、更有效果地工作。

如何為「持續變強的模型」而建

接下來是大家大概最感興趣的部分:戰術上,你要怎麼為這個未來而建?怎麼為越來越強的模型而建?這不只是關於 Opus 4.8 或 Opus 4.7 或今天的任何模型,而是幫助大家理解:隨著模型進步,身為開發者你該想什麼,才能把我們在模型裡看到的智慧增益,真正交到你的使用者手上。

在進入戰術之前,第一件事是心態的轉變。對你嘗試的東西、對你允許 Claude 處理的東西,要有野心。別一直測那些你認為 Claude 十二個月前就會做的任務。開始想那些 Claude 今天還做不到的任務,並持續想著那些 Claude 今天做不到的任務。因為隨著模型進步,那些任務會有越來越多變得可能,而你要能在它們變得可能的當下看見。

做到這件事的第一個方法是建評測——如果你已經有評測,就刷新它。對很多人來說,這往往是理解「今天的模型能做什麼」的第一步。

如果你還沒有評測,可以這樣想:它們是 AI 時代的單元測試。其中一些可以是回歸測試式的——全是今天的模型已經會做的,你只是看你的 harness 或未來的模型是否還能做到。但你真正想做的,往往是建立「模型不會飽和」的評測。意思是:不只看你目前提供給使用者的體驗,還要看你想隨時間提供的體驗、你想把應用帶往的方向,為那些測試案例而建,把它們放進你的評測。這也意味著:留意使用者回報給你的失敗模式,把它們加進評測,模型接下來才會真正解決那些失敗模式。

第二,更新可能已經飽和的評測。我們有時會聽到客戶在新模型發布時說:「欸,我的評測只進步了 1%,我不覺得這個模型有多好。」而隨著他們越玩越多,才發現:哦,這個模型其實在某幾個能力上明顯更好,或在我的評測完全沒測到的某條軸上明顯更好。所以這是一個徵兆:如果你的評測動得不多,你可能要看看評測裡那些模型還沒解掉的剩餘問題,是不是真的公平、可解。如果不是,你的評測可能飽和了。飽和了,就該更新評測、找更難的問題。

最後,一旦你有了評測,你能做的最好的事就是拿它做基準:理解各個模型在上面的表現;新模型出來時,再實際看新模型的表現。

第二點,而且我怎麼強調都不夠:縮小你的鷹架(scaffolding)。鷹架是模型周圍的 prompt、你在模型周圍用的工具、你寫的任何程式碼——有時人們也叫它 harness。看著你的 harness 和鷹架,人們往往因為過去模型撞上的種種失敗模式,不斷往裡面加東西。舉個例子:我們的 claude.ai system prompt 裡,一度有一行指定某種引用格式——那格式早已過時、我們不再使用。

而我們的新模型在指令遵循上變強了很多,開始遵守我們很久以前放進 system prompt 的那行指示。於是我們以為新模型的引用功能壞了——直到去看 system prompt 才發現,其實是模型的指令遵循變好了。我們真正該做的,只是把那一行從 system prompt 整行刪掉。

這個例子說明:縮小鷹架、給模型多一點自主,反而能讓你看見那個模型實際能做什麼。所以你要做的是:為「意圖」、為「你最終想讓模型做什麼」寫 prompt,而不是繞著你跟舊模型踩過的所有坑寫 prompt。

最後,給模型工作的空間。

我們在「給模型思考的空間」時談過一點:你要用 adaptive thinking,讓模型自己決定何時需要思考、需要思考多少。還有一個 effort 旋鈕,你可以調高或調低模型在問題上的用力程度。

其次,你要讓 agent 對你的環境有更多存取、能採取更多行動,但要以受控的方式。如我們所談,模型越來越自主、越來越聰明;但要真正吃到這個紅利,你得給模型行動,以及採取那些行動的能力。我們內部的一個做法——如我們在最近一篇部落格提到的——是在 Claude Code 推出了 auto mode:一個告訴 Claude 哪些動作是安全的分類器。你當然不會想讓模型撒野、也許把環境裡的一切刪光,所以對它能碰什麼要有點節制;但用分類器的方式來做,讓我們得以在「我們要拿多少控制」與「我們要給模型多少控制」之間取得對的平衡。

最後,你要閉合 agent 迴圈。我的意思是:如前面所說,模型現在非常擅長錯誤恢復,但它得知道自己犯了錯。而你告訴模型「有沒有犯錯」的方式,是給它驗證輸出的途徑。例如,如果你在做一個會做應用程式的 agent,你可能想給它一個 computer use 工具。有了它,它就能對前端做QA:點來點去,看是不是真的能動。如此一來,它就能從環境拿到回饋,理解自己是否該回頭更新程式碼。

到這裡——非常感謝大家聽我講能力曲線。希望你們學到了怎麼思考「模型隨時間進步」這件事,以及怎麼為那個未來而建。