大模型JSON输出不稳定？从提示词到后处理的完整工程化解决方案-平芜编程栈

在实际 AI 应用开发中，无论是构建智能 Agent 还是处理结构化数据，让大语言模型稳定、准确地输出 JSON 格式都是一个高频且棘手的需求。模型可能输出不完整的 JSON、包含多余的解释文本，或者在复杂嵌套时出现格式错误，这些都会导致下游程序解析失败。对于准备大模型相关岗位面试的开发者而言，理解并解决这个问题，不仅是展示工程化能力的关键，也是区分“只会调 API”和“能构建可靠系统”的重要标志。

本文将深入探讨如何从提示词设计、API 调用参数控制、后处理校验以及架构设计等多个层面，系统性地解决大模型 JSON 输出不稳定的问题。我们将从最简单的场景开始，逐步深入到生产环境下的最佳实践，并提供可复现的代码示例和详细的排查清单。

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

在要求模型解决具体问题之前，我们必须先理解它为何会“不听话”。大语言模型本质上是基于概率生成文本的序列预测器，它并没有内置的 JSON 语法解析器或验证器。其不稳定性主要源于以下几个方面。

1.1 训练数据与概率生成的本质

模型在训练时学习了海量互联网文本，其中包含大量结构化和非结构化数据。虽然它“见过”无数 JSON 例子，但其学习目标是预测下一个 token（词元）的概率分布，而非保证输出符合严格的语法规范。当生成过程涉及括号、引号、逗号时，任何一个 token 的预测偏差都可能导致格式错误。例如，模型可能预测右花括号}的概率很高，但在生成长文本时，也可能被“接下来应该解释一下”这类训练数据中的常见模式所影响，从而插入多余的自然语言。

1.2 提示词（Prompt）的模糊性

模糊的指令是导致输出格式混乱的首要原因。对比以下两种提示：

模糊提示：“请把用户信息整理成 JSON。”
清晰提示：“请严格输出一个 JSON 对象，包含name(字符串)、age(整数)、hobbies(字符串数组) 三个字段。不要输出任何额外的解释、标记或文本。JSON 内容如下：”

第一种提示没有定义具体的字段名、类型和结构，模型有很大的自由发挥空间，很可能在 JSON 前后加上“好的，这是整理后的信息：”等文本。第二种提示则明确了格式、结构和约束。

1.3 上下文（Context）的干扰

如果对话历史或系统指令中包含了非 JSON 的格式示例、复杂的推理步骤要求，或者本次查询的上下文本身就鼓励模型进行“思考”，那么模型在输出时可能会模仿这种模式，将“思考过程”也一并输出，从而污染了纯 JSON 结果。

1.4 模型本身的“创造性”与“服从性”权衡

有些模型（特别是早期版本或未经严格对齐的模型）倾向于展示其推理能力或提供更“友好”的回答，即使你要求它只输出 JSON，它也可能认为加上说明会对用户更有帮助。这需要通过对模型参数的调整和更严格的指令来抑制。

2. 核心解决方案：从提示词工程到参数调优

解决输出不稳定问题需要一套组合拳，核心在于降低模型生成的不确定性，并明确约束其输出空间。

2.1 构建强约束的提示词（Prompt Engineering）

提示词是控制模型行为的第一道也是最关键的防线。一个优秀的 JSON 生成提示应包含以下要素：

明确的角色与任务：在系统提示（System Prompt）或用户消息开头定义模型角色。
输出格式的严格规定：使用“严格输出”、“只输出”、“必须遵循”等强动词。
JSON Schema 描述：详细描述期望的 JSON 结构，包括字段名、数据类型（string, number, boolean, array, object）、是否必需、以及简单的约束（如枚举值）。
示例（Few-Shot Learning）：提供1-2个输入输出的配对示例，这是让模型快速理解你要求的极佳方式。
负面指令：明确禁止模型做什么，如“不要添加任何额外的解释”、“不要包含 markdown 代码块标记”。

下面是一个整合了以上要素的提示词示例，适用于 OpenAI Chat Completions API：

