Claude 一旦能度量，就能提升速度

# 我们如何在两周内让claude.ai快3倍 来源：https://claude.dev/blog/how-we-made-claude-ai-faster/ 今年八月，我们在为期两周的冲刺中，将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 (https://claude.com/product/tag)（测试版），运行了一个与Opus 5.5大致相当的内部研究模型。Claude负责发现瓶颈、构建基准测试、部署改进方案，并监控每次发布。我们通过设定目标、权衡取舍、审批每次变更来进行引导。在这种方式下，我们合成了超过三千次变更，且未发生任何面向客户的故障或回滚。本文将介绍我们交付了什么、如何衡量效果，以及我们与Claude构建的安全高效的工作循环。 ## 简报 冲刺开始前，我们创建了一个Slack频道，并设置了以下常驻指令 (https://claude.com/docs/claude-tag/users/getting-started#give-claude-standing-instructions)： > @Claude 你的职责是协调所有与claude.ai网站和桌面应用性能相关的事宜。你的责任包括：监控发布以检测性能回归、评估现有遥测数据的准确性和完整性、维护精心管理的可观测性仪表盘、主动实施针对已发现问题和低悬果实的解决方案、提出性能优化项目建议，以及与你的人类队友沟通。[...] 该频道的终极目标是让你尽可能实现自主，但目前我们知道这还不现实。 我们让Claude通过Datadog MCP服务器分析使用数据。它识别出四个影响最大的用户旅程：启动应用、开始对话、加载已有对话和发送消息。覆盖网页和桌面端，贯穿我们的产品线，这些旅程产生了十三项不同的测量指标。为了建立基准，我们添加了插桩代码，确保测量方式可比：每个指标都始于用户交互，终于结果渲染完成，并能区分客户端和服务端的工作。 我们以一份约二十个精选项目的清单开启了冲刺，每个项目针对一个特定旅程。Claude估算每个项目的改进效果（以毫秒计），我们将这些估算汇总以设定冲刺目标。部分项目规模较大，但我们认为两周内可以完成大部分。 到第三天，我们已完成了十三个目标中的十二个。 规划的项目提前完成。为了加快启动速度，我们将静态编辑器内嵌到HTML中，使用户能在React初始化期间输入，并预编译了V8代码缓存，避免桌面端主进程重新编译。为了加快导航速度，我们在对话间保持编辑器挂载、在用户悬停时预加载会话，并将侧边栏重新渲染次数减少了90%。 我们也为Claude留出了发现机会和提出新工作流的空间。这些工作流迅速发展成独立项目，其成果远超我们的初始目标。于是我们设定了新目标，并寻找更多可测量的方面： > @Claude 我们最终几乎资助了原始项目列表中的所有项目，甚至更多。我们来刷新一下 [...] 我们尚未探索什么？可以在哪些方面持续优化？当前哪些领域机会最大？[...] 我对疯狂的想法持开放态度 ## 一切皆可优化 从一开始，我们就希望迭代速度能快于发布节奏。Claude可以异步工作数小时甚至通宵，我们希望让它无需等待线上数据验证其原型。为此，我们寻求在实验环境中衡量性能的其他方法。 Sam找到了第一个线索： \#claude-apps-perf· 讨论串 1. **Sam** 12:34 PM 除了挂钟时间，我们还能做什么？比如衡量JS指令数？ 2. **Claude** App 12:42 PM 可以。对于纯JS热路径，可以计算字面指令数：在Valgrind下运行基准测试，使用`node --predictable`并与已检入的基线比较——运行一次即可，无需统计分析。对于浏览器路径，Chromium下没有指令计数，但有其他确定性指标：每次交互的React提交次数、V8精确覆盖率下的函数调用次数、布局与样式重算次数、DOM变更次数。您想先看哪个？ 3. **Sam** 12:49 PM 我们来探索valgrind + `Ir` + `--predictable`，在讨论串里进行，其他浏览器/React基准测试在新讨论串里进行。在所有讨论串里通知我。你知道我们想要什么。开始吧 这是根据真实对话重建的。十一分钟后，五个讨论串并行运行，分别专注于不同的测量：指令数、V8调用次数、React提交次数、样式重算次数和DOM变更次数。 我们对每个新基准测试都保持审慎态度。每个测试承担双重任务：首先，作为Claude在实验环境中可以优化的指标；其次，作为CI中的防护栏，数值只许下降不许上升。如果测试不稳定，或与用户延迟实际不相关，我们会将其剔除，避免Claude走错优化方向。 > @Claude 请证明针对这些指标的优化能在实际挂钟性能上带来可衡量的提升。对于无法证明这一点的候选测试，我们将取消其使用。 挂钟时间是用户的真实感受，但其数据波动大，且毫秒级的波动不适合作为CI门控指标。指令数因其确定性而具有吸引力，但我们仍需Claude证明它与挂钟时间的关联性。 因此，我们让Claude在两个热路径上尝试降低指令数：组装对话消息树的例程和Claude Code输出中状态行的扫描器。Claude使用Valgrind分析发现，第一个路径中有四分之一的指令用于巨型多态字典查找，为解析同一消息ID重复执行了三次操作。 一小时后，它将这两个路径的指令数分别降低了48%和31%，挂钟时间随之下降了78%和44%。我们添加了两个新的防护栏指标。此后，任何提升这些路径指令数的PR都会导致CI失败，而每日任务会在指令数下降时自动降低上限。 这引出了本次冲刺的核心教训：**有了Claude，衡量即可掌控。** 衡量曾是第零步：你添加指标，等待数据积累，然后才开始理解问题。有了Claude，这成为了优化的第一步。一旦Claude有了要攻克的数字，它就可以开始优化。这意味着我们能做的杠杆效应最大的事情，就是找到更多可衡量的指标。 ## 循环，逐个讨论串进行 所有这些工作都在同一个Slack频道进行，多位工程师和Claude在每个讨论串中协作。冲刺逐渐形成了一个循环 (https://claude.com/blog/getting-started-with-loops)： 1. 有人会开一个讨论串，描述旅程中的某个缓慢环节，常附有截图或录屏。 2. Claude会追踪流程，然后找到或构建一个能证明问题的基准测试。 3. 当它在实验环境中得到有希望的结果后，会提交PR回来——通常是多个PR，按风险和评审范围拆分，任何用户可见的改动都使用功能开关控制。 4. 发布后，Claude监控发布过程并读取线上数据。 5. 如果性能提升，Claude通过降低基准测试阈值来锁定成果；如果没提升，它会关闭功能开关并迭代。 6. 然后它会在同一旅程中寻找下一个缓慢点。 例如：有人分享了一段录屏，显示侧边栏行在页面加载后才逐个出现。聊天和Cowork行的解析时间不同，使页面感觉卡顿。我们现有的监控均未检测到。最接近的是Cumulative Layout Shift (https://web.dev/articles/cls)，但每次偏移仅得分约0.008——远低于0.1的良好阈值。 Issac想到直接引用底层的Layout Instability API (https://wicg.github.io/layout-instability/)。Claude创建了一个遥测事件，将每个`layout-shift`条目的`sources`映射到命名区域（如侧边栏、转录区）和阶段（如首次绘制前、可输入后）。它添加了一个集成测试，该测试在加载带有填充侧边栏的页面时，会将侧边栏数据持有到首次绘制之后，并在任何命名区域发生偏移时失败。Claude用此作为基准测试来证明修复效果：该测试在主干分支上20次运行全部失败，在PR上20次运行全部通过。 事件部署后，Claude读取线上数据，发现31%的网页加载在页面可用后、无需用户交互的情况下移动了元素。随后，Claude按名称逐一排查原因：延迟到达的标题行、用户姓名加载后滑动的光标、滚动条出现时移动的列表。Claude批量修复了主要问题，解决后又发现下一批问题。 并排录制的claude.ai侧边栏加载过程。之前，行项延迟到达并重排：十行跳动，九行出现，四行消失。之后，行项在它们最终位置填充，无任何移动。 **视频** 侧边栏卡顿，修复前后·限速4G网络 这只是一个讨论串。在冲刺期间，我们同时运行超过一百五十个讨论串。 ## 横向扩展 当循环在一个讨论串中奏效后，扩展到更多讨论串只需打开新的即可。Claude不会在原始请求满足后关闭讨论串，而是*持续深入*。单个讨论串可能提交五十甚至上百个优化PR。越来越多地，是Claude而非我们人类，开启新讨论串以追踪它在独立调查或夜间任务中发现的机会。频道中的一位工程师Shelley观察到：“[这个模型]是个数字怪兽。” 每个度量都发现可改进之处。Claude进行React钩子普查，发现编辑器输入路径中有6,900个钩子和900个store订阅，在每次击键时重新渲染。Claude统计样式重算次数，发现单个`:root:has()`选择器为每次DOM变更增加了24毫秒。Claude追踪首次绘制后的代码路径，发现一个遗留的`location.reload()`导致每天五十万次隐藏重载，且我们的负载指标均未察觉。Claude分析空闲标签页的分析器采样，发现相同的缓存快照每分钟被克隆两次到IndexedDB，且都在主线程上。 我们很少预知讨论串会导向何方。在一次CPU卡顿扫描中，Claude注意到高亮已完成的代码块可能导致页面冻结约一秒。它在实验环境中深挖，发现了罪魁祸首：破折号。如果回复的markdown包含任何非Latin-1字符（如破折号或弯引号），V8会将整个字符串存储为UTF-16，这导致所有语法高亮正则表达式进入较慢的双字节路径。Claude通过二十行代码的修改，在高亮前将每个代码块复制为单字节字符串，解决了这个问题。 到第二周，我们几乎无法将产出总结进每日更新中。在最繁忙的日子里，每天合入超过两百次变更。Claude不断提出新基准测试；约三分之一的PR包含额外的遥测或防护栏，而每个新插桩又生成更多讨论串和更多机会。 在一个频道中工作意味着一切公开进行。我们随时跳入彼此的讨论串，争论决策，庆祝成功。消息传开：其他团队开始将他们的变更带入频道，以进行性能审查。由于引入的所有防护栏和Claude技能，新项目以更高效的方式编写。 ## 防护栏 我们为这种节奏做好了准备。因为我们接触的几乎都是热路径（首次绘制、编辑器、转录区），我们提前建立了安全机制。每个PR都经过自动化审查 (https://claude.com/blog/code-review)，并至少获得一个人类批准；单元测试始终先于优化进行；任何可能导致用户可见问题的改动都通过短期功能开关发布。 当功能开关开始堆积时，我们开了一个讨论串来协调其发布和清理。Claude将每个开关分类为“终止开关”或“渐进发布”，并在其安全后立即退役。两周内，我们引入了近两百个功能开关，其中超过一半在结束时已清理完毕。 我们也知道，在快速迭代的代码库中，性能成果会衰减，而在Anthropic，代码发布速度很快 (https://claude.com/blog/agentic-coding-is-straining-ci-heres-how-we-scaled-test-impact-analysis-at-anthropic)。一旦某个项目证明了收益，我们就投资保护它。例如，静态编辑器设计上就很脆弱。我们几乎立即向用户展示页面的HTML副本，并让React直接在其上绘制。 并排录制的claude.ai全新加载过程。之前，页面保持空白，编辑器在2.93秒后才接受输入。之后，静态问候和编辑器在0.36秒接受输入；用户输入消息，约3秒后真正的编辑器淡入时文本得以保留。 **视频** 静态编辑器，修复前后·限速4G网络 如果React渲染偏差哪怕一个像素，魔法就会失效。因此Claude构建了数十个防护栏： - 静态标记通过在jsdom中渲染真实React组件生成，测试确保它们永不偏离。 - 一个集成测试套件对比静态页面与React渲染在十四种视口尺寸下的表现，断言对齐误差在1像素内。 - 击键测试贯穿整个切换过程，任何丢失或乱序的按键都会导致测试失败。 - 在线上环境中，每次切换都会报告十分之一像素级别的偏移。对于任何非零偏移事件，Claude都会开启一个讨论串。 并非所有问题都能在实验环境中发现，因此我们也使用了书中最古老的防护栏：增量发布。高风险变更首先发布给员工，然后是1%的用户，最后是全部用户。内部发布静态编辑器四小时后，一位同事分享了一段录屏，显示了一个我们的指标都未捕捉到的布局偏移。当他在新标签页中打开claude.ai时，编辑器会下移——但这并非我们的代码所致。 \#claude-apps-perf· 讨论串 1. **Marius** 6:15 PM 偶尔，我在新标签页打开claude.ai时（刷新页面时不太明显），会看到一个小的（可能15-20像素）垂直布局偏移（将编辑器框向下推）。我无法完全确定具体原因，但它确实存在。录屏 · 0:02 2. **Claude** App 7:05 PM 在你的录屏中找到了——是Chrome调整页面大小，而非从静态编辑器到真实编辑器的切换（在你今天的全部49次加载中，该切换测量值为0像素）。- 在新标签页中，Chrome在页面下方绘制其自身的56像素页脚（“由anthropic.com管理 · 自定义Chrome”）。当标签页导航到claude.ai时，页脚消失，页面增高56像素，但仅在我们首次绘制约100毫秒后发生。- /new将问候语和编辑器置于距页面顶部18%的高度，因此它们下移0.18 × 56 ≈ 10像素（你的视频测量为10）。刷新没有页脚需要移除，因此仅限新标签页；“偶尔”