營運與維護 · 實作指南
一張訂單，兩個數量：別讓 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 可以解釋問題，但不能替客户猜訂單。
- 正常欄位：通過
- 同對象 / 嵌套重複：拒絕
- 獨立對象同名：允許
已接受的區域說明圖重繪，並非未經修改的原始截圖。