很多AI功能第一次接入时都能跑通，但一旦进入真实业务，最容易暴露的问题往往不是模型不会回答，而是返回结果不稳定。同一个问题，模型可能返回JSON，也可能加上一段解释；字段名称可能变化，数组可能变成字符串，甚至会出现半截结果。
结构化输出解决的是什么问题
结构化输出的目标，是让模型返回可以被程序直接消费的数据，而不是一段只能给人阅读的自然语言。比如商品提取、文章摘要、关键词生成和工单分类，都可以约定固定字段，让后续程序继续执行。
它并不等于“模型一定不会出错”。更准确的理解是：通过明确的字段、类型和枚举范围，降低解析成本，并让错误能够被程序识别。
先设计字段，再写提示词
不要一开始就堆很多格式要求。先确定业务真正需要的字段，例如标题、摘要、标签和置信度，再决定哪些字段必填，哪些字段允许为空。
- 字段名称保持稳定，不要同一项目混用中英文别名；
- 枚举值提前限定，避免出现多个表达相同含义的状态；
- 对数组、数字和布尔值明确类型；
- 允许缺失的信息使用空值，不要让模型自行编造。
JSON Schema要限制到什么程度
Schema越清楚，程序越容易处理，但也不宜把所有自然语言都限制成固定模板。适合约束的是字段类型、必填项、长度、枚举和嵌套关系；不适合过度限制的是文章观点、摘要表达和开放式解释。
{
"type": "object",
"required": ["title", "tags"],
"properties": {
"title": {"type": "string", "maxLength": 60},
"tags": {"type": "array", "items": {"type": "string"}}
}
}解析成功不代表业务正确
JSON能够被解析，只说明语法正确，不代表内容符合业务规则。服务端还要检查标题是否为空、标签数量是否超限、分类是否存在，以及敏感字段是否被误填。
建议把校验拆成两层：第一层检查类型和必填字段，第二层检查业务规则。这样可以快速定位问题，也方便统计哪一类错误最多。
失败后不要无限重试
格式错误可以进行一次带错误提示的修复请求，但不能无上限重试。连续失败时，应保存原始响应、请求标识和校验错误，让任务进入人工处理或降级流程。
- 第一次失败：记录具体字段错误；
- 第二次请求：只要求修复格式，不重复生成全部内容；
- 再次失败：返回安全的默认结构，并标记任务待处理。
如何设计默认值和降级结果
对于非核心字段，可以准备默认值。例如摘要为空时使用文章首段，标签缺失时暂不绑定标签，置信度缺失时设置为待确认。核心字段不能随意填充，宁愿让任务失败，也不要把错误数据写入数据库。
日志要记录哪些信息
排查结构化输出问题时，至少要记录模型版本、请求类型、Schema版本、解析结果、校验错误和重试次数。日志中不要保存完整密钥、用户隐私和不必要的原始内容，可以使用任务ID关联上下文。
总结
AI结构化输出的稳定性，来自“字段设计、Schema约束、服务端校验和失败兜底”四个环节，而不是依赖一句“请严格返回JSON”。把模型当作不稳定的外部服务来设计，才能让AI功能真正进入生产环境。
评论 0