DeepSeek不支持原生JSON Schema强约束输出，需通过自然语言指令+严格示例引导格式，并配合后端校验确保结构正确。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
DeepSeek 不支持原生 JSON Schema 强约束输出
DeepSeek（包括 deepseek-chat 和 deepseek-coder 系列）本身没有内置的 response_format: { "type": "json_object" } 机制，也不接受 OpenAI 风格的 response_format 参数。直接在请求中加 schema 描述，模型大概率会忽略或“自由发挥”，尤其在长输出、嵌套结构或字段类型敏感时，"age": "25" 变成 "age": 25 都可能出错——这不是格式问题，是模型没被对齐过结构化输出能力。
用 system prompt + 示例强制结构化输出
最稳定的做法是：把 schema 转成自然语言指令，并搭配 1～2 个严格格式的输入-输出示例，塞进 system 消息里。模型没见过 JSON Schema 语法，但能模仿你给的格式。
- 用
```json包裹示例输出，且确保字段名、类型、顺序、空值处理（如null还是省略）全部显式写出 - 在指令中强调“只输出纯 JSON，不加任何解释、前缀、后缀、Markdown 代码块标记”——很多失败是因为模型多打了
```json或 “以下是结果：” - 避免模糊表述，比如不要写“按要求返回”，而要写“必须包含
user_id、score、tags三个字段，score必须为数字，tags必须为字符串数组”
示例 system 内容片段：
你是一个严格的 JSON 输出器。只输出符合以下结构的纯 JSON 对象，不加任何额外文本：
{
"product_name": "string",
"price": number,
"in_stock": boolean
}
示例输入：iPhone 15，售价 5999，有货
示例输出：
{
"product_name": "iPhone 15",
"price": 5999,
"in_stock": true
}后处理校验比前端强约束更可靠
即使 prompt 写得再细，DeepSeek 仍可能在边界 case（如空输入、多轮上下文干扰、字段值含换行）下偏离 schema。与其反复调优 prompt，不如默认走两步：
- 接收原始响应后，用
json.loads()尝试解析；捕获json.JSONDecodeError即重试或报错 - 用 Python 的
pydantic.BaseModel或jsonschema.validate()做字段级校验——比如检查email字段是否真为邮箱格式，created_at是否符合 ISO8601 - 对关键字段做类型兜底转换，例如
int(data.get("count", 0))，而不是假设模型一定输出整数
别依赖 temperature=0 来保结构
设 temperature=0 能降低随机性，但不能保证 JSON 合法性。实测中，即使 temperature 为 0，DeepSeek 仍可能漏引号、多逗号、嵌套错位。真正起作用的是 prompt 中的格式锚点（示例）+ 后端校验闭环。如果业务对 schema 一致性要求极高（如写数据库、对接下游 API），建议把 DeepSeek 当作“非可信输入源”，始终以 schema 校验为最终防线。
最容易被忽略的一点：模型不会主动补全缺失字段，也不会把 "is_active": "true" 自动转成布尔值——它只是照着你给的示例仿写。字段存在性、类型、枚举值都得靠你写死在示例里，再靠代码兜底。
