看一套测量方案时，有个地方我一开始没想通：明明要测的是中间那个探头下面的零件，旁边还装了两个探头，它们压根不碰零件，一个贴左边工装，一个贴右边。
后来才明白那两个探头是给中间那个当尺子用的。一圈采样里混着四种东西：零件真弯曲的正弦、主轴顶尖本身的偏心跳动、工件没夹正的倾斜、还有采集噪声。后面三种，和弯了长得一模一样。更坑的是，偏心和倾斜不是随机噪声，它们是低频的、空间相关的，所有探头同一时刻读到的偏移高度一致。你取平均，只会把信号按个比例缩小，那把弯的尺子还是弯的。
那两个不碰零件的探头，量的是工装和顶尖自己的状态。用它们连成一条基线，中间探头该读到多少直的值就出来了。实测减去这条基线，剩下的才是零件真弯了多少。
double k = (s - sLeft) / (sRight - sLeft);
double baseline = refLeft + k * (refRight - refLeft);
double trueValue = measured - baseline;
k 是按物理坐标算的，不是随手写的 0.5。还要防除零，如果左右参考探头重合，分母为零，代码直接给一个哨兵值 -10，让上层知道这次基准不可信，而不是算出一个 NaN 或无穷污染后续。
这件事改了我一个习惯。想看清楚一个对象，先别急着多测它，先想清楚它周围的基准是什么，有没有被它带着跑。基准和对象混在一起的时候，多测几遍取平均没用，平均假设误差是随机的、会互相抵消，可系统误差偏不随机。得把基准单独量出来，再扣掉。
我后来把这套用到别的地方。读一份报表，先看清它的口径和基准是什么，而不是急着看数字本身；接手一个老模块，先找它的参考探头，那些定义清楚、不被业务带着跑的契约，而不是一头扎进业务逻辑。基准清不清，往往决定了你能不能看清对象。