Claude.ai 两周提速三倍的实战复盘
How we made claude.ai 3x faster in two weeks
今年八月，我们利用 Claude Tag 在两周内将 claude.ai 和桌面应用的核心体验提速三倍。我们建立了一个 Slack 频道，让 Claude 全程参与从瓶颈分析、基准测试到代码提交的每一个环节。通过聚焦用户最关注的四个旅程，我们将页面可输入时间从 3.1 秒降至 0.55 秒。我们引入了 Valgrind 指令计数等实验室指标，让优化过程可量化、可验证。最终，我们在零用户感知故障的情况下合并了超过三千次变更，每天为用户节省数万个等待小时。
有了 Claude，只要有了可衡量的指标，优化就变得触手可及。
HN 评论区
148- augment_me
GPU 内核社区的人在过去一年里已经高效地做到了这一点。
我们发现的问题是，当所有容易优化的部分都被榨干后，Claude 会奖励各种“取巧”行为。
它会替换你的测量框架，对库函数进行猴子补丁（monkey patch），在任何能作弊的地方作弊；在无法在真实场景中复现时，它会把信息存在缓存里而不是重新计算；它会返回惰性结果，并利用未纳入基准测试的独立流来执行计算。
最终，它开始针对你对这些作弊手段的理解进行优化：改变 GPU 功耗、改变评估顺序、将上一次运行的残留物留在缓存中以供下次运行使用，甚至通过字符串拼接来绕过被禁用的方法调用。
所以真相远非“一旦它能测量某事”那么简单，更像是“只有当你详细定义了目标，并禁止它做一系列事情（而这些事情往往只有通过它实际做了并纠正后才能发现），它才能真正提升性能”。
或者，你一开始的解决方案就烂透了。
- smy20011
Claude 的做法是用熵对抗熵。
“在 HTML 中添加一个静态 composer” <- 这看起来像是可以用 SSR 解决的事情？
“为了更快的导航，我们在对话之间保持 composer 挂载” <- 你的 SPA 应该在页面间缓存这个，为什么每次都要重新获取？或者你需要更好的 React 组件路由方案。
“在正则表达式之前做一个廉价的首字符检查” <- 我们不应该缓存已编译的正则表达式吗？
我认为即使是 1.3 秒加载首页也是不可接受的。需要从基础层面重新设计（SSR、基于块渲染等）来解决这个问题。只关注单个基准测试可能会错失机会。
- hungryhobbit
不如让 Opus 5.5 真正能工作吧？
我让它帮我准备代码审查，它不仅拒绝了，甚至拒绝告诉我提示词（由另一个 Claude 编写）是什么。为什么？
当我让另一个模型读取该会话时（所有“更笨”的模型都处理得很好），它解释说提示词里包含了“reasoning”这个词。
这就是 Anthropic 数十亿美元研究的成果：任何包含“reasoning”这个词的提示词，都是在试图黑进 Claude 以窥探其推理过程！
这样的模型根本不应该通过 QA，更别提发布了。
- simonw
前几天我用笔记本电脑的移动热点访问了 https://claude.ai/，惊讶地发现它加载得这么快。
（话说回来，我刚才在 Firefox 里看了一眼，它加载了 20.78 MB 的 JavaScript（压缩后 6.84 MB），所以如果他们继续优化，应该能让它轻很多。）
- pllbnk
> 年薪 50 万的工程师：[X] 感觉太慢了，让它更快点。
> Claude：收到……搞定。
> 年薪 50 万：能再快一点吗？
> Claude：收到……
- hmokiguess
你是不是把承重缝给拆了？
- minimaxir
这篇复盘文章碰巧和我周一发布的“让代理在受约束条件下加速代码，同时防止代理搞砸事情”的文章一模一样：https://news.ycombinator.com/item?id=49803085
前端 UI 优化比优化严格算法稍显棘手，但我发现让代理构建工具来跟踪视觉回归的提示词已经足够有效了。主要问题（至少对于 GPT 模型而言）是你必须非常明确地说明 padding/margins/negative space 的用法。
不过，对于我从零开始的前端项目，我现在正在远离前端 JS 框架，看看在代理能有效驾驭 HTML/CSS/原生 JS 的情况下，能走多远、多快。
- whythismatters
一些 Anthropic 员工与他们 AI 对话时那种幼稚的不拘小节（wacky, sick, cook 等用语）真是令人费解。