Anthropic 三位工程师在开发者博客上复盘了如何用两周时间，把 claude.ai 网页版和桌面端的核心体验整体提速约 3 倍：打开页面到能打字从 3.1 秒降到 0.55 秒，新开会话从 0.8 秒降到 0.3 秒，加载云端会话从 2.6 秒降到 0.73 秒。13 项指标几何平均快了 3.1 倍，每天能帮用户省下几万小时等待。干活主力是 Claude，整个冲刺跑在一个 Slack 频道里，两周合入 3000 多个改动，零事故零回滚。核心结论就一句话：只要 Claude 能把一件事衡量出来，它就能把这件事变快。
核心方法：爬山（Hill Climbing）
性能优化中，测量不再是第零步，而是爬山的第一步。Claude 只要有一个能比较的数，就能开始改代码、跑 benchmark、看数字有没有往下走，而且能异步干好几个小时，一晚上自己试很多轮。杠杆最高的事变成了一件：找到更多可衡量的数据指标。
配套三要素：一是每个 benchmark 先证明自己——压下去后用户真实感受到的耗时也会跟着降，证明不了就下线；二是棘轮（ratchet）——benchmark 写进 CI，数字只许降不许升，PR 让数字变差就不让合并；三是护栏和掌舵——每个改动至少一人审批，用户可见的改动放功能开关后面，高风险的先员工、再 1%、最后全量。
实施过程
设定目标与基线
冲刺开始前建了 Slack 频道，给 Claude 留了常驻指令负责性能事务。Claude 通过 Datadog MCP 分析数据，找出影响最大的四类用户操作：打开 App、开始对话、加载已有对话、发送消息——这四类占用户全部活动的 95%。算上网页端和桌面端，一共 13 项测量。
第三天就达成了 12 个目标。开局留了空间让 Claude 自己找机会，结果 Claude 提出来的方向远超预期，于是重新定目标，继续找更多能数的东西。
寻找确定性指标
他们希望 Claude 验证原型时不用等线上数据回来，所以得在实验室里另找测性能的办法。Sam 提出数 JS 指令数：纯 JS 热路径用 Valgrind 跑 benchmark，加 node --predictable，跟基线比就行。浏览器路径用 React 提交次数、V8 函数调用次数、布局和样式重算次数、DOM 变更次数。
一个小时后，两条热路径的指令数分别降了 48% 和 31%，真实耗时分别降了 78% 和 44%。CI 里加了两个新棘轮：任何让指令数变多的 PR 都过不了 CI，每天有个任务，数字降了就把上限往下调。
建立优化循环
稳定循环：有人开讨论串附截图或录屏 → Claude 追踪流程建 benchmark → 实验室拿到结果后带 PR 回来 → 上线后 Claude 盯部署读数据 → 变快了拧紧棘轮，没变就关掉开关继续迭代 → 找下一个慢的地方。
举例：侧边栏会话陆续蹦出来导致页面抖动，CLS 指标几乎检测不到。Claude 建了遥测事件，把每次布局偏移来源对应到有名字的区域和阶段，加了集成测试故意触发偏移，在主分支跑 20 次全红，修复 PR 上跑 20 次全绿。上线后发现 31% 的页面加载在能用后有东西在挪位置，逐个修掉。
冲刺期间同时跑着 150 多个这样的线程。
并行扩展线程
一个线程跑通后多开就行。单个线程能提 50 个优化 PR，有时到 100 个。越来越多的时候是 Claude 自己在开新线程，追它在排查或定时任务里发现的机会。
Claude 全面排查 CPU 卡顿时发现：只要回复 markdown 里有破折号或弯引号等非 Latin-1 字符，V8 就会把整段按 UTF-16 双字节存储，语法高亮正则都被赶到慢路径。修法是一个 20 行改动：高亮前先把代码块复制成单字节字符串。
搭建安全护栏
每个 PR 过自动审查加至少一人审批；单元测试先于优化；用户可见改动放功能开关后面。两周加了近 200 个功能开关，结束时一半以上已清理。
静态输入框是个脆弱设计：HTML 页面副本在上面绘制真正页面，差一个像素就破。所以搭了几十道护栏：jsdom 渲染保证两者不走样、14 种视口逐一比对误差 1 像素内、按键测试交接时持续打字、线上每次交接上报偏移量精确到十分之一像素。
120Hz 帧预算挑战
为了演示实时语法高亮优化，Claude 搭了 120Hz 测试台，用 DevTools begin-frame 控制做确定性逐帧步进，每帧 8.33 毫秒。每一帧画面只有 8.33ms 预算，Claude 一帧一步找出慢的部分，已输出的块缓存、分词逻辑挪到 worker、表格逐格显示。一个线程合入近 60 个 PR，长回复阻塞主线程从 750ms 降到约 200ms，CPU 占用降到三分之一，120Hz MacBook 上全程稳在 120fps。
经验提炼
提出量化目标
先让 Claude 把「快」变成一个数——页面打开到能点击多少毫秒、打包文件多大、打字触发多少次重渲染。测量从第零步变成爬山的第一步。
验证指标有效性
真实的量太吵就换一个稳定的量，前提是先证明两者挂钩。Anthropic 放弃拿毫秒当 CI 闸门改数 CPU 指令数，就是这个逻辑。证明不了的 benchmark 一律下线。
锁定已有成果
每次优化完顺手写检查，把现在的数记下来，以后任何改动让这个数变差就报错。每天数字降了就把上限自动往下调，赢下来的东西就不会在后续改动中悄悄流失。
先建护栏，再扩并发
Anthropic 同时开 150 多个线程两周 3000+ 改动零事故，靠的是整套护栏：每个改动至少一人审批、单元测试先于优化、用户可见改动放功能开关、高风险先员工再 1% 再全量、每个线程有具名的人负责。
人的三项职责
野心：Claude 默认保守，工程师要鼓励它大胆，Raymond 那句「请勇敢一点」就是。目标达成后挨个线程发话：「继续往下压，野心大一点。」
品味：表格一格一格出还是一行一行出、骨架屏何时出现、逐词淡入值不值得花帧预算——Claude 负责抠毫秒，取舍由人拍板。
方向：线程保持窄，只盯一个 benchmark。人决定先后顺序、合并踩脚线程、边际收益递减时关掉线程。900 行换每次省 2 毫秒？一句话毙掉。
实战验证：4 个网站提速
作者让 agent 照这套方法给自己的 4 个在线网站提速，每个站派一个 agent，目标打开到能用 p75 少九成。
效果最好的是公众号排版器：实验室里打开到能打字从 2238ms 降到 209ms，少了九成。三招：按需加载图片/粘贴富文本才用的库、Vue 和 markdown-it 回自有域名、照搬静态输入框写进 HTML。
bookai.top 搜索最热门文章首屏图从几千像素压到合适尺寸，桌面端打开到能用从 7776ms 降到 1588ms，少 79.6%。img2046 压缩工具页按需加载两个库，打开到能用少 11%，脚本执行少 29%。个人主页变化不大，头像换 WebP 后 LCP 快 13.4%。
测量陷阱避坑
踩了三个坑：一是测量机自己的网络——电脑走代理导致所有站首字节时间都在 1.4s，跟网站无关；二是屏幕宽度——同一张图桌面端在首屏是瓶颈，手机端掉到首屏外测不出变化；三是同时开工——4 个 agent 同台机抢 CPU，轮换先后顺序才拿到可信数字。
