3,000 项变更、0 回滚：Claude 如何两周把 claude.ai 提速 3 倍？

本文作者：meng shao（@shao__meng）。版权归作者所有，未经授权禁止转载。

两周，三倍：claude.ai 性能冲刺复盘

TL;DR 2026 年 8 月，Anthropic 团队在一个 Slack 频道里让 Claude 自主完成测量、定位、优化、发布的完整循环，人类只负责定目标、做取舍、审批变更。两周内合并 3000+ 项变更，核心体验 p75 平均快 3.1 倍，零客户可见事故、零回滚。真正的新东西不是某项具体优化，而是“可测量即可优化”这一分工重构，以及让它变得安全的一整套护栏工程。

先看结果：平均数会骗人

十三条 p75 真实用户监控指标（8 月 13 日 vs 8 月 27 日），几何平均 3.1 倍：

| 用户旅程 | 平台 / 产品 | 之前 | 之后 | 提升 |
| --- | --- | --- | --- | --- |
| 启动应用 | claude.ai 网页 · 冷加载 | 3,085 ms | 550 ms | 5.6×（−82%） |
|  | 桌面端 · 冷启动 | 6,310 ms | 3,328 ms | 1.9×（−47%） |
| 发起对话 | Chat 网页 | 416 ms | 273 ms | 1.5×（−34%） |
|  | Chat 桌面 | 460 ms | 224 ms | 2.1×（−51%） |
|  | Claude Code 桌面 | 837 ms | 347 ms | 2.4×（−59%） |
| 加载对话 | Chat 网页 | 1,557 ms | 646 ms | 2.4×（−59%） |
|  | Chat 桌面 | 1,353 ms | 488 ms | 2.8×（−64%） |
|  | Cowork 桌面 · 云端 | 2,566 ms | 728 ms | 3.5×（−72%） |
|  | Claude Code 桌面 | 545 ms | 262 ms | 2.1×（−52%） |
| 发送消息（客户端占比） | Chat 网页 | 180 ms | 59 ms | 3.1×（−67%） |
|  | Chat 桌面 | 140 ms | 64 ms | 2.2×（−54%） |
|  | Cowork 桌面 · 云端 | 928 ms | 48 ms | 19×（−95%） |
|  | Claude Code 桌面 | 250 ms | 52 ms | 4.8×（−79%） |

分布极不均匀：Cowork 发消息快了 19 倍，而网页发起对话只快 1.5 倍。另外两点值得注意：作者明确选取了 p75 口径，p95 长尾被列为“尚未解决”；文中“每天节省数万用户小时等待”是估算而非实测。作为第一方自述，这些数字应当可信，但要清楚它们的边界。

方法论内核：可测量即可优化

With Claude, measuring something makes it tractable. 全文最重要的一句话

传统性能工程的瓶颈从来不是不会改代码，而是测量与验证的周期：加一个指标，等数据回流，然后才真正理解问题在哪。当 Claude 把“建立测量”的成本压到接近于零，优化的整个经济学就变了；最高杠杆的工作变成了寻找更多可测量的东西。围绕这个判断，团队做了三个关键决策：

1.弃用 wall-clock 计时作为 CI 门禁。毫秒级计时在 CI 里噪声太大，无法做可信的通过/失败判据。Claude 提出一套确定性指标：纯 JS 热路径用 Valgrind + node --predictable 数指令，浏览器侧用 React commit 数、V8 精确覆盖的函数调用数、布局/样式重算数、DOM mutation 数。据记载，工程师 Sam 在频道里提出问题十一分钟后，五个分攻坚不同指标的线程已经跑了起来。

2.拒绝盲目相信指标。每个新基准必须先自证与用户可感知的延迟相关。团队让 Claude 把两条热路径的指令数分别压低 48% 和 31%，实测墙钟时间随之下降 78% 和 44%，相关性成立，基准才被允许接入 CI；flaky 或不相关的基准直接废弃，用团队自己的话说，不能让 Claude 爬错的山。

3.CI 棘轮（ratchet）。每个基准同时是实验室里可推动的指标，和一条只能单向下降的 CI 阈值，每日任务自动下调天花板。这是最容易被忽略、工程上却最关键的设计，它保证优化成果不会在快速迭代的代码库里腐化。

三倍里到底有什么：大量存量债务的清理

细看具体发现，所谓三倍提速里很大一块并非高深的算法突破，而是积弊清理：

| 发现 | 影响 |
| --- | --- |
| composer 键入路径累计 6,900 个 React hook、900 个 store 订阅 | 每次按键触发全量重渲染 |
| 一个 :root:has() 选择器 | 每次 DOM 变更增加 24 ms |
| 一处遗留的 location.reload() | 每天约 50 万次隐藏刷新，现有监控完全不可见 |
| 空闲标签页反复克隆相同缓存快照写入 IndexedDB | 每分钟两次，全部发生在主线程 |

其中最精彩的案例是破折号问题。在一次 CPU 卡顿排查中，Claude 注意到高亮一个完成的代码块会冻结页面约一秒，深入实验室后找到了元凶：如果回复的 markdown 里含有任何非 Latin-1 字符（一个破折号、一个弯引号就足够）V8 会把整个字符串存为 UTF-16，于是所有语法高亮正则都走上慢一倍的双字节路径。修复只用了二十行代码：高亮前把每个代码块复制成单字节字符串。修复后，首个代码块的主线程阻塞从约 1 秒降到 0.35 秒。

这个清单本身说明问题：大规模测量会捞出攒了很久的债务。机制上更妙的是飞轮效应，约三分之一的 PR 自带新增埋点或护栏，每一个新仪表又催生新的调查线程。一位工程师的评价很传神：“[This model] is a numbers demon.”

循环与规模

冲刺稳定后形成了固定循环：

