2026 AI 面试题：如何让模型严格输出 JSON，为什么只靠 Prompt 不可靠

题目分类 方向：Prompt 工程 考察点 能否区分“看起来像 JSON”“语法合法”“符合 JSON Schema”和“满足业务规则”这四个层次 能否说明 Prompt、JSON mode、Structured Outputs 和 Function Calling 各自能约束到什么程度 能否设计 Schema、解析、业务校验、有限重试与降级组成的完整链路 能否处理拒答、截断、缺字段、额外字段、类型正确但语义错误等异常 能否说明结构化成功率、业务校验通过率、重试率和降级率等生产指标 知识讲解 1. “严格 JSON”包含哪些要求 模型返回一段以 { 开头的文本，不等于系统已经拿到了可用的 JSON。至少要分清四层要求：输出中没有 Markdown 代码块等多余文字；内容能够被 JSON.parse；字段、类型和枚举符合约定的 Schema；字段值满足业务规则。

例如 {"startDate":"2026-08-20","endDate":"2026-08-10"} 在语法和字段类型上都可能正确，但结束时间早于开始时间，业务上仍然不可用。生产系统不能把“解析成功”当成“结果正确”。 2. 常见方法的约束强度 只在 Prompt 里写“仅返回 JSON，不要解释”，属于 best effort。它能改善结果，但模型仍可能输出代码围栏、遗漏字段、修改字段名，或者在输出被截断后留下半个 JSON。Few-shot 示例可以进一步稳定格式，但仍然不是协议级保证。

JSON mode 通常保证输出是语法合法的 JSON，却不保证一定符合指定字段结构。例如系统需要 status 和 items，模型仍可能返回合法但错误的 {"message":"done"}。

Structured Outputs 会把 JSON Schema 交给支持该能力的模型，在生成阶段约束字段、类型、必填项和枚举。Schema 中应明确 type、properties、required，对象通常还要设置 additionalProperties: false，避免模型生成未声明字段。它比纯 Prompt 和 JSON mode 更适合稳定的数据提取、分类和 UI 配置生成。

Function Calling 或 Tool Calling 也可以使用 Schema 约束参数，但目标不同：Structured Outputs 适合让模型返回一份结构化结果；Function Calling 适合让模型表达“要调用哪个能力以及参数是什么”。模型给出工具参数后，应用仍要校验、鉴权并决定是否执行。 3. 生产级链路 可靠链路通常从一份单一数据契约开始。TypeScript 类型、JSON Schema 和运行时校验规则不要手写三份，否则很容易漂移；可以用 Zod 等 Schema 工具生成类型，并复用到模型响应格式和应用校验中。

模型返回后，先判断请求是否成功、是否拒答或因 token 上限被截断，再完成解析和 Schema 校验。通过结构校验后，还要检查日期先后关系、ID 是否存在、金额范围、权限和跨字段约束等业务规则。只有全部通过，结果才能进入数据库、工具调用或前端状态。

图解：模型侧 Schema 解决的是结构约束，应用侧校验解决的是业务正确性；任一环节失败都不能直接使用结果。

校验失败时可以把精简后的错误信息反馈给模型并重试一次，但要限制次数。连续失败应进入确定性降级路径，例如返回默认结构、切换人工确认、重新询问用户，或把原始文本交给专门的修复流程。不能无限调用模型，也不应该用正则表达式从任意文本中“抠出”JSON 后直接写入业务系统。 4. Schema 怎么设计 Schema 应尽量小而明确。字段名表达业务含义；固定集合使用 enum；数组定义 items；必要字段放入 required；不接受未知字段时设置 additionalProperties: false。可选值最好通过 null 或明确的状态字段表达，不要让模型在缺字段、空字符串和 "unknown" 之间随意选择。

字段描述要说明“这个字段代表什么”，而不是重复类型。Schema 过深、分支过多或包含大量动态键，会提高生成和维护难度；可以把复杂任务拆成两次结构化请求，或者先分类再使用对应的子 Schema。

还要注意不同模型提供方只支持 JSON Schema 的子集。接入前应核对支持的关键字，并对 Schema 本身做版本管理和契约测试。模型或 Prompt 升级时，用固定样本集回归字段完整率和业务校验通过率。 5. 常见失败与监控 常见异常包括拒答、输出截断、Schema 不受当前模型支持、字段值虽然类型正确但事实错误，以及流式传输中把尚未闭合的 JSON 提前交给业务代码。结构化输出只能提高格式可靠性，不能保证内容真实，也不能替代权限检查和事实校验。

线上至少要区分模型请求失败率、拒答率、解析失败率、Schema 通过率、业务校验通过率、平均重试次数和降级率。若只统计最终接口成功率，就无法判断问题发生在模型生成、传输解析、契约变化还是业务规则层。 代码示例 下面使用 TypeScript、Zod 和支持 Structured Outputs 的 Responses API 展示核心链路。模型名称通过配置传入，避免把实现绑定到某个固定版本。

代码讲解 OrderSchema 是模型输出和运行时类型之间的契约。responses.parse 配合 zodTextFormat 让支持该能力的模型按结构生成，并把结果解析到 outputparsed，应用不需要自行删除代码围栏或截取大括号。

代码没有在拿到 outputparsed 后立刻返回，而是继续查询订单是否存在。这一层验证不能只靠 JSON Schema，因为 Schema 能判断 orderId 是字符串，却不知道它是否对应当前用户的真实订单。涉及退款时还需要继续做用户权限、订单状态、金额和幂等校验。

重试被限制为一次，并且反馈的是明确的失败原因。若仍然失败，函数返回可识别的错误，由上层选择补问用户、人工处理或默认降级。实际项目还应区分拒答、超时、截断、Schema 错误和业务校验失败，分别记录指标，而不是统一吞成“JSON 解析失败”。 面试回答 严格 JSON 不能只靠 Prompt，关键是把自然语言约定升级成机器可验证的数据契约。提示词里的“只返回 JSON”最多是 best effort，JSON mode 通常只能保证语法合法；需要稳定字段和类型时，应优先使用模型提供的 Structured Outputs 或带严格 Schema 的工具参数。

这里要区分三个成功标准：JSON.parse 成功、符合 JSON Schema、满足业务规则。Schema 可以约束必填字段、类型、枚举和未知字段，但不能判断订单号是否真实、结束时间是否晚于开始时间，也不能保证模型提取的事实正确，所以应用侧校验不能省。

完整链路是定义 Schema，让模型按 Schema 生成，检查拒答和截断，执行运行时解析，再做跨字段和外部数据校验。失败后只做有限重试，把精简的校验错误反馈给模型；继续失败就补问用户、人工确认或走确定性降级，不能无限重试。

Schema 最好作为单一事实来源，同时生成 TypeScript 类型并用于运行时验证。线上会监控 Schema 通过率、业务校验通过率、重试率和降级率，用固定样本集做模型与 Prompt 升级回归。结构化输出解决的是接口契约问题，不解决事实正确性和业务安全问题。 面试官追问 JSON mode 和 Structured Outputs 的本质区别是什么？ 为什么已经设置 strict，应用侧仍然需要校验？ additionalProperties: false 解决什么问题？ 流式输出 JSON 时，前端应该什么时候开始解析？ Schema 很复杂时，为什么成功率和维护成本可能变差？ Function Calling 的参数符合 Schema，是否就可以直接执行退款？ 模型输出被 token 上限截断时如何识别和处理？ 如何评估更换模型后结构化输出是否发生回归？ 高分回答要点 明确区分语法合法、Schema 合法和业务合法 能根据场景选择 Prompt、JSON mode、Structured Outputs 或 Function Calling 使用单一 Schema 契约连接模型生成、类型系统和运行时校验 覆盖拒答、截断、有限重试、降级、权限和事实校验 能提出分层错误码、质量指标和固定样本回归测试 常见扣分回答 只写“在 Prompt 中强调不要输出其他内容”，把概率性约束当成强保证 认为 JSON.parse 成功就可以直接使用数据 混淆 JSON mode 与 JSON Schema，不知道前者可能返回结构错误的合法 JSON Structured Outputs 成功后跳过业务校验、鉴权和事实检查 解析失败后无限重试，或者用正则截取大括号掩盖上游问题 没有区分拒答、截断、Schema 失败和业务失败，导致线上无法定位 项目结合话术 结构化结果会先定义可版本化的 Schema，并复用到模型响应格式、TypeScript 类型和运行时校验。模型侧负责把输出限制在契约内，应用侧继续验证真实 ID、跨字段规则和用户权限；失败只重试一次，之后进入补问或人工兜底，同时分别记录结构校验和业务校验指标。 参考来源 OpenAI Structured Outputs 官方指南 JSON Schema 对象与 required、additionalProperties