这次我们来看一个在 AI 应用开发中非常实际的问题：如何让大模型稳定、可靠地输出 JSON 格式的数据。无论是构建 AI Agent、开发自动化工具，还是处理结构化数据，JSON 都是系统间通信的“标准语言”。然而，直接让大模型生成 JSON，开发者常常会遇到格式错误、字段缺失、内容幻觉等问题，导致下游流程崩溃。

这篇文章不讨论复杂的学术概念，而是聚焦于一套可落地的工程化解决方案。我们将从问题根源出发，拆解几种主流且经过验证的稳定输出 JSON 的方法，包括提示词工程、函数调用、输出约束框架以及后处理校验。无论你是在准备大模型相关的面试，还是在开发需要稳定 JSON 接口的 AI Agent，这篇文章提供的思路和代码都能直接拿来用。

1. 核心能力速览：JSON 稳定输出方案对比

在深入细节之前，我们先通过一个表格快速了解几种主流方案的核心特点、适用场景和潜在成本，帮助你快速决策。

对于大多数应用，“提示词工程 + 后处理校验”是性价比最高的起点。如果追求极致稳定且能控制推理后端，输出约束框架是最佳选择。基于云服务开发，则首选函数调用。

2. 问题根源：为什么大模型输出 JSON 不稳定？

在寻找解决方案前，必须理解问题从何而来。大模型本质上是基于概率生成文本的“续写机器”，它并不内置 JSON 语法解析器。不稳定输出通常源于以下几点：

1. 训练数据偏差：模型在训练时接触的 JSON 数据可能格式不一，或与非 JSON 文本混杂，导致其对“完美 JSON”的认知不精确。
2. 采样随机性：即使 Temperature 设为 0，生成过程仍可能存在细微波动，一个多余的逗号、缺失的引号都可能导致解析失败。
3. 复杂结构挑战：当要求生成嵌套深、字段多的复杂 JSON 时，模型可能在生成中途“忘记”结构，或产生矛盾的字段值。
4. 指令遵循能力：模型是否能严格遵循“输出必须是 JSON”这条指令，取决于其本身的指令遵循能力和提示词设计的有效性。
5. 上下文长度限制：在长对话中，详细的 JSON Schema 可能会占用大量上下文窗口，影响模型对核心任务的关注。

因此，我们的所有技术手段都围绕一个核心目标：降低模型生成过程中的不确定性，并将格式校验的责任从模型部分或全部地转移到系统层面。

3. 环境准备与前置条件

本文将使用 Python 作为演示语言，并提供兼容 OpenAI API 格式的示例。你可以根据自己使用的模型服务进行调整。

基础环境：

• Python 版本：建议 3.8 及以上。
• 包管理工具：pip。
• 核心库：requests,json,pydantic(用于结构化输出方案)，openai(官方库或兼容库)。

模型服务准备：你需要一个能够提供文本生成服务的大模型 API 端点。这可以是：

• 云服务：OpenAI GPT, Anthropic Claude, 国内各大平台的 API。
• 本地模型：通过ollama,vLLM,llama.cpp,text-generation-webui等框架部署的模型，并暴露兼容 OpenAI 的 API 接口。
• 测试用 API Key：确保你有对应服务的有效 API Key 或本地服务访问权限。

安装基础依赖：

# 安装基础请求和 JSON 处理库 pip install requests # 如果你打算使用 OpenAI 官方库或兼容库 pip install openai # 如果你打算使用 Pydantic 进行结构化输出（方案四） pip install pydantic instructor

instructor库封装了与模型交互的复杂逻辑，是实现结构化输出的利器。

4. 方案一：强化提示词工程

这是最直接的方法，通过精心设计的系统提示词（System Prompt）和用户提示词（User Prompt）来引导模型。

核心思路：

1. 在系统提示词中明确角色和输出格式要求。
2. 在用户提示词中提供清晰、无歧义的任务描述。
3. 提供 JSON Schema 示例（Few-shot Learning），这是大幅提升稳定性的关键。

操作步骤：

