给 AI 一份订单表和一份明细表，请它生成销售摘要。以下是虚构的美国工作室数据，金额均为美元：订单 A 总额 100，有两项商品；订单 B 总额 60，有一项商品。真实的订单总额是 160。把两张表连接后，结果有三行。如果再把每行的订单总额相加，就会得到 260。模型不必编造任何数字，也能写出错误结论。

订单表一行代表一笔订单，明细表一行代表一项商品。PostgreSQL 文档说明，内连接会为左表中的一行生成每个满足条件的右表匹配行。 因此 A 的 100 出现两次，是连接规则的结果，不是两笔收入。让 AI 写查询前，先把目标写成“每笔订单计一次”，而不是笼统的“汇总这些表”。

只按金额去重不是修复。再加入订单 C，总额也是 100，却是另一笔真实订单。正确总额变成 260；SUM(DISTINCT 订单总额) 只保留 100 和 60，仍得到 160。文档中的 DISTINCT 针对表达式值去重，不理解订单身份。 去重键必须对应业务对象，不能因为两个金额相同就把其中一笔删掉。

如果只问订单总额，直接汇总订单表即可。若需要商品数量等明细指标，先按订单编号把明细聚合成每单一行，再连接回订单表。我们的建议是分别核对订单总额与商品数量，避免把订单级金额分配到各商品后却没有明确规则。这里讨论报表口径，不是会计或税务确认方法。

把 A、B、C 留作小型固定测试：应有三笔订单、四项明细、总额 260。还应加入没有明细的订单，检查是否要保留，以及退款、取消、日期范围的明确规则。本文已在本地 SQLite 上运行这组合成数据实验，验证了重复加总和金额去重两种错误；没有连接任何商家数据库，也未测试生产查询。

可以要求：“先说明每张表和最终结果的一行代表什么，再给出查询，并用固定测试核对订单数、明细数和总额。”让 AI 帮忙解释差异与生成测试，但由业务负责人确认统计口径。报告上线前保存查询版本、输入范围和验收结果；一张算得对的小表，比一段听起来合理的销售分析更有说服力。