Java 做 AI 提取任务时，为什么我更建议先想好结构化输出
Spring AI 面试题：结构化输出怎么做？Prompt 模板、实体解析、落库策略一次讲透
如果你的 AI 应用只需要“回一段话”，那普通聊天能力就够了；但只要要进系统、进流程、进审批，结构化输出就会变成第一优先级。
这篇我就按 Java 项目里最常见的工单提取、简历解析、风控摘要这类场景来讲 Spring AI 的结构化输出怎么做。
🦅个人主页
🐼GitHub主页
文章目录
- Spring AI 面试题：结构化输出怎么做？Prompt 模板、实体解析、落库策略一次讲透
- 先看真实问题：为什么很多模型回答看起来很聪明，系统却还是接不住
- 一张表先看懂：纯文本回答和结构化输出到底差在哪
- 举个具体例子：售后工单智能分流：模型先提取，再决定是否转人工
- 代码示例：Prompt 模板 + entity 映射 + 结果落库
- 结构化 DTO
- Spring AI 结构化输出
- 解析失败时的兜底处理
- SQL 示例：结构化结果落库表
- 系统设计时我会优先拆哪几层
- Prompt 约束层
- 对象解析层
- 落库与补偿层
- 真正上线时最容易卡住的点
- 监控和指标建议盯哪些
- 如果面试官问我这块怎么设计，我会这样答
- 结语
先看真实问题：为什么很多模型回答看起来很聪明，系统却还是接不住
AI 项目里最常见的尴尬场景是：模型回答看起来很完整，但字段名称不稳定、布尔值表达不统一、时间格式前后不一，最后后端根本没法直接入库。
所以一旦涉及提取、分类、归因、摘要这些系统化动作，关键目标就不是“让回答更像人”，而是“让结果更像 Java 对象”。
- 工单优先级、标签、是否升级到人工，这些都应该是字段，不应该只是正文里的描述
- 如果解析失败没有兜底，就会出现模型回了内容，但流程节点没法继续往下走
- 结构化输出不仅要关注模型效果，还要考虑落库、补偿和重试
一张表先看懂：纯文本回答和结构化输出到底差在哪
| 维度 | 怎么做 | 为什么 |
|---|---|---|
| 纯文本 | 前端展示友好 | 系统不容易做后续流转 |
| 结构化对象 | 直接映射成 DTO | 适合进库、进规则、进审批 |
| 模板约束 | 提前规定字段和格式 | 减少模型自由发挥 |
| 解析兜底 | 失败时走重试或人工审核 | 避免链路卡死 |
举个具体例子：售后工单智能分流：模型先提取，再决定是否转人工
- 用户提交一段售后描述，后端先把标题、正文、历史客服记录拼成 Prompt。
- 模型输出
priority、category、needEscalation、actions这几个关键字段。 - 如果
needEscalation=true，系统直接创建人工工单；否则进入自动回复流程。 - 如果解析失败或者字段为空，记录到异常表里，后续做人工补录或重试。
代码示例：Prompt 模板 + entity 映射 + 结果落库
结构化 DTO
publicrecordTicketSummary(StringticketId,Stringcategory,Stringpriority,booleanneedEscalation,List<String>actions,Stringreason){}Spring AI 结构化输出
@Service@RequiredArgsConstructorpublicclassTicketSummaryService{privatefinalChatClientchatClient;privatefinalAiExtractRecordRepositoryextractRecordRepository;publicTicketSummarysummarize(Ticketticket){TicketSummarysummary=chatClient.prompt().system(""" 你是售后工单分流助手。 你必须输出结构化结果，不要输出额外解释。 priority 只能是 LOW、MEDIUM、HIGH。 category 只能是 REFUND、LOGISTICS、QUALITY、OTHER。 """).user(u->u.text(""" 工单标题: {title} 工单正文: {content} 历史客服备注: {remark} 请完成分类、优先级判断，并给出建议动作。 """).param("title",ticket.getTitle()).param("content",ticket.getContent()).param("remark",ticket.getLastRemark())).call().entity(TicketSummary.class);saveResult(ticket.getId(),summary);returnsummary;}privatevoidsaveResult(LongticketId,TicketSummarysummary){AiExtractRecordrecord=newAiExtractRecord();record.setBizId(ticketId);record.setExtractType("TICKET_SUMMARY");record.setResultJson(JsonUtils.toJson(summary));record.setParseStatus("SUCCESS");extractRecordRepository.save(record);}}解析失败时的兜底处理
publicTicketSummarysafeSummarize(Ticketticket){try{returnsummarize(ticket);}catch(Exceptionex){extractRecordRepository.save(AiExtractRecord.fail(ticket.getId(),ex.getMessage()));returnnewTicketSummary(String.valueOf(ticket.getId()),"OTHER","MEDIUM",true,List.of("建议转人工复核"),"模型解析失败，已走人工兜底");}}SQL 示例：结构化结果落库表
createtableai_extract_record(idbigintprimarykeyauto_increment,biz_idbigintnotnullcomment'业务主键，例如工单ID',extract_typevarchar(64)notnullcomment'提取类型',result_json jsonnotnullcomment'结构化结果',parse_statusvarchar(32)notnullcomment'SUCCESS/FAIL',error_messagevarchar(500)null,created_timedatetimenotnulldefaultcurrent_timestamp,updated_timedatetimenotnulldefaultcurrent_timestamponupdatecurrent_timestamp);系统设计时我会优先拆哪几层
Prompt 约束层
- 先把字段范围、枚举值、必填项写死，不要靠模型自由发挥
- 复杂场景建议一类任务一个模板，不要让一个万能 Prompt 兼容所有提取任务
对象解析层
- 让结果尽量直接映射到 DTO，后面业务代码更稳
- 如果业务字段很多，可以先提取一级摘要，再做二次加工
落库与补偿层
- 成功结果和失败结果都要落库，后面才好做回放和质量分析
- 关键链路不要只信任一次模型输出，要给人工复核留入口
真正上线时最容易卡住的点
- 没有给字段限定枚举值，最后 priority 可能返回“较高”“高优先级”“urgent”各种写法。
- 解析成功就直接当真值使用，忽略了模型可能对边界样本判断错误。
- 没有落失败日志，后面根本不知道是 Prompt 写坏了，还是模型偶发输出格式异常。
监控和指标建议盯哪些
- 结构化解析成功率
- 字段缺失率、枚举越界率
- 人工复核触发率
- 不同模型在同一提取任务上的准确率和成本
如果面试官问我这块怎么设计，我会这样答
如果面试官问 Spring AI 的结构化输出怎么做，我会先讲这不是“模型回个 JSON”这么简单，而是 Prompt 约束、实体解析、落库补偿三件事一起做。真正上线时，我会先定义 DTO 和字段边界，再用模板约束输出，最后把成功和失败都落库，保证流程可追踪、可回放、可纠错。
结语
AI 提取任务里，最值钱的不是模型说得多漂亮，而是它能不能稳定变成 Java 能消费的对象。
你们如果在做 AI 分类或提取，最头疼的是字段不稳定，还是落库后怎么做人工兜底？