Claude.ai 两周提速 3 倍：Anthropic 拆解对话产品的性能重构

Anthropic 最近公开了一篇工程复盘，解释 Claude.ai 如何在两周内实现约 3 倍的速度提升。这里的“3 倍”并不是模型生成速度突然提高了 3 倍，而是用户从打开页面、发出消息到看到可交互结果的整体体验被重新设计了一遍。

这件事的价值，恰恰不在于某个神奇的前端技巧，而在于 Anthropic 终于把一个长期被忽略的事实讲透了：AI 产品的响应速度，不等于模型的首 Token 延迟；用户感知到的速度，是一条从浏览器到服务端、再到模型输出和界面渲染的完整链路。

对于 Claude.ai、ChatGPT、Gemini 这类产品来说，模型本身可能只占整个等待时间的一部分。页面初始化、鉴权、会话恢复、历史消息加载、工具状态同步、富文本渲染，任何一个环节出现串行等待，最终都会变成用户眼里的“模型很慢”。

先说结论：Anthropic 优化的不是一个点，而是一条链路

Claude.ai 的性能重构，是通过重新测量端到端延迟、减少串行请求、并行化数据加载、提前反馈交互状态，以及降低前端渲染成本来完成的。

Anthropic 的工程复盘给出的核心结果是：在两周时间内，Claude.ai 的关键性能指标提升约 3 倍。这个结果并不意味着所有用户、所有网络环境下的响应时间都会严格缩短到三分之一，而是代表关键用户路径的整体表现获得了显著改善。

可以把一次 Claude.ai 对话拆成几个阶段：

1. 浏览器加载应用代码；
2. 用户身份验证和会话恢复；
3. 获取当前对话及相关配置；
4. 用户提交消息；
5. 服务端处理请求并调用模型；
6. 首个 Token 返回；
7. 浏览器持续接收并渲染流式内容；
8. 工具调用、附件、代码块和 Markdown 等复杂内容完成展示。

用户通常只会把第 5、6 步归因于“模型速度”，但真正影响体验的往往是前后两端。假设模型在 800 毫秒后返回首个 Token，但页面初始化花了 2 秒、会话恢复花了 1 秒、消息渲染又阻塞了 1 秒，用户依然会觉得系统响应迟钝。

这也是此次优化最值得开发者关注的地方：AI 应用性能优化的第一步，不是换模型，而是先确认等待时间到底花在哪里。

第一层重构：从“服务器响应时间”转向“用户感知延迟”

**用户感知延迟，是用户从执行操作到看到有意义反馈之间等待的时间。**它和传统的服务器响应时间不是一回事。

传统 Web 服务经常关注接口的平均响应时间、P95 延迟或者数据库查询耗时。这些指标当然重要，但放到对话式 AI 产品中还不够。因为聊天产品的请求不是简单的“发起—返回”，而是一个持续几十秒甚至几分钟的流式过程。

Anthropic 这次复盘体现出的第一个变化，是把性能指标从单一接口耗时扩展到完整用户旅程。开发团队需要回答的，不再只是“模型多久返回”，而是：

• 用户点击发送后，多久能看到请求确实已经被接收？
• 页面多久能显示加载状态，而不是保持静止？
• 首个有意义的文本多久出现？
• 流式输出期间，页面是否仍然可以滚动、复制和停止生成？
• 一次长回答完成后，代码块和附件是否会让页面卡顿？
• 用户切换历史会话时，是否需要等待所有数据加载完毕？

这类指标更接近真实体验。一个系统即使最终完成时间没有变化，只要能在前 200 毫秒内给出明确反馈，用户主观上也会觉得它更快。相反，一个后台已经开始处理、但前台 2 秒内毫无变化的系统，通常会被判断为卡死。

这并不是“用动画骗用户”，而是把系统已有的状态及时暴露出来。对于 AI 产品来说，透明的状态反馈本身就是功能的一部分。

第二层重构：消灭请求瀑布，而不是盲目增加服务器资源

**请求瀑布，是指后一个网络请求必须等待前一个请求结束后才能开始。**在复杂 AI 应用中，请求瀑布往往比模型本身更容易制造延迟。

一个典型的低效流程可能是：页面先获取用户信息，获取成功后再请求工作区配置；工作区配置返回后，再加载对话列表；对话列表返回后，再加载当前会话；当前会话加载完毕后，前端才开始建立消息流。

每个请求单独看可能只需要几百毫秒，但串在一起之后，等待时间会迅速叠加。尤其是在移动网络、跨区域访问或浏览器首次加载的情况下，网络往返次数本身就可能成为主要成本。

更合理的做法是识别请求之间真正的依赖关系，把没有依赖关系的任务并行执行。例如，用户身份、工作区配置和对话列表通常可以同时请求；当前会话的详细内容也不一定要阻塞页面骨架显示。

