代码实验上线配置的收口方法告警群突然刷屏大模型输出全变成了 JSON 解析失败星期三下午 3 点监控系统忽然触发了高等级告警。核心业务接口报错率飙升到 80%全都是反序列化阶段抛出的json.decoder.JSONDecodeError异常。更诡异的是上游的大模型推理服务 API 状态完全健康响应耗时也没有任何异常。前端界面上用户提交的操作请求却持续弹窗提示“系统内部服务故障”。团队及时成立紧急排障小组。拉出调用的原始文本日志一看大家哭笑不得模型返回的 JSON 串外面居然被贴心地套上了一层json ... 的 Markdown Markdown 语法标记还带上了两句客套话。追查根因上游提示词微调引发下游解析器坍塌经过排查故障根因很快浮出水面。算法同学在半小时前对 System Prompt 做了微调希望模型能生成逻辑更严密的回答。为了让输出格式更美观Prompt 里加了一句“请使用 Markdown 代码块包裹返回的 JSON”。然而下游接入层代码一直使用的是传统的严格解析逻辑json.loads(response_text)。严格解析器遇到开头的json字符及时抛出致命错误。上游只改了一句看起来人畜无害的 Prompt 提示词就直接击垮了下游的整个服务链路。这暴露了目前 LLM 应用开发中最普遍的问题把模型当成绝对确定性的传统 RPC 接口来调用。在大模型算法应用落地中任何输出解析模块都应包含防破垮Crash-Proof的防御性编程逻辑。面向生产环境的 Prompt 防破垮解析器与格式纠偏代码下面的 Python 示例展示了一个具备 Markdown 标签自动剥离、缺失符号修复以及结构化兜底功能的防御性解析器。import re import json import logging from typing import Dict, Any, Tuple logging.basicConfig(levellogging.INFO) logger logging.getLogger(prompt_fault_recovery) class CrashProofJSONParser: 面向生产环境的大模型输出防御性 JSON 解析器 staticmethod def extract_and_clean_json_str(raw_text: str) - str: 从带有 Markdown 或废话的响应中剥离出纯 JSON 字符串 if not raw_text: return # 1. 尝试匹配 json ... 代码块 markdown_match re.search(r(?:json)?\s*([\s\S]*?)\s*, raw_text, re.IGNORECASE) if markdown_match: cleaned markdown_match.group(1).strip() logger.info(提取到 Markdown 包裹的 JSON 内容) return cleaned # 2. 尝试提取首个 { 和最后一个 } 之间的内容 first_brace raw_text.find({) last_brace raw_text.rfind(}) if first_brace ! -1 and last_brace ! -1 and last_brace first_brace: cleaned raw_text[first_brace:last_brace 1].strip() logger.info(通过花括号界定提取 JSON 内容) return cleaned return raw_text.strip() def parse_with_fallback(self, raw_response: str, fallback_schema: Dict[str, Any]) - Tuple[Dict[str, Any], str]: 解析 JSON若失败则尝试纠偏并自动触发兜底 cleaned_str self.extract_and_clean_json_str(raw_response) # 第一次解析尝试 try: parsed_data json.loads(cleaned_str) return parsed_data, SUCCESS_DIRECT except json.JSONDecodeError as e: logger.warning(f标准 json.loads 失败: {str(e)}尝试纠偏修复...) # 简单纠偏逻辑处理末尾多余逗号或缺失引号 fixed_str re.sub(r,\s*([\]}]), r\1, cleaned_str) # 移除末尾尾随逗号 try: parsed_data json.loads(fixed_str) logger.info(自动修复尾随逗号成功) return parsed_data, SUCCESS_AFTER_FIX except json.JSONDecodeError: pass # 解析彻底失败执行兜底降级 logger.error(大模型响应彻底无法解析为 JSON触发安全兜底返回) return fallback_schema, FALLBACK_TRIGGERED if __name__ __main__: parser CrashProofJSONParser() fallback_data {status: error, categories: [], retry_recommended: True} # 1. 模拟触发线上故障的真实响应文本 fault_llm_response 当然这是为你生成的分类结果 json { status: success, categories: [CV, NLP, LLM], } 希望对你有帮助 print( 测试故障文本解析与自动恢复 ) res_data, mode parser.parse_with_fallback(fault_llm_response, fallback_data) print(f解析模式: {mode}) print(最终解析结果 Dict:, json.dumps(res_data, indent2, ensure_asciiFalse))复盘留下的防御性设计防线这次线上故障复盘会结束后团队沉淀了三条铁律防线第一Prompt 变更视同代码变更。绝不许在生产环境私自修改提示词文本。所有的 Prompt 提交应经过 Git 仓库的 Pull Request 审核并触发自动化测试集。第二下游永远不假设上游输出合法。即使模型在 API 级别开启了 JSON 模式下游应用解析层依然要配置正则提取与容错修复逻辑。第三建立 Schema 校验与兜底熔断。解析出来的 Dict 应通过 Pydantic 或 JSON Schema 进行字段类型检查。一旦缺少关键业务字段自动走降级分支。建立长效的提示词回归测试集为了避免类似故障再次发生应建立 Prompt 的持续集成CI回归测试框架。每次修改 Prompt 之后用包含 100 个历史边界 Case 的离线测试集跑一遍。统计自动化解析成功率、字段缺失率以及响应时延。只有当离线回归测试通过率达到 100% 时才允许合入主干并发布上线。把失败的教训转化为确定性的防御代码才是故障复盘最大的价值。