数字对不上：三次数据对账复盘

定位：数据系统的信任，是被几次「数字对不上」救回来的

这套平台是给人看数、拿数做决策的。功能错误用户会报障，数字错误用户不会报——他只是默默不再相信这张表。所以这个项目里最宝贵的反馈，全部来自用户拿着真实业务数据来对账：「这个数应该是 36,479，你算出 36,749」「这个料号明明有数据，为什么查不到」「还是 259 条，不对」。这篇把三次典型对账复盘成方法。

案例一：「实时物料数」之争——先定口径，再谈对错

指标卡上的实时物料数，先后出现过两个版本：先做的是按业务规则去重的口径，用户验收时说和手工账对不上；换成全表行数 COUNT(*) 之后，又花了三轮才让所有相关数字（明细行、去重数、其他行兜底）在新口径下互相咬合——最后用测试夹具断言「各分项之和等于总数」，才算封版。

教训：对账前先问「这个数的口径是什么」，口径之争没有对错，只有选择。而口径一旦选定，必须用一个机器可验证的恒等式（分项和 = 总数）钉死，否则每次改代码都会悄悄漂移。

案例二：「筛选之后数字暴增」——判定和筛选必须分离

一个专用分析场景，用户选了某个筛选条件后，某个统计数字不降反升。查下来是 SQL 写法问题：用户的筛选条件被混进了「专用判定」——本该在全量数据上做的有效性判定，被先用筛选条件过滤了一遍。筛选面越窄，判定通过的占比反而越高，数字自然暴增。

修复后的铁律写进了代码注释：用户的筛选只过滤展示计数，一切判定（去重、有效性、状态归类）永远在全量数据上做。这条后来成为所有聚合 SQL 的评审标准。

案例三：「20155343 查不到」——用真数据走查，别信抽样

半成品查询上线后，用户拿了一批真实料号来验，其中一个按业务知识应该能查到对应印制板，系统却查不到。抽样测试全绿、真实数据漏网——根因在匹配路径的覆盖盲区（单一路径匹配漏掉了间接关联）。修复方向是双路径匹配 + 用用户提供的整批真实料号做回归集。

从此这个项目的测试数据有一条新规矩：功能验收必须带一批用户真实数据走查，样例数据只能证明代码没写错，证明不了业务没漏。

一条制度性防线：数字会撒谎，门槛不会

对账解决「算法错」，还有一类问题是「数据本身坏」：上游同步故障时源表从 218 万行缩到几万行，照常重建物化表就是把坏数据原样端给用户。后来给重建任务加了行数门槛——源数据低于基线直接拒绝重建、保留旧表、告警等人。宁可给旧数据，不给错数据，这条守卫此后再没让坏数据上线过。

价值与可复用方法

三次对账沉淀成四条可复用规则：口径先行并用恒等式钉死；判定与筛选分离；验收必带用户真实数据走查；数据任务全部带行数门槛。方法都不新鲜，新鲜的是执行密度——数据产品的信任就是这样一条一条「对上了」攒出来的。