大模型稳定输出JSON的工程化实践：从提示词到容错机制

你有没有遇到过这种情况：想让大模型帮你生成一段结构化的数据，比如一个用户信息列表、一个配置项数组，或者一个标准的API响应，结果它给你返回了一堆看似正确、实则格式混乱的文本？你满怀期待地复制粘贴，准备解析，结果JSON.parse()直接抛出一个Unexpected token错误，让你瞬间从自动化美梦中惊醒。

这几乎是每个尝试用大模型处理结构化输出的开发者都会踩的第一个坑。你可能会想，不就是生成个JSON吗，大模型这么聪明，按格式写不就行了？但现实是，大模型的“聪明”恰恰是问题的根源——它太擅长“理解”和“自由发挥”了，以至于常常在格式的严谨性上“不拘小节”。一个多余的空格、一个缺失的引号、一句解释性的旁白，都能让整个自动化流程崩溃。

今天要聊的，就是如何让大模型稳定、可靠地输出我们想要的JSON格式。这远不止是写一个“请输出JSON”的提示词那么简单。它涉及到对模型行为的理解、对提示工程的精细控制，以及一套从验证到容错的完整工程化思路。这不仅是面试中常被问到的“八股文”考点，更是构建可靠AI Agent、实现业务流程自动化的基石。

1. 为什么生成标准JSON对大模型来说是个“难题”？

在深入解决方案之前，我们得先理解问题的本质。大模型输出JSON不稳定，不是因为它“笨”，而是由它的工作原理和我们与它的交互方式共同决定的。

1.1 大模型的核心是“续写”，不是“编译器”

大语言模型（LLM）的本质是一个基于概率的文本生成器。它的训练目标是，给定一段上文（上下文），预测下一个最可能的词（Token）。它被海量的互联网文本训练，其中包含了无数种JSON的写法、错误的JSON片段、讨论JSON的教程、以及夹杂着JSON的代码和日志。

当你要求它“输出一个用户列表的JSON”时，模型并不是在调用一个名为generate_json()的函数。它是在基于你的提示词，以及它从训练数据中学到的模式，进行“续写”。它“知道”JSON通常以{或[开头，以}或]结尾，中间有键值对。但它对“严格符合RFC 7159标准”没有强制性的概念。它可能会：

• 添加注释：像写代码一样，在JSON里加上// 这是一个用户对象。
• 使用单引号：因为它在很多JavaScript代码片段里见过{'name': 'John'}。
• 缺失尾逗号：在最后一个元素后不加逗号是对的，但它有时会在数组或对象中间漏掉逗号。
• 键名不加引号：写成了{name: "John"}，这在JavaScript对象中合法，但在JSON中不合法。
• 输出解释文本：在JSON前后加上“好的，这是你要的JSON：”和“以上是生成结果”。

这些输出，对人类来说一眼就能看懂并手动修正，但对JSON.parse()这样的程序来说，就是无法识别的非法字符串。

1.2 我们给的指令，在模型看来可能很“模糊”

“生成一个JSON”这个指令，包含了多层隐含的、但模型可能无法全部捕捉的要求：

1. 格式要求：必须是纯的、有效的JSON字符串。
2. 内容要求：必须包含你指定的字段和信息。
3. 边界要求：除了JSON，不要输出任何其他文本。

人类能轻松理解这三层，但模型可能只专注于最核心的“内容要求”，而忽略了严格的“格式”和“边界”要求。特别是当提示词比较复杂，或者要求模型进行多步推理时，它更容易把格式要求抛在脑后。

1.3 追求稳定，本质上是与模型的“创造性”做斗争

我们使用大模型，往往是看中它的理解和生成能力。但在输出JSON这个场景下，我们恰恰需要压制它的一部分“创造性”和“灵活性”，让它像一个严格的模板引擎一样工作。这是一个有趣的矛盾：我们既要用它的智能来理解复杂需求并填充内容，又要约束它的输出形式达到机器可读的精确度。

理解了这些，我们就能明白，解决方案不能只靠一句更“凶”的提示词，而需要一套组合策略。

2. 第一层控制：编写“强硬而精确”的提示词

提示词是与模型沟通的第一道关口。一个模糊的请求只会得到模糊的回应。我们的目标是让提示词尽可能消除歧义。

2.1 基础版：明确指令与格式示范