system_prompt = """你是一个专业的JSON数据生成器。你的任务是根据用户的输入，生成一个严格符合给定格式的JSON对象。 请遵循以下规则： 1. 输出必须是**一个且仅一个**完整的、语法正确的JSON对象。 2. 不要输出任何JSON以外的文本、解释、道歉、markdown代码块标记（如```json）或前缀。 3. 严格使用以下JSON Schema定义的结构： { "type": "object", "properties": { "name": { "type": "string", "description": "用户的全名" }, "age": { "type": "integer", "description": "用户的年龄，必须是正整数" }, "is_student": { "type": "boolean", "description": "用户是否为在校学生" }, "courses": { "type": "array", "items": { "type": "string" }, "description": "用户选修的课程列表" } }, "required": ["name", "age", "is_student"] } 示例1： 用户输入：张三，30岁，不是学生，学过数学和物理。 输出：{"name": "张三", "age": 30, "is_student": false, "courses": ["数学", "物理"]} 示例2： 用户输入：李四，22岁，是学生。 输出：{"name": "李四", "age": 22, "is_student": true, "courses": []} 现在，请处理新的用户输入。 """ user_input = "王五，25岁，是一名学生，正在学习计算机科学和英语。"

2.2 利用API的格式化功能

主流的大模型API正在逐步原生支持结构化输出，这是最稳定可靠的方法。

OpenAI GPT-4o / GPT-4 Turbo：支持response_format参数。将response_format设置为{“type”: “json_object”}可以显著提高模型输出JSON的倾向性。重要：当使用此参数时，系统或用户消息中必须明确指示模型输出JSON，否则API可能报错。

