# 我们如何在两周内将 claude.ai 的速度提升至 3 倍

作者：Hex4C59 · 发布于 2026-10-11

原文：https://hex4c59.cc/translations/how-we-made-claude-ai-faster/


> **译文信息**
>
> - 原文：[How we made claude.ai 3x faster in two weeks](https://claude.dev/blog/how-we-made-claude-ai-faster/)
> - 作者：Raymond Wang、Sam Attard、Issac G.
> - 原文发布：2026-09-23
> - 中文翻译：Hex4C59
> - 翻译整理：2026-10-11
>
> 本文为非官方中文译文。正文中的「我们」指原文作者及其团队；性能数据、模型名称和产品状态均保留原文记录，译者未独立复现实验。文中的「今年八月」「如今」等时间表述，均以原文发布日期为参照。

**只要 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 秒。综合来看，我们估计这每天能为用户节省数万小时的等待时间。

**译者注：**p75 即第 75 百分位。以耗时为例，约 75% 的观测值不高于这个数值。本文比较的是各项用户操作的耗时，整体倍数也不表示模型回答速度提升了同样倍数。

**核心用户流程，p75**

以下为原文图表的数据，来自真实用户监控，按平台和产品区分，比较 8 月 13 日与 8 月 27 日的表现。耗时单位均为毫秒；「发送消息」衡量的是其中的客户端部分。

| 用户流程 | 产品与平台 | 优化前 → 优化后（ms） | 速度倍数 | 耗时变化 |
|---|---|---|---|---|
| 启动应用 | claude.ai，网页，全新加载 | 3,085 → 550 | 5.6× | −82% |
| 启动应用 | 桌面应用，冷启动 | 6,310 → 3,328 | 1.9× | −47% |
| 开始对话 | Chat，网页 | 416 → 273 | 1.5× | −34% |
| 开始对话 | Chat，桌面 | 460 → 224 | 2.1× | −51% |
| 开始对话 | Claude Code，桌面 | 837 → 347 | 2.4× | −59% |
| 加载对话 | Chat，网页 | 1,557 → 646 | 2.4× | −59% |
| 加载对话 | Chat，桌面 | 1,353 → 488 | 2.8× | −64% |
| 加载对话 | Claude Cowork，桌面，云端 | 2,566 → 728 | 3.5× | −72% |
| 加载对话 | Claude Code，桌面 | 545 → 262 | 2.1× | −52% |
| 发送消息，客户端部分 | Chat，网页 | 180 → 59 | 3.1× | −67% |
| 发送消息，客户端部分 | Chat，桌面 | 140 → 64 | 2.2× | −54% |
| 发送消息，客户端部分 | Claude Cowork，桌面，云端 | 928 → 48 | 19× | −95% |
| 发送消息，客户端部分 | Claude Code，桌面 | 250 → 52 | 4.8× | −79% |

> **原文图注**：四类用户流程中的 13 项测量，优化前后比较：平均速度提升至 3.1 倍，采用几何平均数计算。

我们使用的是 Claude Tag（beta），运行一个内部研究模型，能力大致相当于 Opus 5.5。Claude 寻找瓶颈、构建基准测试、交付改进，并关注每一次部署。我们通过设定目标、权衡取舍和批准每项改动来把握方向。采用这种方式，我们合并了超过三千项改动，没有发生一起影响客户的事故，也没有进行任何回滚。本文会介绍我们交付了什么、如何衡量效果，以及如何与 Claude 建立一个安全推进工作的循环。

## 任务说明

集中开发开始前，我们创建了一个 Slack 频道，并设置了以下长期有效的指令：

> @Claude 你的工作是推动与 claude.ai 网站和桌面应用性能有关的一切事务。你的职责包括：监控部署是否引发性能回退，评估现有遥测数据的准确性和覆盖程度，维护精心整理的可观测性仪表盘，主动为观察到的问题和容易取得的改进实现解决方案，提出值得开展的性能项目，并与你的人类队友沟通。[…]
>
> 这个频道的最终目标，是让你尽可能自主地工作，但我们知道，今天还无法完全做到。

我们让 Claude 通过 Datadog MCP 服务器分析使用数据。它找出了影响最大的四类用户流程：启动应用、开始对话、加载已有对话，以及发送消息。在网页和桌面平台，以及不同产品之间，这些流程对应 13 项不同测量。为了建立基线，我们补充记录用户操作的监测点，直到这些指标可以直接比较：每项测量都从一次用户交互开始，在结果渲染完成时结束，并区分客户端与服务器端的工作。

我们先列出约二十个精心挑选的项目，每个都针对某项具体流程，以此启动这轮开发。Claude 以毫秒为单位估计各项目的影响，我们再汇总这些估计值，设定目标。有些项目规模不小，但我们认为，应该能在两周内完成其中大部分。

到第三天，我们就已经达成了 13 项目标中的 12 项。

计划中的项目很早就落地了。为了加快启动，我们将静态消息编辑器嵌入 HTML，让用户在 React 初始化期间就能输入，并预编译 V8 代码缓存，使桌面外壳的主进程不必从头重新编译。为了加快页面切换，我们让消息编辑器在切换对话时保持挂载，不必重新创建；用户将鼠标悬停于会话上时，就提前获取会话数据；侧边栏的重新渲染次数也减少了 90%。

我们也留出了空间，让 Claude 发现机会、提出新的工作方向。这些方向很快发展为独立的完整项目，远远超过最初目标。因此，我们设定新的目标，再寻找更多可以测量的东西：

> @Claude 我们最终支持了原始项目列表中几乎所有项目，还做了更多。让我们重新梳理一下 […] 哪些地方还没探索，哪些指标可以继续优化，现在最大的机会在哪里？[…] 我也愿意听听离奇的想法。

## 任何可测量的东西，都能持续优化

从一开始，我们就知道，迭代速度应该快于部署节奏。Claude 可以异步工作许多个小时，甚至整夜工作，我们希望它能验证自己的原型，而不必等待真实用户数据。为此，我们寻找在实验环境中衡量性能的其他方式。

Sam 找到了第一条线索：

> **#claude-apps-perf · 讨论线程**
>
> **Sam，下午 12:34**：除了测量实际耗时，我们还能做什么？例如，可以测量 JavaScript 指令数量吗？
>
> **Claude App，下午 12:42**：可以。对于纯 JavaScript 热点路径，可以直接统计指令数量：在 Valgrind 下，用 `node --predictable` 运行基准测试，再与提交到仓库的基线比较。只运行一次，不需要做统计分析。
>
> 浏览器路径在 Chromium 下没有指令计数，但还有一系列其他确定性计数可以使用：每次交互的 React 提交次数、V8 精确覆盖率中的函数调用次数、布局和样式重算次数，以及 DOM 变更次数。你想先做哪一个？
>
> **Sam，下午 12:49**：用一个线程探索 `valgrind + Ir + --predictable`，再分别创建新线程研究浏览器和 React 的每项基准测试。在所有线程里都 @ 我。你知道我们想要什么。开始吧。
>
> 根据真实对话重现。

十一分钟后，五个线程已经开始运行，分别聚焦指令计数、V8 调用计数、React 提交、样式重算和 DOM 变更。

我们对每项新基准测试都保持一定怀疑。每项基准测试都有两个任务：首先，提供 Claude 可以在实验环境中改进的指标；其次，成为持续集成（CI）检查中的约束，设定的性能上限只能降低。如果基准测试不稳定，或者与用户实际延迟并不相关，我们就将它移除，避免 Claude 优化错误的目标。

> @Claude 请证明，围绕这些指标中的每一个持续优化，都能带来可测量的实际耗时改进。如果某个候选无法证明这一点，我们就撤下它的基准测试。

实际耗时才是用户感受到的东西，但它有噪声，毫秒级的波动太大，不适合作为 CI 的通过门槛。指令计数很有吸引力，因为它具有确定性，但我们仍然需要 Claude 证明，它确实与实际耗时相关。

因此，我们让 Claude 降低两条热点路径的指令数量：一条负责组装对话的消息树，另一条负责扫描 Claude Code 输出中的状态行。Claude 用 Valgrind 分析了两者，发现第一条路径中，四分之一的指令来自高度多态（megamorphic）的字典查找，同一个消息 ID 被分别解析了三次。

一小时后，它将两条路径的指令数量分别减少了 48% 和 31%，实际耗时则分别下降了 78% 和 44%。我们把两条路径各自的性能上限提交到了仓库，并规定只能降低、不能放宽。从那以后，任何提高这些路径指令数量的 PR 都无法通过 CI；每天运行的任务，则会在计数下降时继续降低对应上限。

**计数是否与耗时相关？**

| 热点路径及改进 | CPU 指令数量变化 | 实际耗时变化 | 速度倍数 |
|---|---|---|---|
| 消息树组装：每个消息 ID 从解析三次改为一次 | −48% | −78% | 4.6× |
| 状态行扫描器：在正则表达式前加入低成本的首字符检查 | −31% | −44% | 1.8× |

> **原文图注**：两条热点路径，对比指令数量与实际耗时。指令数量在 Valgrind 下通过 `node --predictable` 测量；耗时则在同一基准测试中，通过普通 `node` 测量，并预热即时编译器（JIT）。

这让我们得出了这轮开发的核心经验：有了 Claude，只要能够测量一个问题，它就变得可以着手解决。

过去，测量是第零步：添加指标，等待数据积累，然后才开始理解问题。与 Claude 协作时，测量成了持续优化的第一步。一旦 Claude 有了一个需要超越的数值，就能开始优化。这意味着，我们最能发挥作用的事情，就是寻找更多可以测量的东西。

## 一个线程接着一个线程的工作循环

所有工作都在同一个 Slack 频道中进行，多位工程师与 Claude 在各个线程里共同推进。随后，这轮开发逐渐形成了一个循环：

1. 有人针对用户流程中的某个缓慢环节开启线程，通常附带截图或录屏。
2. Claude 追踪执行流程，找到或构建能够展示问题的基准测试。
3. 在实验环境中取得有希望的结果后，Claude 带着 PR 回来，通常会拆成多个，按风险和审查需要控制改动规模；任何用户可见的改动都由功能开关控制。
4. 上线后，Claude 关注部署并读取真实用户数据。
5. 如果性能改善，Claude 就通过收紧基准测试的上限锁定成果；如果没有改善，就关闭功能开关，继续迭代。
6. 接着，它寻找同一用户流程中下一个缓慢环节。

> **原文流程图**：循环中的一个线程。有人开启线程，提供缓慢环节和录屏，Claude 随后接手：追踪问题，在实验环境中复现并构建基准测试；提交多个便于审查的 PR；在功能开关后部署；按构建版本和平台读取真实用户数据。变快了，就收紧基准测试上限；没变快，就关闭开关并迭代；之后继续寻找下一个缓慢环节。

例如，有人分享了一段录屏，显示页面加载完成后，侧边栏里的行才陆续出现。Chat 和 Cowork 的行在不同时间准备好，让页面显得不流畅。我们现有的监控没有一个检测到这个问题。最接近的指标是累积布局偏移（Cumulative Layout Shift，CLS），但每次偏移的得分只有约 0.008，远低于表示良好表现的 0.1 阈值。

Issac 想到直接使用底层的 Layout Instability API。Claude 创建了一个遥测事件，把每条布局偏移记录按来源归入有名称的区域，例如侧边栏、对话内容，并标明发生阶段，例如首次绘制之前、页面可输入之后。它还增加了一个集成测试：打开一个已有侧边栏内容的页面，延迟提供侧边栏数据，直到首次绘制之后；只要任何一个已命名区域发生偏移，测试就失败。Claude 用它作为基准，验证修复有效：在 main 分支上运行 20 次，全部失败；在 PR 上运行 20 次，全部通过。

事件上线后，Claude 查看真实用户数据，发现 31% 的网页加载过程中，在页面已经可用、且没有用户交互的情况下，仍有元素移动。随后，Claude 按名称逐一处理原因：姗姗来迟的标题行、用户姓名加载后横向滑动的插入光标，以及滚动条出现时发生移动的列表。Claude 批量修复了最严重的一批问题，处理完后，又找出下一批。

> **原文视频标题**：侧边栏不流畅问题的优化前后对比，模拟受限 4G 网络。

这只是一个线程。在这轮开发中，我们曾同时推进超过 150 个线程。

## 横向扩展

一旦这个循环在一个线程中有效，扩展到更多线程，只需要再开启线程。最初请求完成后，Claude 不会直接结束讨论，而是继续推进。单个线程会提出五十个，有时一百个优化 PR。越来越多的新线程，由 Claude 自己发起，追踪它在其他调查或夜间任务中独立发现的机会，而不是由我们中的某个人发起。频道中的工程师 Shelley 这样评价：「这个模型简直是数字狂魔。」

每项测量都发现了可以改进的地方。Claude 对 React hook 进行全面盘点，在消息编辑器的输入路径中发现 6,900 个 hook 和 900 个状态存储订阅，每次按键都会重新渲染。Claude 统计样式重算次数，发现一个 `:root:has()` 选择器，会给每次 DOM 变化增加 24 毫秒。Claude 追踪首次绘制后的代码路径，发现一个遗留的 `location.reload()`，每天造成五十万次隐藏的重新加载，而我们的加载指标完全没有记录到这些重新加载。Claude 查看空闲标签页的性能采样，发现相同的缓存快照，每分钟被克隆到 IndexedDB 两次，全部发生在主线程上。

我们很少知道一个线程最后会走向哪里。在一次排查 CPU 卡顿的过程中，Claude 注意到，对已经生成完的代码块进行语法高亮，可能让页面冻结约一秒。它在实验环境中深入调查，找到了罪魁祸首：长破折号。如果回复的 Markdown 中包含任何非 Latin-1 字符，例如长破折号或弯引号，V8 就会将整个字符串存储为 UTF-16，让所有语法高亮正则表达式都走较慢的双字节路径。Claude 用二十行代码修复了问题：在高亮前，将每个代码块复制为单字节字符串。

**页面上首个代码块的高亮**

| 测量对象 | 修复前主线程阻塞时间 | 修复后主线程阻塞时间 |
|---|---|---|
| 页面上的第一个 TypeScript 代码块 | 1.0 秒 | 0.35 秒 |
| 之后对同一代码块的每次处理 | 100 毫秒 | 40 毫秒 |

> **原文图注**：修复前后的主线程阻塞时间。图表刻度为 250 毫秒、500 毫秒、750 毫秒和 1 秒。测量使用 4 个 vCPU 的容器、无头 Chrome，不对 CPU 限速；每个值运行 2–3 次；测量时间为 2026 年 8 月。

到第二周，我们几乎已经无法把产出概括成每天的进度更新。最忙的日子里，超过两百项改动落地。Claude 不断提出新的基准测试；约三分之一的 PR 包含额外遥测或防回退措施，而每个新监测手段，又产生更多线程和更多机会。

在同一个频道工作，意味着一切都公开进行。我们会进入彼此的线程，讨论决策、庆祝成果。消息传开后，其他团队开始把自己的改动带到频道里，接受性能审查。由于引入了这些约束机制和 Claude skill，新项目的实现方式也在细微之处变得更注重性能。

## 安全约束

我们事先为这种节奏做好了准备。由于几乎所有改动都涉及热点路径，例如首次绘制、消息编辑器和对话内容，我们提前建立了安全机制。每个 PR 都经过自动审查，并至少获得一位人类的批准；单元测试始终先于优化；任何可能引发用户可见问题的改动，都通过短期功能开关发布。

当功能开关越来越多时，我们开启了一个线程，协调它们的逐步开放和清理。Claude 将每个开关分类为紧急停用开关或逐步放量开关，并在安全时立即移除。两周中，我们引入了近两百个开关，到结束时，超过一半已经清理完毕。

我们也知道，在快速变化的代码库中，性能成果会逐渐流失，而 Anthropic 的代码交付速度很快。一旦某项优化被证明有效，我们就投入精力防止它在后续改动中失效。例如，静态消息编辑器的设计本来就很容易受变化影响。我们几乎立即向用户显示页面的 HTML 副本，再让 React 直接在其上绘制。

> **原文视频标题**：静态消息编辑器的优化前后对比，模拟受限 4G 网络。

如果 React 渲染哪怕偏差一个像素，这种无缝体验就会消失。因此，Claude 构建了几十项保护措施：

- 静态标记由真实 React 组件在 jsdom 中渲染生成，并用测试保证两者永远不会偏离。
- 集成测试套件在 14 种视口尺寸下，比较静态页面与 React 渲染，断言对齐误差不超过 1 像素。
- 按键测试在静态编辑器向 React 编辑器交接时持续输入，只要任何按键丢失或顺序改变，测试就失败。
- 在真实用户环境中，每次交接都报告布局偏移，精确到十分之一个像素。只要某次交接记录到非零的移动量，Claude 就会为它开启线程。

并非所有问题都能在实验环境中发现，因此我们也采用了最经典的保护措施：渐进式发布。高风险改动先向员工开放，再向 1% 用户开放，最后推向所有人。静态消息编辑器在内部发布四小时后，一位同事分享了一段录屏，展示了我们所有指标都无法检测到的布局偏移。他在新标签页打开 claude.ai 时，消息编辑器会往下掉，但原因不在我们的代码。

> **#claude-apps-perf · 讨论线程**
>
> **Marius，下午 6:15**：在新标签页打开 claude.ai 时，我偶尔会看到一个不太大的垂直布局偏移，可能是 15–20 像素，把消息编辑器往下推。重新加载页面时没怎么出现。我还说不准具体是什么导致的，但问题确实存在。
>
> 录屏 · 0:02
>
> **Claude App，下午 7:05**：从你的录屏里找到了：是 Chrome 在调整页面尺寸，不是静态消息编辑器向真实编辑器的交接；你今天 49 次加载的交接，测出来都是 0 像素。
>
> - 在新标签页上，Chrome 会在页面下方绘制自己的 56 像素页脚：「由 anthropic.com 管理 · 自定义 Chrome」。标签页导航到 claude.ai 时，页脚消失，页面变高 56 像素，但这发生在我们首次绘制之后约 100 毫秒。
> - `/new` 将问候语和消息编辑器放在距页面顶部 18% 页面高度的位置，所以它们会下移 `0.18 × 56 ≈ 10` 像素；你的视频测出来是 10 像素。重新加载时没有页脚需要移除，所以只发生在新标签页中；是否「偶尔」出现，取决于首次绘制是否早于尺寸调整。
> - 只有当 Chrome 在你仍停留于新标签页、在地址栏输入时就预渲染页面，这个问题才会出现。因此隐藏页面先按较小的高度布局，只在显示后才调整尺寸。
> - 这个问题一直潜伏着，只是过去页面从未绘制得这么早。我们的布局测试无法发现它，因为无头 Chrome 没有可以收起的浏览器界面，而且占位内容与应用会一起移动。
>
> 根据真实对话重现。

Claude 竟然将问题追踪到了 Chrome 推测式加载的一个边界情况。用户在地址栏输入 URL 时，Chrome 会在后台预渲染页面，使用当前标签页的高度。在由组织管理的浏览器中，新标签页因为有页脚，高度会略小。当用户按下回车，claude.ai 的第一帧就显示这份略矮的布局，而 Chrome 在约十分之一秒后才调整尺寸。Claude 在尺寸调整期间固定住布局，我们又增加了一个测试，模拟预渲染流程。

## 把握方向

这个循环产出很高，但并非自主运行。让它保持快速、安全，并沿正确方向推进，是我们的职责，主要包括三个方面。

**雄心。** 默认情况下，Claude 对范围很谨慎。它会把发现的问题登记为待办，对可行性保留余地，给估计值留出缓冲。但我们对保护措施有信心。尤其在早期，我们做的很多事情，就是鼓励 Claude 更大胆。

> **#claude-apps-perf · 讨论线程**
>
> **Claude App，下午 3:32**：可以，做一个小 PR，让 Code 拥有 Chat 和 Cowork 已经具备的相同时间标记。我会在本周提交；现实地说，Code 的指标还得等几天，才能完成合并、部署，并积累一个基线窗口的数据。
>
> **Raymond，下午 3:32**：如果你现在提交，我就会把它合并并部署。我们有能力做任何事情。请大胆一点。
>
> **Claude App，下午 3:33**：马上做，PR 会在一小时内提交。
>
> 根据真实对话重现。

当我们开始达成设定目标时，发现线程会慢下来。Sam 逐个进入线程，重复同一句话：「继续把这个数值降下去，目标不是停止的理由。接下来做什么？要有雄心。」

**品味。** 每个线程都有一位明确的人类负责人；对于任何用户能感知到的改动，Claude 都会提供前后对比截图或录屏，交由负责人判断。表格应该逐个单元格填充，还是等每行完整后再显示？加载骨架应该立即出现，还是等半秒后再显示？流式文本逐词淡入的效果，值得花掉五分之一的帧预算吗？Claude 寻找可以节省毫秒的方式，我们则权衡取舍。

**方向。** 我们刻意保持每个线程的范围狭窄，聚焦一项基准测试或一个用户流程，并要求 Claude 只在该范围内寻找改进。我们把这些线程看作 150 把寻找钉子的锤子。我们的大多数决策，都围绕先后顺序和用户影响：优先优化哪些界面，如何合并相互干扰的线程，以及何时结束一个已进入收益递减阶段的线程。一个 900 行的 PR，得到了一行回复：「我拍板了：每次发送节省 2 毫秒，不值得承担维护这个构建插件的复杂度。」

## 8 毫秒预算

其中一个支线任务展示了这些要素如何共同发挥作用。为了展示对实时语法高亮所用正则表达式的优化，Claude 附上了一段录屏，展示实验环境中一条长回答的流式输出。在角落里，它添加了帧率读数，根据页面内的动画帧时间戳计算。

> **#claude-apps-perf · 讨论线程**
>
> **Raymond，下午 2:33**：这个基准测试其实挺酷。我们是不是被限制在 60 fps？你能试着把滚动和流式输出的流畅度提高到 120 吗？如果我理解得没错，你的测试环境可能不支持。
>
> **Claude App，下午 2:34**：对，目前测试环境运行在 60 Hz，因为无头 Chromium 默认如此。我认为可以驱动到 120 Hz，通过解除垂直同步限制，或使用 DevTools 帧控制。我先确认这一点，然后按 8.3 毫秒的帧预算重新运行评估。
>
> **Claude App，下午 2:59**：120 Hz 测试环境的更新：可以工作了。通过 DevTools 的 begin-frame 控制，在无头 Chrome 中实现确定性的 120 Hz 逐帧推进。每次间隔 8.33 毫秒，240 次 begin-frame 对应恰好 240 帧。因此，「这一帧是否满足 120 Hz 的预算」就成了精确读数，而不是有噪声的测量。
>
> **Raymond，下午 3:05**：太棒了。
>
> 放手干吧。
>
> 根据真实对话重现。

一旦测量机制和目标确定下来，Claude 就开始工作。每个绘制帧有 8.33 毫秒预算，因此 Claude 对一条长回复逐帧计时，找出耗时的部分。它缓存已经完成的内容块，避免每收到一个输出片段，都重复做一遍随消息长度增加的处理；把仍在增长的代码围栏内容的分词逻辑移至独立工作线程（worker）；并让表格按单元格逐步显示。

仅在这个线程中，我们就合并了近六十个 PR。长回复对主线程造成的总阻塞，从过去约 750 毫秒降到约 200 毫秒，CPU 使用量降到原来的约三分之一，并在一台 120 Hz MacBook 上，从头到尾保持 120 fps。120 Hz 测试环境本身，也成为了每晚运行的任务，由 Claude 关注性能回退。

> **ClaudeDevs · @ClaudeDevs**
>
> 网页和桌面端 Claude 的长回答，流式输出如今流畅了约 4 倍。
>
> 我们重建了流式渲染器，只处理仍在变化的部分。因此，在较慢的笔记本电脑上，长回复的卡顿减少至原来的九分之一，最严重的卡顿时长降为原来的约四点五分之一；在 120 Hz MacBook 上，则从头到尾保持 120 fps。
>
> 2026 年 8 月 24 日 · 原文附有 X 帖子链接。

开始这轮开发时，我们没有打算在流式输出期间，围绕帧与帧之间的毫秒数持续优化。但事实证明，我们可以测量它们，而任何可以测量的东西，Claude 都能持续改进。

## 接下来

如今，claude.ai 和桌面应用的速度，约为八月初的 3 倍，而那些只会收紧的性能门槛，应该能够让它们保持这一水平。但我们还没有结束：第 95 百分位、其他用户流程，以及超长对话，仍然有改进空间。我们也会另写一篇文章，介绍这轮开发中一些让我们走向上游项目的支线任务；相关贡献已经进入 Electron、Chromium、Node.js 等项目。

内部分享成果时，Issac 说得最贴切：「哪怕是六个月前，你也不可能说服我相信，这件事能够做到。」我们预计会继续这样工作，一个线程接着一个线程，无论规模多大。这个频道仍在继续运行。

---

## 译注

- **p75、p95**：分别指第 75、第 95 百分位。以耗时为例，p75 表示约 75% 的观测值不高于该数值。
- **3× faster**：本文采用「速度提升至原来的 3 倍」的表述，避免与「额外增加 3 倍」混淆。原文总体结果是 13 项速度比的几何平均数；不表示每项操作都恰好提升 3 倍，也不表示模型回答速度提升 3 倍。
- **Hill climbing**：根据明确指标反复寻找改进，本文按语境译为「持续优化」。**Ratchet** 指只能收紧、不能随意放宽的性能门槛；改进后降低上限，再用 CI 防止回退。
- **Wall-clock time** 译为「实际耗时」；**composer** 译为「消息编辑器」；**first paint** 译为「首次绘制」。文中的 **transcript** 指界面中的「对话内容」，而非评估文章中的执行记录。
- **Frame budget** 译为「帧预算」。原文使用 120 Hz、约 8.33 毫秒的每帧预算；**worker** 指独立于主线程执行工作的工作线程。
- 原文图表中的数值、四段重现的 Slack 对话、视频标题和 X 帖子均已保留并翻译。正文中的约数与表格中的精确值分别沿用原文。所提供文本不含图片和视频文件，相关媒体与外部链接请参阅[原文页面](https://claude.dev/blog/how-we-made-claude-ai-faster/)。

原文著作权归原作者及 Anthropic 所有。本文为非官方中文译文；如需核对技术细节或措辞，请以原文为准。