Anthropic 如何使用 Claude 改善应用性能

我喜欢全栈性能的细节：数据加载、浏览器，以及系统的端到端使用体验。Anthropic 称，在为期两周的冲刺中，它主要借助 Claude 让 Claude 网页和桌面应用的核心体验快了约三倍。我想看看团队测量了什么，又给模型提供了哪些工具。

文章称，四类用户流程占了 95% 的活动：启动应用、开始对话、加载对话和发送消息。在第 75 百分位，网页从全新加载到可以输入的时间从 3.1 秒降到 0.55 秒；启动 Claude Code 会话从 0.8 秒降到 0.3 秒。

同一份报告称，加载 Claude Cowork 云端会话的时间从 2.6 秒降到 0.73 秒。桌面应用冷启动的例子从约 6.3 秒降到 3.3 秒。这些是特定流程和百分位的测量，并不保证每次交互都快三倍。

我自己也注意到此前的一些改进，并看到网站采用了 TanStack Router。我好奇团队在框架更换后如何找到更多提升，尤其是性能应当包含用户实际能够做什么，而不只是内部组件何时报告加载完成。

在我快速的浏览器测试中，刷新和发送提示词感觉更快了。但我创建线程后立即刷新，它没有立刻出现在最近列表中。后来缺失的线程出现了，所以我观察到的是显示延迟，而不是线程永久丢失的证据。

ChatGPT 和 Claude 都曾使用本地缓存保存最近项目；在这个例子中，Claude 的侧栏看起来使用了 IndexedDB。显示缓存数据可以避免加载时侧栏为空，但也带来另一个问题：显示的数据何时、如何与服务器同步？

我在另一个浏览器中删除了两个线程，然后刷新。旧条目仍显示了一段时间，点击还会报错；后来它们消失了。我怀疑缓存过期或失效机制有问题，但这里无法查看 Anthropic 的代码，不能确定究竟是哪项实现导致了延迟。

在 T3 Chat 中，我们会让缓存内容保持淡化状态，直到服务器新数据到达，而不是把它呈现为肯定是最新的。这是另一个产品的设计选择，说明了同一个矛盾：既要让页面感觉即时，又不能掩盖缓存可能过期的事实。

我还注意到 T3 Chat 中有一个加载较慢的选择器，于是让智能体调查如何缓存其数据。这是实际使用界面时才容易发现的细节。快速首屏很有用，但如果其他控件仍在等待，它就不应是唯一目标。

Anthropic 称，团队通过 Claude Tag 在共享 Slack 频道工作，使用的内部研究模型被描述为大致相当于 Opus 5.5。团队报告冲刺中有超过 3,000 项变更，且没有面向客户的事故或回滚。我观察到的侧栏现象是另一个观察，不能独立验证该事故统计。

我曾怀疑模型护栏会不会妨碍深入的性能工作，后来检查自己的一个例子，发现实际中断来自针对删除命令的安全检查。这个纠正很重要：我没有证据表明那次中断是浏览器性能分析护栏造成的。

按照我的经验，OpenAI 模型擅长持续调查性能问题，部分原因是它们可用的计算机操作工具。两个模型家族都仍需要有效的测量工具，而我也经常自己检查结果。如果智能体看不到相关行为，声称它能优化系统意义不大。

Anthropic 给 Slack 频道设定了持续的性能任务，包括监控部署、评估遥测、维护仪表盘、提出机会并与人沟通。Claude 通过 Datadog MCP 连接找出四类影响最大的流程；团队随后为不同产品和平台定义了 13 项可比较的测量。

每项测量都从用户交互开始，到结果渲染完成为止，并区分客户端与服务器工作。这很重要：我见过仪表盘报告组件转换只用了 200 毫秒，却忽略了到达该组件之前已经花了好几秒。局部追踪很快，仍可能掩盖缓慢的用户体验。

团队从约 20 个选定项目开始，用估算的毫秒收益设定目标。文章说第 3 天已达到 13 项目标中的 12 项。我开玩笑说模型经常高估智能体工作的耗时，但实际进度本身不能证明最初估算保守的原因。