不要只说“输出JSON”。要规定细节。

请生成一个包含三个用户信息的列表，以JSON数组格式输出。要求： 1. 每个用户是一个对象，包含 `id` (整数)、`name` (字符串)、`email` (字符串) 和 `active` (布尔值) 字段。 2. 确保输出是 **一个完整且有效的JSON字符串**，可以被标准的JSON解析器直接解析。 3. 除了这个JSON字符串外，**不要输出任何其他内容**，包括解释、注释、Markdown代码块标记或前言后语。

关键点分析：

• 结构化要求：明确列出了字段名和类型，减少了模型自由发挥的空间。
• 有效性强调：直接点明“完整且有效”、“可直接解析”，强化了格式目标。
• 边界锁定：“不要输出任何其他内容”是关键，直接堵住了模型添加额外文本的倾向。

2.2 进阶版：提供结构化模板（Schema）

对于更复杂的结构，直接给出一个JSON Schema或示例模板，效果极佳。这利用了模型的上下文学习（In-Context Learning）能力。

请根据以下对话内容，提取关键信息并填充到下面的JSON模板中。 对话： [用户与客服的对话文本...] JSON模板： { "intent": "string， 总结用户意图", "entities": [ { "type": "string， 实体类型如人名、地点、时间", "value": "string， 实体值" } ], "sentiment": "string， 情感极性：positive/negative/neutral", "requires_follow_up": "boolean， 是否需要跟进" } 请严格按照上述模板的字段和结构输出JSON，不要添加或减少字段，不要输出模板以外的任何文字。

关键点分析：

• 示例驱动：模型擅长模仿。提供一个具体的、正确的模板，它照葫芦画瓢的准确性远高于听你抽象描述。
• 字段约束：模板明确了所有键和值的类型，甚至给出了枚举值的示例（如positive/negative/neutral），极大地限制了输出范围。
• 双重保险：最后的强调句再次加固了边界。

2.3 专业技巧：使用系统提示词（System Prompt）与角色设定

如果你使用的API（如OpenAI Chat Completion API）支持系统提示词，这是设定行为基调的最佳位置。系统提示词用于定义模型的“角色”和全局行为准则。

你是一个精确的JSON数据生成器。你的唯一任务是根据用户的请求，生成严格符合RFC 7159标准的JSON数据。 你必须遵守以下规则： 1. 输出必须是纯JSON，无任何前置或后置文本。 2. 所有字符串必须使用双引号。 3. 不允许使用JavaScript风格的注释。 4. 确保所有括号和引号正确配对。 5. 如果请求不明确，请输出一个包含“error”字段的JSON对象来说明问题，而不是自然语言。

将格式要求放在系统提示词中，相当于为整个对话会话设定了一个“宪法”。在后续的用户请求中，即使指令简单，模型也会倾向于遵守这个基础设定。

注意：提示词的作用有上限。对于复杂任务或低温度（Temperature）设置下仍不稳定的模型，不能100%依赖提示词。它降低了出错的概率，但不能消除。

3. 第二层控制：利用API参数与模型特性

提示词是软件需求，API参数则是编译器的优化选项。正确配置它们，能从概率层面进一步锁定输出。

3.1 温度（Temperature）与核采样（Top-p）：降低“随机性”

• 温度（Temperature）：控制输出的随机性。值越高（如0.8-1.0），创意越丰富；值越低（如0-0.3），输出越确定、可预测。
  • 对于JSON生成，建议设置为0.1或0.2。这会让模型几乎总是选择最可能的下一个Token，极大提高格式一致性。
• 核采样（Top-p）：另一种控制随机性的方法，动态选择累积概率超过p的最小词集。通常与温度配合使用。
  • 对于JSON生成，可以设置为0.1或更低，进一步收紧候选词范围。

配置示例（以OpenAI API为例）：

