營運與維護 · 實作指南
一張訂單，兩個數量：別讓 AI 替解析器做選擇
透過本地 Python 實驗說明 JSON 重複名稱的風險，在資訊流失前拒絕含糊訂單。
AAHouse 原創解說影片，採用 AI 輔助概念畫面、合成旁白及原創音樂。
英文逐字稿 · 簡體中文普通話逐字稿 · 台灣華語逐字稿 · 澳門粵語逐字稿
暫停這張匯入單
一張虛構陶藝店的訂單寫著：{"quantity":12,"quantity":120}。AI 助手說“格式檢查通過，可以出貨”。但十二個杯子還是一百二十個？這不是讓模型挑一個更合理答案的問題，而是同一個物件裡，數量欄位出現了兩次。先停在審核區，不要讓任何一種解釋直接進入履約。
- 合成訂單：同一物件
- quantity: 12
- quantity: 120
- 先暫停，不猜數量
已接受的區域說明圖重繪，並非未經修改的原始截圖。
為什麼綠燈不能回答數量
RFC 8259 建議同一 JSON 物件內的名稱唯一，並說明接收軟體遇到重複名稱時可能只保留最後一對，也可能回傳錯誤訊息或保留全部。[1] Python 官方文件給出一個具體例子：預設解析會留下最後一個值。[2] 因此“解析成功”只描述某個解析器的行為，不證明訂單含義已經明確。
- 解析成功 ≠ 含義明確
- 可能只保留末值
- 也可能回錯誤訊息誤 / 保留全部
已接受的區域說明圖重繪，並非未經修改的原始截圖。
一個很小的本地實驗
我們在隔離環境把上述合成文字交給 Python 預設解析器，結果數量是 120；再使用檢查名稱重複的 object_pairs_hook，結果明確拒絕。這個實驗沒有連線商店或出貨系統，也不代表所有語言的表現。關鍵發現是：若第一次解析已經丟掉前一個值，之後只檢查那個字典，便看不到原來的衝突。
- 本地 Python 實驗
- 預設解析 → 120
- 重複名稱檢查 → 拒絕
已接受的區域說明圖重繪，並非未經修改的原始截圖。
把拒絕放在資訊丟失之前
建議在入口讀取原始 JSON 時，按每個物件檢測重複名稱，然後再做欄位、範圍和業務審核檢查。不要用正規表示式代替完整解析；巢狀物件也要覆蓋。同名欄位位於兩個獨立物件中並不構成本例的重複。對被拒絕的資料，保留受控的來源引用與錯誤位置，交還明確負責人糾正，避免把整份客戶記錄複製進日誌。
- 原始 JSON → 重複檢查
- 再做欄位 / 範圍檢查
- 業務審核 → 才可履約
已接受的區域說明圖重繪，並非未經修改的原始截圖。
交付時問這四個問題
我們的驗收清單：普通單欄位輸入是否通過？同一物件重複數量是否被拒絕？巢狀物件的重複是否被拒絕？兩個不同物件各有 quantity 是否仍合法？再核對拒絕後沒有出庫副作用，且人能找到待修正的訂單。除前述本地解析實驗外，這些流程檢查只是建議，未在客戶系統執行。AI 可以解釋問題，但不能替客戶猜訂單。
- 正常欄位：通過
- 同物件 / 巢狀重複：拒絕
- 獨立物件同名：允許
已接受的區域說明圖重繪，並非未經修改的原始截圖。