早期改进包括把静态输入框嵌入 HTML，让用户在 React 初始化期间就能输入，以及预编译 V8 代码缓存供桌面主进程使用。对话间保持输入框挂载、悬停时预取会话也帮助了导航；文章称侧栏重新渲染减少了 90%。

悬停预取是我最喜欢的让导航感觉即时的技巧之一。仍然需要考虑预取数据变化之后会发生什么：快速路径只有在结果准确、用户能理解状态时才有价值。

Anthropic 还邀请 Claude 在初始项目之后提出新工作。我喜欢在系统有充分测试时为不寻常的想法留出空间。让智能体提出更大胆的方案可能发现狭窄指令不会揭示的选择，但方案仍需验证并权衡取舍。

我在 Lakebed 上尝试过类似方法，要求提出极端的性能方案。智能体提出持久 V8 执行服务、查询编译器以及应用数据的持久本地所有权。我选择了第一个，并报告在自己的工作负载中提升两到四倍；另外两个想法没有实现。

Lakebed 的工作并不是一句神奇提示词。我们花时间构建性能检查和行为回归检测，工作持续数小时，中间还有中断。有用的模式是给智能体探索空间，同时建立证据证明结果确实有效。

Anthropic 希望迭代速度快于部署周期。实际耗时有意义但噪声较大，因此团队探索确定性代理指标：JavaScript 指令数、V8 调用数、React 提交次数、样式重算和 DOM 变更。多个调查可以同时在不同线程中运行。

对于纯 JavaScript 热路径，文章介绍了使用 Valgrind 和 Node 的 predictable 模式，并将指令数与提交的基线比较。浏览器工作则需要不同的测量。每种测量呈现的行为不同，没有任何一种自动证明页面感觉更快。

我担心，如果智能体只优化调用数或请求数，可能会删掉保持数据新鲜的工作，即使这些工作并不阻塞交互。我认为这可能与观察到的侧栏现象有关，但这只是理论。我没有验证究竟是哪项改动造成了该现象。

做性能工作时，我常常先要求提出几种理论，让智能体构建候选改进，然后自己体验。数字指标可能漏掉细微的用户体验回归；测试应当反映真实使用者关心的事。

文章说团队对每个新基准都保持怀疑。有用的指标既要能在实验室里改善，也要能作为 CI 护栏；如果它不稳定或与用户延迟不相关，团队就丢弃它，而不是优化错误的目标。

在 T3 Code 中，我减少了打开大型线程所需的数据量，并增加了一个 CI action，使用有代表性的已存线程数据来测量传输量。这个 action 可以向实现智能体和审查者发出回归信号，但不能代替检查界面是否正常工作。

智能体帮助制作了这套测试。我本人没有读过每一行，但它的信号确实帮助我的工作捕获了回归。我认为，即使生成的测试代码不属于交付产品，用智能体构建测量工具仍然有价值。

Anthropic 在两个热路径上比较了指令数与实际耗时：消息树组装和状态行扫描器。它报告指令数分别下降 48% 和 31%，实际耗时分别下降 78% 和 44%。图表本身没有给出评估实际影响所需的绝对时长。

团队为这些计数增加了 CI 上限，并在路径改善时由每日任务降低上限。我喜欢这种只向更好方向更新的机制：否则真实改进可能悄悄成为后来回归的空间。但实现和用户目标变化时，阈值仍需要谨慎维护。

我见过数字质量门槛适得其反。在 Twitch，我曾因为删除大量未使用实现会改变总体覆盖率百分比而无法删除它，尽管替代实现拥有完整覆盖率。当指标被当成目标而不是信号时，它可能阻止改进。

更大的教训是，测量给智能体提供了可以具体改善的东西。但数字必须代表值得解决的问题，团队也必须对照用户体验检查结果。测量工具不能代替对产品的判断。

Anthropic 描述了一个重复循环：有人针对缓慢流程开线程，Claude 追踪并建立基准，产出的 PR 按风险和审查需要控制规模。用户可见的改动放在功能开关后面；部署后，现场数据决定保留、关闭开关还是继续迭代。

这个循环包含真实用户数据，很重要。我还希望提出和合并改动的工程师亲自试用结果。有些回归虽然少见或令人烦恼，却不够明显，用户未必会以团队能看到的方式报告它们。

