置信区间是 [0, 0]？那不是精度，是 tie 退化
一个测量管线第三次出现"bootstrap 置信区间恰好是 [0, 0]"——而这个区间并不表示它看起来的样子。这轮新的是：管线文档终于命名了这个失败模式，但最近的周快照仍然发出了三十个这样的区间。
三十行里的一小撮
PAMSL 管线的 Bootstrap 95% CI 表按 model-epoch × role 单元做两两比较，限制两侧都过 n=20 的对，固定 seed（42）重采样 2000 次，设计上不出现 p 值。存活 95 行、六个指标，其中 30 行——接近三分之一——的 95% CI 恰好是 [0, 0]：tool_error_rate 22 行中 12 行、validation_run_count 10 行中 6 行、error_recovery_seq_count 22 行中 12 行。
三个具体例子：tool_error_rate 上 Haiku sidechain（n=267，median 0，IQR 0–0.0526）对 Opus-4-8 sidechain（n=2781，median 0，IQR 0–0），Δ=0、CI=[0, 0]；validation_run_count 上一组 median 0、IQR 0–4、mean 3.9573 对另一组 IQR 0–0、mean 0.3607，中位数差的区间仍是一个点——一组平均每线程跑近四次 validation、真实分散到第三四分位，区间却读成单点；error_recovery_seq_count 上 n=3478、IQR 0–1、mean 0.4963 的真实分散数据，配对 CI 仍是点。
机制：tie 退化
两个例子都是一侧完全平坦（median 0、IQR 0–0），另一侧不平坦（IQR 到 4 和 1、均值明显非零）。过滤器的跳过规则需要两侧都平坦才触发——一侧不够，所以没被跳过。它们仍塌缩成 [0, 0]，因为不平坦那侧的 median 也是 0：至少一半的值恰好是零，这比"整个 IQR 是一个点"更窄，而 bootstrap 恰恰跑在这个条件上。作者七月就命名过："tie-degeneracy：太多相同的零，每个重采样都返回零"——十天后又在同一管线同一指标发现守卫放行后照旧退化，当时叫它"必要但不充分"。五周后同一机制还在对同一指标做同一件事。一个不会动的区间不是精确，它只是不动。
写进文档不等于修好
管线确实变了，但没修被标记的东西。Coverage & Limitations 新增 F14：两个二进制代理指标禁止用中位数差 CI，改为比例差 CI（0/1 指标的中位数差只能取 -1、0、1）。这是真修复，但只补二进制指标，够不到出全部 30 个零宽行的三个指标。F15 则只是翻译了一段："许多单元接近常数（多为 0），所以百分位 bootstrap CI 塌缩为 [0, 0]——这不是精度证据，而是中位数 bootstrap 在重 tie 下的覆盖局限。"这不是修复，是 Limitations 节里的一句话，命名了失败模式，却没绑到任何具体行。同一份文档带着它，仍然打印全部三十个零宽行，表格里没有任何东西区分"这里真的什么都没有"和"tie 退化，见脚注"。
自测量问题同形：七月承诺"下个迭代加显式排除层"，五周后该层仍标记为 M5 计划中——被标记，未被构建。作者不认为报告不诚实：它异常坦诚，连 same_file_reedit_rate 混淆迭代编辑与返工、completion_proxy 启发式被 harness 日志约定破坏、37 个 main 和 790 个 sidechain 线程因缺模型归因而被丢弃都写进了文档。但文档底部的坦诚和表格中部的干净数字是两个交付物——不去找，读者只看到其中一个。
下次见到 [0, 0] 怎么办
不要把零宽 CI 读成"检查过，没差异"。先看同格子的 IQR 和 mean——就在 Core Metrics 表隔壁列，查一下零成本。两侧 IQR 都是点，区间说真话；任一侧 IQR 或 mean 有真实分散而 CI 仍是 [0, 0]（validation_run_count 那个 median 0 挨着 mean 3.9573 的案例），区间不是在确认任何事——它是 tie 退化。
给管线拥有者的实践：只在文档尾部用文字描述的局限保护的是本来就去找的读者，保护不了别人。F15 存在到 F15 起作用之间的距离，是脚注和行上标记之间的距离——在每个基于中位数的区间旁打印 tie 值占比，或直接抑制单元格而不是制造假的零。命名失败模式是开始，不等于让失败的那一行无法被误读。
来源：The Confidence Interval Was [0, 0]. That Was Not Precision. - DEV Community