Anthropic如何两周将Claude.ai速度提升3倍

一旦 Claude 可以测量某个指标，它就能让它变得更快。于是我们不断发现更多可以测量的东西。

今年八月，我们在大约两周的冲刺中，将 claude.ai 和 Claude 桌面应用的核心用户体验提升了约 3 倍。用户一直在反馈说很慢，他们是对的。我们通过一个 Slack 频道运行所有工作，Claude 参与每个讨论线程。

我们聚焦于四个用户旅程，它们占据了 95% 的用户活动。在第 75 百分位下，claude.ai 全新加载时到可输入页面的时间从 3.1 秒缩短至 0.55 秒，启动新的 Claude Code 会话从 0.8 秒缩短至 0.3 秒，加载 Claude Cowork 云端会话从 2.6 秒缩短至 0.73 秒。总体而言，我们估计这每天为用户节省了数万小时的等待时间。

我们使用了 Claude Tag（beta），运行一个与 Opus 5.5 大致相当的内部研究模型。Claude 发现了性能瓶颈，构建了基准测试，交付了改进方案，并监控每次部署。我们通过设定目标、做出权衡和审批每一项变更来引导方向。通过这种方式，我们合并了超过三千次变更，没有产生任何面向客户的故障或回滚。本文将介绍我们交付了什么、如何测量，以及我们与 Claude 建立的循环来安全地完成这一切。

在冲刺开始前，我们创建了一个 Slack 频道，并设定了以下持续性指令：

@Claude 你的职责是促进与 claude.ai 网站和桌面应用性能相关的所有事务。你的职责包括监控部署中的性能回归、评估现有遥测的准确性和全面性、维护精心管理的可观测性仪表板、主动为观察到的问题和容易实现的成果实施解决方案、提出性能项目机会，以及与你的队友沟通。[...]

这个频道的最终目标是让你尽可能自主，但我们知道目前这还无法实现。

我们让 Claude 通过 Datadog MCP 服务器分析使用数据。它识别出四个影响最大的用户旅程：启动应用、开始对话、加载现有对话和发送消息。在网页和桌面端，以及跨产品线，这些旅程共有十三个独立的测量指标。为了建立基线，我们添加了插桩，直到它们能够直接比较：每个都以用户交互开始，在结果渲染完成时结束，并区分了客户端和服务端的工作。

我们用大约二十个精选项目启动了这次冲刺，每个项目都针对一个特定的旅程。Claude 预估了每个项目的影响（以毫秒为单位），我们将这些预估汇总，为冲刺设定了目标。有些项目规模相当大，但我们认为可以在两周内完成大部分。

到第三天，我们已经实现了十三个目标中的十二个。

计划中的项目提前落地了。为了加快启动，我们把静态 composer 烘焙到了 HTML 中，这样用户可以在 React 初始化期间输入内容；我们还预编译了 V8 代码缓存，这样桌面 shell 的主进程就不需要从头重新编译了。为了加快导航，我们在对话之间保持 composer 挂载，在用户悬停时预取会话，并将侧边栏的重新渲染减少了 90%。

我们还为 Claude 留出了空间来识别机会和提出新工作流。这些工作流很快演变成独立项目，大大超出了我们的初始目标。于是我们设定了新目标，然后寻找更多可测量的东西：

@Claude 我们已经为最初项目列表中的几乎每个项目提供了支持，甚至更多。让我们做一次更新 [...] 我们没有探索什么，我们可以在什么方向上做优化，此时最大的机会在哪里？[...] 我对疯狂的想法持开放态度

任何东西都可以被优化

从一开始，我们就知道自己想要比部署节奏更快地迭代。Claude 可以异步工作很多小时，甚至通宵，我们想让它在不等 field reads 的情况下验证其原型。为了实现这一点，我们寻找在实验室中测量性能的其他方法。

Sam 找到了第一个突破口：

#claude-apps-perf · threadSSam12:34 PM

除了墙上时钟计时，我们还能做什么？比如能测量 JS 指令数吗？ClaudeApp12:42 PM

可以的。对于纯 JS 热路径，精确的指令计数：用 Valgrind 运行基准测试，配合 node --predictable，然后与检查过的基线比较——单次运行，无需统计。

对于浏览器路径，Chromium 下没有指令计数，但有一系列其他确定性计数：每次交互的 React 提交次数、V8 精确覆盖的函数调用次数、布局和样式重计算次数、DOM 变更次数。你想先看哪个？SSam12:49 PM

让我们在一个线程中探索 valgrind + Ir + --predictable，在新线程中探索每个浏览器/react 基准测试。在所有线程中 ping 我。你知道我们要什么。开始吧

（从真实对话重建。）