对于 T3 Code，我让一个 GitHub 标签触发 macOS 桌面构建，这样我就可以在另一台机器上下载并测试 PR，而不必手动构建。降低试用改动的摩擦，能让亲自审查更容易发生。这类基础设施可能和新仪表盘一样有用。

Anthropic 文章中的屏幕录制显示，侧栏各行在不同时间出现。现有的累积布局偏移监控没有捕获它：每次偏移约为 0.008，低于常用的 0.1 阈值。团队增加了更具体的事件，以及针对指定区域偏移的集成测试。

我怀疑，如果测试禁止任何后续偏移，可能会让团队不愿在服务器返回更新列表时刷新本地缓存的侧栏。这是一种可能的失败模式，并不是对我观察到的旧条目的已证实解释。文章没有提供足以证明它的实现细节。

据报告，现场事件发现 31% 的网页加载在页面可用后仍有内容移动。Claude 逐一处理迟到的标题、移动的插入符号和出现的滚动条等原因。缓存内容可以减少可见移动，但团队仍需要协调旧数据与新数据。

有观众问我不读代码怎么发现问题。我可以观察行为，并依据经验形成理论，但我也可能错。如果能访问代码仓库，我会让智能体先用证据检验这个理论，再告诉团队应该改什么。

这正是工程直觉仍然重要的地方：理解用户流程、识别可能的失败模式，并质疑测试是否捕获了真正的问题。我通过手工处理这些系统学到了很多；如今如何建立同样的直觉，我没有简单的办法。

一旦针对某个问题的调查和测试能够运行，团队就可以在多个线程或机器上并行做类似工作。在我的 T3 Code 例子里，建立测试后智能体合并了许多性能 PR。我报告了两个可见回归，这说明检查和审查仍然重要。

Anthropic 称，单个线程有时会提出几十个优化 PR，Claude 也会自行开启新调查。据报告，一次统计发现输入框打字路径中有 6,900 个 React hook 和 900 个 store 订阅，每次按键都会重新渲染。这是该次调查报告的具体数字。

另一个报告的发现是，一个根级 :has() 选择器给 DOM 变更加上了 24 毫秒。残留的 location.reload() 路径导致隐藏刷新；据称，相同的缓存快照还会每分钟两次在主线程中复制到 IndexedDB。这些都是性能分析揭示隐蔽工作的具体例子。

我再次猜测 IndexedDB 路径的改动可能与侧栏问题有关，但无法验证这种联系。人很容易把看似合理的故事当成诊断；没有追踪数据或代码，我只能把它作为待调查的问题。

在另一项报告的调查中，给已完成的代码块做语法高亮可能让页面冻结约一秒。Anthropic 将问题归因于响应含非 Latin-1 字符，使高亮正则走了更慢的双字节字符串路径。在高亮前将代码块复制到单字节字符串，降低了该例中测得的阻塞。

我更喜欢把昂贵的语法高亮移出主线程。在 T3 Code 中，我介绍了基于 worker 的做法，以及高亮完成前的视觉淡入。包大小和加载方式存在取舍，但目标是在后台工作时保持导航响应。

Anthropic 称最忙的时候一天有超过 200 项变更，约三分之一的 PR 增加了遥测或护栏。共享频道让不同团队的人可以讨论工作并请求审查。共享上下文有助于协调并行工作，但仍需要有人对决策负责。

根据文章，每个 PR 都经过自动审查和至少一次人工批准，测试先于优化编写，可能影响用户的改动使用短期功能开关。团队引入了近 200 个开关，结束时已清理超过一半。这些是团队报告的做法。

静态输入框需要早期 HTML 与 React 渲染版本对齐。团队称，它从真实组件生成静态标记，在 14 种视口尺寸下比较并要求误差不超过一像素，还测试了切换期间输入是否丢失或顺序错乱。团队也在现场测量移动。

高风险改动先向员工开放，再向 1% 的用户开放，最后全面推出。一名员工仍发现了现有指标没有捕获到的输入框偏移。这提醒我们，分阶段开放和人工观察可以发现实验室测试未覆盖的问题。

报告的原因是组织管理的浏览器中 Chrome 的推测性预渲染。新标签页有一个页脚，缩短了视口高度；预渲染的 Claude 页面继承了该高度，导航后才重新调整。团队让布局跨越尺寸变化保持固定，并为这一流程增加测试。

