你装好一台机器，跑个分看看这颗 CPU 体质如何。跑完一对比参考值，低了 12%——"这颗 CPU 是不是有问题？"但当你换一个版本的跑分软件再跑一次，结论完全反过来了：这次它不但不低，还偏高。同一个硬件、同一台机器，两个版本给出相反的判断。
现象
- 用某个版本的基准测试跑分，结果比预期偏低约 12%，看着"可疑"；
- 换另一个大版本的基准测试再跑，结果却偏高；
- 硬件、散热、电源计划都没变，只是软件版本不同；
- 你不确定该相信哪个，更不确定"这颗 CPU 到底正不正常"。
根因
根因是：跑分软件不同大版本的分数，基准不可比。
基准测试的分数不是物理量，它是"某项工作负载在本软件定义下花了多久"的一个相对度量。软件的测试负载、计分方式在不同大版本之间很可能被改过：
- 换了测试场景（负载变了，考察的硬件特性不同）；
- 换了计分基准（分数与耗时的换算关系变了）；
- 更新了指令集支持（老版本不认新指令，或者新版本才用得上新指令）；
- 甚至改了默认的测试时长和迭代次数。
结果就是：同一个硬件，在版本 A 下得 1000 分、在版本 B 下得 900 分，是很正常的——这不是硬件变了，是尺子变了。
这也正是"结论完全反过来"的原因：你拿版本 B 的分数去和版本 A 的参考区间比（或者反过来），等于拿两把不同的尺子量身高。12% 的差异完全落在"版本基准差异"的量级之内，它说明不了这颗 CPU 有任何问题。
解决
正确的做法分几步：
1. 先问"对方用的是哪个版本"。 无论你是在跟网友的对比、还是跟某个评测的参考值比，第一步都是确认基准版本号一致。版本对不上，后面的比较全部作废。
2. 取对应版本的参考区间。 同一个基准版本、同一档位的 CPU，会有大量样本构成一个分布。你要比的是"落在这个分布里没有",不是"跟某一个具体数字差多少"。低几个百分点在分布内是正常的。
3. 控制变量。 跑分对以下因素非常敏感，比较前要拉齐：
- 后台程序：杀软扫描、索引、更新服务都会吃掉分数；
- 内存通道：单通道 vs 双通道，差异可能比版本差还大；
- 电源计划：省电模式会主动降频，分数自然低；
- 散热与温度：撞到温度墙就降频，跑分时长越长影响越大。
4. 判断体质看别的指标。 想确认一颗 CPU 是否正常，跑分不是好证据。更靠谱的是看它在满载下的电压与频率：同样跑满，电压是否落在该型号的正常区间、能否稳定维持标称频率。这些是硬件层面的物理量，不像跑分那样受软件版本影响。
5. 重复测、取多轮。 单次跑分受随机因素影响，至少跑两三遍看分数稳不稳。分数如果每轮跳动很大，说明有别的变量在干扰（温度、后台负载），先把这些排掉再谈结论。
延伸与预防
这条坑的通用教训是：跨版本比较分数，等于拿两把不同的尺子量身高。
凡是"用某个可比较的数值来判断好坏/是否异常"的场景，都要先确认度量基准本身是否一致：
- 性能测试：软件大版本之间负载和计分方式会变；
- 覆盖率 / 静态检查：规则集升级后，"问题数"的增减可能只是规则变严了，不是代码变差了；
- 耗时统计：换了机器、换了依赖版本、换了数据规模，"快了/慢了"的结论都不成立；
- 任何评分体系：评分模型的改版会让历史分数失去可比性。
对应的通用习惯有三条：
- 永远把"基准版本/环境"和"数值"一起记录。 只留一个孤零零的分数，等于留了一个无法解读的数字。
- 比分布，不比单点。 找到一个合理的区间，而不是一个精确的参考值——单点比较几乎必然被噪声和版本差异淹没。
- 用物理量兜底。 当一个指标容易被工具/版本影响时，去找一个更接近本质的指标来交叉验证。跑分不稳，就看电压和频率；接口耗时不稳，就看请求数和错误率。有第二个独立证据，结论才站得住。