先判断是计算错误还是粒度错误

当销售额突然翻倍，第一反应不应是怀疑 AI。更常见的原因是订单与订单明细、门店与商品等不同粒度表被直接连接，导致同一金额重复出现。

排查从三件事开始：每张表一行代表什么；连接键在两侧是否唯一；Join 前后行数和金额是否发生异常膨胀。把这三项写入模型文档，比事后解释图表更有效。

把关系从“能连”升级为“为什么能连”

外键相同不代表业务上可直接连接。需要声明一对一、一对多还是多对多关系，以及应该在哪个粒度聚合后再连接。对多对多关系，必须定义桥接表和去重规则。

语义模型还应说明时间关系：订单日期、发货日期和结算日期不能混为一个“日期”。用户问同比时，系统需要知道使用哪一个日期以及缺失日期如何处理。

一个指标最好有明确的计算定义、默认粒度、可用维度和禁止组合。这样 AI 在生成查询时，不只是找到字段，还能沿着已批准的聚合路径计算。

BuildTable 的建模方法可帮助团队整理字段、关系和业务语义；具体实现方式要结合现有数据平台验证，尤其是复杂 Join、历史拉链和跨时区场景。

选取十条可人工核对的订单或设备记录，分别验证明细、汇总、过滤和时间切换。再用一个已知的异常案例测试模型能否指出数据限制，而不是给出一个看似精确的数字。

将对账结果、测试 SQL、模型版本和已知限制一起保存。任何指标变更都重新运行这组测试，避免“修复一个问题又引入另一个问题”。

下载 BuildTable，或联系我们讨论企业数据建模场景。