企业 AI 输出要接入业务系统，先约定哪些字段和校验规则？

先围绕具体任务约定字段

当 AI 的结果只供人阅读时，字段顺序不一致通常表现为编辑返工；当结果要进入 CRM、工单或表格时，错误字段、空值和不合规选项可能改变后续处理。因此，在接通下游系统之前，先写一份“输出契约”：每个字段是什么意思、能出现什么值、谁检查、失败时停在哪里。输出契约是团队之间的约定，不等于某个模型已经能稳定遵守它。

先从一项具体任务开始，例如把已授权的来信整理成一条待分派记录。不要先设计一套覆盖全公司的大 schema。选 3 到 5 个真实流程里确实需要的字段，逐个写清楚定义、来源、类型、是否必填和接收系统中的目标字段。若“客户类型”在不同团队有不同口径，应先统一业务定义；把相同名称放进 JSON 并不能自动消除歧义。

字段说明至少应回答四件事：它代表什么事实、允许什么形式、由什么证据支持、下游会据此做什么。比如“跟进优先级”应说明合法值，以及它是 AI 建议还是业务负责人已确认的等级。如果接收系统会据此自动分配任务，建议将“模型建议”与“确认后的正式值”分开存放。不要把推断值直接落进看起来像已确认事实的字段。

接下来区分必填、选填和条件必填。必填字段缺失时，约定结果进入待补资料状态，还是整个记录停止传递；选填字段缺失时，约定使用空值、`null` 或显式状态。避免让模型用“未知”“无”“不适用”和空字符串随意互换。这些词的业务含义不同：没有提供资料、确实不存在和暂时无法判断，可能要求不同的人采取不同动作。接收系统如果不支持区分这些状态，就先改约定或保留人工整理，不要默默丢掉差别。

把结构校验与业务事实核对分开

字段类型和允许值也要写明。日期是日期还是日期时间，时间使用哪个时区；金额是否拆成数字和币种；分类值是否来自固定枚举；列表里每一项的结构是什么。若允许值之外出现新类别，不要让系统随便映射到最接近的一项。返回“未匹配，需要确认”通常比伪装成合法值更利于处理。

JSON Schema 官方文档说明，schema 可以描述 JSON 的类型、属性、必填项和其他约束，并由 validator 对实例执行验证。团队可以用它检查输出是否是对象、字段类型是否符合、必填项是否存在、枚举值是否在清单内。但结构验证只能回答“这个结果符合约定的形状吗”，不能回答“内容符合事实吗”。比如一个格式正确的日期仍可能是错误日期；字段叫 `source_url` 也不能证明链接支持了旁边的判断。因此，将结构检查和业务审核分成两个关卡。

第一关做机械校验：能否解析、字段是否齐全、类型与枚举是否合法、是否出现未约定字段。第二关做语义核对：来源是否支持字段内容、不同字段之间是否自相矛盾、是否缺少适用条件、是否把建议写成承诺。低风险字段可以按团队确认的规则自动通过结构检查；涉及报价、客户承诺、外发消息、任务分配或其他实际动作的字段，应明确负责人复核范围。不要因为 JSON 可解析就直接触发业务动作。

写清失败状态和人工接手

校验失败时要有明确状态，而不是无限修补。可以区分“格式错误”“缺少依据”“未知枚举”“业务冲突”“需要权限确认”几类，分别指定停止、补资料、人工复核或由维护者更新契约的处理方式。一次模型重试也应受限：先判断问题能否通过重试解决，若问题本质上是来源缺失或字段定义不清，就不要循环要求模型重新生成同一个猜测。

用样例把约定跑通。准备正常样例和边界样例：一个必填字段缺失、出现未登记类别、类型不匹配、两个字段矛盾、来源为空、内容超出允许范围。样例使用前要确认数据已获准用于测试；可用脱敏或合成资料检验格式流程，但不能用它们证明真实业务字段已准确。每个样例记录预期状态、实际校验结果、责任人和下游是否被阻止。

接口版本变化也要提前处理。新增或重命名字段之前，确认生产接收方是否依赖旧字段；列出新旧映射、兼容期限、缺省行为和回退条件。对未知字段是拒绝、忽略还是进入复核队列，应与接收系统负责人确认。流程不能默认双方会同时更新。如果契约改变会影响既有记录，也需决定历史数据是否需要回填；这属于业务与系统范围评估，不宜由文章读者直接照抄。

可以把失败状态做成一张小型状态表，而不是只写一句“校验失败后人工处理”。例如，格式无法解析时不发送；字段缺失时进入待补资料；来源无法核实或字段冲突时交事实负责人；超出权限时停止并请系统管理员检查；下游已经成功但响应不明确时先查询原任务记录。每个状态要配一个能执行的下一步、负责角色和结束条件。谁负责、是否允许继续，应按企业现有流程确认，不由模型输出自行决定。

演练边界情况，再连接下游系统

检查是否能把一次运行准确地映射到一次下游动作。可使用团队既有的任务编号或请求标识来连接输入、输出、校验结果和最终处置。若一个输入可能产生多条目标记录，应区分父任务和子结果；如果一个目标记录会由多个来源共同填充，应说明每个字段对应哪项任务与证据。这样在复核某一条数据时，负责人不必从一整段对话中猜它怎样生成，也不必把完整敏感输入重复抄进多个日志。

试运行时保留几类反例，验证契约真的限制了结果：模型省略字段、输出额外键、把数字写成文字、把未知值填成猜测、把建议状态放进正式字段，以及两个字段互相冲突。让执行者不仅确认“校验器报错”，还要确认记录有没有被写入、负责人的队列里出现了什么、谁能解除阻塞。只在文档上写有回退办法，不等于目标系统真的会停下来。

若更换模型、任务说明、来源资料或接收系统字段，先判断本次改动影响契约哪一部分。格式变更应重新验证结构样例；业务定义变更应由事实负责人确认；接收端升级则要与其维护团队核对字段兼容。把批准记录关联到契约版本，并明确旧版停止时间。未决定的字段不要暂时用临时含义顶替后再忘记清理，否则一个名称可能在不同团队之间代表不同事实。

落地前可以用这份清单逐项核对：

接入前逐项确认

先让一项范围明确、错误可被发现的任务经过完整验证，再决定是否扩大字段或连接更多系统。契约能减少“各自以为字段是什么意思”的落差，却不能替代数据来源核验、权限判断和业务责任。若下游动作影响客户或正式业务记录，先确定由谁承担最终确认，再考虑自动流转。

• 每个字段是否有唯一、业务可理解的定义和责任人？
• 是否注明来源、类型、必填规则、允许值和“不知道”的表达？
• 模型建议与已确认事实是否能够区分？
• 结构校验通过后，是否还有针对事实、条件和权限的业务核对？
• 失败时会停止、补资料还是转交谁处理？下游动作是否被阻止？
• 重试和版本变化会不会覆盖正式记录或产生重复结果？
• 测试样例是否覆盖缺值、冲突、边界值和不支持情况？
• 是否记录契约版本、校验结果、处理人和必要的结果定位信息？