畀 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 幫手解釋差異同產生測試，但係統計計算方式要由業務負責人確認。報表上線之前，保存查詢版本、輸入範圍同驗收結果；一張計得啱嘅小表，比一段聽落合理嘅銷售分析更有說服力。