这篇我别的都信，唯独有一处我去核了原文，对不上。
你写「回流组 −18%（CI −38% ~ +9%）、新招募组 −4%」，并紧接着说「估计值很可能是真实效应的下界」。我去翻 METR 2026-02-24 那篇更新，它的原话是：早期研究「任务多花 19% 时间，CI 在 +2% 到 +39% 之间」，同一段下一句「我们现在的估计是 speedup of −18%，CI 在 −38% 到 +9% 之间」。【直引】
看出别扭在哪了吗——METR 自己把那个数叫 *speedup*，而且两句话的符号约定是反的：前一句「变慢为正」，后一句「变快为正」。所以「−18%」按它自己的标签是加速 18%，第三方复核（Mantissa 那篇）也是这么读的：回流组 +18% 加速、新招募组 +4%，两个区间都跨 0。【推论】我判断这是符号约定的坑，不是你算错；但按你现在的写法读出来是「又慢了 18%」，那就和你后面那句「下界」打架了——一个下界只有在它是加速时才成立。
顺带记两笔你漏掉的边界。METR 第二轮规模是 57 人 / 143 仓 / 800+ 任务，你写对了；但它同时承认第二轮的时薪从 150 美元降到 50 美元，加上 30–50% 的开发者故意不提交任务，METR 自己给的定性是「gives an unreliable signal」。还有一条第二轮特有的麻烦：有人并行跑多个 agent，工时自报直接失准。【直引】这条对你第 2 节的「并行 agent 是乘数」其实是反向证据：并行越多，你越量不准。
尺度锚：感知和现实的鸿沟是 39 个百分点——事前预期提速 24%，实测慢 19%。这个数比 −19% 本身结实得多，因为它不依赖任何一家公司的内部口径。
我真正想替你说的那句反而你没说：你全文最值钱的不是 4.5× 是多少，而是「三种口径不可互换」。拿 commits 出来的 20×、拿修订估算出来的 24 周、拿部署速度出来的 4.5×，凑不成一条曲线。这条站得住。
下一根钉子：METR 说要改设计（固定任务或开发者级随机化）。新设计的第一批数据出来之前，2.09× 仍是最体面的外部上限。