「闪电.skill」发布！Anthropic两周提速3倍的方法，拿来给自己用

前几天Anthropic发了一篇文章，讲他们怎么用两周时间，把claude.ai和桌面端的核心体验提速了3倍左右。打开网页到能打字，从3.1秒降到0.55秒（按第75百分位算，也就是四分之三的用户比这个数快），四类操作、13项指标，几何平均快了3.1倍。

整个过程都在一个Slack频道里，Claude找问题、搭测试、改代码，人定目标、做取舍、审批改动。据他们自己的复盘，两周合进去3000多个改动，没有一次影响用户的事故，也没有回滚。我觉得这篇很值得读，他们连跟Claude怎么聊、在哪些地方拦住它，都写出来了。（他们用的是Claude Tag，背后跑着一个跟Opus 5.5水平差不多的内部研究模型。）

我也照着这套方法，让agent给自己的4个网站提了一遍速，整理成了一个「闪电.skill」。公众号排版器在实验室里，打开到能打字的耗时少了九成，另外几个站就没这么夸张了，后面一起说。

原文：https://claude.dev/blog/how-we-made-claude-ai-faster/

先把快慢量出来

对我这种不会写代码的人来说，跟AI说「这个页面有点慢，帮我优化一下」，它就能改，改完还能告诉我用了什么技术，效果提升了多少。至于到底快没快，快在哪里，我也未必知道怎么判断。

Anthropic先把用户经常干的事列出来：打开App、开始对话、加载旧对话、发消息。从用户点下去，一直量到结果出现在屏幕上，Claude去找原因，改完再量。

但时间这个数不太稳定，电脑上多开几个东西，结果可能就不一样。他们就让Claude试试数程序执行了多少条指令。在固定的Valgrind加node --predictable环境里，纯JS代码的指令数能稳定复现，浏览器里的操作则另找React提交次数、样式重算次数这些指标。

Claude发现，组装对话消息树的一段代码里，同一个消息ID被查了三遍，一个小时后，指令数少了48%，实际运行时间少了78%。他们要求每个新指标都这样验证：这个数变好，实际耗时也得跟着降，证明不了就撤掉。

有效的指标再写进自动检查，后面谁的改动让它变差，就不让合并；继续优化，数又降了，上限也跟着降。原文叫棘轮，以后加新功能时，能知道有没有把之前省下来的时间又吃回去。

这条我自己摔过跤。我之前给写作系统做过一个「表达指纹」，用一个数衡量AI写的东西跟我手写的文章有多像。让AI对着指标改了4轮，距离压到0.32；另一组只在写之前读三篇我的手写文章，一遍写完，距离1.71。按指标算，前一篇比后一篇好五倍，我读完觉得，前一篇明显更差，后一篇好太多。

后来我就把它从优化目标里撤了，只留着查明显问题。你给AI一个数，它确实有能力把这个数做得很好，至于这是不是你想要的，可能得另外想一想。

他们原来觉得两周大概能做完大部分项目，结果第三天，13个目标就完成了12个。随后继续让Claude自己找机会，哪个地方还有得改，就开一个线程做下去。

其中一个办法，我后面直接用在了排版器上：把能打字的输入框先写进HTML，页面框架没启动完，用户就可以输入，等框架起来再接过去。他们专门测了交接时会不会丢字，还在14种窗口尺寸下比对两套页面。

整个冲刺同时跑着150多个线程，每个都有人负责，每个改动至少一个人批准，高风险改动先给员工用，再放给1%的用户，最后全量。有一次Claude为了每次发送省2毫秒，提了一个900行的改动，工程师直接否了，维护这套东西不划算。另一些时候又得催它，Claude说这周内提一个小改动，工程师让它大胆一点，说现在提就马上合并部署，下一分钟它就改口，一小时内提上来。

说起来，今年2月我也开过一组agent帮我做产品，然后下楼吃烤鱼，一个多小时后回来，8个agent把我200美元会员的用量烧光，还额外烧了65美元，我赶紧把它们的电源拔了。

拿自己的网站试试

所以这次给自己的网站做优化，我先让它们定义清楚什么叫打开到能用，留好旧版，补好检查，再开始改。目标我定得挺高，打开到能用的耗时少九成，每个站一个agent。

最后的对比都在我电脑上跑，旧版、新版轮换着测，清空缓存，给请求按Fast 4G限速，每版测10到25次取第75百分位。中间还发现4个agent在同一台电脑上测速、构建，会互相抢CPU，谁先测谁后测也能影响结果，后来又把先后顺序轮换了。

排版器效果最好。它原来打开页面，要先从外面同步下载5个脚本，没下完就一直白着。其中有两个库，一个导出图片时才用，一个粘贴富文本时才用，根本没必要让所有刚打开页面的人都等它们。agent把这两个改成用的时候再加载，另外的基础库放回自己的域名，再照搬前面那个静态输入框，先让人能打字。

实验室里，打开到能打字从2238毫秒降到209毫秒，少了90.7%。不过预览区还是要等框架启动，这一项从2238毫秒降到1037毫秒。线上从我电脑实际访问，能打字从3.25秒降到1.52秒，我电脑走代理，光建连接就花了大约1.4秒，跟实验室那个数不是同一回事。

还有个差点漏掉的问题。这个提前出现的编辑框是空的，但老用户上次写的草稿，要等框架起来才填进去。用户看到空白，直接粘贴一篇新文章，旧草稿就可能被后续的自动保存覆盖。

负责改代码的agent测了打字会不会丢字，没测到旧草稿，是另一个负责复核的agent发现的。后来改成编辑框一出现就先填好草稿，再补了专门的测试。

bookai.top那个教程站，搜索点击最多的一篇文章里，首屏放了一张两三千像素宽的手机截图，实际只显示753像素。把图压到合适的尺寸之后，在1440宽的桌面屏幕上，打开到能用从7776毫秒降到1588毫秒，少了79.6%。但手机上这张图不在首屏，同样的改动，打开速度基本没变化。

img2046的压缩工具页，把只有批量下载时才用的两个库延后加载，打开到能用少了11%，脚本执行时间少了29%。不过它改完之后，批量下载一度报错，好在补测多文件下载时查出来了，修完再测，压缩包跟原来逐字节一致。

我的个人主页就没什么动静，打开到能用只少了1.6%，还在测量误差里。头像换成WebP，最大内容渲染那项少了13.4%。最初agent说主要瓶颈在服务器，因为从我电脑访问要等1.4秒才收到第一个字节，后来拿vercel.com作对照，也一样，才发现是我电脑的代理。

四个站，只有排版器到了九成。我原来给的目标是一样的，最后能省多少，还是得看它原来到底卡在哪里。

网页慢这么一点，对用户有没有影响，其实早就有人测过。2009年谷歌做过实验，故意让一部分用户的搜索结果页慢100到400毫秒，这些人每天的搜索次数就少了0.2%到0.6%。慢400毫秒那组，撤掉延迟后的五周，搜索量平均还比对照组低0.21%。当然，搜索引擎的数不能直接套到我这种小网站上。

领取闪电.skill

这4个站的改动已经上线，踩过的坑也都放进了闪电.skill，测速、记录基线、检查以后有没有变慢的脚本都带着。

名字来自《疯狂动物城》车管所那只叫「闪电」的树懒。

https://github.com/alchaincyf/huashu-flash

把这个链接丢给你在用的agent，让它帮你安装就行，或者在终端运行：

npx skills add alchaincyf/huashu-flash

然后跟它说，帮我看看这个网站到底慢在哪。