JSON 合法了，业务流程还是可能走偏
开发人员让 AI 输出一份客户工单，接口检查发现括号和字段都正确，于是直接写入系统。几天后才发现，优先级写成了“急、一般、普通”三种文字，而下游只认识 P1、P2、P3；日期有时是本地格式，有时带时区；“客户已确认”还被写成了“客户大概率确认”。数据能解析，业务却不能据此做决定。
企业在接 AI 时容易把注意力放在提示词上，反复要求模型“严格按格式输出”。格式当然重要，但真正决定能否上线的是字段背后的业务含义。字段谁使用、何时必填、无法判断时怎么处理，都要在开发和业务之间说清楚。
先做字段字典，再确定 AI 输出模板
字段契约可以从一张表开始。记录字段名称、业务含义、类型、单位、允许值、是否必填、来源和使用系统。比如“预计签约日期”到底是客户口头表达的日期、销售判断日期，还是合同生效日期，必须解释清楚。
提示词里的示例不能代替正式契约。示例用于帮助 AI 理解，契约用于让系统和人共同验收。字段发生变化时，要同步更新接口、表单、报表和评测样本，不要等到某次导入失败才发现两个部门对同一个词有不同理解。
- 业务名称和系统字段名分开记录，避免只看代码缩写。
- 对枚举值、金额、日期和状态字段设置明确范围。
- 允许输出“未知、待确认、无法判断”，不要逼 AI 填一个猜测值。
校验要分两层：先看格式，再看是否符合业务
第一层是程序校验，负责检查字段是否齐全、类型是否正确、日期和金额能否解析、枚举值是否在允许范围内。第二层是业务校验，负责检查字段之间有没有矛盾，例如退款金额不能高于订单金额，已关闭客户不能被标记为待跟进，承诺日期不能早于当前流程节点。
两层都通过，也不代表所有结果都可以自动执行。涉及合同、付款、删除、对外承诺和客户等级变化的结果，应根据风险设置人工确认。输出被拒绝时，要告诉员工是哪项校验没有通过，并保留原始内容。
不要让异常变成一堆没人看的错误日志
结构化输出出现异常时，系统应把任务送到对应队列：字段缺失交给业务补充，数据冲突交给负责人确认，系统接口失败交给技术处理，敏感操作则进入审批。不同问题进入同一个错误列表，最后只会形成堆积。
还要记录异常发生在哪一版提示、哪一份资料、哪个模型和哪个下游系统。高频异常回到字段契约和流程设计中解决，偶发异常保留人工兜底，避免错误静默写入。
验收样本要故意包含脏数据和模糊表达
不要只用整理得很漂亮的测试数据。应加入错别字、缺字段、多个日期、同义表达、相互矛盾的客户说法，以及 AI 没有证据判断的情况。验证系统是否拒绝不完整结果、是否正确进入人工队列、是否会把不确定信息伪装成确定值。
上线后的指标可以看自动通过率、人工退回率、字段修正率、静默错误数和下游补救时间。自动通过率越高不一定越好，如果员工和客户不断在后面修正，真正成本只是被隐藏了。企业 AI 的输出契约，最终要服务于可用、可追踪和可纠正。
要点总结
- 高风险字段和对外动作仍建议人工审核，低风险且经过充分验证的场景可以逐步自动化。
- 业务负责含义和规则，技术负责实现和校验，双方共同维护版本和变更记录。
- 不能。Schema 主要检查结构和类型，金额关系、流程状态和权限边界还需要业务校验。
参考来源说明
本文围绕“让 AI 输出表格不等于能接进系统：结构化字段也要有业务契约”展开，结合 5 份公开资料及一路凯歌在“企业 AI 服务”方向的执行经验整理，重点看它对官网可引用结构、FAQ 设计和后续获客复盘的影响。