Schema 归一化导读
结构化输出和工具调用常见的问题，不在于模型不会生成 JSON，而在于不同 provider 对 schema 的校验严格度并不一致。
schema normalization 的作用不是“悄悄改 JSON”，而是让不同 provider 在面对严格 schema 时 行为更一致，减少你在客户端和应用层为每个 provider 单独写兼容逻辑的成本。
它会修什么
| Name | Type | Required | Description |
|---|---|---|---|
required | repair | 把遗漏或不完整的 required 字段补齐，减少 provider 严格校验失败。 | |
additionalProperties | repair | 把对象额外字段策略补成更一致的形态，避免严格 provider 直接拒绝。 | |
nested object shape | repair | 修补嵌套对象和数组里的 schema 细节，让深层结构也更稳定。 |
一个典型前后对比
json
// 原始 schema（常见问题：additionalProperties 未声明）
{
"type": "object",
"properties": {
"severity": { "type": "string" },
"summary": { "type": "string" }
},
"required": ["severity", "summary"]
}
// 归一化后（更适合严格 provider）
{
"type": "object",
"properties": {
"severity": { "type": "string" },
"summary": { "type": "string" }
},
"required": ["severity", "summary"],
"additionalProperties": false
}它解决的是 provider 差异，不是业务建模能力
如果你的 schema 本身就表达错了业务含义，归一化不会替你修产品设计。它做的是把 “原本合理但不同 provider 接受度不同”的 schema 调成更稳定的交集。
什么时候特别值得开
- 你在多个 provider 间切换，而且 JSON schema 经常被拒。
- 你要做严格 machine-parseable 输出，而不是“差不多像 JSON 就行”。
- 你不想在应用层为 OpenAI、Anthropic、Google 分别写一套 schema 兼容逻辑。
最容易犯的错
text
1. 以为 schema normalization 会替你设计 schema。
2. 明明是业务字段定义错了，却把问题怪到 provider 身上。
3. 已经跨 provider 运行严格 schema，却还坚持每家手工兼容。
4. 只看模型输出，不看 provider 在 schema 校验阶段就已经拒绝。