DeepSeek 的 JSON 输出能把教学指令转为结构化数据，稳定与否取决于 Schema、提示词、参数和校验重试的协同设计。
在 AI 指导老师的工作流里，学情诊断、题目生成、评分细则和学习路径都需要被下游系统直接读取，纯文本答案很难完成入库、比对和触发后续逻辑，JSON 因而成为模型与业务系统之间的契约。DeepSeek 虽然提供 JSON 输出模式，但它不会自动理解私有字段和教学语义，真正的稳定性来自对模型行为、提示词结构、参数设置和工程校验的共同约束。下面从四个关键层面拆解可复用的技巧。
1. 理解 JSON 输出的底层约束
DeepSeek 的 JSON 输出模式通常通过 API 的 response_format 参数开启，将 type 设为 json_object 后，模型会尽量返回可解析的 JSON 对象。这个模式解决的是语法层面的概率问题，而不是数据库意义上的表结构强制。模型仍然按 token 概率逐字生成，字段遗漏、类型漂移、数组长度不符、嵌套层级错位都可能发生。官方文档往往会提示，提示词中必须出现 JSON 字样，最好给出一个目标示例，否则接口可能报错或返回空内容。实际调用时还要给足 max_tokens，因为输出一旦被截断，尾部缺少右花括号，整个结果就会变成非法 JSON。
在 AI 指导老师场景中，最常见的误用是只写一句“请返回 JSON”，却没有说明字段名、字段含义和取值范围。比如让模型生成错题归因，它可能返回一段自然语言，再附上 Markdown 代码块；即使代码块里是合法 JSON，字段也可能叫“原因”“建议”“知识点”，与下游解析器约定不一致。JSON 模式只保证大概率语法合法，不保证语义正确，更不保证业务字段完整。把模型当成一个需要明确契约的协作方，而不是数据库，是设计提示词的前提。
还要注意模型版本、上下文长度、流式输出和并发限流带来的边界影响。推理型模型在长链思考后可能把 JSON 放在末尾，流式场景下不能等到完整响应再解析，而要用增量缓冲识别对象闭合。并发高时，超时和截断会增多，重试策略必须与限流配合。理解这些约束后，才不会把偶发失败归因于模型“不听话”，而是从接口参数、提示词和工程侧逐一排查。
2. 用 Schema 设计锁定教学数据结构
在写提示词之前，先设计 JSON Schema，再让 DeepSeek 按 Schema 填充。教学数据结构通常包含任务类型、学段、学科、知识点数组和题目数组。以数学辅导为例，一个可用的顶层对象可以包含 task_type、grade、subject、knowledge_points、questions 和 metadata。questions 中每个元素包含 id、stem、options、answer、explanation、difficulty 和 source。嵌套层级最好控制在三层以内，数组元素保持完全一致，这样解析器和校验器都容易维护。字段名建议用英文短横线或下划线风格，字段值再用中文，避免编码和转义带来的额外问题。
Schema 不能只以 TypeScript 接口或表格形式丢给模型，还要用自然语言解释每个字段。比如 difficulty 取 1 到 5 的整数，1 代表基础，5 代表竞赛拓展；options 在选择题中为四个字符串，在主观题中为 null；knowledge_points 必须从给定的知识点列表中选择，不允许自创。最小示例要覆盖选择题、填空题和主观题，还要覆盖信息不足时用 null 的情况。对于错题诊断，可以定义 student_id、error_type、root_cause、evidence、recommended_exercises 等字段，并限定 error_type 为概念混淆、计算失误、审题偏差、方法缺失等枚举值。枚举越明确，模型越不容易自由发挥。
可选字段和空值处理是 Schema 设计中最容易被忽略的部分。模型倾向于把空值填成“暂无”或空字符串，而解析器可能只接受 null。可以在提示词中明确，未知信息统一用 null，数组无内容时用空数组，不要编造。Schema 还要版本化，比如 schema_version 字段，每次字段调整都同步更新提示词、校验器和数据库映射。AI 指导老师面对的是持续迭代的课程体系，今天可用的字段明天可能扩展，提前版本化能减少线上事故。
3. 提示词与参数协同控制输出稳定性
提示词结构决定了 DeepSeek 对任务的优先级判断。系统消息适合设定角色和格式纪律，例如“你是 K12 数学教研助手，只输出 JSON 对象，不要 Markdown 代码块，不要解释，不要添加 JSON 之外的任何字符。”用户消息再提供具体任务、输入数据和 Schema 说明。把格式要求放在系统消息中，比放在大段任务描述末尾更稳定。若模型仍输出 “`json 围栏，可以在后处理阶段剥离，但不要因此放弃在提示词中约束，因为围栏越少，解析链路越短。
参数设置要与提示词配合。temperature 建议设在 0 到 0.3 之间，减少字段名和枚举值的随机漂移；top_p 可保持在 0.8 附近；频率惩罚不宜过高，否则可能破坏 JSON 键的重复模式。max_tokens 要按目标 Schema 估算，批量生成十道题和单题诊断所需长度完全不同，留出 20% 到 30% 余量能降低截断概率。开启 response_format 的 json_object 后，提示词中仍要包含 JSON 字样和示例，这是 DeepSeek 稳定触发 JSON 模式的重要条件。对于批量任务，可以在提示词中要求模型先按顺序填充字段，但最终只输出 JSON 结果。
Few-shot 示例是稳定输出的关键杠杆。准备两到三个高质量示例，覆盖正常输入、边界输入和错误输入，示例本身必须是合法 JSON，且字段顺序、类型和嵌套结构与目标一致。示例不要太多，否则占用上下文并可能让模型机械复制。AI 指导老师还要加入防幻觉约束，例如“知识点必须来自给定列表，题目答案必须可验证，信息不足时使用 null”。如果任务复杂，可以拆成两阶段，第一阶段让模型输出字段填充计划，第二阶段只负责按计划生成 JSON，但对外仍然保持单次结构化返回。这样能在不增加下游解析复杂度的前提下，提高字段准确率。
4. 解析校验与重试机制保障可用性
DeepSeek 返回内容后，第一步不是直接入库，而是做防御性提取。即使提示词要求纯 JSON，模型仍可能带上“以下是结果”或代码块围栏。可以用正则匹配第一个左花括号到最后一个右花括号，再尝试 json.loads 解析。解析成功后进入 Schema 校验，检查必填字段、数据类型、枚举范围、数组长度和嵌套结构。比如选择题要求 options 为四个字符串，answer 必须是 A 到 D 之一，difficulty 必须是 1 到 5 的整数。校验器还要做归一化，把“A.”转为“A”，把“1”转为 1，把空字符串转为 null，减少模型格式波动对业务的影响。
校验失败后要进入有策略的重试，而不是原样重复请求。把校验错误摘要附加到下一轮提示中，例如“上一次输出的 answer 字段不是 A 到 D，请只修复 JSON，不要改变其他字段”。重试次数控制在两到三次，配合指数退避和限流，避免账单和延迟失控。若仍然失败，可以降级到规则模板或人工审核，并记录原始输出、错误类型、Prompt 版本和模型版本。这些日志是后续优化 Schema 和提示词的依据。对于批量生成教学题目的场景，可以给每个任务分配幂等 id，重试时覆盖同一条记录，防止重复入库。
在 AI 指导老师的真实流水线中，校验和重试往往比提示词本身更能决定可用性。以批量生成五十道小学数学题为例，Schema 要求每题四个选项、一个答案、一段解析和一个知识点。模型可能在其中几题返回五个选项，或把解析写成“略”，或把知识点写成大纲外的名称。校验器识别后，只针对失败题目重试，成功题目直接落库，整体成本远低于全量重跑。流式输出场景可以用增量解析库缓冲对象，遇到闭合再校验。把解析、校验、重试和日志串成闭环，DeepSeek 的 JSON 输出才能从演示能力变成稳定产能。