简单说，优化前像是在机场排队：必须办完第一件事，才能开始第二件事。优化后则是把能同时办理的手续放到多个柜台处理。

这类优化的难点不在于写出几行异步代码，而在于重新梳理系统依赖关系。开发者需要确认：哪些数据是首屏必需的，哪些数据可以延后；哪些失败会阻塞主流程，哪些失败只影响次要功能；哪些信息可以使用旧缓存，哪些信息必须实时获取。

在 AI 产品中，最容易被误判为“必须立即加载”的内容包括：历史消息完整列表、模型选择器的全部配置、工具状态、附件元数据以及用户偏好设置。但从用户第一次看到输入框的角度看，这些数据并不一定都需要阻塞首屏。

第三层重构：把“可用”与“完整”拆开

**渐进式加载，是先展示可交互的最小界面，再逐步补齐非关键内容。**这是此次性能改造中最符合对话产品特点的思路。

很多 Web 应用在页面初始化时，试图一次性准备好所有内容：完整侧边栏、全部会话、模型配置、插件信息、历史附件和用户设置。这样做的好处是页面加载完成后状态比较完整，坏处是任何一项数据变慢，都会拖慢整个页面。

Claude.ai 这类产品更适合采用“先让用户开始工作”的策略。输入框、发送按钮、当前会话骨架和基本导航应该优先出现；历史会话、复杂设置和低频功能则可以在后台继续加载。

这种策略背后的判断很简单：用户打开 AI 产品，最重要的动作通常不是浏览全部历史记录，而是立即输入下一条问题。

从产品体验上看，页面可以被拆成三层：

• 核心层：输入框、发送按钮、当前消息流和停止生成；
• 辅助层：会话标题、模型切换、附件状态、工具调用提示；
• 延后层：历史会话完整列表、设置页数据、低频配置和统计信息。

核心层应该尽可能早地可用。辅助层可以随着请求返回逐步补齐。延后层则不应该阻塞对话主流程。

这套分层并不只适用于 Claude.ai。任何带有长上下文、文件上传、工具调用或多代理流程的 AI 产品，都应该重新审视哪些状态真的需要在第一时间完成初始化。

第四层重构：流式输出不只是模型能力，也是前端性能问题

流式输出，是模型生成内容后立即分段发送并渲染，而不是等待完整答案生成后一次性返回。

现在几乎所有主流 AI 产品都支持流式输出，但“支持流式”不等于“流式体验好”。如果前端每收到一小段文本就触发完整页面重排，长回答、代码块和复杂 Markdown 很快会让浏览器主线程变得拥堵。

常见问题包括：

• 每个 Token 到达后都重新解析整篇 Markdown；
• 代码高亮在输出过程中重复执行；
• 消息列表不断改变高度，导致滚动位置跳动；
• 长上下文对话中，所有历史消息都参与重新渲染；
• 工具调用状态更新和文本输出互相触发重绘。

因此，AI 应用的流式优化不能只看网络层，还要看浏览器如何消费这些数据。更合理的策略通常包括：对短时间内到达的内容进行批处理；只更新当前正在生成的消息；将已完成消息冻结，避免重复渲染；把代码高亮、附件预览等高成本任务放到低优先级队列中。

这里有一个容易被忽视的判断：流式输出的目标不是让每个 Token 都尽快显示，而是让用户持续看到稳定、有意义的进展。

如果每个字符都实时刷新，却导致页面滚动抖动、输入框失去响应，用户体验反而会变差。AI 前端需要在“实时感”和“渲染稳定性”之间做取舍。

为什么这次改造只用了两周？

两周提速 3 倍的前提，不是两周内重写整个 Claude.ai，而是集中处理最影响主路径的少数瓶颈。

大型 AI 产品通常已经积累了大量功能：文件、项目、记忆、工具调用、联网搜索、代码执行、团队空间以及多种模型配置。全面重构的风险很高，也没有必要。真正有效的做法，是先把性能问题拆成可测量的用户路径，再优先处理最短板的环节。

从工程管理角度看，这类项目通常会遵循几个原则：

1. 先建立基线：记录首屏可用时间、首个 Token 时间、会话恢复时间和长回答渲染耗时；
2. 优先处理高频路径：不要先优化极少数用户才会访问的设置页；
3. 每次只改一类变量：否则很难判断性能改善来自哪里；
4. 同时看平均值和尾部延迟：P50 变快不代表最慢的 10% 用户获得改善；
5. 用真实用户数据验证：本地开发环境中的“很快”，并不等于真实网络环境中的“很快”。

尤其是尾部延迟。AI 产品的性能问题经常集中在少数极慢请求上，例如首次访问、历史会话特别长、附件较大、浏览器设备较旧或网络质量较差的用户。如果只看平均值，最需要改进的用户群体很容易被掩盖。

Anthropic 这次公开复盘的意义，也在于它没有把性能提升包装成模型能力升级，而是承认复杂 AI 产品的瓶颈可能来自基础设施、网络请求和客户端架构。这种透明度对开发者更有参考价值。

