Claude.ai 為何兩週快了 3 倍？Anthropic 如何重做載入、導覽與回覆串流

Claude.ai 打開後等很久，或切換對話時畫面卡一下，使用者通常會覺得「Claude 變慢了」。但等待時間不只來自模型產生答案，也可能花在載入頁面、恢復對話、繪製側邊欄，或把長答案逐段顯示出來。

Anthropic 工程師在 2026 年 9 月 23 日公布的效能回顧中表示，團隊在 8 月用兩週，讓 Claude.ai 與桌面版的核心使用體驗整體快了約 3 倍。這次「快 3 倍」指常用操作流程的完成速度。模型每秒生成多少字屬於另一種指標，文章沒有提供模型推理時間或 token（模型處理文字的基本單位）生成速度提升 3 倍的數據。Anthropic 原文

這次案例值得看的地方，是團隊如何把「覺得慢」拆成可量測的操作，再讓 Claude 協助尋找瓶頸。改善來自介面與程式執行路徑，也靠工程師保留測試、審查與逐步上線的控制權。

Claude.ai 快 3 倍，具體快在哪裡？

Anthropic 先挑出四種最常見的操作：開啟 App、開始新對話、載入舊對話、傳送訊息。團隊表示，這些流程合計約占 95% 的使用行為，並為網頁版、桌面版及不同產品建立 13 個量測指標。每個指標都從使用者開始操作算起，到結果完成顯示為止，並分辨瀏覽器端與伺服器端的工作。

官方文章公開了幾個代表數字，採用第 75 百分位的延遲：

第 75 百分位可以理解成：把一批測量結果由快到慢排序，大約 75% 的結果不會超過這個數字，較慢的約四分之一則可能等更久。這類數字比單看平均值更能呈現多數使用者的等待狀況，但它仍無法代表每一次操作。web.dev 對第 75 百分位的說明

因此，「快 3 倍」應解讀為 Anthropic 對這批核心體驗指標的整體描述。報告涵蓋特定頁面、裝置與操作流程，沒有保證每次操作都少等三分之二。原文沒有列出全部 13 個指標的前後數值，也沒有提供獨立機構重做的測試結果。團隊估計每天因此省下數萬小時的使用者等待時間，這是 Anthropic 的估算，未附外部驗證的實測統計。

幾個介面改動，先把等待感降下來

對使用者來說，重要的往往是「什麼時候能開始做事」，不一定要等整個 App 的程式都載入完。Anthropic 先把一個簡化版的輸入框直接放進網頁 HTML，讓使用者可以先打字。等 React 這套前端介面程式啟動後，正式輸入框再接手。團隊也替交接設計檢查，避免使用者已輸入的文字在切換時消失。

導覽方面，切換對話時，輸入框會留在原處，因此頁面不用重新建立整個輸入區。滑鼠移到某個對話時，系統就會預載它的資料，使用者點開時能少等一段時間。團隊也把側邊欄重新繪製次數減少 90%。桌面版則預先快取 V8（負責執行 JavaScript 程式的引擎）編譯程式的結果，減少啟動時從頭編譯的工作。這些改動縮短了可開始輸入與切換對話前的等待。

團隊也處理長答案顯示不順的問題。瀏覽器必須在有限時間內完成每次畫面更新。以每秒 120 次更新為目標時，一次更新大約只有 8.3 毫秒。Anthropic 表示，經過約 60 次程式變更後，測試中的長答案串流把主執行緒卡住的總時間從約 750 毫秒降至 200 毫秒，並在一台 120 Hz MacBook 上維持每秒 120 幀（fps）。這是畫面顯示效率的改善，原文沒有在此宣稱模型吐字速度提升相同比例。這組測試數據也只適用於文章描述的測試環境。

Claude 負責找問題，人類負責把關

讓這些改動能快速累積的關鍵，是團隊先把「快不快」變成能反覆測的數字。直接量真實時間很符合使用者感受，但結果會受到裝置、背景工作與網路狀況影響，不適合單靠一次跑分就判定程式是否退步。

因此，工程師和 Claude 為不同路徑設計較穩定的實驗室指標。例如，計算某段 JavaScript 程式執行了多少指令，或統計一次互動觸發幾次介面繪製、樣式重算和網頁元素變動。每個指標都要先證明與實際等待時間有關。如果跑分很穩定，卻無法預測使用者端是否變快，團隊就會丟棄它。

