必须启用原生json mode并配置response_format为json_object，配合严格system prompt和schema约束，再经正则提取、语法修复与强制校验三步后处理，才能确保deepseek输出可直接解析的纯json。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
你需要让DeepSeek输出可直接被程序解析的纯JSON字符串，而不是带说明文字、代码块包裹或首尾杂音的混合文本。这在API对接、Agent开发、自动化数据采集等场景中必须一步到位，否则后续所有解析逻辑都会失败。
启用原生JSON Mode（优先级最高）
这是最硬核的底层约束，直接干预模型生成过程的token概率分布，物理上禁止输出非JSON字符。
在API请求体中加入 【response_format": {"type": "json_object"}】 字段，且确保model参数指向支持该功能的版本（如deepseek-chat-202412、deepseek-v4或文档明确标注JSON Mode可用的型号）。
发送请求前检查：Content-Type必须为application/json；messages数组不能为空；system消息中不得出现“请解释”“请说明”等触发自由文本的动词。
这一步生效后，模型第一个输出字符必定是{，最后一个必定是}，中间绝不会插入“好的，这是你要的JSON：”之类废话——它不是靠提示词说服，而是被服务端强制截断了非JSON路径。
用system prompt双保险锁定结构
即使启用了JSON Mode，字段名、类型、嵌套层级仍可能漂移。必须用system消息把schema钉死。
统一LLM网关 - 一个API对接70+AI模型，使用单一API密钥即可调用GPT、Claude、Gemini、Qwen、Deepseek、Grok等主流模型。
方法一：自然语言+示例强引导
在system角色中写：“你是一个严格的JSON生成器。只输出合法JSON对象，不加任何说明、空行、代码块标记、中文引号或尾随逗号。字段必须完全匹配用户指定结构。”
user消息里紧跟着写：“返回包含product_id（字符串）、price（数字）、in_stock（布尔值）的对象。示例：{"product_id":"SKU123","price":299.9,"in_stock":true}”
方法二：嵌入JSON Schema描述
在user消息中直接给出标准Schema：
{"type":"object","properties":{"name":{"type":"string"},"score":{"type":"number"}},"required":["name","score"]}
【注意：Schema中不要用$ref、anyOf等复杂关键字，DeepSeek V4以下版本对高级语法支持不稳定】
后处理清洗与校验（不可跳过）
第一步：提取最内层JSON片段
用正则 r'```json\s*({[^}]*})\s*```|(\{.*?\})' 匹配响应体，优先取第一个捕获组；若无代码块，则取第二个组。匹配时启用re.DOTALL标志，确保跨行内容也被捕获。
第二步：修复常见语法错误
对提取出的字符串执行：去除BOM头 → 替换全角引号为半角 → 删除末尾逗号 → 补全缺失的}（仅当左括号数比右括号多1时补）→ 去除首尾空白。
第三步：强制校验与兜底
调用 json.loads()；若抛出JSONDecodeError，则立即丢弃响应并重试，【绝不尝试智能补全或默认值填充——那会让错误静默传播】。