这和 Claude Code 最近的质量争议有什么关系？

Claude Code 的质量问题和 Claude.ai 的速度问题并不是同一件事，但它们共同说明了 AI 产品不能只追求单一指标。

此前，Claude Code 用户曾反馈模型在一段时间内出现推理质量下降、上下文衔接变差和代码任务完成度降低等问题。相关讨论将原因指向推理强度调整、上下文处理逻辑以及系统提示变化等产品层改动。

这类事件和 Claude.ai 的性能重构放在一起看，会得到一个更重要的结论：AI 产品优化通常存在速度、成本、上下文完整性和回答质量之间的交换关系。

把推理预算调低，可能降低等待时间，但也可能影响复杂任务的可靠性；清理历史推理内容，可能节省上下文成本，但也可能让长会话中的决策链断裂；增加更多系统提示，可能改善输出格式，却可能压缩模型用于解决问题的有效空间。

因此，性能优化不能只看“快了多少”，还要问三个问题：

• 质量是否保持稳定？
• 哪些用户群体受益，哪些用户群体受损？
• 优化是否改变了模型在复杂任务中的行为？

对开发者而言，最危险的性能改动不是明显的宕机，而是那种让系统表面上更快、实际上悄悄降低任务成功率的改动。

和竞品相比，Claude.ai 的速度优势能维持多久？

Claude.ai 的这次提速更像是工程效率的补课，而不是形成永久技术壁垒。

ChatGPT、Gemini、Perplexity 以及各种 AI 编程工具都在持续优化类似问题。请求并行、缓存、预加载、服务端渲染、流式渲染和增量更新，已经是成熟互联网产品的通用技术，不会因为某家公司先公开复盘就变成独家能力。

但这不意味着这次优化不重要。AI 产品的真正难点在于，模型链路比传统 Web 应用复杂得多：请求可能要经过权限系统、上下文拼接、模型路由、工具调用、内容安全检查、计费统计和多轮状态管理。任何一层都可能把一个简单的聊天请求变成多阶段工作流。

Claude.ai 如果能够持续把这些能力整合在较低延迟下，对高频用户尤其重要。对于开发者、研究人员和企业用户来说，偶尔快一次没有决定性意义，真正有价值的是连续几十轮对话后仍然保持稳定响应，不因上下文变长、工具变多而明显变慢。

换句话说，AI 产品的速度竞争正在从“谁的模型首 Token 更快”转向“谁能在复杂工作流中保持稳定的端到端延迟”。

给 AI 产品开发者的四个启示

**第一，先测量用户路径，再讨论优化方案。**不要因为模型接口变慢，就立刻更换模型。先确认时间到底消耗在网络、鉴权、上下文组装、模型等待还是浏览器渲染。

**第二，把首屏可用和数据完整分开。**用户需要的是尽快开始工作，而不是等待所有后台数据准备完毕。对话产品尤其应该优先保证输入框、消息流和停止生成等核心功能。

**第三，流式体验必须由前后端共同设计。**服务端提供流式数据只是起点，前端还需要处理批量更新、消息冻结、滚动稳定和复杂内容渲染，否则网络层节省下来的时间会被浏览器消耗掉。

**第四，不要用速度指标掩盖质量变化。**任何降低推理预算、压缩上下文或调整系统提示的改动，都应该配套任务成功率、用户重试率和长会话质量评估。

最后：AI 应用的下一场竞争，在模型之外

Anthropic 用两周时间把 Claude.ai 提速约 3 倍，最值得关注的不是这个数字本身，而是它揭示了 AI 产品竞争的重心正在变化。

模型能力仍然是基础，但当主流模型都能完成大多数通用问答后，用户体验越来越取决于模型之外的系统工程：数据如何加载、状态如何恢复、输出如何渲染、工具如何调度、上下文如何保留，以及系统在最复杂的场景下是否依然稳定。

这也是 Claude.ai 这次性能重构对开发者最直接的提醒：如果你的 AI 产品很慢，不要先假设模型不够快；如果你的 AI 产品很难用，也不要先假设用户不会写提示词。很多问题，可能藏在产品架构本身。

在接下来一段时间里，AI 应用的速度评价标准大概率会继续变化。用户不再只关心“多久开始输出”，还会关心长对话是否卡顿、工具调用是否顺滑、页面是否稳定，以及复杂任务能否在较少重试下完成。

模型决定产品的上限，工程决定用户能否真正触及这个上限。Claude.ai 这次两周提速 3 倍，本质上是 Anthropic 对后半句话的一次公开证明。

参考来源

1. GitHub 站内检索：How we made claude.ai 3x faster in two weeks —— 用于检索 Anthropic 工程复盘文章及相关技术讨论。
2. GitHub 站内检索：Claude Code quality reports —— 用于补充了解 Claude Code 质量反馈与产品层优化讨论。