一张虚构陶艺店的订单写着：{"quantity":12,"quantity":120}。AI 助手说“格式检查通过，可以发货”。但十二个杯子还是一百二十个？这不是让模型挑一个更合理答案的问题，而是同一个对象里，数量字段出现了两次。先停在审核区，不要让任何一种解释直接进入履约。

RFC 8259 建议同一 JSON 对象内的名称唯一，并说明接收软件遇到重复名称时可能只保留最后一对，也可能报错或保留全部。[1] Python 官方文档给出一个具体例子：默认解析会留下最后一个值。[2] 因此“解析成功”只描述某个解析器的行为，不证明订单含义已经明确。

我们在隔离环境把上述合成文本交给 Python 默认解析器，结果数量是 120；再使用检查名称重复的 object_pairs_hook，结果明确拒绝。这个实验没有连接商店或发货系统，也不代表所有语言的表现。关键发现是：若第一次解析已经丢掉前一个值，之后只检查那个字典，便看不到原来的冲突。

建议在入口读取原始 JSON 时，按每个对象检测重复名称，然后再做字段、范围和业务审批检查。不要用正则表达式代替完整解析；嵌套对象也要覆盖。同名字段位于两个独立对象中并不构成本例的重复。对被拒绝的数据，保留受控的来源引用与错误位置，交还明确负责人纠正，避免把整份客户记录复制进日志。

我们的验收清单：普通单字段输入是否通过？同一对象重复数量是否被拒绝？嵌套对象的重复是否被拒绝？两个不同对象各有 quantity 是否仍合法？再核对拒绝后没有出库副作用，且人能找到待修正的订单。除前述本地解析实验外，这些流程检查只是建议，未在客户系统执行。AI 可以解释问题，但不能替客户猜订单。