1. 定义你的 JSON Schema：首先明确你希望模型输出的数据结构。

   // 例如，我们希望模型分析用户评论的情感并提取实体 { "sentiment": "positive", // 或 "negative", "neutral" "confidence": 0.95, "entities": [ {"name": "iPhone 15", "type": "PRODUCT"}, {"name": "battery life", "type": "FEATURE"} ], "summary": "用户对iPhone 15的电池续航表示满意。" }

2. 构建系统提示词：

   system_prompt = """ 你是一个精准的JSON数据生成器。你必须严格遵循以下规则： 1. 你的所有输出必须是**且仅是**一个合法的JSON对象。 2. 不要输出任何JSON之外的解释、道歉、前缀或后缀文本（如```json```标记）。 3. JSON必须完全符合下面提供的“输出格式示例”的结构和字段类型。 输出格式示例： { "sentiment": "positive", "confidence": 0.95, "entities": [ {"name": "示例产品", "type": "PRODUCT"}, {"name": "示例特性", "type": "FEATURE"} ], "summary": "这是一个示例总结。" } """

3. 构建用户提示词：

   user_prompt = """ 请分析以下用户评论，并生成符合上述格式的JSON。 评论：`iPhone 15的电池续航真的太棒了，一天一充完全没问题，就是价格有点贵。` """

4. 调用模型 API：

   import openai import json client = openai.OpenAI(api_key="your-api-key", base_url="https://api.openai.com/v1") # 本地模型则替换base_url response = client.chat.completions.create( model="gpt-3.5-turbo", # 或你的模型名称 messages=[ {"role": "system", "content": system_prompt}, {"role": "user", "content": user_prompt} ], temperature=0.1, # 低温度提高确定性 max_tokens=500 ) raw_output = response.choices[0].message.content.strip() print("模型原始输出：", raw_output) # 尝试解析 try: result = json.loads(raw_output) print("解析成功：", json.dumps(result, indent=2, ensure_ascii=False)) except json.JSONDecodeError as e: print(f"JSON解析失败！错误：{e}") print("原始文本需要后处理。")

效果验证与排查：

• 成功：json.loads()能成功解析，并且数据结构符合预期。
• 常见失败：
  • 输出包含 Markdown 代码块：如 ````json ... ```，需要在解析前用字符串方法（如.strip(‘’)`）去除。
  • 输出前有思考链：如“好的，我将分析...”，模型没有严格遵守指令。需要强化系统提示词，或换用指令遵循能力更强的模型。
  • 字段类型错误：confidence输出了字符串“0.95”而非数字。可以在 Schema 示例中明确注释类型，或在后处理中转换。

5. 方案二：利用函数调用 (Function Calling)

这是 OpenAI、Claude 等主流API提供的原生稳定方案。模型不直接输出JSON，而是输出一个“调用函数”的请求，其中参数必然是合规的JSON。

核心思路：

1. 将你期望的 JSON 结构定义为一个“函数”（Function）的参数（Parameters）。
2. 在 API 调用时，将函数定义传给模型。
3. 模型返回一个包含function_call属性的消息，其中arguments就是格式正确的 JSON 字符串。

操作步骤：

1. 定义函数工具（Tools）：

   tools = [ { "type": "function", "function": { "name": "extract_sentiment_and_entities", "description": "从用户评论中提取情感、置信度、实体和总结。", "parameters": { "type": "object", "properties": { "sentiment": { "type": "string", "enum": ["positive", "negative", "neutral"], "description": "评论的情感倾向" }, "confidence": { "type": "number", "description": "情感判断的置信度，0-1之间" }, "entities": { "type": "array", "items": { "type": "object", "properties": { "name": {"type": "string"}, "type": {"type": "string", "enum": ["PRODUCT", "FEATURE", "PERSON", "LOCATION"]} }, "required": ["name", "type"] }, "description": "评论中提到的实体列表" }, "summary": { "type": "string", "description": "对评论的简短总结" } }, "required": ["sentiment", "confidence", "entities", "summary"] } } } ]

   这里使用 JSON Schema 严格定义了参数结构。

