🧑💻 面试官：我们让模型从发票里提取订单号和金额，它返回了合法 JSON：{"order_id":"A123","amount":9900}。可以直接写入报销单吗？
🙋♂️ 我：不能只看它能不能解析。amount 是元还是分？发票上金额真是 9900 吗？订单号是否存在、是否属于当前用户？这些都不由“JSON 合法”保证。
🧑💻 面试官：那用了严格的 JSON Schema 结构化输出，字段和类型都对了呢？
🙋♂️ 我：那解决了格式和一部分类型问题，但还要做业务校验与来源核对。比如金额字段是数字，不代表数字就是对的；输出符合 Schema，也不代表用户有权限提交这张发票。
🧑💻 面试官：如果模型返回拒答，或者输出被截断，你的后端怎么处理？
🙋♂️ 我：先检查这次生成是否完整、是否拒答，再决定能否解析。解析失败可以有限重试或改走人工，但不能把半截 JSON 当成空字段写库，更不能在重试时重复创建报销单。
这题的分界线是：结构化输出保证“长得像数据”，业务系统还要判断“数据真不真、能不能用、能不能写”。
面试速答（60 秒版）
合法 JSON 不能直接入库。它只说明语法上能解析；即使用 JSON Schema 约束了字段和类型，也只能说明结构符合预期，不能证明金额、订单归属和业务条件正确。
我会把链路分几关：先检查模型调用是否完成、有没有拒答或截断；再做结构校验；之后核对金额单位、范围、订单是否存在、发票和订单是否一致，以及当前用户是否有权限。涉及写入时，用明确的确认或审批流程，并给一次业务请求设置幂等键，防止超时重试生成两张单。
失败时不要统一“再问一次模型”。格式错误可以有限重试；原始材料模糊或数据冲突，应标记待核对或转人工；权限不通过直接阻止写入。评测也要分别看格式通过率、字段准确率和错误写入率。
知识点详解：JSON 到数据库之间还有哪些关？
第一关：这次模型输出是否完整
后端收到字符串之前，先看 API 返回的状态。生成可能因为输出长度限制被截断，也可能明确拒答。若只取一段文本就调用 JSON 解析器，错误处理很容易混乱：截断可能报语法错，拒答可能被误当作缺字段。应先区分调用失败、不完整、拒答和正常完成，再分别处理。
普通“请输出 JSON”提示与真正的结构化输出机制也不同。前者只是希望模型遵守格式；严格 Schema 可在支持的模型和接口上提高结构可靠性。但即使结构被保证，业务真值没有被保证。
第二关：结构正确，内容也可能错
假设 OCR 把发票上的 99.00 识别成 9900，模型输出 amount: 9900，Schema 仍然会认为它是数字。又或者发票上是 99 元，但报销系统以分为单位，9900 是对的；如果没明确单位，单看 JSON 根本分不出是哪一种。
所以字段定义里要明确单位、币种、日期格式和允许缺失值。应用还要核对来源：金额能否回连发票原文，订单号能否在订单系统查到，发票抬头和订单归属是否符合规则。对高风险字段，必要时给人工看原件确认。
这里顺便分清三层校验：语法校验看能否解析 JSON；结构校验看字段和类型；业务校验看值是否合理、可信、符合权限。只过了前两关，不该直接把模型输出当成业务事实。
第三关：写入不是“把对象存进表里”那么简单
用户点击确认报销时，后端要以当前登录身份重新校验订单归属和报销规则。不要因为模型曾输出 order_id，就让它决定替谁创建单据。
写入也要考虑重试。前端超时后用户再点一次，或者后端在“数据库已提交、响应没返回”时重试，都可能导致重复单据。用业务请求 ID/幂等键识别同一次提交，并让数据库约束与交易流程配合。模型重新生成了另一份 JSON，不应自动视为另一笔合法申请。
怎么评测这条链路
准备带标准字段的发票样本，里面要有模糊金额、不同币种、订单不存在、他人订单和重复提交。分别统计解析与 Schema 通过率、关键字段准确率、需要人工核对时是否正确停下，以及有没有错误写入。
只看“JSON 输出成功率”，容易得到一个很好看的数字，却看不出报销系统正在接收错误金额。
面试官继续追问
既然严格 Schema 能保证结构，还要自己校验字段类型吗？
仍要在应用边界按实际接口契约检查，尤其涉及不同模型、版本和异常响应时。更重要的是，类型合法不代表业务合法：amount 是数字，也可能是错单位或错金额。
解析失败就自动重试三次，可以吗？
要先看失败原因。格式错误或短暂调用异常，可以有限重试；原始发票模糊、数据冲突或权限失败，重复生成不会把材料变清楚。重试还不能重复触发写入。
模型提取结果和订单系统不一致，以谁为准？
订单状态与归属以权威订单系统为准；发票内容以可核验原件或可信解析结果为依据。冲突时不要让模型投票选一个，应该标记待核对并阻止自动入库。
面试速记卡
- 合法 JSON：只过语法关，不证明字段值正确。
- 严格 Schema：约束结构和类型，不能替代来源、权限与业务规则。
- 异常分流：先辨别失败、截断、拒答和正常完成，再解析。
- 入库门槛：核对金额单位、来源、订单归属与用户权限。
- 重试安全：写操作有幂等键，避免一次请求生成多张单。
