🚨 AI-LECTURER 快訊速報｜2026-09-25｜5 分鐘速讀

🚨 Anthropic 公開提速做法：先讓 Claude 能「量測」，兩週把 claude.ai 與桌面應用快了約 3 倍

取材：Once Claude can measure something, it can make it faster（Hacker News（AI 高人氣））｜完整課同日跟進，見書架
📍 真實場景
在小型電商公司負責網站的工程師小陳（自學轉職滿一年）

客服這週轉來三則「網頁開很慢」的抱怨，主管問你：慢在哪裡？修完能快多少？

😖 卡住的地方：你手上沒有任何數字，只能憑感覺說「好像有變快」。改了半天，也講不出到底有沒有用。
💡 讀完你會知道 Anthropic 用 AI 提速的順序是先量、再估、再改，並且今天就能替自己的網站做出第一份基準數字。

⚡ 一句話講清楚

Anthropic（Claude 的開發公司）在部落格公開了一次提速紀錄。今年 8 月，他們用兩週的 sprint一段固定期限、集中火力衝同一個目標的工作方式，把 claude.ai 網站與 Claude 桌面應用的核心體驗加速約 3 倍。起因是使用者一直說「很慢」，團隊承認他們說得對。他們鎖定占使用者 95% 活動的四個操作：開啟應用、開始一段對話、載入舊對話、送出訊息。跨網頁、桌面與不同產品，這四個操作總共換算成 13 項量測。文章給了三組 p75（第 75 百分位）把所有人的等待時間由快排到慢，排在 75% 位置的那個秒數，代表「大多數人」的體驗的數字：全新載入 claude.ai 到「可以打字的頁面」，從 3.1 秒降到 0.55 秒；開新的 Claude Code 工作階段，從 0.8 秒降到 0.3 秒；載入 Claude Cowork 雲端工作階段，從 2.6 秒降到 0.73 秒。Anthropic 估計，這每天替使用者省下數萬小時的等待。

文章的關鍵句是「Claude 一旦能量測某件事，就能把它變快」。做法是先開一個 Slack 頻道，給 Claude 一份長期指令：監看每次上線有沒有變慢、檢查現有監測資料準不準、維護儀表板、主動修容易改的問題、提出提速專案，並和人類同事溝通。接著 Claude 透過 Datadog MCP server讓 AI 能直接查詢 Datadog（一種記錄網站實際跑多快、多少人在用的監控服務）資料的連接介面分析使用資料，找出這四個最重要的操作。團隊再補上埋點在程式裡加上計時的小程式碼，記錄某個動作花了多久，讓 13 項數字可以互相比較。每項都從使用者動作開始，到畫面呈現完成才結束，並分開計算前端（使用者這側）和伺服器各花多少時間。這些量測就是後面所有優化的基準線改動之前的起始數字，之後才能比出有沒有進步。

分工上，團隊用 Claude Tag（測試版），底層是內部研究模型，能力約略相當於 Opus 5.5。Claude 負責找瓶頸、建立基準測試（benchmark）專門重複量同一件事的測試，用來公平比較改動前後、送出改進、盯每一次上線；人類負責設目標、做取捨、批准每一項變更。他們先手選約 20 個專案，由 Claude 估算每個能省多少毫秒，加總後訂出目標，第三天就達成 13 項目標中的 12 項。整個衝刺合併了三千多個變更，沒有發生任何影響客戶的事故，也沒有退版（rollback）上線後發現有問題，把程式退回到上一個版本。以上依部落格節錄整理；每一項優化具體怎麼改，節錄沒有涵蓋，這裡不臆測。

🏃 快速上手三步（今天就能做）

1
先量：挑 3 個最常用的動作，寫下今天的數字打開你自己的網站或專案，列出使用者最常做的 3～4 個動作，例如開首頁、搜尋、送出表單。每個動作都定義好「起點＝使用者動作，終點＝畫面顯示完成」。用 Chrome 按 F12，切到「效能」分頁，錄製一次載入。同一個動作重複 5 次，由快到慢排好，取第 4 個（約略等於 p75）。判斷標準：每個動作都有一個寫下來的數字，例如「首頁可操作要 3.1 秒」。沒有數字就不要往下走。
▼
2
再估：請 AI 列出瓶頸，並逐項估計能省幾毫秒把步驟 1 的數字和 DevTools 截圖貼給 Claude 之類的 AI 助理，指令這樣下：「請列出最可能的 3 個瓶頸，每個都估計可省幾毫秒，並說明改完要怎麼驗證。」這對應 Anthropic 的做法：由 Claude 估每個專案的毫秒數，加總後當目標。判斷標準：每個提案都同時有「預估省 X 毫秒」和「驗證方法」，缺一個就退回請 AI 重寫。
▼
3
改一件、重量一次、留好退路一次只改一件事，用 git 讓每個變更各自一個 commit。改完用步驟 1 一模一樣的方法重量。有變快就保留；沒變快或變慢，就用 git revert用一個新的存檔把某次修改反向撤銷，歷史紀錄都還在退回。注意：AI 提的每個修改你都要自己看過再批准，Anthropic 也是由人類批准每一個變更。判斷標準：每個保留下來的改動，都能拿出「改前 X、改後 Y」兩個數字。

🧠 工程思維透鏡（資深工程師看到的是什麼）

🔭 「快 3 倍」這個數字，能直接套用到我的專案嗎？
不能直接套用。這是 Anthropic 的自我報告，量測條件是 p75、全新載入，範圍限於四個操作，而且用的是內部研究模型，不等於你手上的工具能複製同樣結果。文章也說目標是由 Claude 估算後加總，13 項有 12 項第三天就達標。這可能表示估算偏保守，也可能表示原本就有很多容易改的地方，節錄沒有交代，不能下定論。真正能搬走的是方法：先把使用者關心的動作量成穩定的數字，之後每個決策才有依據。
🔭 三千多個變更、零事故，靠的是什麼？代價在哪？
文章給出的安全機制有三個：人類批准每個變更、Claude 監看每次上線、13 項統一定義的量測。兩週三千多個變更，平均每天超過 200 個，人工批准是否真的逐行審查、有沒有分級，節錄沒有說明，這是需要追問的空白。另一個風險是指標本身：AI 會很認真地把「被量到的東西」變快，如果起點、終點定義不一致，就會把錯的東西最佳化。這也是 Anthropic 先花力氣讓 13 項量測可以直接比較的原因。對一般團隊來說，先把量測做對，比急著放手讓 AI 自己改更重要。