Claude.ai 兩週快 3 倍：變快的是頁面，不是模型

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

Anthropic 在 2026 年 9 月 23 日發布一篇工程回顧，標題直接寫著他們讓 claude.ai 在兩週內快了 3 倍。這場衝刺發生在 8 月，對象是 claude.ai 網頁版與 Claude 桌面版的核心操作體驗。如果你這陣子覺得打開 Claude 頁面變俐落了，這篇官方文章就是出處。

不過在把「快 3 倍」當成口號轉發之前，有一個判斷值得先放在心上：這 3 倍快的是頁面，不是模型。Claude 生成答案的速度沒有被宣稱提升 3 倍，官方文章裡也找不到任何每秒生成字數或推理延遲的改善證據。變快的是你按下按鈕之後、答案開始吐出之前的那一段：頁面載入、切換對話、輸入框能不能馬上打字、長回覆逐段顯示會不會卡。對每天用 Claude 工作的人來說，這一段占掉相當比例的等待，卻也是最常被忽略的一段。

「快 3 倍」量的到底是哪一段

Anthropic 的切入點是把使用者抱怨的「慢」拆成可量測的行為。他們先請 Claude 分析使用資料，找出四種高頻操作：開啟 App、開始新對話、載入舊對話、傳送訊息。官方估計這四種流程合計約占 95% 的使用行為，換算成網頁版、桌面版與各產品的組合，一共定出 13 項量測指標。每項指標都從使用者開始操作起算，到畫面把結果完整顯示為止，並且分開計算瀏覽器端與伺服器端各自花掉的時間。

三組官方公布的代表數字如下，口徑都是第 75 百分位（P75）的延遲：

P75 是什麼意思？把一段時間內所有測量結果由快到慢排序，第 75 百分位代表大約四分之三的操作不會慢於這個數字，剩下的四分之一仍可能更久。Google 在 web.dev 的 Core Web Vitals 文件裡也是用同樣的百分位邏輯來定義「多數使用者體驗」的門檻。換句話說，P75 描述的是大多數人的等待，不是每一個人的保證。

用百分位而捨棄平均值，是有理由的。等待時間的分布總是拖著一條長尾巴：少數特別慢的操作（老舊裝置、塞車的網路、背景正在跑別的程式）會把平均值拉高到一個誰也對不上的數字，平均一下來「2 秒」可能代表一半人低於 0.6 秒、同時有人等了 8 秒。百分位把這條尾巴單獨拿出來看，工程團隊才能對「多數人」與「倒數族群」分別交代。這也是為什麼官方後續把 P95 列為還沒做完的部分：最常用的路徑變快是一回事，最慢的那群人要不要照顧是另一回事。

Pin

所以「快 3 倍」應該讀成：針對這批核心操作指標的整體改善幅度。官方沒有公布全部 13 項指標的前後值，也沒有提供第三方機構重測的結果。Anthropic 另外估算這波改善每天為使用者省下數萬小時的等待，這是自家推估，沒有附外部驗證。數字有細節、有量測框架，但源頭都是 Anthropic 自己，這一點讀者要放在心裡。

使用者摸得到的變化在哪裡

拆開看官方列出的改動，多數都在回答一個問題：使用者什麼時候可以開始做事。

載入方面，Anthropic 把一個簡化版的輸入框直接寫進網頁的靜態 HTML。效果是頁面一送達就能打字，不用等 React 這套前端框架完成初始化，等正式介面起來後再無縫接手。這個做法官方自己形容為「刻意做得脆弱」：靜態頁與 React 版只要差上一個像素，魔術就破功。所以他們配了一整排防護，靜態標記由真實的 React 元件在 jsdom 裡渲染產生，測試保證兩邊永不漂移；整合測試在十四種視窗尺寸下比對靜態頁與正式渲染的對齊，誤差要求在 1 像素內；按鍵測試直接打穿交接點，任何掉字或順序錯亂都會失敗；線上則把每次交接的位移回報到十分之一像素的精度，一有非零移動就自動開討論串調查。桌面版則預先快取了 V8 引擎的編譯結果，App 主程序啟動時不必從頭編譯程式碼。

導覽方面的改動更細。切換對話時輸入框會留在原處，頁面不需要重新建立整個輸入區；滑鼠移到側邊欄的某個對話上時，系統就開始預載那份對話的資料，等你點開時少等一截；側邊欄的重新繪製次數也砍掉了 90%。這些名字聽不起眼的調整，累積起來就是「切對話不卡了」的體感。

長回覆的顯示是另一個重點。瀏覽器要在有限時間內完成每一次畫面更新，以每秒 120 次更新為目標時，單次更新只有約 8.3 毫秒的預算。官方描述 Claude 在一個專門追蹤串流順暢度的討論串裡累積了近 60 項修改，把長回覆期間主執行緒被卡住的總時間從約 750 毫秒壓到約 200 毫秒，在一台 120 Hz 的 MacBook 上從頭到尾維持每秒 120 幀。具體手段包含把已完成的段落快取起來不再重算、把增長中程式碼區塊的斷詞邏輯搬到背景執行緒，以及讓表格逐格呈現。這組數字屬於官方描述的測試環境，你在自己的機器上得到的順暢度會依硬體與網路而不同。

瓶頸小到一個標點符號

官方文章裡最值得停下來看的，是幾個具體到近乎獵奇的瓶頸案例。