这是一个有趣的浏览器边缘情况：页面可能在用户导航之前就已渲染，使用随后会变化的尺寸。我最初猜测是扩展或布局计算，但那不是报告中的诊断。看到实际追踪结果比相信第一个看似合理的理论更重要。

Anthropic 将这项工作描述为高效但并非自主完成：人设定目标的雄心、选择取舍并指导线程。我喜欢明确告诉智能体，达到初始目标后仍可探索；前提是测量、审查和回滚机制足以支持这种探索。

文章中的一个例子里，模型建议等待数天建立基线。人类表示团队可以立即合并和部署，并鼓励它更大胆。在自己的工作中，我也见过模型给出的时间估计没有反映并行智能体工作流的实际能力。

措辞可能影响智能体考虑的选项范围。要求提出大胆或不寻常的方案，可能让它超越保守的初步回答。我不会把这视为无需证据就合并高风险改动的许可：有用的结果是更广的选项集合，而这些选项仍须评估。

每个优化线程都有一名明确的人类负责人。Claude 用截图或录制展示用户可感知的变化，由人决定何时显示骨架屏、表格是否逐步出现，以及动画是否值得其帧成本。这些选择关乎用户体验，不只是孤立的基准。

对于加载骨架屏，我会先查看真实等待时间的分布。如果数据出现前只显示两帧骨架屏，效果可能比什么也不显示更差。正确阈值取决于观察到的工作负载和用户实际看到的视觉行为。

我个人不喜欢逐词淡入动画，更喜欢等完整段落或代码块出现，而不是展示不完整的 token。T3 Code 使用另一种渲染方式保持页面响应。这是我的偏好；其他产品可能根据用户和测量做不同取舍。

我测试了 Claude 中的表格流式显示，看到单元格逐个出现。我更喜欢等完整表格，也不喜欢渲染不完整的代码块，因为这会让高亮更复杂。这正是文章在人类判断部分将此类决定称为品味的原因。

方向意味着让线程保持聚焦，并决定优先做什么、何时停止。文章描述了一个 900 行 PR 被拒绝，因为每次发送节省两毫秒不足以抵消维护新构建插件的复杂性。即使收益可以测量，如果增加的复杂性不成比例，也可能不值得。

一项调查以约 8.3 毫秒的帧预算为目标，这是 120 Hz 下每帧可用的时间。最初的无头 Chromium 测试环境以 60 Hz 运行，因此 Claude 探索 DevTools 帧控制，构建了确定性的 120 Hz 测试。这让团队能够反复测量流畅度。

文章中的 Slack 对话展示的是简洁进度更新，而不是每次工具调用。我觉得这适合某些任务：我需要足够的信息判断结果，但不总需要看每个命令。不同任务可能需要不同的细节程度。

团队逐帧检查长篇流式回复，发现每个数据块都包含随消息长度增长的工作。它缓存已完成的块，把增长中的代码块 token 化移到 worker，并选择逐单元格显示表格。我不同意最后的展示选择，但优化与这一产品决定是不同的事。

Anthropic 报告该项调查中合并了近 60 个 PR。在它的例子里，长回复的主线程总阻塞时间从约 750 毫秒降到 200 毫秒，CPU 使用量降至约三分之一，并在 120 Hz MacBook 上整个回复期间保持每秒 120 帧。新的 120 Hz 测试环境成为夜间回归任务。

我此前主张流式传输完整段落、代码块和工具调用，而不是不完整的 token。文章引用了这场讨论。无论团队选择哪种渲染方式，都应该同时测试响应速度和结果是否便于阅读。

Anthropic 称，第 95 百分位的流程和非常长的对话仍有改进空间，并计划另文介绍上游贡献。我曾批评 Claude Desktop，但也注意到了改善，并感谢参与工作的人。

我的结论是，先让智能体找到可靠的性能测量方法，验证这些测量，然后再追求改进。笼统地要求让系统更快，会引来猜测；可测量的循环则为智能体和人类审查者提供证据。

人仍有工作要做：选择重要的用户结果、审视取舍、测试产品，并决定复杂性是否合理。为智能体构建这样的环境本身就是工程工作，我很享受再次探索这些问题。