JSON Schema 验证的是输出的形状（shape）。它并不验证该形状内数值的含义。在长达 9 个月的时间里，你的 AI 流水线产生的每一条输出都顺利通过了校验，监控显示 Schema 合规率为 100%，你的团队也理所当然地认为符合 Schema 的响应在契约层面就是正确的。接着，一次模型升级发布了，每一条输出依然能通过校验，但你的 Slack 告警频道却在一夜之间从每天 50 条消息飙升到了 800 条。
Schema 没有出问题，出问题的是其内部数值的分布。这就是大多数 AI 团队在生产环境中发现的鸿沟：JSON 契约是一个类型系统（type system），而非行为系统（behavior system），而下游消费者一直依赖于某种契约从未被要求强制执行的数值分布。
故障模式
想象一个分流流水线。模型接收一个入境支持工单，并输出一个如下所示的 JSON 对象：
{ "category": "billing" | "technical" | "account", "priority": "low" | "medium" | "high", "summary": string } Schema 在集成边界被强制执行。校验层会拒绝任何不匹配的内容。下游服务消费这些对象并应用一条业务规则：任何 priority: high 的工单都会升级到值班（on-call）的 Slack 频道。
九个月来，历史比例大致为 70% 低优先级、25% 中优先级、5% 高优先级。值班频道每天大约会看到 50 次升级，这是一个单人可以处理的负荷。容量规划、告警路由和轮值表都是针对这一比例进行校准的。
模型在周二早上发布了升级。新模型对自己的判断更加自信。同样的提示词（prompt）现在在（低、中、高）分布上产生了 30/35/35 的比例。每一条输出依然符合 Schema 校验。每一个枚举值依然在允许的集合内。校验层报告零拒绝。推理团队的仪表盘显示的依然是维持了九个月的绿色。
周二，Slack 频道收到了 800 条消息。值班人员无法跟上进度。下游服务因“告警骚扰”被立案。故障根因花了一周时间才找到，因为没有人去排查生产者；生产者的契约显示它非常健康。
Bug 不在模型中。Bug 在于那个假设——即认为语法层面的契约足以约束语义层面的依赖。
为什么 Schema 无法捕捉到这一点
JSON Schema 在设计上就是对结构的描述。它说明了存在哪些字段、它们持有哪种类型以及允许哪些枚举值。它不会说明每个枚举值出现的频率、字段的联合分布，或是下游系统所依赖的相关性。
这并不是 JSON Schema 的缺陷。这是类型系统的边界。类型系统回答的是：这个值在允许的集合中吗？它不回答：允许集合中的数值比例是否与你昨天看到的保持一致？
当输出生产者是一段确定性的代码时，这个问题很少出现。确定性代码不会在你毫无察觉的情况下悄悄改变其输出分布。但模型会。模型的输出分布是其权重、提示词、训练数据以及推理时设置的函数。其中任何一项都可能改变。当它们改变时，Schema 无法察觉。
将 Schema 校验视为生产契约的团队，实际上签署了一份生产者可以随意修改而不违约的合同。提供者可以发布一次升级，改变每一个下游决策的含义，而契约不会发出警告，因为升级并没有改变契约的指代物。指代物永远是形状，而非含义。
漂移潜藏的三个地方
在结构有效的输出中，有三个地方会以 Schema 无法捕捉的方式发生可靠的漂移。
枚举比例偏移 (Enum mix shift)。 模型开始产生不同比例的允许枚举值。上述例子就是这种情况。下游系统有一条基于特定数值的业务规则，而该规则的影响范围（blast radius）对该数值出现的频率非常敏感。
字段相关性偏移 (Field correlation shift)。 单个字段孤立看都正常，但联合分布发生了变化。旧模型产生 category: billing 配对 priority: high 的概率是 2%。新模型产生这种配对的概率是 18%。一个按类别进行键分区（key-partition）的下游队列路由规则是针对旧的联合分布设计的，现在 billing 分区过热。
自由文本长度和内容偏移 (Free-text length and content shift)。 summary 字段被定义为任意长度的字符串。Schema 对空字符串和 1 万个字符的字符串都感到满意。产生更长摘要的模型升级不会破坏校验，但它会破坏下游系统——例如将摘要索引到有单文档大小限制的搜索引擎中，或者一个假设平均长度为 200 字符的翻页 UI。
在每种情况下，Schema 的回答都是相同的：输出有效。但在每种情况下，下游系统的体验都是不同的，而唯一能告诉团队这种差异的，是 Schema 无法产生的度量指标。
真正的契约必须涵盖的内容 一个能够经受住模型升级考验的契约，除了 Schema 之外，至少还需要涵盖另外两点。
分布不变性（Distributional invariants）。 对于每一个其分布对下游消费方具有承重意义的字段，需指明基准分布和容差。例如：“在过去 7 天内，优先级比例为 70/25/5 ± 5 个百分点。”当产出的比例超出容差时，这应当被视为契约破裂，而非性能问题。其修复方式与类型破裂（Type break）相同：要么消费方更新其预期，要么生产方回滚。
已知共同依赖项的联合分布不变性（Joint distribution invariants for known co-dependencies）。 如果下游系统的正确性取决于字段的组合，请将这种组合写入契约。例如：“只有不到 5% 的输出应同时具备 category: billing 和 priority: high。”这比边际分布检查的维护成本更高，因此请将其保留给消费方真正敏感的连接点。
这种自律中最难的部分不是数学，而是识别哪些字段对哪些消费方是具有承重意义的。生产方和消费方团队通常会跳过这段对话，因为 Schema 让他们有了跳过的借口。基于 Schema 验证的契约给双方留出了一种错觉：只要通过了类型检查，集成工作就完成了。
弥合差距的模式 在经历过一次此类事故并决定不再重蹈覆辙的团队中，通常会出现四种模式。
分布监控作为生产方的责任。 生产方的仪表盘不仅包含 Schema 合规率，还包含每个枚举字段的滚动混合比例。当比例偏移超出设定基准的容差时，系统会触发警报。警报会路由到生产方团队，因为只有生产方才能决定这种偏移是否是有意为之。群体稳定性指数 (PSI)、Jensen-Shannon 散度或 Kolmogorov-Smirnov 检验是常用的统计工具；选择哪一种并不重要，重要的是必须运行其中之一。
带有数值分布不变性的契约测试。 集成测试套件不仅断言样本输出符合 Schema，还断言样本分布处于基准的指定容差范围内。如果模型升级导致分布发生偏移，那么在升级进入生产环境流量之前，契约测试就会失败。如果测试套件使用真实的生产环境提示词（Prompts）并针对候选模型进行重放，效果最佳，因为这样测量的分布就是升级后实际产生的分布。
在分布偏移下能够优雅降级的下游适配器。 消费方针对生产方无法保证不会发生的偏移进行加固。例如，Slack 升级规则会将每小时的触发次数限制在已知的上限，而不是对每一个 high 级别事件都触发告警。当某个分区的进入速率超过其基准的倍数时，按类别排序的队列会自动重新平衡。其前提是生产方最终总会发生偏移，而消费方在偏移发生时应当优雅降级，而不是直接崩溃。
AI 输出的语义化版本控制。 当生产方意识到行为变化时，会在响应封包中提升版本号。消费方锁定在一个版本上，并在迁移前重新进行评估。这是成本最高的模式，因为它需要团队间的协作，但这也是团队在经历第一次事故并意识到这种偏移是多么隐蔽之后，往往会采取的模式。协作的成本，本质上是承认契约始终带有社会属性，而非纯粹的技术属性。
你必须与下游消费方进行的对话 这其中最难的部分不是技术，而是生产 JSON 的团队与消费 JSON 的团队之间的对话。
生产方团队自然的表述是：“我们没有更改 Schema。我们没有更改 API。现在的模型更好了。输出仍然是有效的。”每一句话都是事实。
消费方团队自然的表述是：“我们的服务昨天还是健康的，今天就出故障了，而唯一的变量就是你们的升级。你们弄坏了我们的系统。”这句话也是事实。
双方都是正确的，因为他们谈论的是两种不同的契约。生产方团队遵循的是 Schema 契约。消费方团队遵循的是分布契约，但他们从未写下来，生产方团队也从未同意过。事故发生的那一刻，就是这份未成文的契约显形之时。
事故之后的收尾工作是将之前隐含的内容写下来。消费方的正确性依赖于哪些字段？比例是多少？在什么时间窗口内？偏移的容差是多少？Schema 本身不需要为了涵盖这些而膨胀。一份由双方共同拥有的独立分布契约可以做到这一点。关键在于，契约必须以某种形式存在，并且在破裂时能导致构建失败，而不是仅仅让值班人员的传呼机响个不停。
架构上的认知 JSON Schema 是针对输出的类型系统，而不是针对输出的行为系统。如果一个团队在符合 Schema 验证的契约背后发布了模型升级，那么在没有触发契约设计的任何防线的情况下，他们已经改变了下游每一个决策的含义。
补救办法不是放弃 Schema。Schema 能以较低的成本捕获语法类错误。补救办法是认识到，对于 AI 输出，Schema 是契约的底线，而不是上限。契约的其余部分必须通过代码、测试和仪表盘来编写，并且当生产方的分布偏离消费方的预期时，必须大声报错。
做得好的团队会将结构有效的输出视为必要非充分条件。他们监控生产方的分布，将消费方锚定在基准线上，并将分布偏移视为契约破裂，必须在流量继续之前完成调和。而那些做不到这一点的团队，最终会遇到某个周二：值班告警增加了 16 倍，生产方的仪表盘显示全绿，而事后分析报告解释说——模型变得更好了，但契约没有察觉到。
余下内容仅对会员开放。 会员可读完整内容 —— 每一个公开发布的观点背后，那些框架、决策与推理的全貌。
— 完整文章，包含未公开存档的部分 — 可落地的工作框架，附带权衡与决策依据 — 新文章抢先看，先于公开发布 登录以继续阅读→ 随时取消 · 一次订阅，畅读全部