from openai import OpenAI client = OpenAI() response = client.chat.completions.create( model="gpt-4o", messages=[ {"role": "system", "content": "你输出JSON。"}, {"role": "user", "content": "列出三个水果及其颜色，格式为JSON数组，每个对象有‘name’和‘color’字段。"} ], response_format={"type": "json_object"}, # 关键参数 temperature=0.1 # 降低随机性 ) print(response.choices[0].message.content)

Anthropic Claude：支持在系统提示中使用特定的XML标签来定义输出结构，功能非常强大。

system_prompt = """ <format> { “fruits”: [ { “name”: “fruit name“, “color”: “color name“ } ] } </format> 请根据用户描述，将数据填充到上面的JSON格式中。只输出JSON，不要有其他内容。 """

本地模型（如通过 Ollama 部署）：许多微调模型（如llama3.2、qwen2.5系列）对json或json_object指令响应良好。提示词策略与上述类似，同时可以结合temperature和top_p参数。

2.3 调整生成参数以降低随机性

模型的生成参数直接影响输出的确定性和创造性。为了获得稳定的JSON，应进行如下配置：

参数	推荐值	说明
`temperature`	0.1 - 0.3	控制随机性。值越低，输出越确定、可重复。设为接近0的值可获得最稳定的JSON，但可能牺牲一些灵活性。
`top_p`(nucleus sampling)	0.1 - 0.5	与`temperature`类似，控制候选词的范围。低值使模型仅考虑高概率token，输出更稳定。通常与`temperature`配合使用，调整一个即可。
`max_tokens`	适量调高	确保预留足够的token数来生成完整的JSON。太短会导致输出被截断。可以根据你期望的JSON复杂度进行估算并留有余量。
`stop`	可设置`\n`等	如果模型有在JSON后添加换行符再写解释的习惯，可以设置停止序列。但需谨慎，可能截断合法JSON内的换行。

一个调用示例如下：

response = client.chat.completions.create( model="gpt-4o", messages=messages, response_format={"type": "json_object"}, temperature=0.2, # 低随机性 top_p=0.3, # 高确定性采样 max_tokens=500, # 预留足够长度 # stop=["\n\n"] # 可选，根据情况设置 )

3. 后处理与验证：构建安全网

无论提示词多完美，参数多严格，在生产环境中都不能完全信任模型的原始输出。必须建立可靠的后处理与验证流程。

3.1 健壮的后处理解析

后处理代码的目标是：从模型的原始响应中，尽可能提取出有效的 JSON 字符串。

import json import re def extract_and_parse_json(raw_response: str): """ 从可能包含额外文本的响应中提取并解析JSON。 参数: raw_response: 模型返回的原始文本 返回: 解析后的Python字典或列表，如果失败则返回None或抛出异常。 """ # 方法1：尝试直接解析（如果模型非常听话） try: return json.loads(raw_response) except json.JSONDecodeError: pass # 方法2：使用正则表达式查找最像JSON的部分 # 这个正则匹配以 { 开头，以 } 结尾，且中间括号匹配的文本（简化版，适用于对象） json_match = re.search(r'\{[^{}]*\}|\{[^{}]*\{[^{}]*\}[^{}]*\}', raw_response, re.DOTALL) # 对于JSON数组，可以匹配 \[.*?\] array_match = re.search(r'\[.*?\]', raw_response, re.DOTALL) candidate = None if json_match: candidate = json_match.group(0) elif array_match: candidate = array_match.group(0) if candidate: try: # 再次尝试解析找到的候选文本 return json.loads(candidate) except json.JSONDecodeError: # 可以尝试更激进的清理，如去除首尾空白、换行，但需小心 candidate_clean = candidate.strip() # 处理常见的非JSON前缀，如 `json` 或 反引号 if candidate_clean.startswith('```json'): candidate_clean = candidate_clean[7:] elif candidate_clean.startswith('```'): candidate_clean = candidate_clean[3:] if candidate_clean.endswith('```'): candidate_clean = candidate_clean[:-3] try: return json.loads(candidate_clean) except json.JSONDecodeError as e: print(f"清理后仍无法解析JSON: {e}") print(f"原始文本: {raw_response[:200]}...") return None # 方法3：如果以上都失败，记录日志并返回None或抛出业务异常 print(f"无法从响应中提取JSON: {raw_response[:500]}...") return None # 使用示例 raw_output = model_response.choices[0].message.content parsed_data = extract_and_parse_json(raw_output) if parsed_data: # 继续你的业务逻辑 process_data(parsed_data) else: # 触发降级策略，如使用默认值、重试或人工审核 handle_failure()

3.2 使用 JSON Schema 进行验证

提取出 JSON 后，必须验证其结构是否符合预期。jsonschema库是 Python 中的标准工具。

from jsonschema import validate, ValidationError # 定义你期望的 Schema expected_schema = { "type": "object", "properties": { "name": {"type": "string"}, "age": {"type": "integer", "minimum": 0}, "is_student": {"type": "boolean"}, "courses": { "type": "array", "items": {"type": "string"}, "default": [] # Schema 可以定义默认值，但 validate 不负责填充 } }, "required": ["name", "age", "is_student"], "additionalProperties": False # 禁止出现未定义的字段！ } def validate_json_data(data): try: validate(instance=data, schema=expected_schema) print("JSON 数据验证通过。") return True except ValidationError as e: print(f"JSON 数据验证失败: {e.message}") print(f"失败路径: {e.json_path}") # 这里可以记录更详细的错误信息，用于优化提示词或触发重试 return False # 在解析后调用验证 if parsed_data and validate_json_data(parsed_data): # 数据完全符合预期，安全使用 save_to_database(parsed_data)

将additionalProperties设置为False是一个好习惯，可以防止模型“臆造”出你不希望的字段。

4. 高级策略与架构设计

对于企业级或高可靠性应用，需要从架构层面考虑稳定性。

4.1 实现重试与降级机制

网络波动、模型瞬时故障或偶尔的格式错误是不可避免的。一个健壮的系统应该具备重试能力。

import time from tenacity import retry, stop_after_attempt, wait_exponential, retry_if_exception_type class RobustJSONGenerator: def __init__(self, client, model): self.client = client self.model = model @retry( stop=stop_after_attempt(3), # 最多重试3次 wait=wait_exponential(multiplier=1, min=2, max=10), # 指数退避 retry=retry_if_exception_type((json.JSONDecodeError, ValidationError, KeyError)) # 仅在解析/验证失败时重试 ) def generate_json_with_retry(self, user_input, system_prompt): messages = [ {"role": "system", "content": system_prompt}, {"role": "user", "content": user_input} ] response = self.client.chat.completions.create( model=self.model, messages=messages, response_format={"type": "json_object"}, temperature=0.1, max_tokens=1000 ) raw_json = response.choices[0].message.content parsed_data = json.loads(raw_json) # 直接解析，假设提示词足够强 validate(instance=parsed_data, schema=expected_schema) # 验证 return parsed_data def generate_json_with_fallback(self, user_input): """带有最终降级策略的生成""" try: return self.generate_json_with_retry(user_input, strong_system_prompt) except Exception as e: print(f"所有重试均失败: {e}") # 降级策略1：使用更简单的提示词再试一次（快速路径） try: return self._generate_with_simple_prompt(user_input) except Exception: # 降级策略2：返回一个安全的默认值或空结构 return {"name": "N/A", "age": 0, "is_student": False, "courses": []} # 或者，将任务放入死信队列，供后续人工处理 # send_to_dlq(user_input)

4.2 为复杂任务设计分步 Agent

对于极其复杂、一步到位的 JSON 生成容易出错的场景，可以设计一个多步执行的智能体（Agent）。

规划 Agent：分析用户输入，拆解出需要填充的 JSON 字段和所需的信息点。
提取/推理 Agent：针对每个信息点，通过调用工具（如搜索、计算）、链式思考（Chain-of-Thought）等方式，得出具体值。
组装与校验 Agent：将收集到的值按照 Schema 组装成 JSON，并进行自我检查和修正。

这种方式将单次生成的大概率错误风险，分散到多个可控的小步骤中，每一步都可以进行校验和重试，整体成功率更高。可以使用 LangChain、LlamaIndex 等框架来编排此类工作流。

4.3 微调（Fine-tuning）专用模型

如果 JSON 输出的结构和领域非常固定（例如，始终从医疗报告摘要中提取相同的几十个字段），那么收集一批高质量的（输入，输出 JSON）配对数据，对基础模型进行微调，是获得最高稳定性和准确性的终极方案。微调后的模型会深刻理解你所需的格式，几乎不再需要复杂的后处理。可以使用LlamaFactory、Axolotl等工具进行高效微调。

5. 常见问题排查清单

当你的大模型 JSON 输出仍然不稳定时，请按照以下清单逐项检查：

问题现象	可能原因	检查与解决步骤
输出包含额外文本（如“好的，这是JSON：”）	提示词约束力不足，或系统提示未生效。	1. 检查系统提示（System Prompt）是否明确要求“只输出JSON”。 2. 在用户提示中再次强调“不要输出任何非JSON文本”。 3. 使用API的`response_format`参数（如果支持）。
JSON不完整或被截断	`max_tokens`参数设置过小。	1. 估算输出JSON的大致长度（可使用在线Token计算器）。 2. 将`max_tokens`设置为估算值的1.5-2倍。 3. 检查后处理代码是否错误地截断了字符串。
字段类型错误（如数字写成字符串）	提示词中对字段类型的描述不够清晰，或模型理解偏差。	1. 在提示词的Schema描述中明确类型，如`“age”: {“type”: “integer”}`。 2. 提供包含正确类型的示例（Few-Shot）。 3. 在后处理中使用`jsonschema`验证，并对类型错误进行自动转换（如`int(parsed[“age”])`）。
缺少必需字段或多了未知字段	Schema定义不清或模型自由发挥。	1. 在提示词中列出`required`字段。 2. 在验证Schema中设置`“additionalProperties”: false`。 3. 后处理时检查字段是否存在，并为可选字段提供默认值。
简单场景成功，复杂场景失败	复杂嵌套结构或逻辑超出了单次提示的处理能力。	1. 考虑采用分步Agent策略，先提取简单部分，再组合。 2. 尝试让模型“先思考，后输出”，将推理过程与JSON输出分离（可通过临时变量实现）。 3. 检查复杂输入是否清晰无歧义。
同一提示词在不同模型上效果差异大	不同模型的对齐能力和指令遵循能力不同。	1. 为不同模型定制提示词。较小或专用模型可能需要更详细、更示例化的提示。 2. 优先选择在官方文档中明确支持JSON输出或函数调用的模型（如GPT-4系列，Claude 3）。 3. 测试并记录不同模型的稳定性，作为选型依据。

6. 生产环境最佳实践

将大模型 JSON 生成能力投入生产，除了上述技术点，还需考虑工程和运维层面。

配置与提示词外部化：不要将提示词硬编码在代码中。将其存储在数据库、配置文件或配置中心，便于动态调整、A/B测试和版本管理。
全面的日志记录：记录每一次调用的请求提示词、模型参数、原始响应、解析后的数据以及验证结果。这些日志是优化提示词、排查问题和评估模型性能的黄金数据。
监控与告警：定义关键指标进行监控，如：JSON解析成功率、Schema验证通过率、平均响应延迟、Token消耗量。当解析成功率下降时触发告警。
设置速率限制与熔断：对模型API的调用进行限流，防止因意外循环或流量激增导致费用爆炸或服务雪崩。在连续失败时启动熔断机制。
成本与性能权衡：更强大的模型（如GPT-4）通常格式遵循能力更好，但成本更高、速度更慢。要根据业务对准确率和延迟的要求进行选型。对于格式简单的任务，性能优异的较小模型（如qwen2.5）配合精心设计的提示词可能是性价比更高的选择。
人工审核回路：对于关键业务数据或解析持续失败的案例，设计流程将数据转入人工审核队列。这些人工纠正后的数据又可以作为高质量样本，用于优化提示词或微调模型，形成闭环。

稳定获取大模型输出的 JSON 不是一个单点技巧，而是一套涵盖提示词设计、API调用、后处理、验证和系统架构的工程体系。从定义一个清晰的 Schema 开始，用强约束的提示词和低随机性参数引导模型，再用健壮的后处理代码作为安全网，最后通过监控和重试机制保障线上可靠性。在面对面试官时，能够系统地阐述这套从预防到补救的完整方案，远比仅仅回答“可以用正则表达式提取”更能体现你的工程深度和解决复杂问题的能力。在实际项目中，建议从最简单的提示词和直接解析开始，然后随着遇到的具体问题，逐步引入更高级的策略，最终构建出适合自身业务场景的稳定数据流水线。