2. 调用模型 API（OpenAI 格式示例）：

   response = client.chat.completions.create( model="gpt-3.5-turbo", messages=[ {"role": "user", "content": "分析评论：iPhone 15的电池续航真的太棒了，一天一充完全没问题，就是价格有点贵。"} ], tools=tools, tool_choice={"type": "function", "function": {"name": "extract_sentiment_and_entities"}}, # 强制调用特定函数 temperature=0 ) # 提取函数调用参数 tool_call = response.choices[0].message.tool_calls[0] function_name = tool_call.function.name arguments_str = tool_call.function.arguments # 这就是稳定的JSON字符串 print("函数名：", function_name) print("参数字符串：", arguments_str) # 解析JSON result = json.loads(arguments_str) print("解析结果：", json.dumps(result, indent=2, ensure_ascii=False))

效果验证与排查：

• 成功：response.choices[0].message.tool_calls不为空，且arguments能成功解析为 JSON。
• 优势：格式稳定性由 API 平台保障，几乎不会出现语法错误。是构建多步骤 Agent（模型选择工具->调用工具->获得结果）的标准方式。
• 限制：完全依赖于云服务商对该功能的支持。本地部署的模型若未暴露tool_calls接口，则无法使用此方法。

6. 方案三：使用输出约束框架 (Grammar/Constrained Decoding)

这是本地部署场景下的“终极解决方案”。它在模型生成文本的每个步骤，都通过一个预定义的语法（如 JSON 语法）来限制下一个可生成的 Token，从而保证输出完全符合语法规范。

核心思路：

1. 使用支持 Constrained Decoding 或 Grammar 的推理服务器，如llama.cpp(通过grammar参数)、vLLM(通过guided_json或guided_regex等)。
2. 定义一个描述目标 JSON 结构的语法文件（通常是 GBNF 格式）。
3. 在 API 请求中传入该语法，服务器会在生成时强制执行。

操作步骤（以 llama.cpp 的 server 为例）：

1. 准备 GBNF 语法文件(json_schema.gbnf)：

   root ::= object value ::= object | array | string | number | "true" | "false" | "null" object ::= "{" ws (string ":" ws value ("," ws string ":" ws value)*)? "}" array ::= "[" ws (value ("," ws value)*)? "]" string ::= "\"" ([^"\\] | "\\" (["\\/bfnrt] | "u" [0-9a-fA-F] [0-9a-fA-F] [0-9a-fA-F] [0-9a-fA-F]))* "\"" number ::= ("-"? ([0-9] | [1-9] [0-9]*)) ("." [0-9]+)? ([eE] [-+]? [0-9]+)? ws ::= [ \t\n]*

   这是一个标准的 JSON 语法。你还可以定义更具体的语法，只允许生成你想要的特定结构。

2. 启动 llama.cpp 服务器(确保支持grammar参数)：

   ./server -m your-model.gguf -c 2048 --grammar-file json_schema.gbnf

3. 发送带有 grammar 的 API 请求：

   import requests import json # 假设 llama.cpp server 运行在本地 8080 端口 url = "http://localhost:8080/completion" payload = { "prompt": "分析以下评论，输出一个JSON，包含'sentiment'（positive/negative/neutral）、'confidence'（0-1小数）、'summary'（总结字符串）三个字段。评论：iPhone 15的电池续航真的太棒了。\nAssistant:", "temperature": 0.1, "max_tokens": 200, "grammar": "你的 GBNF 语法字符串，或从文件读取", # 或者使用 `grammar_file` 参数 "stop": ["\n", "Human:", "User:"] # 停止词 } response = requests.post(url, json=payload) result = response.json() generated_text = result["content"].strip() print("受语法约束的输出：", generated_text) # 此时 generated_text 几乎可以确定是合法 JSON parsed_json = json.loads(generated_text)

效果验证与排查：

• 成功：输出能被json.loads()解析，且结构符合语法定义。
• 优势：格式正确率极高，从根源上杜绝了语法错误。性能开销小。
• 挑战：
  • 配置复杂：需要搭建支持该特性的推理服务器。
  • 灵活性：过于严格的语法可能限制模型的内容表达能力。需要在“格式正确”和“内容灵活”间权衡。
  • 服务端支持：并非所有推理框架都支持此功能。

7. 方案四：采用结构化输出库 (Pydantic + Instructor)

