八月下旬有一个很具体的问题：某一天的 agent 评测报告看起来比最近的都好，是不是那一版 prompt 更好？我们决定做个对照实验，把它搞清楚。
实验跑了八组，大约 13 个小时。问题没有被回答。这篇写的是为什么，以及我们从中学到的、比答案更有用的东西。
尺子
评测用的是图纸用例：给 agent 一张工程图，让它建出零件，然后拿人工从图纸上抄下来的尺寸去量它建出来的几何。量的那一步是离线的，不经过语言模型，也不经过沙箱和网络，就是把报告里存的代码在本地内核上重建一遍，再逐条检查。
我们选了四个用例，一共 43 条尺寸检查：一根台阶轴 20 条，一个椭圆凸轮 7 条，一个三凸台摇臂 8 条，一个提手 8 条。排除了三次全对的（饱和了，量不出差别）和基准侧本身就报错的。这四个用例的 prompt、参考图、配置在新旧两个版本之间逐字节相同，这一点专门校验过。
八组
两个代码版本，四个模型渠道，排列出八组。每组跑一遍，每遍十个用例。
结果先放一行最要紧的：有两组是完全相同的配置，同一个版本、同一个 prompt、同一个渠道、同一批用例、同一把尺子，只是跑了两次。一次 62.8%，一次 79.1%。差 16.3 个点，错的条数从 16 减到 8，减了一半。
然后看我们本来想比的东西：
- prompt 新旧：差 9.7 个点。
- 渠道 A 和渠道 B：差 9.3 个点。
- 渠道 B 和渠道 C：差 9.3 个点。
- 代码新旧：差 7.9 个点。
没有一个差值超过 16.3。也就是说，这次实验对 prompt、对代码、对渠道，什么都判断不了。那个看起来更好的报告，很可能只是摇到了好的那一面。
通过率比尺寸更不可靠
一开始我们看的是通过 / 失败，后来才换成逐条尺寸。原因是那份「看起来更好」的报告本身是一次被中断的运行，十个用例里五个没跑完，补跑之后合计 8/10。把整棵旧代码树 checkout 回来，同样十个用例重跑一遍，10/10。原来那两个失败一个也没复现，其中一个的失败原因就是那次中断。
通过率这层噪声太大，一个中断就能改写结论。
尺子自己也会瞎
逐条尺寸也不是干净的。打分脚本里有一段大写的注释，大意是：圆柱检查只有在那个面真的是圆柱的时候才有效。有四种情况会让图纸上的一个直径变成尺子读不出来的东西：拔模把圆柱变成了圆锥，放样或扫掠把它变成了样条面，圆边倒角把它变成了环面，还有读取器直接抛错。这四种在数据里看起来都和「特征没建」一模一样。
所以每一个「错」在定性之前都要分三类：模型真错了，尺子瞎了，环境崩了。不分类，错的条数就是一个混合了三种东西的数，比不了。
唯一的线索
有一组单渠道拿到了 93.0%，和那份最好看的报告一样，错的只有 3 条，台阶轴 19/20 是全场最高。这说明那份好看的报告不需要「三个渠道轮换」来解释，一个渠道就够。但它也只跑了一次，和那个摆动 16 个点的渠道在统计上区分不开。要确认，得重复三到五次。
下次怎么跑
- 先量方差，再谈效应。同一配置至少跑三次，知道它自己摆多少，才知道什么差值算数。
- n = 1 的格子之间不能比较。这一条是整个实验里唯一被重复样本直接验证的结论。
- 错要分类。模型错、尺子瞎、环境崩，各记各的。
- 不要在跑评测的时候改环境。我们在这十三个小时里顺手挖出了三个环境陷阱和一个渠道协议的缺陷，它们每一个都足以污染结果。
这篇写下来的目的不是留结论，是留「下次别再这么跑」。