1. 先搞清楚“前言后语”到底是怎么来的如果你在用大模型生成 JSON 时经常遇到模型在 JSON 外面“画蛇添足”加上一堆解释、说明、问候语导致你的解析器天天报JSONDecodeError或者Unexpected token那这篇文章就是为你写的。这个问题不是模型“笨”而是我们没把需求说清楚。模型尤其是对话型模型它的训练目标就是“像人一样说话”。你让它“生成一个用户信息的 JSON”它很可能会理解为“先礼貌地回应一下用户然后生成 JSON最后再总结一句”。于是你得到的输出就变成了好的这是您需要的用户信息JSON数据 { name: 张三, age: 30 } 希望这个信息对您有帮助你的json.loads()一碰到“好的这是...”就直接崩溃了。这背后的核心矛盾是你需要的是机器可解析的、纯净的结构化数据而模型默认生成的是人类可读的、带有上下文语境的自然语言。解决这个问题的思路不是去骂 API 或者换模型而是通过一套组合拳从“提需求”到“收结果”的整个链路上给模型戴上“紧箍咒”。我一般会按这四个层次来处理层层加固确保输出可控提示词工程在提问时就把规矩立好这是第一道也是最重要的防线。Few-shot 示例光说不够直接给模型看“满分答案”长什么样。生成参数调优利用 API 的参数从概率上抑制废话的生成。后处理与校验假设前几步都可能失效最后加一道程序化的安全网。下面我就按这个顺序拆解每一步具体怎么做以及为什么这么做。2. 第一层防线用提示词把规矩焊死提示词是你的首要指令。模糊的指令得到模糊的结果精确的指令才能逼近你想要的结果。针对“输出纯净 JSON”这个目标你的提示词需要包含以下几个关键要素2.1 明确指令使用“命令式”语气不要用商量或描述的口吻。直接、强硬、无歧义。错误示例“请生成一个JSON。”一般示例“请输出一个JSON格式的数据。”推荐示例“你是一个JSON数据生成器。严格只输出一个合法的JSON对象不要有任何额外的文本、解释、Markdown代码块标记或前言后语。”关键点角色设定“你是一个JSON数据生成器”。这比单纯提要求更有效它设定了模型的“身份”让其行为模式向工具靠拢。“严格只输出”这是强约束词强调了排他性。列举禁止项“不要有任何额外的文本、解释、Markdown代码块标记或前言后语”。把你能想到的“废话”形式都列出来避免模型钻空子。2.2 定义结构在提示词中嵌入Schema告诉模型JSON里具体要有什么字段什么类型。这能极大减少模型的“自由发挥”空间。推荐示例“...JSON对象必须包含以下字段name(字符串)age(整数)hobbies(字符串数组)。请基于以下信息生成用户叫李四25岁喜欢阅读和游泳。”关键点将数据结构作为提示词的一部分。这相当于给了模型一个模板。如果可以甚至可以直接给出一个JSON Schema的描述虽然模型不一定完全理解Schema但“字段名”、“类型”这些关键词它能捕捉到。2.3 指定格式强调“直接解析”友好性明确告诉模型它的输出将直接被另一个程序消费。推荐示例“你的输出将被直接传递给json.loads()函数进行解析因此必须确保输出是单一、完整、有效的JSON没有任何前缀或后缀。”关键点“直接传递给json.loads()”这是一个非常技术化、精确的场景描述能让模型意识到其产出的“机器属性”。“单一、完整、有效”这三个词是JSON解析的核心要求。一个综合性的强力提示词模板如下你是一个专业的JSON数据生成API。请严格遵循以下要求 1. 只输出一个合法的JSON对象不要输出任何其他文字、标点如json、问候语、总结句。 2. JSON的结构必须如下{user_id: int, user_name: string, items: [{id: int, name: string}]} 3. 你的输出将直接被Python的json.loads()解析请确保它是纯净的、可被直接解析的。 4. 基于以下信息生成用户ID是1001用户名是“测试用户”有两个物品id分别为1和2名称分别为“苹果”和“香蕉”。先别急着跑模型写好提示词只是第一步。对于复杂任务模型可能还是会在“理解指令”和“执行指令”之间出现偏差。这时就需要第二层防线。3. 第二层加固用Few-shot示例提供“满分答案”Few-shot learning少样本学习是让大模型“照葫芦画瓢”的最有效方法之一。你给它看几个输入-输出的例子它就能更好地模仿你想要的输出格式和风格。对于纯净JSON输出Few-shot示例的力量在于它跳过了模型对指令的“解读”环节直接展示了“正确行为”应该是什么样。3.1 如何构造Few-shot示例你的示例需要非常“干净”并且要刻意包含对“前言后语”的排除。示例对话以OpenAI ChatML格式为例[ { role: user, content: 生成一个表示一本书信息的JSON包含title和author字段。书是《三体》作者刘慈欣。 }, { role: assistant, content: {\title\: \三体\, \author\: \刘慈欣\} }, { role: user, content: 生成一个表示天气的JSON包含city, temperature, condition字段。城市北京温度22条件晴朗。 }, { role: assistant, content: {\city\: \北京\, \temperature\: 22, \condition\: \晴朗\} } ]关键点Assistant的回复必须是纯粹的、标准的JSON字符串。不要加引号外的任何字符。示例数量2-3个高质量的示例通常就足够了。关键是示例必须绝对正确。示例多样性最好覆盖你任务中可能的不同结构如包含数组、嵌套对象等。3.2 在API调用中集成Few-shot当你使用ChatCompletion类API时将这些示例作为对话历史messages的开头部分然后再附上你真正的用户请求query。import openai client openai.OpenAI(api_keyyour-api-key) messages [ {role: user, content: 生成一个表示一本书信息的JSON包含title和author字段。书是《三体》作者刘慈欣。}, {role: assistant, content: {\title\: \三体\, \author\: \刘慈欣\}}, {role: user, content: 生成一个表示天气的JSON包含city, temperature, condition字段。城市北京温度22条件晴朗。}, {role: assistant, content: {\city\: \北京\, \temperature\: 22, \condition\: \晴朗\}}, # 以上是Few-shot示例 {role: user, content: 你是一个JSON数据生成器。严格只输出一个合法的JSON对象不要有任何额外的文本。JSON必须包含name和age字段。用户叫王五28岁。} ] response client.chat.completions.create( modelgpt-3.5-turbo, messagesmessages, temperature0.1, # 温度调低减少随机性 max_tokens150 ) generated_text response.choices[0].message.content print(generated_text) # 期望输出: {name: 王五, age: 28}通过“强提示词”“Few-shot示例”模型输出废话的概率已经大大降低。但为了更稳妥我们还需要在模型“思考”和“生成”的过程中施加影响。4. 第三层控制调整生成参数抑制“废话”大模型生成文本是一个概率采样过程。通过调整API参数我们可以影响这个过程让模型更倾向于输出我们想要的格式如JSON而不是自然语言句子。4.1 关键参数及其作用参数推荐值作用解析temperature0.1 ~ 0.3控制随机性。值越低输出越确定、可预测。对于需要固定格式的JSON生成必须调低以避免模型突发奇想加入解释。**top_p(核采样)0.1 ~ 0.5与temperature类似控制采样池的大小。低值使模型从概率最高的少数token中选择输出更稳定。通常与temperature选一个调低即可。max_tokens略大于预期JSON长度限制生成的最大长度。设置一个合理的上限可以物理上阻止模型生成过长的、包含额外解释的文本。stop可设为\n或\}停止序列。如果你确定JSON对象结束后不应该有任何内容可以设置停止序列。但需谨慎如果JSON本身包含换行或\}可能会提前截断。response_format{ \type\: \json_object\ }(如果API支持如gpt-4-turbo)这是最强力的武器。直接告诉API你需要JSON对象格式的输出系统会在底层进行约束。这是首选方案。4.2 参数配置示例# 使用OpenAI API并利用 response_format 参数 response client.chat.completions.create( modelgpt-4-turbo-preview, # 或 gpt-3.5-turbo-1106 及更高版本支持此参数 messages[ {role: system, content: 你只输出JSON。}, # 系统消息强化角色 {role: user, content: 生成包含name和age的JSON。姓名赵六年龄35。} ], temperature0.1, max_tokens200, response_format{ type: json_object } # 关键参数 ) # 此时API会强制保证返回可解析的JSON几乎杜绝前言后语。重要提醒当使用response_format: json_object时系统或用户消息中必须明确指示模型生成JSON否则API可能会报错。这就是为什么上面的例子中系统消息强调了“你只输出JSON”。即使三层防御都做了在生产环境中我们依然要假设模型偶尔会“抽风”。因此最后必须有一道自动化的、程序化的安全网。5. 第四层兜底后处理与健壮性校验这一层的原则是不信任任何外部输入。无论前面的提示词多完美参数多严格拿到生成文本后先进行校验和清洗再尝试解析。5.1 后处理清洗流程写一个通用的extract_json函数它的任务是从可能被污染的文本中把JSON“挖”出来。import json import re def extract_json(text): 从可能包含额外文本的字符串中提取第一个有效的JSON对象或数组。 参数: text (str): 模型返回的原始文本。 返回: dict/list: 解析后的JSON数据。 str: 如果提取失败返回原始文本或错误信息。 # 1. 首先尝试直接解析整个文本最优情况 try: return json.loads(text) except json.JSONDecodeError: pass # 直接解析失败继续下面的步骤 # 2. 使用正则表达式查找最像JSON的部分 # 这个正则匹配以 { 开头以 } 结尾中间内容相对平衡的字符串简易版 json_pattern r(\{.*?\}) matches re.findall(json_pattern, text, re.DOTALL) # re.DOTALL 使 . 匹配换行符 for match in matches: # 尝试平衡大括号这是一个更健壮但复杂的方法的简化版 # 这里我们简单尝试解析每一个匹配项 try: return json.loads(match) except json.JSONDecodeError: continue # 当前匹配无效尝试下一个 # 3. 如果上述方法都失败尝试查找 json ... 代码块 code_block_pattern r(?:json)?\s*\n(.*?)\n code_match re.search(code_block_pattern, text, re.DOTALL) if code_match: try: return json.loads(code_match.group(1).strip()) except json.JSONDecodeError: pass # 4. 所有尝试都失败返回错误或原始文本 # 在实际生产中这里应该记录日志并抛出异常或返回错误标识 raise ValueError(f无法从文本中提取有效的JSON。原始文本{text[:200]}...) # 使用示例 raw_output 好的这是您需要的JSON数据 { name: 孙七, age: 40 } 祝您使用愉快 try: clean_data extract_json(raw_output) print(解析成功:, clean_data) # 输出: {name: 孙七, age: 40} except ValueError as e: print(解析失败:, e) # 在这里可以执行降级策略例如重试、使用默认值、通知人工处理等5.2 校验与降级策略提取出JSON后不要直接使用还需要进行校验结构校验检查必需的字段是否存在类型是否正确。可以使用jsonschema库。import jsonschema schema { type: object, properties: { name: {type: string}, age: {type: number, minimum: 0} }, required: [name, age] } try: jsonschema.validate(instanceclean_data, schemaschema) print(JSON结构校验通过) except jsonschema.ValidationError as e: print(f结构校验失败: {e})业务逻辑校验检查数据是否合理。例如年龄是否在正常范围内ID是否为正值等。降级策略如果清洗和校验都失败了你的程序应该有一个备选方案重试用相同的提示词和参数重新调用一次API。默认值返回一个安全的默认数据结构。人工审核队列将无法解析的原始文本和任务ID放入一个队列供后续人工处理并记录日志用于优化提示词。抛出明确异常让上游调用者知道本次生成失败而不是返回一个错误的数据。6. 实战组合拳与排查清单把以上四层结合起来就是一个健壮的模型JSON生成管道。流程如下构造请求使用强约束提示词Few-shot示例低随机性参数(temperature0.1) JSON响应格式(如果支持)。调用API发送请求获取原始响应。后处理清洗调用extract_json函数尝试从原始响应中剥离出纯净的JSON字符串。解析与校验将清洗后的字符串用json.loads()解析并进行结构化和业务逻辑校验。处理异常如果任何一步失败执行降级策略重试/默认值/人工审核。6.1 当解析依然报错时的排查清单即使有了四层防御如果还遇到JSONDecodeError或IndexError、KeyError等解析后错误请按以下顺序排查第一步看原始输出打印或记录模型返回的原始文本(response.choices[0].message.content)。检查它是否仍然包含非JSON内容。如果是问题出在第一、二、三层提示词、示例、参数。第二步检查提示词和示例提示词是否足够强硬是否明确说了“不要有任何额外文本”Few-shot示例是否绝对干净助理回复里有没有不小心多出逗号、句号或换行系统消息是否设定了正确角色比如“你是一个JSON生成API”。第三步检查API参数temperature是否设得太高比如大于0.7是否忘记了使用response_format{ type: json_object }如果模型支持max_tokens是否太小导致JSON被截断第四步检查后处理逻辑extract_json函数中的正则表达式是否能匹配你遇到的非JSON格式比如模型可能用json 而不是json。清洗后的字符串在解析前是否可以用在线JSON校验工具验证其合法性第五步模型与任务复杂度对于结构非常复杂或嵌套很深的JSON能力较弱的模型如某些小参数模型可能无法可靠生成。考虑升级模型或简化输出结构。任务指令是否过于复杂让模型产生了“必须先解释再输出”的倾向尝试将复杂任务拆分成多个简单API调用。6.2 针对特定错误码的快速思路JSONDecodeError: Expecting property name enclosed in double quotes 模型可能使用了单引号而不是双引号。可以在后处理中使用text.replace(, \)谨慎地替换但更好的方法是在Few-shot示例中强化使用双引号。JSONDecodeError: Extra data 文本中包含多个JSON对象或尾部有多余字符。后处理函数应只提取第一个完整对象。KeyError或IndexError JSON解析成功但结构不符合预期。问题不在解析而在生成。需要加强提示词中的Schema定义和Few-shot示例的准确性并添加jsonschema校验。输出null或空对象{} 模型可能无法从你的输入中提取信息或者温度太低导致“僵化”。适当提高temperature到0.3并检查输入信息是否明确。这套“提示词-Few-shot-参数-校验”的四层方案其核心思想是将“期望”从模糊的自然语言描述逐步转化为精确的机器约束。它不能保证100%绝对不出错但能将故障率降低到可接受的水平并为可能发生的错误提供明确的捕获和处理路径。在实际项目中尤其是批量处理任务时这套组合拳是保证流程稳定性的必备工具。