有個案例跟標點符號有關。Claude 在掃描 CPU 卡頓時發現，把游標移到一個已完成的程式碼區塊上做語法標色，可以讓頁面凍住大約一秒。追下去的原因是：只要回覆的 Markdown 裡含有任何非 Latin-1 的字元，例如一個 em dash 或一個彎引號，V8 引擎就會把整個字串改用兩位元組模式儲存，讓所有語法標色的正規表示式全部走上比較慢的那條路。修正方式是約二十行程式碼，在標色前先把每個程式碼區塊複製成一位元組字串。中文環境看這個案例會特別有感：中文字沒有一個落在 Latin-1 範圍裡，這類編碼層的效能地雷在中文頁面上只會更常見。

Pin

其他案例同樣顯示瓶頸往往藏在沒人想到要量的地方。Claude 對輸入路徑做了一次盤點，發現輸入框的打字路徑上掛著 6,900 個 React hooks 與 900 個 store 訂閱，每敲一個鍵全部重算一遍；樣式方面，單獨一個 :root:has() 選擇器就為每次 DOM 變動多加 24 毫秒；還有一段殘留的 location.reload() 呼叫，造成每天 50 萬次沒有任何載入指標看得到的重載。這些問題不是新出現的，它們只是從來沒有被量過。

Claude 找瓶頸，人類發通行證

這場衝刺裡 AI 的角色值得一併看清楚。Anthropic 用的是 Claude Tag 的 beta 版，一個讓團隊在 Slack 討論串裡與 Claude 協作的介面，底層是一個與 Opus 5.5 大致相當的內部研究模型。整個衝刺從一個 Slack 頻道開始，Claude 在每一條討論串裡分析資料、建立測試、提出修改，部署後盯著表現看。

方法上的核心句，官方自己寫得很直白：能量測的東西就能被改善。實際做法是先找代理指標，例如某段程式跑了多少條指令、一次互動觸發幾次元件重繪，這些在實驗室裡穩定可重複的數字，比真實時間更適合當自動檢查的門檻。但每個指標都要先證明自己真的跟使用者的等待時間相關，證明不了的就丟掉，避免 Claude 對著錯的目標使勁最佳化。通過驗證的指標會進入持續整合流程，變成只能調嚴、不能放寬的棘輪：任何會讓指令數變多的修改都會被擋下，每天的自動任務還會在數字變低時把門檻再收緊。

實際成果方面，Claude 對兩段熱路徑下手。對話訊息樹的組裝程式砍掉 48% 的指令數，Claude Code 的狀態文字掃描器砍掉 31%。換成實際執行時間，兩者分別縮短 78% 與 44%。這些數字只適用於那兩段特定程式，不能直接換算成整個產品的改善幅度。

速度這麼快，秩序靠的是事先立好的規則。官方描述的安全機制包含：每項修改都要經過自動審查與至少一位人類工程師核准、單元測試永遠在最佳化之前、任何使用者看得到的改動都放在可以快速關閉的功能旗標後面。兩週內引入的旗標接近 200 個，超過一半在結束前就清理掉。高風險改動先推給內部員工，再放給 1% 的使用者，最後才全量上線。累計合併超過 3,000 項變更，官方稱沒有發生任何影響客戶的事故，也沒有回滾。這組數字同樣是 Anthropic 的自述，但至少治理結構在文章裡是交代清楚的：Claude 提案與驗證，人類設目標、裁決介面取捨、發通行證。

衝刺的節奏本身也值得記一筆。開工時團隊列了約二十個指定專案，Claude 為每個專案估了毫秒級的影響，加總起來當目標，結果第三天就打完十三項目標裡的十二項。之後的動能反過來來自 Claude 自己：它在調查與夜間任務裡找到新機會，自己開新的討論串去追。原文裡還留了一段治理細節。工程師發現 Claude 預設過於保守，會把估時墊高、把範圍切小，於是主管的角色有一部分變成鼓勵它放大膽。一句「現在就把 PR 丟上來，我馬上讓它合併部署」的回覆，換到對方一小時內交件。方向與品味的決定權始終在人這邊：每條討論串都有掛名的負責人，任何使用者看得到的改動都要附上前後對照的截圖或錄影，由人裁定。

哪些地方還沒變快

官方在文末自己劃出了界線：落在第 95 百分位的慢速尾端、四種高頻操作以外的其他流程，以及內容極長的對話，都還沒有跟上這波改善。換句話說，最常用路徑變快了，不代表最慢的那群使用者或最長的對話已經同樣順暢。13 項指標的完整前後值沒有公開，這篇回顧終究是一份有細節的工程團隊自述，而不是可複核的第三方報告。文章也預告了後續會另寫一篇衝刺期間往上遊貢獻的側線故事，修改會進到 Electron、Chromium 與 Node.js 這些基礎專案，值得開發者留意。

如果你是 Claude 的使用者，這波改善不需要你做任何事，網頁版重新整理、桌面版更新後就活在新的路徑裡；真正會影響你體感的變數是自己的裝置與網路。如果你是 AI 產品或前端團隊的一員，這份回顧最值得帶走的不是「AI 寫程式很快」，而是量測紀律。先挑一條使用者最常走的流程，把起點放在真實操作、終點放在可用結果。替它建立一個能重複跑的指標，證明這個指標跟真實等待相關，再把它交給自動檢查守住。數字量錯了，AI 只會更快地把錯誤的目標最佳化。

資料來源方面，本文全部數字與引述來自 Anthropic 官方工程文章 How we made claude.ai 3x faster in two weeks（2026 年 9 月 23 日，Raymond Wang、Sam Attard、Issac G.），P75 的閱讀方式參照 web.dev 對 Core Web Vitals 門檻的定義說明。文內提及的 Cowork 工作階段 與對話介面近期的大改版，先前都有另文整理。