这个方案将开发者从手动解析和校验 JSON 的繁琐工作中解放出来。它利用 Python 的类型提示和 Pydantic 的数据验证，由instructor这样的库负责与模型通信，并自动将模型的响应转换为类型安全的 Python 对象。

核心思路：

1. 用 Pydantic 的BaseModel定义你期望的数据结构。
2. 使用instructor库“修补” OpenAI 客户端，使其支持从对话中提取结构化数据。
3. 像调用普通函数一样调用模型，直接得到结构化的对象。

操作步骤：

1. 安装库并定义模型：

   import instructor from pydantic import BaseModel, Field from typing import List # 使用 instructor 修补客户端 client = instructor.patch(openai.OpenAI(api_key="your-api-key")) # 用 Pydantic 定义数据结构 class Entity(BaseModel): name: str = Field(..., description="实体的名称") type: str = Field(..., description="实体类型，如 PRODUCT, FEATURE") class SentimentAnalysis(BaseModel): sentiment: str = Field(..., description="情感倾向", enum=["positive", "negative", "neutral"]) confidence: float = Field(..., ge=0, le=1, description="置信度") entities: List[Entity] = Field(default_factory=list, description="识别出的实体列表") summary: str = Field(..., description="评论总结")

2. 调用模型获取结构化对象：

   analysis: SentimentAnalysis = client.chat.completions.create( model="gpt-3.5-turbo", response_model=SentimentAnalysis, # 关键参数：指定返回的模型 messages=[ {"role": "user", "content": "分析评论：iPhone 15的电池续航真的太棒了，一天一充完全没问题，就是价格有点贵。"} ], max_retries=2, # instructor 会自动在解析失败时重试 ) # 直接使用对象！ print(f"情感: {analysis.sentiment}") print(f"置信度: {analysis.confidence}") for entity in analysis.entities: print(f"实体: {entity.name} - {entity.type}") print(f"总结: {analysis.summary}") # 也可以轻松转为字典或JSON print(analysis.model_dump_json(indent=2, ensure_ascii=False))

效果验证与排查：

• 成功：函数调用直接返回一个SentimentAnalysis类型的对象，无需手动解析 JSON。如果模型输出不符合 Pydantic 模型定义，instructor会在后台尝试修复或重试（取决于max_retries设置）。
• 优势：
  • 开发体验极佳：类型安全，IDE 自动补全。
  • 自动验证与修复：库自动处理格式错误和类型转换。
  • 与 FastAPI 等框架无缝集成：可以直接用 Pydantic 模型做请求/响应模型。
• 注意：instructor在底层可能通过多次调用模型或后处理来实现结构化，可能会增加延迟和 token 消耗。但它提供了最鲁棒的开发者体验。

8. 方案五：构建后处理与重试的安全网

无论采用哪种方案，一个健壮的系统都应该包含后处理层作为最后的安全网。其核心是：尝试解析 -> 失败则修复 -> 再解析。

操作步骤：

1. 基础解析与清洗：

   import json import re def safe_json_parse(raw_text: str, max_attempts: int = 2): """ 尝试解析JSON，失败时尝试清洗常见格式问题。 """ text = raw_text.strip() # 尝试1：直接解析 for attempt in range(max_attempts): try: return json.loads(text), f"直接解析成功 (尝试 {attempt+1})" except json.JSONDecodeError as e: if attempt == max_attempts - 1: # 最后一次尝试也失败，进入修复流程 break # 简单清洗：去除可能包裹的markdown代码块 text = text.strip('`').strip() if text.startswith('json'): text = text[4:].strip() # 尝试2：使用LLM进行修复（轻量级） repaired_text = repair_json_with_llm(text) # 假设有这个函数 try: return json.loads(repaired_text), "经LLM修复后解析成功" except json.JSONDecodeError: pass # 尝试3：暴力提取（最后手段） match = re.search(r'\{.*\}', text, re.DOTALL) if match: try: return json.loads(match.group()), "通过正则提取后解析成功" except json.JSONDecodeError: pass # 所有尝试都失败 raise ValueError(f"无法从文本中解析出有效JSON。原始文本开头：{text[:200]}") def repair_json_with_llm(bad_json_str: str) -> str: """调用一个快速、廉价的模型（如 gpt-3.5-turbo）来修复JSON。""" # 实现略：构造一个提示词，要求模型只输出修正后的JSON。 pass

2. 集成到主流程：

   # 假设你从模型得到了 raw_output raw_output = response.choices[0].message.content try: data, parse_method = safe_json_parse(raw_output) print(f"解析成功！方法：{parse_method}") print(json.dumps(data, indent=2, ensure_ascii=False)) except ValueError as e: print(f"解析最终失败：{e}") # 触发降级逻辑，如记录日志、使用默认值、请求人工干预等

效果验证与排查：

• 成功：最终能获得一个可用的 Python 字典或列表。
• 设计要点：
  • 分层修复：先尝试低成本清洗（去除标记、空白），再使用成本较高的 LLM 修复。
  • 设置重试上限：避免无限循环。
  • 降级策略：当所有修复都失败时，必须有明确的降级方案（如返回错误、使用空结构、触发告警）。

9. 资源占用与性能观察

不同的方案对资源和性能的影响不同：

• 提示词工程：几乎没有额外开销。但可能因输出格式错误导致下游处理失败，间接增加整体延迟。
• 函数调用：云 API 通常对 Function Calling 有微小溢价，但避免了后续的解析和重试开销，整体链路更稳定高效。
• 输出约束框架：在推理时施加语法约束，有极小的计算开销（通常<5%），但换来了近乎 100% 的格式正确率，对于高吞吐量服务，总体 TCO（总拥有成本）可能更低。
• 结构化输出库：如instructor，可能因自动重试和修复机制导致额外的 API 调用，增加 token 消耗和延迟。但在开发效率和系统鲁棒性上收益巨大。
• 后处理与重试：增加本地 CPU 计算（用于解析、正则匹配）和可能的额外 LLM 调用开销。应将其视为“保险”，成本应控制在主流程的较小比例内。

监控建议：

1. JSON 解析成功率：监控json.loads()的成功率，这是最直接的指标。
2. 重试率：如果使用了重试机制，监控重试发生的频率。
3. 端到端延迟：比较不同方案下，从发送请求到获得可用结构化数据的整体延迟。
4. Token 消耗：对比不同方案下单次请求消耗的 Prompt Tokens 和 Completion Tokens。

10. 常见问题与排查方法

11. 最佳实践与使用建议

1. 从简到繁：首先用提示词工程+后处理验证可行性。如果格式错误率<5%，通常已足够。如果错误率高，再考虑更复杂的方案。
2. 选择合适的模型：指令遵循能力强、在代码或结构化数据上训练过的模型（如 GPT-4, Claude 3, DeepSeek-Coder, Qwen2.5-Coder）在输出 JSON 上表现更好。
3. 提供高质量示例：在提示词中提供 1-2 个精准的输入-输出对（Few-shot），比千言万语的规定都有效。
4. 温度（Temperature）设置：生成 JSON 时，将temperature设为较低值（如 0.1 或 0），以降低随机性。
5. 为生产环境设计降级方案：即使使用了函数调用或 Grammar，网络、服务也可能出错。你的代码应该能处理解析失败的情况，例如记录日志、返回友好错误、使用缓存值或触发人工审核流程。
6. 关注安全与合规：当模型生成的 JSON 内容来自不可控的用户输入时（如情感分析、实体提取），务必对输出内容进行安全检查，防止注入攻击或不当内容。
7. 性能测试：在决定采用某种方案前，用你的实际数据和流量进行压力测试，评估其解析成功率、延迟和成本。

稳定输出 JSON 不是单一技巧，而是一个系统工程。从清晰的提示词定义，到利用平台的高级功能（函数调用），再到本地部署的硬约束（Grammar），最后辅以自动化的后处理校验，层层递进，才能构建出真正可靠的 AI 数据管道。对于面试官而言，能系统性地阐述这几种方案及其选型考量，远比死记硬背某个 API 参数更有价值。在实际开发中，根据你的团队技术栈、模型部署方式和性能要求，选择一到两种方案组合使用，就能解决绝大多数大模型输出不稳定的痛点。