营运与维护 · 实作指南
一张订单，两个数量：别让 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，结果明确拒绝。这个实验没有连接商店或发货系统，也不代表所有语言的表现。关键发现是：若第一次解析已经丢掉前一个值，之后只检查那个字典，便看不到原来的冲突。
- 默认解析 → 120
- 重复名称检查 → 拒绝
未经修改的原始来源说明图。
把拒绝放在信息丢失之前
建议在入口读取原始 JSON 时，按每个对象检测重复名称，然后再做字段、范围和业务审批检查。不要用正则表达式代替完整解析；嵌套对象也要覆盖。同名字段位于两个独立对象中并不构成本例的重复。对被拒绝的数据，保留受控的来源引用与错误位置，交还明确负责人纠正，避免把整份客户记录复制进日志。
- 再做字段 / 范围检查
- 业务审批 → 才可履约
未经修改的原始来源说明图。
交付时问这四个问题
我们的验收清单：普通单字段输入是否通过？同一对象重复数量是否被拒绝？嵌套对象的重复是否被拒绝？两个不同对象各有 quantity 是否仍合法？再核对拒绝后没有出库副作用，且人能找到待修正的订单。除前述本地解析实验外，这些流程检查只是建议，未在客户系统执行。AI 可以解释问题，但不能替客户猜订单。
- 同对象 / 嵌套重复：拒绝
- 独立对象同名：允许
未经修改的原始来源说明图。