chimera-give-the-denominator

你正准备把一个比率、一个百分比或一个计数放进报告、提交信息、基准测试表格，或者一条发给会据此行动的人的消息里。"34% 的运行失败了。""错误增加到 3 倍。""覆盖率下降了。"

这条不适用于读者本来就能自行拆解的数字：一次测出来的延迟、一个版本号、一份他们看得见的 diff 里的文件数。这里的风险专指聚合量——一个由你挑的一个集合除以你挑的另一个集合算出来的量，而这两次挑选在句子里都看不见。

1. 永远把原始计数写在比率旁边：34%（17/50 次运行）。如果你说不出分母，那你还不知道自己测的是什么。
2. 说清是哪个分母。发起的运行和完成的运行是不同的集合，除以完成数会悄悄删掉崩溃的那些——而那恰好是让你去看这个数字的那一批。
3. 发布之前，先按原因拆分分子。这 17 次失败里，有多少是已经开着的 issue、多少是已知的提供方超时抖动、多少是只在这台机器上失败的 fixture？把拆分结果报出来：17 次失败——其中 14 次是已知的连接超时，3 次原因不明。
4. 在一个没有改动的基线上跑同一次测量，然后相减。真正有意义的数字，是在 main 上活不下来的那部分。
5. 当 n 小到再多一个样本就能把头条数字挪动好几个百分点时，把这句话写进报告里，替代那个百分比。

把这条用在所有地方，会把可读的行文变成一片括号沼泽，读者会开始跳过括号——这比原来的问题更糟，因为现在分母就在页面上，却没人读。把完整拆解留给那些真的会有人据以行动的数字。

更尖锐的风险在另一个方向：按原因拆分同样是把真问题说小的工具。把十四次失败标成"已知噪声"，只有在这个标签是在你看到它往哪边有利之前就贴上的，才算诚实。如果你发现自己是在写总结的时候才把"已知"这个桶越撑越大，那这个数字就是结论，不是证据。

写出分母也救不了一个糟糕的分母。2/3（n=3）依然只是三次运行；分母让这个弱点变得可见，而不是修好它。