官方文章舉了兩段較耗時程式的例子：對話訊息樹組裝程式與 Claude Code 狀態文字掃描器。Claude 找到重複查找資料的工作，讓前者的指令數減少 48%，後者減少 31%。對應的實際執行時間分別縮短 78% 與 44%。這些數字只適用於這兩段特定程式，不能直接套用成整個 Claude.ai 的改善幅度。團隊把有效指標放進持續整合流程（CI），也就是程式提交前的自動檢查。若新改動讓指標惡化，檢查就會擋下來。

Claude 透過 Claude Tag（一個讓團隊在 Slack 工作串中與 Claude 協作的工具）分析使用資料、建立測試、提出程式變更，並在部署後查看表現。工程師則設定目標、判斷優先順序、取捨介面改變，並核准每項改動。Anthropic 表示，衝刺期間同時進行超過 150 個工作串，合併了 3,000 多項變更，而且沒有發生影響客戶的事故，也沒有回滾。這些成果數字來自公司自己的回顧。

團隊也先建好安全欄杆：程式先通過測試，每個變更至少要有一位工程師核准，可能影響使用者的功能先放在可快速關閉的功能旗標後，再逐步從內部員工、一小部分使用者推到所有人。快速產出由 AI 協助，品質與風險則由人來判斷。

其他 AI 產品團隊可以借鏡什麼？

這次衝刺最容易複用的部分，是「找指標、證明指標、用指標守住成果」的做法。團隊沒有只看模型回覆要等幾秒，而是追蹤使用者從開啟頁面、切換對話到看到畫面的完整流程。這讓他們找到模型之外的瓶頸，例如側邊欄反覆重畫、工作階段載入太晚，或答案串流時瀏覽器忙著處理已經完成的內容。

其他團隊可以先從使用頻率高、使用者最常抱怨的流程著手，將量測起點設在真實操作，終點設在可使用的結果。接著在本機或測試環境建立可重複的指標，確認它確實與使用者等待時間相關，再把它放進自動檢查與逐步發布流程。AI 工具可以加快追查和提出改法，但數字本身若量錯，AI 只會更快地把錯誤目標最佳化。

這個案例也有範圍限制。Anthropic 表示，較慢尾端的表現（第 95 百分位，P95）、其他操作流程與特別長的對話仍有改善空間。也就是說，最常用的路徑變快，不代表長尾使用者或長對話已經同樣順暢。團隊沒有公開全部 13 個指標、使用者端測試分組與獨立複驗資料，所以讀者可以把它視為一份有細節的工程團隊自述，仍不宜當成適用所有 AI 產品的保證。

常見問題

Claude.ai 的模型回答速度也快了 3 倍嗎？

官方文章報告的是網頁、桌面 App、對話切換與回覆顯示等操作體驗，沒有提供模型每秒生成 token 數或推理延遲快 3 倍的數據。閱讀這項成果時，應把介面等待和模型生成分開看。

第 75 百分位代表所有人都能在這個時間內完成嗎？

不是。它表示大約四分之三的測量結果不超過這個時間，另外四分之一仍可能更慢。這也是為什麼團隊同時指出第 95 百分位與長對話仍有改善空間。

Claude 在這次提速中做了什麼？

Claude 協助分析操作資料、找出程式瓶頸、建立效能測試、提出程式變更，並查看部署後的數據。工程師仍負責選擇目標、審查使用者可見的改變、核准程式與決定何時擴大上線。

小型團隊也能用相同方法嗎？

可以採用量測方法，但不必複製 Anthropic 同時開 150 多個工作串的規模。先挑一條重要流程、建立可信的基準、逐步加上自動檢查與小流量發布，通常更適合作為起點。

結語：把「等很久」拆成能改善的步驟

Claude.ai 這次提速的核心啟示，是 AI 產品的體感速度由整條操作流程共同決定。若模型回覆很快，頁面卻遲遲不能輸入，使用者仍會覺得慢。若回覆已經生成，畫面每隔幾秒才更新，使用者同樣感受不到流暢。

Anthropic 的案例顯示，AI 可以幫團隊更快探索瓶頸，但要讓改善可靠，仍要靠能與真實體驗對得上的指標、人類審查，以及漸進發布。若你正在改善一項 AI 服務，可以先從一條最常用的操作路徑量起，再逐步擴大到其他功能。

資料來源

• Raymond Wang、Sam Attard、Issac G.，Anthropic 工程文章：How we made claude.ai 3x faster in two weeks，2026 年 9 月 23 日。
• web.dev：How the Core Web Vitals metrics thresholds were defined，用於解釋第 75 百分位的閱讀方式。