AI 输出 JSON 改了字段，下游流程怎么避免接错？

格式合规不等于业务判断正确

结构化生成可以要求输出符合指定 Schema，减少漏字段或枚举值越界等格式问题。但一个字段即使类型正确，仍可能取错来源、把未知值填成猜测，或把建议写成已确认状态。下游流程不能只用 JSON parse 成功作为验收。

建立字段契约和版本记录

每个字段记录名称、业务含义、来源、允许值、缺失处理、确认责任人与下游用途。确实可能未知的值，应使用明确的空值或待确认状态，而不是让模型编一个默认值。保存 schema 版本、提示版本、解析器版本和发布日期。

若字段会被表单、CRM 或自动任务消费，先在测试环境对照旧版和新版输出，检查必填项、枚举、单位和兼容方式。新增、删除、重命名字段前，确认下游消费者不会把未知字段静默丢掉或误映射。

覆盖失败和拒答路径

测试有效对象、字段为空、输入资料不足、信息冲突、输出截断、拒答和不支持的格式。官方文档也提醒，结构化输出仍可能遇到拒答或长度截断等边界；应用需要识别并妥善处理。不要把失败响应当成正常业务值继续写入。

对于会发送通知、改变状态或触发外部操作的字段，先经过白名单验证和人工确认；结构化格式本身不构成执行授权。

用三层检查验收

第一层检查 JSON 和 Schema 是否匹配；第二层检查数值、来源和字段语义是否符合证据；第三层检查下游在边界状态下是否按预期停止、提示或转人工。每次变更保留小型回归集和分歧样例。若无法确认字段意义或下游影响，先不要让新输出进入正式流程。

把字段更新当作接口变更

每次修改 Schema 都应列出旧字段、新字段、兼容策略和受影响的下游步骤。新增字段若是必填，旧版消费方可能无法处理；字段名重命名则可能让已有映射静默失效。先通过自动化检查识别解析失败，再用代表性样本检查内容和值的业务含义。

保留版本号或可追踪的配置提交，把失败输出、拒答、截断与正常对象分开记录。若格式不支持或下游校验未通过，使用可理解的待处理状态，不要把半成品显示为已完成。

用一组对照样本检查变更影响

为每个关键字段准备几类输入：资料齐全、缺字段、格式异常、来源冲突和必须拒答。测试旧 Schema 与新 Schema 时，分别检查解析结果、字段映射、错误提示和下游状态。样本不是越多越好；先保证每种会改变处理路径的情况都出现，并由了解字段含义的人确认预期结果。

如果字段新增只用于内部展示，应确认消费者是否允许忽略未知字段；如果字段改名或含义变化，就需要同步更新所有读取方，不能只改生成提示。发布说明写清版本、生效时间、兼容范围和回退方式。遇到不支持的输入时，系统应明确停在待处理状态，避免业务人员误以为记录已经完整。