来源信息

  • 文档类型：阅读笔记 · 整理日期 2026-10-07
  • 原文：《How we made claude.ai faster》 · 作者 Raymond Wang、Sam Attard、Issac G. · 发布于 claude.dev · 发布日期 2026-09-23
  • 原文地址：https://claude.dev/blog/how-we-made-claude-ai-faster/
  • 本文为阅读整理，观点与数据以原文为准；原文不提供的事实均已标注为整理者说明。

阅读范围

  • 全文，含目标、指标爬坡、线程闭环、扩展、防护、人工引导、帧预算与后续。

样本与目标

文章回顾 2026 年 8 月两周冲刺，用内部研究模型和人工批准改进网站与桌面体验。实时用户监测比较 8 月 13 日与 27 日：网页可输入时刻的 p75 从 3.1 秒到 0.55 秒。标题“约三倍”是核心旅程的概括，不是所有操作、模型推理或网络请求都快三倍。

团队从高频旅程建立统一起止点，区分客户端与服务端。静态输入框、桌面代码缓存、复用组件与预取等解决不同瓶颈，不能归因于单一技巧。

测量与线程闭环

真实耗时有噪声，实验室尝试指令计数、函数调用、渲染提交、布局及 DOM 变化等代理指标。只有证明关联用户延迟、且稳定的指标才成为回归门槛。

流程是发现慢路径、建立基准、小步修改、部署看真实数据，再收紧门槛或关开关重试。侧栏抖动案例显示总体 CLS 好看也可能漏掉体验问题，需按区域与阶段监测。并行扩展后还发现重复订阅、样式重算与字符串高亮等问题。

防护、引导与帧预算

修改先有测试、自动审查和人工批准，可见风险用短期功能开关与分阶段发布。静态界面接管需检查尺寸对齐、按键不丢失与现场位移，实验室还可能遗漏浏览器界面触发的变化。

人负责目标、体验取舍、线程边界与维护成本。120 Hz 实验采用确定性帧推进及约 8.33 ms 预算，通过缓存完成块、将处理移到 worker 等优化；保持 120 fps 的报告有特定 MacBook 与场景条件。结语仍列 p95、其他旅程和长对话的改善空间。

限制与游戏开发建议

这是特定产品、负载、硬件和冲刺流程的报告，未独立复现实验，也不能复制其百分比预测游戏性能。本文未运行基准、部署或建立持续监控。

以下为整理者建议，非原文实测，也不表示已经实施。

要塞场景先定义玩家感受的等待和帧时间，再按寻路、NPC 调度、资源查询与 UI 刷新拆分。操作计数可辅助定位，但必须与目标设备的帧耗时关联，不能只追求计数下降。

用固定场景、种子和单位规模做可重复基准，并补充真实试玩。优化前后核对行为一致性，关注峰值和长尾，而非仅平均值。缓存、批处理与跨线程可能引入过期状态、任务延迟或顺序问题，需功能断言保护。

每次只验证一项假说，记录收益和维护代价；若小幅提速需要复杂机制，应由人判断是否值得。回归门槛也要允许合理功能增长，不能让单向数字目标迫使系统牺牲体验。

小结

先让正确的体验指标可测，再形成优化、现场验证与回归保护闭环；人的判断决定哪些数字值得追求。

参考来源

相关笔记

说明

  • 本篇主题为前端性能测量，Anthropic 官方文档中暂无对口章节，外链改用 Google web.dev 官方性能文档。