一張虛構陶藝店的訂單寫著：{"quantity":12,"quantity":120}。AI 助手說“格式檢查通過，可以出貨”。但十二個杯子還是一百二十個？這不是讓模型挑一個更合理答案的問題，而是同一個物件裡，數量欄位出現了兩次。先停在審核區，不要讓任何一種解釋直接進入履約。

RFC 8259 建議同一 JSON 物件內的名稱唯一，並說明接收軟體遇到重複名稱時可能只保留最後一對，也可能回傳錯誤訊息或保留全部。 Python 官方文件給出一個具體例子：預設解析會留下最後一個值。 因此“解析成功”只描述某個解析器的行為，不證明訂單含義已經明確。

我們在隔離環境把上述合成文字交給 Python 預設解析器，結果數量是 120；再使用檢查名稱重複的 object_pairs_hook，結果明確拒絕。這個實驗沒有連線商店或出貨系統，也不代表所有語言的表現。關鍵發現是：若第一次解析已經丟掉前一個值，之後只檢查那個字典，便看不到原來的衝突。

建議在入口讀取原始 JSON 時，按每個物件檢測重複名稱，然後再做欄位、範圍和業務審核檢查。不要用正規表示式代替完整解析；巢狀物件也要覆蓋。同名欄位位於兩個獨立物件中並不構成本例的重複。對被拒絕的資料，保留受控的來源引用與錯誤位置，交還明確負責人糾正，避免把整份客戶記錄複製進日誌。

我們的驗收清單：普通單欄位輸入是否通過？同一物件重複數量是否被拒絕？巢狀物件的重複是否被拒絕？兩個不同物件各有 quantity 是否仍合法？再核對拒絕後沒有出庫副作用，且人能找到待修正的訂單。除前述本地解析實驗外，這些流程檢查只是建議，未在客戶系統執行。AI 可以解釋問題，但不能替客戶猜訂單。