給 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 幫忙解釋差異與產生測試，但由業務負責人確認統計計算方式。報表上線前儲存查詢版本、輸入範圍和驗收結果；一張算得對的小表，比一段聽起來合理的銷售分析更有說服力。