结构化输出 Prompt 应该怎么写？如何让模型稳定输出 JSON？

博主简介你好我是安逸CSDN「人工智能技术领域新星创作者」码龄 6 年。博客总访问量 31万博客粉丝 1.2万。我长期关注人工智能技术与工程实践主要研究和分享 AI Agent、RAG 系统、MCP 协议、OpenClaw、AI 编程工具以及大模型工程化落地。同时也持续输出 Java / Spring、Transformer、机器学习、深度学习与计算机视觉等方向的学习笔记和项目经验。 推荐系列合集目前已经整理了 生产级 RAG 系统实战、Agent 记忆系统、MCP 协议深度解析、OpenClaw 系列、Hermes Agent Obsidian、图解机器学习、Claude Code 系列和 Agent 经典面试题等系列合集涵盖 AI 应用开发、智能体实践、知识管理、机器学习与 AI 编程工具。GZH安逸Ai (科技前沿新闻Github热门项目最新免费资料...)网页观看完整系列合集 Anyi AI 学习资源站这是一道综合深度题面试官想看你对 AI 模型输出控制的理解有多深。核心考三个点三层约束机制的区别、Schema 设计原则、工程化落地策略。为什么纯 Prompt 要求 JSON 不够可靠模型本质上是个文本生成器它生成的是字符串不是 JSON 对象。你让它输出 JSON它可能真的给你一段 JSON但也可能在前面加一句好的这是你要的 JSON或者把字段名搞成中文或者少个逗号。五类常见问题格式漂移— 明明要的是 JSON它给你加个代码块包裹字段缺失— 少则少矣结构不完整类型错误— 布尔值给你转成字符串 true额外解释文本— JSON 前后夹杂说明文字边界条件崩溃— 遇到特殊情况直接创意发挥想象你让助理写报告他可能在前面加个好的老板以下是报告然后把格式搞得五花八门。这就是纯 Prompt 的问题——模型是听话的但它会自由发挥。五类工程问题示意图格式漂移、字段缺失、类型错误、额外文本、边界崩溃三层约束机制的核心区别别被名字搞晕核心就一句话约束能力逐层递增。第一层JSON Mode这是最弱的约束。模型只是尽量输出合法的 JSON 语法但不保证包含什么字段。这个模式告诉你用 Word 写但没告诉你写什么格式。第二层JSON Schema给你一个结构模板描述字段名、类型、是否必填。但这只是描述模型可以不完全遵守——就像你给助理一个文档模板他可能觉得模板太死板自己改改。第三层Structured Outputs这是真正的约束模型输出严格贴合 Schema不敢越雷池一步。好比直接在 Word 里锁定格式助理只能填空改不了样式。特性JSON ModeJSON SchemaStructured Outputs语法合法性✅ 保证❌ 不保证✅ 保证字段完整性❌ 不保证⚠️ 描述但不执行✅ 保证外部调用❌ 不负责❌ 不负责❌ 不负责三层约束机制对比图JSON Mode / JSON Schema / Structured Outputs 约束能力对比还有个容易混淆的概念Function Calling它和 Structured Outputs 长得像但本质不同。Function Calling 生成的是调用意图——模型告诉你该调用哪个工具、传什么参数然后你在业务侧执行这个调用把结果再喂给模型。Structured Outputs 是直接输出数据让你消费Function Calling 是生成调用指令让系统执行。Function Calling 流程图模型生成工具名参数 → 业务侧执行 → 结果回填模型Schema 设计的核心原则Schema 是后端 DTO 和模型之间的契约写清楚了才不会鸡同鸭讲。记住这几个原则一个字段只表达一件事字段名要见名知意别搞个user_info塞一堆东西进去。分开定义职责清晰。字段说明写清楚何时用何时不用{ nickname: { type: string, description: 用户的昵称如果用户没有设置则为空字符串 } }这样模型就知道什么时候该填、什么时候该空着。枚举优先于自由文本能用枚举就别让模型自由发挥。模型写优秀你期望的是excellent这种类型错误太常见了。必填字段谨慎使用别看到字段就加required。有些字段是可选的硬性要求只会让模型在边界情况下崩溃。Schema 要有版本号{ version: 1.0.0, fields: { ... } }防止契约被悄悄破坏出了问题好追溯。Schema 设计原则图字段单一职责、枚举使用、required 处理、nullable 处理、version 字段的最佳实践示例生产环境的工程化策略即使用了 Structured Outputs也要像防御性驾驶一样做好防护。校验失败要带错误信息重试模型可能突然抽风返回格式不对。重试时把错误信息一并带过去让模型知道自己哪里错了。必要时降级处理重试三次还失败别死等。降级到兜底方案比如返回默认结构或标记异常状态。始终保留服务端校验模型输出是外部输入你不知道它什么时候会变。服务端校验是最后一道防线别省掉。工具调用要校验权限和归属Function Calling 生成的参数可能被污染。调用前检查这个操作是否有权限、参数归属是否正确。输入 → Schema 校验 → 失败重试/降级 → 成功处理 → 返回结果工程化落地流程图输入→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 是严格约束——工程落地时要做好校验和降级防御性编程永不过时。