ARTICLE · 1124167
AI 能生成 JSON,为什么系统还是接不住?
AI 能生成 JSON,为什么系统还是接不住?客户发来一句话：“蓝色那款来两箱，还是上次的地址，周五前要。” 你让 AI 提取成订单信息。它很配合：商品、数量、地址、时间，四个字段排列整齐。接口能解析，页面能显示，演示到这里，气氛通常很好。 但系统真要创建订单，问题就来了。蓝色那款是哪一个商品？一箱有多少件？“上次”是哪次？周五前是发货，还是送达？ 这些问题，JSON 的大括号一个也没回答。 把 AI 的输出接进业务系统，需要同时约定字段的形状、字段的含义，以及什么条件下可以继续执行。 只写一句“请严格输出 JSON”，往往只完成了最容易看见的那部分。1. 结构化输出解决了什么 普通文本回答很适合人读，程序却希望每次拿到相同的字段。今天写“数量：两箱”，明天写“需要两箱货”，意思差不多，解析方式得换一套。 结构化输出通过预先给定的字段规则，让回答按指定形状返回。JSON Schema 可以描述对象、类型、必填项和枚举。例如，数量应该是整数，处理状态只能从几个约定值中选择。这样，程序就不用从一段礼貌又热情的回答里捞数字。 Google 的结构化输出文档明确提醒：应用仍要验证字段值，处理格式符合规则但含义错误的结果；同时，它支持的是 JSON Schema 的一部分，复杂规则存在限制。 这意味着，选工具时要看它支持哪些约束；设计业务时，还要自己回答“这个值凭什么可以用”。 “蓝色那款”即使被放进一个字符串字段，仍然没有变成库存系统里的商品编号。数字 2 即使类型完全正确，也没有告诉系统是两件还是两箱。 格式约束减少了接口对接中的一类麻烦。接下来要处理的，是信息本身。2. 先把“数量 2”拆开 回到这条客户留言。假设系统直接保存 quantity: 2，仓库按件发货，客户按箱下单，双方都能找到一句话证明自己没看错。 更稳妥的订单草稿，应该先保留四件不同的事：原话中的数量、原话中的单位、对应的商品，以及商品的包装规格。 比如，原始数量是 2，原始单位是“箱”，商品编号暂时为空。等系统确认商品，再从商品资料读取一箱的件数。只有包装规格确定，才计算最终的件数。 如果该商品当前包装是每箱 12 件，程序可以计算出 24 件。这里的 12 来自商品资料，24 来自计算，AI 负责识别客户说了“两箱”。把这几个来源分开，出错时才知道该查哪里。 原文信息、系统查到的信息和程序计算出的信息，应当能够分辨。 全部混进模型的一次回答里，后续就很难判断它是在提取、推断，还是顺手补齐。 地址也是同样的道理。“上次的地址”可以保存为客户的地址引用要求，但不宜让模型凭一句话写出一个完整地址。系统要在已确认客户身份的前提下查询历史记录；查到多个地址时，再让客户确认。客户一句“照旧”，不能替数据库做唯一性判断。 为了便于复查，可以给每条草稿信息保留对应原文。数量旁能看到“两箱”，时间旁能看到“周五前要”。原文片段帮助人定位依据，但它本身也需要核对，不能因为模型附了一段引文就自动相信。3. 给缺失信息一个正式位置 不少接口把每个字段都设成必填，又要求 AI “不要遗漏”。模型面对的任务于是变成：无论原文有没有，都要填满。 表格看起来完整，问题却被藏进了默认值。 订单草稿可以允许商品编号为空，同时增加一个明确的处理状态。比如：信息完整且通过检查时为 ready；存在需要客户补充的条件时为 needs_confirmation；输入与当前业务范围不相容时为 unsupported。 这些是应用自己设计的状态，不是模型接口自动替业务提供的判断。 对这条留言，草稿的状态应该是待确认。缺口至少包括商品身份、地址指向，以及交付时间的含义。如果系统已有明确的客户规则，部分问题可以由查询解决；没有这类规则，就不能让一次推测偷偷升级成业务事实。 提问也可以更具体：“您说的蓝色款，是商品 A 还是商品 B？”比“请补充商品信息”更容易得到可用回答。前提是 A、B 来自当前可售商品，不能由模型临时编两个选项。 “周五前要”则需要区分发货时间与送达时间，还要结合本次对话日期、业务时区和明确约定。系统可以保留原话，提出确认问题。不能因为日期字段要求一种标准格式，就替客户决定一个精确时间。 这里有个很实用的设计原则：允许草稿不完整，但不允许缺口失去踪迹。 空值有对应原因，原因有下一步动作，后续处理才能接得上。4. 模型给了 ready，系统还得再看一遍 如果模型返回 ready，是否就可以创建订单？ 还需要经过应用的检查。状态是模型输出的一部分，不能让它兼任最终审批人。 先检查形状：字段是否齐全，类型是否正确，状态是否在允许范围内。不符合就停止当前消费过程，保留错误信息，进入重新生成或人工处理。 再检查业务含义：商品编号是否真实存在且可售，客户是否有权使用这条地址，箱规是否有明确来源，数量是否满足业务限制。“商品编号长得像编号”与“这个商品真的能下单”，是两项不同的检查。 最后检查提交条件：需要确认的事项是否全部关闭，用户是否已明确要求创建订单。这一层与字段正确性有关联，但有自己的规则。客户只要求“帮我看看要多少钱”，即使草稿已经完整，也不代表他要求下单。 
通过这些检查，草稿才进入实际创建环节。创建成功后的订单编号和状态，应该来自业务系统的返回结果。不要把模型提前写出的“已下单”当成操作回执。 如果外部系统调用失败，草稿仍可以保留。页面应说明停在哪一步，让人看到已确认信息与当前失败原因。把一切失败都翻译成“AI 暂时不太聪明”，既不方便排查，也容易让用户重新输入已经确认过的内容。 这套分工很清楚：模型理解留言，业务系统查证与计算，应用决定是否放行，订单系统提供实际结果。5. 失败时，别先把提示词加长 面对错误输出，一个常见反应是在提示词末尾继续加要求：“认真检查”“绝对不要出错”“所有字段必须准确”。写着写着，像在给一个不听话的实习生发长消息。 有些错误确实可以通过更清晰的字段说明改善。比如把“数量”改成“客户原话中的数量，尚未进行包装换算”，就减少了一种歧义。 但查不到箱规的问题，需要补充商品资料；客户身份不清的问题，需要身份确认；调用被截断的问题，需要检查接口结果。把这些全交给提示词，最后只会得到一份态度更认真的错误答案。 所以，失败后先判断原因。结构不合法，可以在可控次数内重新生成；业务条件缺失，应查询或追问；服务超时、拒绝或未完整返回，应按接口状态处理。具体状态名称与处理方式要看所用服务，不能假设每种失败都会返回一个可用的 JSON 对象。 重新生成时，只反馈确切错误。例如“商品编号不在本次允许列表中”，比“答案质量不好”更能帮助修正。同时保留输入与失败原因，避免每次重来都丢掉已经确定的信息。 也不要把模型自报的置信度直接当放行门槛。它说“我有 95% 把握”，不等于业务系统已经验证了商品、单位和地址。检查事实的条件，应尽量写成能执行的规则。6. 用几条难接的留言验收 上线前，挑一条信息完整的留言演示，当然很容易让流程顺利结束。真正值得检查的，是那些让系统必须停一下的输入。 先放入“两箱，照旧”。预期结果是保留数量与单位，指出无法唯一确定的商品或地址。若系统直接补齐商品编号，说明缺失信息没有被正确处理。 再放入“两箱蓝色 A 款”，但当前商品资料没有箱规。预期结果是识别商品与原始数量，停止包装换算。没有依据时得到一个整齐的件数，应当算失败。 接着放入“先算一下两箱多少钱，暂时别下单”。预期结果可以产生报价所需的草稿，但不能触发订单创建。字段齐全不应绕过客户的意图。 还要把模型返回结果截断、给一个不存在的商品编号，观察应用是否能分别识别格式问题和业务问题。它们不该被合并成同一种“重试一下”。 这些验收要看实际状态变化：草稿里留下什么，缺口怎样显示，提交动作有没有发生，最终回执来自哪里。只看最后一句“处理成功”，看不出系统究竟有没有守住边界。 如果你正在把 AI 接进表单、工单或订单系统，可以从一个动作开始：找出最容易被模型补齐的必填字段，写清它的来源、缺失时的状态，以及放行前必须满足的条件。 等这项约定落到了程序里，JSON 才有了可靠的接收方。一个暂时不能提交、却能解释原因的草稿，往往比一张填得满满当当的订单，更接近可用的自动化。