1.有人开帖描述一段卡顿，常附录屏或视频；

2.Claude 追踪流程，搭建或找到能复现问题的基准；

3.实验室结果有前景后提交 PR，按风险分级拆分，用户可见的变更一律藏在 feature flag 后；

4.发布后 Claude 亲自盯部署、读现场数据；

5.有效则收紧棘轮锁定成果，无效则关旗迭代，然后寻找同一旅程里的下一处卡顿。

侧边栏抖动是个典型例子：有人录到侧边栏条目在页面加载后才依次弹出，观感卡顿，但现有的 Cumulative Layout Shift 指标每次位移只记 0.008 分，远低于 0.1 的“良好”阈值，完全抓不到。Issac 提议直接调用底层的 Layout Instability API，Claude 据此建立了把每次位移映射到“区域 × 阶段”的遥测事件，并用它作为基准证明修复：主分支上 20 次测试全部失败，PR 上 20 次全部通过。上线后现场数据显示：31% 的网页加载在页面可用后仍有未经交互的内容移动。Claude 随后按名逐个消灭（迟到到达的表头、用户名加载后侧滑的光标、滚动条弹出时移动的列表）修完一批，再找下一批。

规模随之失控般增长：单个线程平均产出 50–100 个 PR，越来越多地由 Claude 自己开帖追查夜间任务中发现的机会；高峰期同时运行 150+ 个线程，最忙的一天落地 200+ 项变更。到第二周，团队已经难以把产出压缩进每日简报。

护栏：为什么敢这么快

因为触碰的几乎全是热路径（首屏、composer、对话流），安全机制在冲刺开始前就已就位：

| 机制 | 具体做法 |
| --- | --- |
| 代码评审 | 每个 PR 自动评审 + 至少一人工批准 |
| 测试先行 | 单元测试永远先于优化 |
| Feature flag | 用户可见变更全部走旗；两周引入近 200 个，分为 kill switch / ramp 两类管理，过半在结束前已清理 |
| CI 棘轮 | 指标只能单向下降，每日自动下调天花板 |
| 灰度发布 | 高风险变更按员工 → 1% → 全量三级放量 |

对“故意做脆”的方案，护栏密度还要再加。静态 composer 的思路是先用 HTML 画出可打字的页面，再让 React 直接覆盖上去；如果 React 渲染偏差哪怕一个像素，魔法就穿帮了。于是 Claude 为它建了十几个护栏：用 jsdom 渲染真实 React 组件生成静态标记并用测试防止漂移、十四种视口下 1px 对齐断言、击键穿越交接点的丢键测试、现场 0.1px 级位移遥测；任何非零位移都会自动开帖。

但实验室总有盲区。灰度中一位同事发现新标签页打开 claude.ai 时有约 10px 的布局下坠，而所有指标都看不见它。Claude 从录屏中定位到根源：受组织管理的 Chrome 会在新标签页底部画一条 56px 的页脚，用户在地址栏输入时 Chrome 预渲染的页面按这个较矮的高度布局，导航过来后页脚消失、视口变高，页面在首帧后约 0.1 秒被 Chrome 重新调整尺寸。这个问题其实一直潜在，只是页面过去从不会那么早绘制出来。Claude 钉住了跨 resize 的布局，并补上了模拟预渲染流程的测试。

人还坐在驾驶座上

作者对“自治”的表述相当坦诚：这个循环高产，但它不是自治的。人的工作收敛为三件事。

野心（Ambition）。 Claude 天性谨慎：发现的问题先开工单，可行性上留有余地，估算里垫了缓冲。团队对护栏有信心，于是大量早期工作就是在推它胆子大一点，最典型的对话是，Claude 说这个 PR 本周内提上去、真实数字还得等几天部署，Raymond 回复“你现在就提，我马上让它合并部署。我们有能力做任何事，请大胆一点”，一分钟后 Claude 答复“在做了，一小时内提 PR”。达标之后线程会自然放缓，也需要人挨个去催：目标不是终点，继续往下压。

品味（Taste）。每个线程有具名的人类负责人，凡用户可感知的改动，Claude 都用前后对比截图或录屏呈现，由人裁决：表格该逐格填充还是等整行完成？加载骨架该立即出现还是等半秒？流式文本逐词淡入，值不值得它消耗的那五分之一帧预算？Claude 负责省毫秒，人来权衡取舍。

方向（Direction）。线程被刻意保持狭窄，聚焦单一基准或旅程，“一百五十把锤子找钉子”。人的决策集中在排序与影响判断上：优先做哪些界面、如何合并互相踩脚的线程、何时关闭边际收益递减的线程，一个 900 行 PR 收到过一行回绝：每次发送省 2ms，不值这个构建插件的维护复杂度。

支线：8 毫秒预算

一条支线任务把上述要素完整串了起来。Claude 在演示一个正则优化的录屏角落里加了帧率读数，Raymond 看到后追问：这测试台不错，但我们是不是被钉在 60fps 了？能不能冲 120？

Claude 用 DevTools 的 begin-frame control 搭出了确定性 120Hz 测试台，240 次 begin-frame 精确产出 240 帧，每帧预算 8.33ms，“这一帧是否超预算”从噪声感知变成了精确的二元读数。在此基础上，它逐帧走完一个长回复：记忆化已完成的块以消掉随消息增长的线性开销、把代码围栏的分词逻辑移入 worker、让表格逐格显现。单线程落地近 60 个 PR：长回复的主线程阻塞从约 750ms 降到约 200ms，CPU 占用约为原来的三分之一，在 120Hz MacBook 上全程满帧。这个测试台本身成了夜间任务，由 Claude 持续盯回归。

团队事先并未计划对流式输出做帧级优化，但事实证明：能被计数的，就能被优化。