结构化输出 Prompt 应该怎么写？如何让模型稳定输出 JSON？
这是一道综合深度题，面试官想看你对 AI 模型输出控制的理解有多深。核心考三个点：三层约束机制的区别、Schema 设计原则、工程化落地策略。
为什么纯 Prompt 要求 JSON 不够可靠？
模型本质上是个"文本生成器"，它生成的是字符串，不是 JSON 对象。你让它"输出 JSON"，它可能真的给你一段 JSON，但也可能在前面加一句"好的，这是你要的 JSON"，或者把字段名搞成中文，或者少个逗号。
五类常见问题：
- 格式漂移 — 明明要的是 JSON，它给你加个代码块包裹
- 字段缺失 — 少则少矣，结构不完整
- 类型错误 — 布尔值给你转成字符串 "true"
- 额外解释文本 — JSON 前后夹杂说明文字
- 边界条件崩溃 — 遇到特殊情况直接"创意发挥"
想象你让助理写报告，他可能在前面加个"好的老板，以下是报告"，然后把格式搞得五花八门。这就是纯 Prompt 的问题——模型是听话的，但它会"自由发挥"。
三层约束机制的核心区别
别被名字搞晕，核心就一句话：约束能力逐层递增。
第一层：JSON Mode
这是最弱的约束。模型只是"尽量"输出合法的 JSON 语法，但不保证包含什么字段。这个模式告诉你"用 Word 写"，但没告诉你"写什么格式"。
第二层：JSON Schema
给你一个结构模板，描述字段名、类型、是否必填。但这只是"描述"，模型可以不完全遵守——就像你给助理一个文档模板，他可能觉得模板太死板，自己改改。
第三层：Structured Outputs
这是真正的约束，模型输出严格贴合 Schema，不敢越雷池一步。好比直接在 Word 里锁定格式，助理只能填空，改不了样式。
| 特性 | JSON Mode | JSON Schema | Structured Outputs |
|---|---|---|---|
| 语法合法性 | ✅ 保证 | ❌ 不保证 | ✅ 保证 |
| 字段完整性 | ❌ 不保证 | ⚠️ 描述但不执行 | ✅ 保证 |
| 外部调用 | ❌ 不负责 | ❌ 不负责 | ❌ 不负责 |
还有个容易混淆的概念：Function Calling
它和 Structured Outputs 长得像，但本质不同。Function Calling 生成的是"调用意图"——模型告诉你该调用哪个工具、传什么参数，然后你在业务侧执行这个调用，把结果再喂给模型。Structured Outputs 是直接输出数据让你消费，Function Calling 是生成调用指令让系统执行。
Schema 设计的核心原则
Schema 是后端 DTO 和模型之间的契约，写清楚了才不会"鸡同鸭讲"。记住这几个原则：
一个字段只表达一件事
字段名要见名知意，别搞个 user_info 塞一堆东西进去。分开定义，职责清晰。
字段说明写清楚"何时用何时不用"
{
"nickname": {
"type": "string",
"description": "用户的昵称，如果用户没有设置则为空字符串"
}
}这样模型就知道什么时候该填、什么时候该空着。
枚举优先于自由文本
能用枚举就别让模型自由发挥。模型写"优秀"你期望的是"excellent"，这种类型错误太常见了。
必填字段谨慎使用
别看到字段就加 required。有些字段是可选的，硬性要求只会让模型在边界情况下崩溃。
Schema 要有版本号
{
"version": "1.0.0",
"fields": { ... }
}防止契约被悄悄破坏，出了问题好追溯。
生产环境的工程化策略
即使用了 Structured Outputs，也要像防御性驾驶一样做好防护。
校验失败要带错误信息重试
模型可能突然抽风，返回格式不对。重试时把错误信息一并带过去，让模型知道自己哪里错了。
必要时降级处理
重试三次还失败？别死等。降级到兜底方案，比如返回默认结构或标记异常状态。
始终保留服务端校验
模型输出是外部输入，你不知道它什么时候会变。服务端校验是最后一道防线，别省掉。
工具调用要校验权限和归属
Function Calling 生成的参数可能被污染。调用前检查这个操作是否有权限、参数归属是否正确。
输入 → Schema 校验 → 失败重试/降级 → 成功处理 → 返回结果
面试怎么答
基础版（能过的回答）
面试官问怎么让模型稳定输出 JSON，我会从三个层面回答：
第一层是约束机制。纯 Prompt 要求 JSON 不可靠，因为模型输出的是文本。JSON Mode 只保证语法合法，JSON Schema 描述结构但不强制执行，Structured Outputs 才是真正约束输出贴合 Schema。Function Calling 本质是生成调用意图，不是直接返回数据。
第二层是 Schema 设计。字段要单一职责、字段说明写清楚何时用何时不用、枚举优先于自由文本、必填字段谨慎使用、Schema 要有版本号。
第三层是工程落地。校验失败要带错误信息重试、必要时降级处理、始终保留服务端校验。
加分版（让面试官眼前一亮）
在基础回答之上，我会补充几点：
国产模型这块，DeepSeek-V3/R1 支持 strict 模式，效果接近官方 Structured Outputs。Moonshot 目前建议用 json_object 模式。
JSON Schema 有个局限性要清楚：它只描述不执行，不同供应商支持度也不一样，不要把它当成灵丹妙药。
Schema 契约意识很重要。我会把它当作后端 DTO 和模型之间的协议，设计时考虑字段的原子性和向后兼容性。
一句话总结
结构化输出的本质是逐层加约束：Prompt 是建议、JSON Mode 是语法约束、JSON Schema 是结构约束、Structured Outputs 是严格约束——工程落地时要做好校验和降级，防御性编程永不过时。