AI 输出的数据格式不稳定，怎样约定字段、校验与人工确认？

AI 把客户需求整理成表格或 JSON，第一份写数量，第二份写需求量，第三份把“约十套”变成确定的 10。界面看起来规整，后续导入仍可能失败，业务含义也可能改变。提高稳定性需要同时约定字段结构、来源依据和不确定信息的处理方式。

先固定结果怎样被后续使用

人工阅读的摘要可以保留自然语言；自动进入询盘记录的数据则应有明确字段。先定义哪些字段用于检索、哪些仅供人员参考，再决定类型、允许值与必填条件。不必为每一句原文都增加字段，也不能让模型每次自己发明列名。

表中是虚构的设计样例，不代表所有询盘都应采用同一字段。需要日期或数量的机器值时，可同时保留原始表达和确认状态；在确认前不要让推断值驱动报价或承诺。

结构正确、来源正确、业务可用分三步验证

JSON Schema 等工具可检查对象结构、类型、必需字段以及额外字段规则。属性写进 properties 不自动等于必填，是否必填需要明确约定。必填但允许 null，与字段完全缺失也不是同一种结构；这些规则应由接收方确认。

结构通过后，再核对值是否来自原文及是否保留条件。数字类型的 10 可以完全符合格式，却仍可能是模型猜出来的。最后检查业务关系，例如型号与单位是否匹配、日期是否存在歧义、当前结果是否需要人工确认。三类校验不能互相替代。

用正常与异常样例检查处理路径

使用虚构语句“想了解 A-10，数量约十套，交期还没定”。可接受结果应保留 A-10、数量的估计含义以及交期待确认；不可接受结果是给出固定交付日期，或把约十套变成客户已经确认下单。

再加入没有数量、同一段有两种型号、单位冲突和无法识别字符的样例。记录原文、生成结果、失败字段与原因，而不只统计有没有成功解析 JSON。模型更新后重复同一批样例，并检查原先正确的字段有没有退步。

失败后有限修正，不把校验当成事实生成器

格式错误可以按明确反馈重新生成，但应限制尝试次数，并再次执行完整验证。若原文没有某个值，重复要求“补齐必填”只会增加编造风险；正确去向应是待确认、拒绝自动导入或人工补充。人工修改也保留依据，不无声覆盖原始表达。

未经核实的结果先进入可审阅状态，不自动触发重要外部动作。网站可以帮助人员发现问题，但最终要让接收方知道哪些字段已确认、哪些还不能使用。

如需把 AI 整理结果接入网站表单或资料录入，可私聊客服，提供脱敏原文、期望字段及不允许出现的错误，沟通结构校验与人工复核范围。

技术参考：JSON Schema：对象属性、必需字段与额外字段。