response = openai.chat.completions.create( model="gpt-4-turbo", messages=[...], # 你的提示词 temperature=0.1, # 低温度，追求稳定 top_p=0.1, # 低核采样，集中选择 max_tokens=1000 )

3.2 停止序列（Stop Sequences）：强制截断

如果你发现模型总在JSON结束后“画蛇添足”，比如加上“json”的代码块结束标记，你可以将 `\n、```json` 等设置为停止序列。当模型生成这些字符时，API会立即停止生成，从而避免多余内容。

response = openai.chat.completions.create( model="gpt-4-turbo", messages=[...], temperature=0.1, stop=["```", "\n\n"] # 当模型开始生成代码块标记或连续空行时停止 )

3.3 选择支持“JSON模式”的模型或功能

这是最强大的武器。一些先进的模型或API直接提供了“强制JSON输出”模式。

• OpenAI的response_format参数：在最新的API中，你可以设置response_format={ "type": "json_object" }。这会强制模型输出有效的JSON。注意，系统提示词或用户消息中必须明确要求模型生成JSON，此参数才能生效。
• Claude的XML工具调用：Anthropic的Claude模型支持用XML标签来结构化输出，你可以要求它将内容包裹在<json>...</json>标签中，然后通过解析XML来提取纯净的JSON。
• 本地模型的指导格式：一些本地部署的模型，如通过Llama.cpp，可以使用grammar参数来约束输出格式，理论上可以强制输出符合JSON语法的文本。

使用JSON模式的示例：

# 使用OpenAI的JSON模式 response = openai.chat.completions.create( model="gpt-4-turbo-preview", messages=[ {"role": "system", "content": "你只输出JSON。"}, {"role": "user", "content": "生成两个产品的信息，包含name和price字段。"} ], response_format={ "type": "json_object" }, # 关键参数 temperature=0.1 ) # 此时 response.choices[0].message.content 理论上一定是可解析的JSON字符串。

这一层控制是工程上的关键加固。它将格式正确的概率从提示词层面的“大概率”，提升到了API层面的“极大概率”。

4. 第三层防御：后处理与容错机制

无论前两层做得多么完美，在生产环境中，我们都必须假设失败可能发生。一个健壮的系统不能因为模型的一次“抽风”而崩溃。因此，后处理与容错是必须的工程环节。

4.1 健壮的解析：尝试与修复

不要直接相信模型的输出就是完美JSON。写一个解析函数，它应该：

1. 尝试直接解析。
2. 如果失败，尝试清理常见错误。
3. 再次解析。
4. 如果还失败，提供明确的错误处理和降级方案。

import json import re def safe_parse_json(raw_text: str, max_attempts: int = 3): """ 尝试安全地解析可能包含杂质的JSON字符串。 """ text_to_parse = raw_text.strip() for attempt in range(max_attempts): try: # 尝试1: 直接解析 return json.loads(text_to_parse) except json.JSONDecodeError as e: if attempt == max_attempts - 1: # 所有尝试都失败，抛出异常或返回降级结果 raise ValueError(f"无法解析为JSON，原始文本：{raw_text[:200]}...") from e # 尝试2: 清理常见的非JSON内容 # 移除可能的Markdown代码块标记 text_to_parse = re.sub(r'^```json\s*|\s*```$', '', text_to_parse, flags=re.IGNORECASE) # 移除JSON以外的行（假设JSON是连续块） lines = text_to_parse.split('\n') json_lines = [] in_json_block = False for line in lines: stripped = line.strip() if stripped.startswith('{') or stripped.startswith('['): in_json_block = True if in_json_block: json_lines.append(line) if stripped.endswith('}') or stripped.endswith(']'): in_json_block = False text_to_parse = '\n'.join(json_lines) # 尝试3: 修复常见的格式错误（谨慎使用） # 例如，将单引号替换为双引号（简单场景） # text_to_parse = re.sub(r"(?<!\\)'", '"', text_to_parse) # 注意：复杂的修复可能引入新错误，最好结合具体错误信息处理 # 再次尝试解析 continue # 理论上不会走到这里 return None

4.2 验证与模式校验

即使解析成功，内容也可能不符合你的业务要求（例如，缺少必填字段，类型不对）。使用像jsonschema这样的库进行验证。

from jsonschema import validate, ValidationError # 定义你的JSON Schema product_schema = { "type": "object", "properties": { "name": {"type": "string"}, "price": {"type": "number", "minimum": 0} }, "required": ["name", "price"], "additionalProperties": False } def validate_product(data): try: validate(instance=data, schema=product_schema) return True, None except ValidationError as e: return False, str(e) # 使用 parsed_data = safe_parse_json(model_output) is_valid, error_msg = validate_product(parsed_data) if not is_valid: print(f"数据验证失败: {error_msg}") # 执行降级逻辑，如使用默认值、记录日志、触发人工审核等

4.3 设计降级与重试策略

• 重试：如果解析或验证失败，可以带着更明确的错误信息（如“上次输出不是纯JSON，请重试并只输出JSON”）重新调用一次API。通常重试1-2次能解决大部分临时性问题。
• 降级：如果重试后仍失败，系统应有备选方案。例如：
  • 返回一个包含错误信息的标准JSON结构{"error": "生成失败", "data": null}。
  • 调用一个更简单、更稳定的备用模型或规则引擎。
  • 将任务放入队列，标记为需要人工处理。
• 监控与告警：记录JSON生成失败率。如果失败率异常升高，可能意味着提示词需要调整、模型服务不稳定或输入数据出现了新的模式。

这一层是系统的安全网。它承认不确定性，并确保在不确定性发生时，系统依然能可控地运行，而不是崩溃。

5. 从单次成功到工程化实践

让单次调用输出JSON只是第一步。真正的挑战在于将其融入一个稳定、可维护的生产系统。

5.1 构建可复用的提示词模板

不要在每个函数里硬编码提示词字符串。将它们模板化、模块化。

# 在配置或单独的文件中定义模板 PROMPT_TEMPLATES = { "extract_user_info": """ 你是一个信息提取助手。请从以下文本中提取用户信息，并严格按照下方JSON格式输出。 文本： {user_input} JSON格式： {{ "name": "string", "age": "integer | null", // 如果未提及则为null "city": "string | null" }} 只输出JSON，不要有其他内容。 """ } # 使用时渲染 def build_prompt(template_name, **kwargs): template = PROMPT_TEMPLATES[template_name] return template.format(**kwargs) prompt = build_prompt("extract_user_info", user_input=some_text)

5.2 将LLM调用封装为可靠函数

创建一个统一的客户端函数，集成参数配置、错误处理、重试和降级逻辑。

import tenacity from openai import OpenAI, APIError client = OpenAI() @tenacity.retry( stop=tenacity.stop_after_attempt(3), wait=tenacity.wait_exponential(multiplier=1, min=2, max=10), retry=tenacity.retry_if_exception_type((APIError, json.JSONDecodeError, ValidationError)), before_sleep=lambda retry_state: print(f"第{retry_state.attempt_number}次重试...") ) def generate_structured_data(prompt_template: str, input_data: dict, output_schema: dict): """生成结构化数据的可靠函数""" prompt = prompt_template.format(**input_data) # 调用API response = client.chat.completions.create( model="gpt-4-turbo", messages=[{"role": "user", "content": prompt}], temperature=0.1, response_format={"type": "json_object"}, max_tokens=500 ) raw_output = response.choices[0].message.content # 安全解析 parsed_data = safe_parse_json(raw_output) # 模式验证 is_valid, error = validate_against_schema(parsed_data, output_schema) if not is_valid: raise ValidationError(f"Schema validation failed: {error}") return parsed_data

5.3 为Agent设计结构化输出规范

如果你在开发AI Agent（智能体），那么结构化输出是其与环境（工具、其他Agent、用户）交互的“语言”。你需要为Agent的每一步“思考”或“行动”定义清晰的输出契约。

例如，一个决策Agent的输出格式可以定义为：

{ "thought": "分析用户请求，决定下一步是回答问题还是调用工具。", "action": "call_tool | respond_directly", "action_input": { "tool_name": "search_web", "query": "具体查询词" } // 如果action是call_tool // 或者 // "response": "直接回复给用户的文本" // 如果action是respond_directly }

通过强制Agent以这种格式输出，你就能编写一个解析器，稳定地获取它的意图和参数，从而驱动后续的流程。这就是为什么“稳定输出JSON”是构建复杂、可靠Agent系统的核心技术前提。

回到最初的问题，让大模型稳定输出JSON，不是一个技巧，而是一个从提示词设计、参数调优到工程化防御的完整体系。它考验的不仅是你对大模型的理解，更是你构建鲁棒软件系统的能力。下次当面试官问你这个问题时，你可以从“模型概率本质与格式严谨性的矛盾”谈起，讲到“三层控制策略”，最后落到“工程化容错与Agent设计”，这远比单纯背几个提示词技巧要深刻得多。