两周，三倍。Claude 团队把 claude.ai 的加载与响应速度拉高了三倍，而这次性能攻坚的主力工具，是他们自己家的 Claude。真正值得琢磨的不是这个数字，是过程：测量、归因、改代码，三个阶段里模型都在场。官方博客干脆连用到的提示词一并公开了。于是一份战报变成了一套能照抄的工作流。
三倍提速之前，先承认你根本不知道慢在哪
火焰图永远比直觉可靠
性能优化最常见的失败方式，是凭手感开工。团队做的第一件事不是改代码，而是把尺子立起来：真实用户的首屏时间、首 token 到达时间、交互响应延迟，拆成几条独立曲线持续记录。为什么非要拆？因为这三条曲线背后的因果链压根不是一回事。首屏慢，多半出在资源加载和关键渲染路径；首 token 慢，指向服务端排队和调度；交互卡顿，则常常是主线程被长任务堵住了。混成一个「整体偏慢」的指标，你得到的只是一个没法动手的结论。
首屏、首 token、交互延迟，是三笔账
把这三笔账分开之后，优先级才排得出来。产品体感上最刺人的是首 token——用户敲完一句话，眼睛盯着空屏等，那段沉默比任何进度条都难熬。所以团队把流式的每一段延迟都打上时间戳，从请求发出到第一个字符落到屏幕上，中间被切成若干区间。哪个区间占了大部分耗时，修复的枪口就对准哪里。这种做法听起来朴素，但它直接掐死了「我们一起优化一下吧」这类没有靶子的讨论。
把「慢」拆成能证伪的小问题
一个笼统的性能投诉无法被验证，也就无法被解决。团队把它翻译成一句句可以被数据判死刑的话：某个组件的重复渲染是不是主因？某次请求能不能合并？某个长列表的重排能不能推迟到空闲时段？每一条都对应一个可测量的假设。这一步做完，后面交给 Claude 的工作才有明确的输入，否则模型也只能给你一堆正确的废话。
让 Claude 上场，功夫全在喂什么
给它 trace，别给它形容词
很多人用模型调性能，问的是「我的页面很慢，怎么优化」。这种问法注定得到泛泛而谈。有效的做法是把 profiling 数据、调用栈、相关源码片段一起塞进去，让模型看见真实的执行路径。它的强项不在于背出优化清单，而在于面对一份具体的 trace 时，能指出「这个函数在 200 毫秒里被调了 47 次」这种人类扫一遍会漏掉的模式。数据越具体，回答越具体，这条规律在这里格外硬。
逼它自证，也逼它自拆
模型给出一个可疑的瓶颈点，别急着照做。追问它：如果这个假设是错的，数据会长什么样？有没有别的解释能同样吻合这些数字？这种反向质询能把不少听起来合理的猜测筛掉。团队在博客里强调的也是这个节奏——先让 Claude 提出假设，再让它自己找反例。跑一轮下来，剩下两三个真正值得动刀的，比一口气列出二十条建议有用得多。
一次神提示不如一套能复用的模板
真正被团队保留下来的，是那套反复调用的提示词结构：交代上下文、贴入数据、限定输出格式、要求给出验证方式。每次遇到新的性能问题，换个数据填进去就能跑。这比追求某一句「神奇咒语」务实得多，因为性能优化从来不是一次性事件，它会一直发生。能复用的提示词，本质上就是团队新增的一条工程流程。
两周时间表
前三天只搭基线
这三天不写任何优化代码。全部精力用来把测量做实：埋点补齐、指标定义对齐、自动化脚本跑通。听上去慢，但它省下的是后面十一天反复争论「到底有没有变快」的时间。没有基线，任何改动都是玄学。
中间一周：批量修、逐个验
进入主攻阶段，节奏变成流水线：Claude 辅助定位、工程师写补丁、自动回归验证、数据回填看曲线。同一类问题攒够几个就一起处理，避免在相似的地方反复切换上下文。速度提升主要来自这一周，但它的效率建立在上一周的测量基础上，而不是靠加班堆出来。
末段两天，守住不倒退
性能是会被悄悄吃回去的。最后两天做的事是把它锁住：加性能预算告警、把关键路径的指标接进日常监控、让明显回退的改动在合并前就被拦下来。做完这一步，「三倍」才是可持续的状态，而不是一次发布会上的数字。
比「快了三倍」更重要的事
模型在性能工程里换了个座位
过去模型在工程流程里的位置偏下游——写代码、补测试。这次它被放到了诊断环节，掺和的是「哪里有问题」这个更靠前的判断。这个位置的变化不小：写代码可以事后校验，定位瓶颈却高度依赖对数据的解读能力，而这恰好是当前模型的强项。团队愿意把提示词公开，某种程度上也是在说，这条路别人也能走。
性能预算，得变成每天的例行动作
两周四倍速的故事容易让人误以为性能优化是一场战役。它更像日常卫生。指标的采集、异常的告警、合并前的拦截，这些动作一旦内建成流程，就不需要再组织一次「专项攻坚」。Claude 在其中扮演的角色，是把这个流程里最耗人力的解读环节压缩掉。工具会换，这套做法不会过期。
