两周合了 3000 个改动，真正的教训是关于度量的

Anthropic 在八月用两周把 claude.ai 和桌面端整体提速了大约 3 倍。有意思的不是提速，是一个模型在大约 150 条并发线程上合了 3000 多个改动，零客户可见事故，零回滚。高峰日一天落地 200 多个。

数字都是 75 分位，8 月 13 日对 8 月 27 日。claude.ai 冷加载 3085ms 到 550ms，砍掉 5.6 倍。桌面端冷启动 6310ms 到 3328ms。Claude Code 桌面启动 837ms 到 347ms。加载会话 1557ms 到 646ms。Cowork 云会话 2566ms 到 728ms。Cowork 发消息 928ms 到 48ms，19 倍。最初十三个目标里有十二个在第三天就达成了。

值得抄的是那个循环。工程师或者模型从一段截图或录屏里认出一条慢路径。模型先建一个可复现的度量——Valgrind 指令数、V8 调用数、React commit 数、样式重算次数、DOM 变更数。有了数字才开始做原型，提交多个按风险大小切开的 PR，用户可见的改动全挂在开关后面。先发给员工，再 1%，再全量。然后读真实用户的现场数据，按构建版本和平台分好。成功就把基准值往下拧一格，当成永久护栏。失败就关掉开关继续挖。总共造了近 200 个开关，到冲刺结束一半以上已经退役。

整篇文章围着的那句话：一旦 Claude 能度量某个东西，它就能让它更快。反过来说，人这边杠杆最高的活变成了找出更多可以度量的东西。这把大多数人用编码 agent 的方式倒了过来——通常是人指定改动、agent 来写；这里是人指定指标、agent 去找改动。

用的模型是 Claude Tag，一个大致相当于 Opus 5.5 水平的内部研究模型，在一个 Slack 频道里靠常驻指令运转。人这边三条掌舵原则：野心（把模型从保守的范围里推出去）、品味（用户能感知的取舍由人决定）、方向（线程要窄、要排好顺序）。有工程师的反应比那张基准表更值钱——哪怕六个月前，你也说服不了我这事能成。

该说的保留：性能优化是这套打法最友好的领域，因为成功判据是一个没法争辩的数字。这正是它管用的原因，也正是它没法推广到所有事情上的原因。

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