Dify 输出 JSON 怎样交给业务系统：先校验再入库

Dify 输出JSON后，不应直接入库。先解析成对象，再校验结构，最后检查业务规则与操作权限，只有全部满足才提交。结构化输出能约束格式，却不能证明订单真实、金额正确或调用者有权创建记录。本文用合成订单演示业务系统应承担的校验，不连接任何真实数据库。

先写清下游需要什么

假设系统只创建采购草稿，需要外部单号、币种、明细和备注。明细含物料编号、数量和单位价格，币种仅允许CNY或USD，数量必须大于零，价格不得为负。创建正式采购单还需人工确认，本轮范围仅到草稿。

附件提供JSON Schema、有效与无效样例，以及每个案例的预期结果。Schema是项目自定义契约，不是Dify官方订单接口。以此实现时应使用支持所选规范版本的校验库，本文仅提供契约材料，没有在目标应用执行平台输出实验。

分三层拒绝错误

第一层检查响应是否可解析。模型输出带代码围栏、附加解释或半截字符串时，严格解析器可能失败。不要简单从第一个大括号截到最后一个大括号后就入库，这可能误截文本或掩盖多个对象。应保留原始响应并转到可控修复或人工复核。

第二层检查对象类型、必填字段、数组最少项目、字段类型和额外字段。JSON Schema中的properties只描述字段规则，必填需要required；要限制未声明字段，应按规范明确设置additionalProperties。数字字符串不等于数字，空字符串也不等于缺失字段。

第三层检查业务语义。物料编号必须在目标环境存在，币种要符合供应商协议，金额计算按系统规则进行，外部单号要符合幂等约定。Schema无法独立证明这些信息，所以校验通过仍可能被业务层拒绝。

有效与无效样例逐一解释

有效样例包含三条合成物料，数量和单价都是数字，币种在允许范围。业务层仍需查询物料是否可用，再计算总额。无效样例之一缺外部单号，应在结构层失败；另一条数量是负数，应在约束层失败；第三条格式合法却使用不存在的物料，应在业务层失败。

这三种错误需要不同返回原因。给前端统一显示“AI失败”不利于修复；把完整原始异常直接暴露给用户又可能泄露内部结构。可以定义脱敏错误码、可理解说明和关联标识，详细证据保存在授权日志中。

在Dify内约束，在业务服务端复核

官方LLM节点当前支持通过可视编辑器或JSON Schema配置结构化输出，并指出不同模型的原生JSON支持情况会影响可靠性。可在应用中使用结构化输出减少格式问题，但业务服务仍必须独立验证，不能只信任平台界面上的设置。

如果应用在工作流里先做一轮代码校验，下游接口依然不能省略验证，因为其他调用路径、配置变更或网络封装可能绕过上游检查。把契约版本写进请求或运行记录，便于发现前后端使用不同Schema的情况。

对于格式错误，不建议无限让模型自行修复。应限定修复次数，保留原错误，且修复过程不得凭空补业务事实。缺订单号就要求用户补充或按明确规则生成，不能让模型编一个看起来合理的真实编号。

防重复与人工确认

同一请求因超时重试，可能多次收到合法JSON。业务系统应以外部单号或独立幂等键识别重复，重复请求返回已有草稿状态，不再次创建。幂等键不能由不可靠的自由文本随意变化，应由服务端按任务记录管理。

人工确认页面展示关键字段与来源，确认后再执行正式动作。若用户改了数量或币种，应产生新版本并重新校验，不沿用旧的通过状态。授权检查也在执行时再确认，不能把之前能查看草稿等同于现在能提交采购。

以故障样例验收

至少运行有效对象、缺字段、错类型、负数、未知物料、重复请求和权限不足。检查每项是否停在正确层级，失败时有没有产生数据库写入。只有错误路径可预测、可追踪，JSON才真正成为业务接口契约的一部分。

交付时把Schema、样例、错误码和调用记录一并版本化。以后新增字段或改变默认值，先讨论兼容性，再更新两端校验。让模型生成一个漂亮JSON只是开始，正式产品还需要明确哪些数据能进入系统、哪些必须停下来等待确认。

数值字段还需要精度策略。单价与金额使用何种小数位、在哪一步四舍五入、税费由谁计算，都应由业务系统约定，不让模型自行决定。日期、时区与枚举值也应有明确规范，不能因为字符串格式正确就默认可入账。附件仅覆盖最小结构，正式扩展时应为每个新增规则补一个有效例和一个无效例，并保留旧契约的兼容测试。校验失败记录可以用于改进提示，但不能成为跳过服务端验证的理由。

官方依据：Dify LLM结构化输出说明与JSON Schema对象规则。平台配置不替代业务端校验。

可下载本文合成样例与记录表，附件里的数据只用于演示核对方法，请在副本中填写目标环境结果。更多背景可看专题与相关原理及交付说明。需要把这套核对接进已有业务系统，可带上脱敏材料、当前版本与失败记录，通过定制咨询讨论范围；集成商可查看系统集成协作。