十一点钟后，五个线程同时运行，每个都专注于不同的测量：指令计数、V8 调用计数、React 提交次数、样式重计算和 DOM 变更。

我们对每个新基准测试都保持一定的怀疑态度。每个基准测试都有两个职责：首先，Claude 可以在实验室中改进的指标；其次，CI 中的护栏，数值只能下降。如果基准测试不稳定，或者与用户延迟没有实际关联，我们就会放弃它，而不是让 Claude 在错误的方向上优化。

@Claude 请证明针对每个基准测试的优化能够带来可衡量的墙上时钟性能提升。对于无法证明这一点的候选基准测试，我们会将其下架。

墙上时钟时间是用户感受到的，但它很嘈杂，毫秒级精度对于 CI 门控来说太不稳定了。指令计数之所以吸引人，是因为它们是确定性的，但我们仍然需要 Claude 证明它们与墙上时钟时间相关。

于是我们让 Claude 在两个热路径上推动计数下降：一个是组装对话消息树的例程，另一个是扫描 Claude Code 输出中状态行的扫描器。Claude 用 Valgrind 分析了这两个路径，发现第一个路径中四分之一的指令是 megamorphic 字典查找，三次解析同一条消息 ID。

一小时后，它将两条路径的指令数分别减少了 48% 和 31%，墙上时钟时间分别下降了 78% 和 44%。我们签入了两个新的 ratchet。从那时起，任何 raising 这些路径指令计数的 PR 都会导致 CI 失败，每天任务会在计数下降时降低上限。

这引导我们得出了冲刺的核心教训。有了 Claude，测量某样东西就让它变得可以优化。

测量曾经是第零步：你添加一个指标，等待数据流入，然后才开始理解问题。有了 Claude，它成了攀登的第一步。一旦 Claude 有了要超越的数字，它就可以开始优化。这意味着我们能做的最有杠杆效应的就是找到更多可以测量的东西。

循环，线程逐线程

所有这些都在同一个 Slack 频道中进行，多位工程师和 Claude 在每个线程中一起工作。从那里，冲刺进入了一个循环：

有人会打开一个关于旅程中缓慢环节的线程，通常附带截图或录屏。

Claude 会追踪流程，然后找到或构建一个基准测试来证明问题。

一旦在实验室中有了有希望的结果，Claude 会带着 PR 回来——通常是好几个，按风险和审查大小拆分，任何面向用户的内容都放在 flag 后面。

上线后，Claude 监控着部署过程并读取现场数据。

如果性能提升了，Claude 就通过降低基准线来锁定成果；如果没有，就关闭开关并继续迭代。

然后它开始在同一链路中寻找下一个慢点。

一个例子：有同事分享了一段屏幕录制，显示侧边栏行是在页面加载后才弹入的。Chat 和 Cowork 行的解析时间不同，导致页面感觉卡顿。我们的现有监控工具都没有检测到这个问题。最接近的指标是 Cumulative Layout Shift，但每次偏移的分数只有约 0.008——远在良好阈值 0.1 以内。

Issac 提出了一个想法：直接引用底层的 Layout Instability API。Claude 创建了一个遥测事件，将每个 layout-shift 条目的来源映射到命名区域（如 sidebar、transcript）和阶段（如 before first paint、after typeable）。它添加了一个集成测试，在侧边栏数据已填充的情况下打开页面，将侧边栏数据保留到首次绘制之后，然后在任何命名区域发生任何偏移时失败。Claude 用这个作为基准来验证修复：测试在 main 分支上 20 次运行全部标红，在 PR 分支上 20 次运行全部标绿。

事件部署后，Claude 读取现场数据，发现 31% 的网页加载在页面可用后发生了元素移动，且没有任何用户交互。从此，Claude 按名称逐个排查原因：一个延迟到达的标题行、一个在用户名加载后横向滑动的插入符、一个在滚动条弹出时移动的列表。Claude 批量修复了排名靠前的问题，问题消除后，又找到了下一批问题。

播放视频VIDEOPause侧边栏卡顿，前后对比

这只是一个线程。在整个冲刺期间，我们同时运行了超过一百五十个这样的线程。

一旦循环在一个线程上验证有效，在更多线程上运行就只是打开它们的问题。Claude 不会在原始请求得到满足后就关闭线程，而是会继续推进。一个单独的线程会提交五十个、有时甚至一百个优化 PR。越来越多的工作是由 Claude 而不是我们主动开启新线程，去追逐它在独立调查或夜间任务中发现的机会。频道里的工程师 Shelley 观察到："[这个模型] 是个数字狂魔。"

