

### 题目分类
- 方向：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 解决的是结构约束，应用侧校验解决的是业务正确性；任一环节失败都不能直接使用结果。

![image.png](https://developer.qcloudimg.com/http-save/yehe-8338883/5258883781f45d1e45406d396b43b06f.png)

校验失败时可以把精简后的错误信息反馈给模型并重试一次，但要限制次数。连续失败应进入确定性降级路径，例如返回默认结构、切换人工确认、重新询问用户，或把原始文本交给专门的修复流程。不能无限调用模型，也不应该用正则表达式从任意文本中“抠出”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 展示核心链路。模型名称通过配置传入，避免把实现绑定到某个固定版本。

```ts
import OpenAI from "openai";
import { zodTextFormat } from "openai/helpers/zod";
import { z } from "zod";

const client = new OpenAI();

// 模型侧负责满足这份传输结构。
const OrderSchema = z.object({
  orderId: z.string().min(1),
  action: z.enum(["refund", "exchange", "consult"]),
  reason: z.string().min(1),
  confidence: z.number().min(0).max(1),
});

type OrderIntent = z.infer<typeof OrderSchema>;

async function extractOrderIntent(text: string): Promise<OrderIntent> {
  let validationFeedback = "";

  for (let attempt = 1; attempt <= 2; attempt++) {
    const response = await client.responses.parse({
      model: process.env.LLM_MODEL!,
      input: [
        {
          role: "system",
          content: "提取售后意图。不要猜测不存在的订单号。",
        },
        {
          role: "user",
          content: `${text}${validationFeedback}`,
        },
      ],
      text: {
        format: zodTextFormat(OrderSchema, "order_intent"),
      },
    });

    const value = response.output_parsed;
    if (!value) {
      validationFeedback = "\n上次发生拒答、截断或解析失败，请重新提取。";
      continue;
    }

    // Schema 正确不代表业务正确，订单必须真实存在。
    if (await orderExists(value.orderId)) return value;

    validationFeedback = "\n上次 orderId 不存在，不要编造；无法确定时应请求补充信息。";
  }

  throw new Error("STRUCTURED_OUTPUT_UNAVAILABLE");
}

declare function orderExists(orderId: string): Promise<boolean>;
```

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

代码没有在拿到 `output_parsed` 后立刻返回，而是继续查询订单是否存在。这一层验证不能只靠 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 升级回归。结构化输出解决的是接口契约问题，不解决事实正确性和业务安全问题。

### 面试官追问
1. JSON mode 和 Structured Outputs 的本质区别是什么？
2. 为什么已经设置 `strict`，应用侧仍然需要校验？
3. `additionalProperties: false` 解决什么问题？
4. 流式输出 JSON 时，前端应该什么时候开始解析？
5. Schema 很复杂时，为什么成功率和维护成本可能变差？
6. Function Calling 的参数符合 Schema，是否就可以直接执行退款？
7. 模型输出被 token 上限截断时如何识别和处理？
8. 如何评估更换模型后结构化输出是否发生回归？

### 高分回答要点
- 明确区分语法合法、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 官方指南](https://developers.openai.com/api/docs/guides/structured-outputs)
- [JSON Schema 对象与 required、additionalProperties](https://json-schema.org/understanding-json-schema/reference/object)

能否区分“看起来像 JSON”“语法合法”“符合 JSON Schema”和“满足业务规则”这四个层次

2026AI面试题-怎么让模型严格输出 JSON？为什么只靠 Prompt 不可靠？

前端

人工智能

建立分层校验机制：模型输出需依次通过语法解析、Schema结构校验及业务规则验证。优先采用StructuredOutputs约束字段类型与枚举，应用侧继续执行跨字段及外部数据校验。有限重试后将错误反馈模型，连续失败则降级处理。监控Schema通过率、业务校验通过率、重试率及降级率四项核心指标。

回归测试

代码解释

TypeScript 

数据库

Markdown

JSON

2026上云采购 | AI焕新·智启新局

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

2026AI面试题-怎么让模型严格输出 JSON？为什么只靠 Prompt 不可靠？-腾讯云开发者社区-腾讯云

2026AI面试题-怎么让模型严格输出 JSON？为什么只靠 Prompt 不可靠？

2026AI面试题-怎么让模型严格输出 JSON？为什么只靠 Prompt 不可靠？

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