可数且自证相关的指标，让 Claude 能爬、ratchet 能锁，提速约 3x
测量本身就让问题变得可处理：只要有一个可以打败的数字，Claude 就能马上开始优化，所以杠杆最高的动作是找更多能测的东西。
过去测量是「第零步」：先加指标，等数据回流，然后才开始理解问题。现在 agent 能异步连跑数小时甚至通宵，写优化的边际成本被压得很低，约束就从「谁来改」转移到「有没有可以爬的数」。冲刺里大约三分之一的 PR 带着新遥测或新护栏，每个新仪器又引出新线程，形成自我增强的循环。
“With Claude, measuring something makes it tractable.” ¶23
前端性能天然有大量确定性计数可以爬。研究和内容创作类工作缺少这种数，文章没有讨论目标无法计数时这套方法还能不能用。
实验室代理指标必须是确定性的，而且要证明它和用户体感相关；证明不了就下架，不让 Claude 爬错山。
墙钟时间噪声大，毫秒级数据不能当 CI 闸门。纯 JS 热路径用 Valgrind 加 node --predictable 数指令，跑一次就行，不需要统计。浏览器路径没有指令计数，就用 React 提交次数、V8 精确覆盖调用数、样式重算次数、DOM 变更数这一串确定性计数。团队明确要求 Claude 证明压低计数能换来可测的墙钟收益：两条热路径的指令数分别降了 48% 和 31%，墙钟时间对应降了 78% 和 44%。这一步是防 Goodhart 效应（指标一旦成为优化目标就会失真）的关键。
“we threw it out rather than let Claude climb the wrong hill” ¶18
用 DevTools begin-frame control 做 120 Hz 确定性帧步进，号称能把「这一帧有没有超出 8.33 ms 预算」变成精确读数。
用只降不升的 ratchet 把收益锁住，防止快速迭代的代码库把优化慢慢侵蚀掉。
每个 benchmark 身兼两职：在实验室里是 Claude 可以推动的指标，在 CI 里是一道只能往下收紧的护栏。任何让指定路径指令数上升的 PR 都会让 CI 失败；每天有任务在计数下降后同步下调上限。改进确认生效后，Claude 把 benchmark 往下 ratchet；没有生效就关掉 flag 继续迭代。
“any PR that raised the instruction counts of those paths failed CI” ¶22
确定性指令计数加 ratchet，是全文最容易在个人项目里复现的机制。但 Valgrind 在 macOS 上的支持情况需要核实，这是推断。
安全护栏在冲刺开始前就布好，高速迭代才不出事。
每个 PR 都过自动评审，并且至少要一位人工批准；先写单元测试再做优化；可能造成用户可见问题的改动一律放在短期 feature flag 后面；高风险改动按员工、百分之一用户、全量的顺序发布。静态 composer 本来就很脆，Claude 为它建了几十条护栏：在 jsdom 里渲染真实 React 组件生成静态标记，防止两者漂移；在十四种视口下断言静态页和 React 渲染的对齐误差在 1 px 以内；用按键测试穿越交接点；现场上报每一次交接的偏移。flag 被分成 kill switch 和 ramp 两类，近两百个 flag 里过半在冲刺结束时已经清理。
“unit tests always came before optimizations” ¶41
「三千多个变更，零事故零回滚」的口径值得推敲。按原文的循环，效果不好时是「关 flag」而不是回滚，所以关 flag 的次数不计入回滚；「面向客户的事故」也没有定义。近两百个 flag 只清理了过半，剩下的就是技术债。
实验室和现有监控都有盲区，要靠自建的细粒度现场遥测和真人灰度来补。
侧栏行逐个弹出、肉眼可见地抖动，但每次 CLS 只有约 0.008，远在 0.1 的「良好」阈值以内，现有监控全部漏报。团队直接调用 Layout Instability API，把每次 layout-shift 映射到具名区域和阶段，结果发现 31% 的网页加载在页面可用之后仍有元素移动。修复用集成测试证明：main 上 20 次中 20 次红，PR 上 20 次中 20 次绿。另一个 Chrome 预渲染案例更典型：在组织托管的浏览器里，新标签页有一条 56 px 的页脚，headless 没有浏览器 UI，测试原理上就抓不到，最后是员工灰度阶段的真人录屏发现的。
“None of our existing monitors detected it.” ¶32
这一点暂无对应的审视。
这个循环很高产，但不是自主的：雄心、品味、方向这三件事仍然要靠人掌舵。
雄心：Claude 默认对范围保守，会把发现挂成 ticket、对可行性有所保留、估计留余量；达标之后线程会放慢，需要人反复强调「目标不是终点」。品味：每个线程都有具名的人类 owner，用户可感知的变化附上前后截图或录屏，由人来裁决。方向：线程刻意收窄，一个线程只盯一个 benchmark 或一条旅程；人负责排序、合并互相踩脚的线程、关闭收益递减的线程。例如一个 900 行的 PR 被一句话否决，理由是为每次发送省 2ms 不值得维护一个构建插件的复杂度。
“By default, Claude is careful about scope.” ¶57
文章回避了成本和人力：一百五十个并行线程的 token 花费、三千多个 PR 每个至少一位人工批准的审阅工时、被拒 PR 的比例、参与的工程师人数、Claude 毫秒级影响估计的事后准确度，都没有披露。
作者没有直接谈到这一点。
这是 Anthropic 给自家产品写的成功案例，用的是「大致相当于 Opus 5.5」的内部研究模型，加上还在 beta 的 Claude Tag。外部读者没法用同等配置复现团队层面的结果。
作者没有直接谈到这一点。
3x 是聚合口径，只给了 p75；四条旅程只公布了三组前后数据，十三项指标的全表和目标值都没给。「每天省下数万用户小时」是估计，作者也承认 p95 还有改进空间。
为何用确定性计数替代墙钟时间，以及计数如何先自证相关、再锁进 CI 只降不升
测量本身就让问题变得可处理：只要有一个可以打败的数字，Claude 就能马上开始优化，所以杠杆最高的动作是找更多能测的东西。
过去测量是「第零步」：先加指标，等数据回流，然后才开始理解问题。现在 agent 能异步连跑数小时甚至通宵，写优化的边际成本被压得很低，约束就从「谁来改」转移到「有没有可以爬的数」。冲刺里大约三分之一的 PR 带着新遥测或新护栏，每个新仪器又引出新线程，形成自我增强的循环。
With Claude, measuring something makes it tractable.
¶23 ↗
实验室代理指标必须是确定性的，而且要证明它和用户体感相关；证明不了就下架，不让 Claude 爬错山。
墙钟时间噪声大，毫秒级数据不能当 CI 闸门。纯 JS 热路径用 Valgrind 加 node --predictable 数指令，跑一次就行，不需要统计。浏览器路径没有指令计数，就用 React 提交次数、V8 精确覆盖调用数、样式重算次数、DOM 变更数这一串确定性计数。团队明确要求 Claude 证明压低计数能换来可测的墙钟收益：两条热路径的指令数分别降了 48% 和 31%，墙钟时间对应降了 78% 和 44%。这一步是防 Goodhart 效应（指标一旦成为优化目标就会失真）的关键。
we threw it out rather than let Claude climb the wrong hill
¶18 ↗
用只降不升的 ratchet 把收益锁住，防止快速迭代的代码库把优化慢慢侵蚀掉。
每个 benchmark 身兼两职：在实验室里是 Claude 可以推动的指标，在 CI 里是一道只能往下收紧的护栏。任何让指定路径指令数上升的 PR 都会让 CI 失败；每天有任务在计数下降后同步下调上限。改进确认生效后，Claude 把 benchmark 往下 ratchet；没有生效就关掉 flag 继续迭代。
any PR that raised the instruction counts of those paths failed CI
¶22 ↗
安全护栏在冲刺开始前就布好，高速迭代才不出事。
每个 PR 都过自动评审，并且至少要一位人工批准；先写单元测试再做优化；可能造成用户可见问题的改动一律放在短期 feature flag 后面；高风险改动按员工、百分之一用户、全量的顺序发布。静态 composer 本来就很脆，Claude 为它建了几十条护栏：在 jsdom 里渲染真实 React 组件生成静态标记，防止两者漂移；在十四种视口下断言静态页和 React 渲染的对齐误差在 1 px 以内；用按键测试穿越交接点；现场上报每一次交接的偏移。flag 被分成 kill switch 和 ramp 两类，近两百个 flag 里过半在冲刺结束时已经清理。
unit tests always came before optimizations
¶41 ↗
实验室和现有监控都有盲区，要靠自建的细粒度现场遥测和真人灰度来补。
侧栏行逐个弹出、肉眼可见地抖动，但每次 CLS 只有约 0.008，远在 0.1 的「良好」阈值以内，现有监控全部漏报。团队直接调用 Layout Instability API，把每次 layout-shift 映射到具名区域和阶段，结果发现 31% 的网页加载在页面可用之后仍有元素移动。修复用集成测试证明：main 上 20 次中 20 次红，PR 上 20 次中 20 次绿。另一个 Chrome 预渲染案例更典型：在组织托管的浏览器里，新标签页有一条 56 px 的页脚，headless 没有浏览器 UI，测试原理上就抓不到，最后是员工灰度阶段的真人录屏发现的。
None of our existing monitors detected it.
¶32 ↗
这个循环很高产，但不是自主的：雄心、品味、方向这三件事仍然要靠人掌舵。
雄心：Claude 默认对范围保守，会把发现挂成 ticket、对可行性有所保留、估计留余量；达标之后线程会放慢，需要人反复强调「目标不是终点」。品味：每个线程都有具名的人类 owner，用户可感知的变化附上前后截图或录屏，由人来裁决。方向：线程刻意收窄，一个线程只盯一个 benchmark 或一条旅程；人负责排序、合并互相踩脚的线程、关闭收益递减的线程。例如一个 900 行的 PR 被一句话否决，理由是为每次发送省 2ms 不值得维护一个构建插件的复杂度。
By default, Claude is careful about scope.
¶57 ↗
这是 Anthropic 给自家产品写的成功案例，用的是「大致相当于 Opus 5.5」的内部研究模型，加上还在 beta 的 Claude Tag。外部读者没法用同等配置复现团队层面的结果。
3x 是聚合口径，只给了 p75；四条旅程只公布了三组前后数据，十三项指标的全表和目标值都没给。「每天省下数万用户小时」是估计，作者也承认 p95 还有改进空间。
「三千多个变更，零事故零回滚」的口径值得推敲。按原文的循环，效果不好时是「关 flag」而不是回滚，所以关 flag 的次数不计入回滚；「面向客户的事故」也没有定义。近两百个 flag 只清理了过半，剩下的就是技术债。
确定性指令计数加 ratchet，是全文最容易在个人项目里复现的机制。但 Valgrind 在 macOS 上的支持情况需要核实，这是推断。
用 DevTools begin-frame control 做 120 Hz 确定性帧步进，号称能把「这一帧有没有超出 8.33 ms 预算」变成精确读数。
文章回避了成本和人力：一百五十个并行线程的 token 花费、三千多个 PR 每个至少一位人工批准的审阅工时、被拒 PR 的比例、参与的工程师人数、Claude 毫秒级影响估计的事后准确度，都没有披露。
前端性能天然有大量确定性计数可以爬。研究和内容创作类工作缺少这种数，文章没有讨论目标无法计数时这套方法还能不能用。