每一项测量都发现了可以改进的地方。Claude 运行了一次 React Hook 普查，发现作曲器的输入路径中有 6,900 个 Hook 和 900 个 store 订阅，每次按键都会触发重渲染。Claude 统计了样式重计算次数，发现一个 :root:has() 选择器给每次 DOM 变更增加了 24 毫秒。Claude 追踪了首次绘制后的代码路径，发现一个遗留的 location.reload() 导致每天五十万次隐藏刷新，而我们的加载指标完全看不到。Claude 阅读了空闲标签页的 profiler 样本，发现相同的缓存快照每两分钟就在主线程上被克隆到 IndexedDB 一次。

我们很少能预见一个线程会通向何方。在一次 CPU 卡顿扫描中，Claude 发现高亮一个已完成的代码块可能会导致页面冻结约一秒钟。它在实验室深入排查，找到了罪魁祸首：破折号。如果回复的 markdown 包含任何非 Latin-1 字符，如破折号或弯引号，V8 会将整个字符串存储为 UTF-16，这使得每个语法高亮正则表达式都走上较慢的双字节路径。Claude 用二十行代码修复了这个问题：在高亮之前将每个代码块复制到一个单字节字符串中。

到第二周时，我们几乎无法将产出总结成每日更新。最忙碌的日子里，有超过两百个变更落地。Claude 不断提出新的基准测试；约三分之一的 PR 包含了额外的遥测或护栏，而每个新工具又会产生更多带有更多机会的线程。

在一个频道中工作意味着一切都是透明的。我们进出彼此的线程，讨论决策、庆祝成果。消息传开了：其他团队开始把他们的变更带入频道进行性能审查。新项目以更加微妙的高性能方式编写，因为引入的那些护栏和 Claude 技能已经存在。

我们为这种节奏做好了准备。因为我们触及的几乎所有东西都是热路径（首次绘制、作曲家、转录稿），我们一开始就建立好了安全机制。每个 PR 都要经过自动化审查，至少需要一个人类审批，单元测试总是先于优化执行，任何可能导致用户可见问题的改动都通过一个短期特性开关来上线。

当开关堆积起来时，我们开了一个线程来协调它们的推出和清理。Claude 将每个开关分类为终止开关或灰度开关，并在安全的情况下立即退役。在两周内，我们引入了近两百个开关，其中超过一半在结束时已经被清理。

我们还知道性能收益在快速迭代的代码库中会衰减，而在 Anthropic 代码交付很快。一旦一个项目证明了收益，我们会投入资源来保护它。例如，静态作曲家本身就是有意为之的脆弱。我们几乎立即向用户展示页面的 HTML 副本，然后让 React 直接在其上绘制。

播放视频VIDEOPause静态作曲家，前后对比

如果 React 渲染偏差哪怕一个像素，魔法就会消失。所以 Claude 构建了数十个护栏：

静态标记是通过在 jsdom 中渲染真实 React 组件生成的，测试保证它们永远不会漂移。

一个集成测试套件在十四个视口尺寸上比较静态页面和 React 渲染，断言对齐精度在 1 像素以内。

一个按键测试在交接过程中直接输入，并在任何键丢失或乱序时失败。

在现场，每次交接都会报告精确到十分之一像素的偏移。Claude 为任何非零移动的事件打开一个线程。

并非所有问题都能在实验室中被捕获，所以我们也使用了最古老的护栏：增量发布。高风险变更首先向员工推出，然后是 1% 的用户，最后是所有人。在内部发布静态作曲家四小时后，一位同事分享了一段屏幕录制，显示了一种我们的指标看不到的布局偏移。当他在新标签页中打开 claude.ai 时，作曲家会下移——但那不是我们的代码。

#claude-apps-perf · 线程MMarius下午 6:15偶尔，我看到在打开 claude.ai 新标签页时会有一个较小的（大约 15–20px）垂直布局偏移（将作曲家框向下推），在页面重载时不太明显。我无法准确确定到底是什么原因造成的，但它确实存在屏幕录制 · 0:02ClaudeApp下午 7:05在你的录制中找到了——是 Chrome 在调整页面，而不是从静态作曲家到真实作曲家的交接（今天你的 49 次加载中那一步测量为 0 像素）。在新标签页上，Chrome 在页面下方绘制了自己的 56 像素页脚（"由 anthropic.com 管理 · 自定义 Chrome"）。当标签页导航到 claude.ai 时页脚消失，页面增加了 56 像素的高度，但大约在我们的首次绘制后 100 毫秒才发生。/new 将问候语和作曲家放在离页面顶部 18% 的位置，所以它们下移了 0.18 × 56 ≈ 10 像素（你的视频测量到 10 像素）。重载没有页脚需要移除，所以只在新建标签页时发生；"偶尔"是因为首次绘制是否会早于调整取决于 Chrome 是否在地址栏预渲染页面：当你还停留在新标签页时，隐藏的页面以较短的高度布局，只有在显示后才调整大小。这是一直存在的潜在问题；只是页面以前从来没有这么早绘制过。我们的布局测试看不到它，因为无头 Chrome 没有浏览器 UI 需要收回，占位符和应用一起移动。已根据真实对话重现。

