从模式约束、示例引导、参数控制到校验重试，讲清让DeepSeek稳定输出可解析JSON的工程方法。
在AI指导老师的实际工作流里，JSON不是装饰性格式，而是连接模型与题库系统、批改引擎、学习计划服务的接口。DeepSeek默认以自然语言作答，若只写“请输出JSON”，常会附解释、加代码围栏或在字段名上自由发挥，导致下游解析失败。稳定输出需要把提示词当成协议文档来写，并在调用层做校验与修复，而不是把解析失败归因于模型“不听话”。
1. 用显式模式约束字段边界
JSON输出本质上是受约束的生成任务，模型需要知道有哪些字段、字段是什么类型、是否必填、取值范围如何。系统提示中给出JSON Schema或等价的结构说明，比“返回结构化结果”这类模糊指令有效得多。字段名建议使用英文小写加下划线，避免同义歧义；类型明确写为integer、string、array、object；枚举字段固定可选值；必填字段列全；空值策略说明是用null还是空数组。例如批改结果可以定义为score为0到100的整数，errors为数组且元素包含type枚举、evidence字符串、suggestion字符串，summary为字符串。这样模型不会临时增加confidence、remark等计划外字段。
DeepSeek的JSON Output模式需要把response_format参数设为json_object，同时提示中要出现json字样并给出期望结构，否则接口可能拒绝请求，或者模型仍输出自然语言。实际写法应把角色、任务、输出协议分开：系统消息声明“只输出一个JSON对象，不要markdown围栏，不要解释”，用户消息只放待处理文本。协议部分越像接口文档，模型越容易按字段边界生成。
嵌套结构要控制深度，超过三层时拆成两个对象或分步生成；数组元素结构要在schema中写清楚，避免模型把对象写成字符串。日期统一用ISO 8601格式，布尔值不要用“是/否”字符串代替。字段边界越明确，后续校验成本越低，修复提示也越容易定位问题。
2. 以少样本示例固定输出协议
示例是比抽象规则更强的约束。给1到3个完整输入输出对，覆盖正常样本、边界样本和缺失信息样本，比反复描述“请保持格式一致”更有效。示例中的JSON要短小、字段齐全、格式与目标完全一致，不要包含无关业务长文，否则模型会复制冗余内容。系统提示负责协议，用户消息负责数据，示例可以放在系统提示末尾，形成稳定的输出模板。
示例还要展示“不要什么”。在协议中明确说明输出必须是裸JSON，不得使用“`json围栏，不得在JSON前后写“以下是结果”。如果任务需要模型在信息不足时处理，示例中应给一个字段为null或空数组的合法输出，避免模型编造数据。示例不是越多越好，质量比数量重要，一个覆盖边界情况的短示例往往比三个长示例更稳定。
以课程大纲生成为例，示例输入是“Python入门，8课时，零基础”，输出包含course_title、level、objectives数组、lessons数组，每个lesson含title、duration_minutes、exercises数组。示例之后，用户只替换业务数据。少样本会占用token，长任务用schema加一个短示例即可，重点是把字段名、层级和空值写法固定下来。
3. 在调用层控制参数与失败重试
参数会直接影响结构化输出的稳定性。结构化任务应把temperature调到0到0.3，减少字段名和措辞漂移；top_p保持默认或较高值，不必同时大幅调整。max_tokens要按目标JSON长度留出余量，长数组任务尤其要防止截断，因为截断后的JSON无法解析。流式输出在需要完整JSON校验时不适合边流边解析，先收集完整响应再处理更稳妥。
调用DeepSeek时设置response_format为json_object，并在提示中保留json关键词和结构示例；系统消息固定协议，用户消息只放变量。若使用Function Calling，把参数schema交给工具定义，模型返回结构化参数，但不要同时混用两套协议，否则模型容易在普通JSON和工具参数之间摇摆。
重试要分类处理。语法错误可以把原始输出和解析错误回传，要求“只输出修正后的JSON，不改变业务内容”；schema错误指出具体字段和期望类型；语义错误如分数越界，要求重新评分并说明依据。重试最多两到三次，每次收紧提示，避免无限循环。失败样本要记录下来，作为下一轮提示优化的依据，而不是每次从零调试。
4. 建立解析校验与修复闭环
不要假设模型输出一定可解析。收到响应后先做轻量清洗：去掉BOM、首尾空白、意外包裹的markdown围栏和JSON前后的解释文字，但清洗要保守，避免误删字符串内的合法内容。然后用严格JSON解析器解析，再用JSON Schema或Pydantic模型校验类型、枚举、必填、数值范围、数组长度。校验层是模型输出进入业务系统的闸门，不能省略。
错误可以分为三类处理：语法错误走修复提示；结构错误指出缺失字段或类型不符；语义错误如difficulty不在枚举内，要求模型只修正该字段。修复提示附上原始JSON、错误信息和目标schema，要求输出完整对象而非补丁。修复轮次不宜过多，两轮仍失败就转人工或降级处理，避免把错误数据带入下游。
工程闭环还包括指标监控。统计一次解析成功率、字段完整率、重试次数和平均修复轮次，按任务类型分别看。题库生成任务中，若difficulty枚举错误集中出现，就在schema和示例中同时强化；若summary经常为空，就增加必填约束和示例。把失败样本沉淀为回归集，每次调整提示后重跑，确保JSON输出稳定而不是偶然可用。