MMarius下午 6:15偶尔，我看到在打开 claude.ai 新标签页时会有一个较小的（大约 15–20px）垂直布局偏移（将作曲家框向下推），在页面重载时不太明显。我无法准确确定到底是什么原因造成的，但它确实存在屏幕录制 · 0:02

ClaudeApp 7:05 PM 在你的录制里找到了——是 Chrome 在调整页面大小，不是从静态 composer 切换到真实 composer 的移交过程（你今天 49 次加载中那一步都测量为 0 px）。在新标签页上，Chrome 会在页面下方绘制自己的 56 px 页脚（"Managed by anthropic.com · Customize Chrome"）。当标签页导航到 claude.ai 时，这个页脚消失了，页面因此高了 56 px，但这发生在我们的首次绘制后约 100 ms。

/new 让问候语和 composer 位于页面高度 18% 的位置，所以它们会下沉 0.18 × 56 ≈ 10 px（你的视频测量值是 10）。重新加载没有页脚可以移除，所以只有新标签页会出现这种情况；"偶尔"是因为首次绘制是否会早于页面 resize。

这只是一种偶发现象，因为它需要 Chrome 在你仍在新标签页时从地址栏预渲染页面：隐藏的页面以较短的高度进行布局，只在显示后才调整大小。

这个问题一直潜伏着；只是页面之前从未这么早就进行绘制。我们的布局测试看不到它，因为无头 Chrome 没有浏览器 UI 可以收缩，而且占位符和应用是一起移动的。

Claude 通过某种方式将其追踪到 Chrome 推测性加载中的一个边缘情况。当用户在地址栏输入 URL 时，Chrome 会在后台预渲染页面，使用当前标签页的高度。对于由组织管理的浏览器，新标签页会因为一个页脚而稍微短一些。当用户按下回车键时，claude.ai 的第一帧显示的是那个稍矮的布局，然后 Chrome 大约在十分之一秒后调整了其大小。Claude 在调整大小时保持布局固定，我们添加了一个测试来模拟预渲染流程。

这个循环很有成效，但并非自主运作。保持它的快速、安全和正常运行是我们的责任，这包含三个部分。

雄心。默认情况下，Claude 对范围很谨慎。它会创建工单记录问题，对可行性持保留态度，并给估计值留出余地。但我们对自己的护栏很有信心。我们所做的很多事情，尤其是在早期，是鼓励 Claude 更大胆一些。

#claude-apps-perf · thread ClaudeApp 3:32 PM 是的——就一个小 PR，让 Code 获得与 Chat 和 Cowork 相同的计时标记。这周我会提上去；实际上 Code 的数字要等几天，要合并、部署，再等一个基线窗口。

RRaymond 3:32 PM 如果你现在提上去，我会合并并部署。我们有能力做任何事。请更大胆一些。

ClaudeApp 3:33 PM 好的——PR 一小时内会提出来。

当我们开始达到设定的目标时，注意到线程会放缓。Sam 逐个线程发了同一条消息："让我们继续压低这个数字，目标不是终点。还有什么可以做的？要有雄心。"

品味。每个线程都有一个具名的人类负责人，Claude 用修复前后的截图或录屏来突出显示用户可感知的任何变化，让他们做判断。表格应该逐格填充，还是等到每行完成后再一起显示？加载骨架应该立即显示，还是延迟半秒？流式文本的逐词淡入效果是否值得消耗帧预算的五分之一？Claude 在寻找削减毫秒的方法，而我们则在权衡这些取舍。

方向。我们保持每个线程刻意狭窄，专注于一个基准或用户旅程，只要求 Claude 在该范围内寻找改进。我们把线程想象成 150 把锤子寻找钉子。我们的大部分决策都围绕着排序和用户影响：优先处理哪些界面、如何合并互相冲突的线程、以及何时关闭已产生边际效益递减的线程。一条 900 行的 PR 只收到了一行回复："我决定 2ms per send 不值得维护这个构建插件的复杂性。"

8 毫秒的预算

其中一个支线任务展示了所有这些如何协同工作。为了演示实时语法高亮中一个正则表达式的优化，Claude 附上了一个屏幕录制，显示在实验室中流式传输的长回答。在角落里，它加了一个帧率读数，通过页面中的 animation-frame 时间戳计算得出。

#claude-apps-perf · thread RRaymond 2:33 PM 这实际上有点像个很棒的基准测试。我们被限制在 60 fps 吗？能否尝试更高的帧率来观察性能表现？