能聊不等于能接系统：JSON 稳流程才稳

水无痕
· 6 分钟阅读
能聊不等于能接系统：JSON 稳流程才稳
能聊不等于能接系统：JSON 稳流程才稳

凌晨两点，线上流程突然中断。排查日志后，原因令人血压飙升：模型在返回的 JSON 数据前多写了一句“好的，以下是您要的结果”。就这一句多余的文本，导致解析直接报错。

这是一个典型的工程陷阱：大模型能够写出大段漂亮、通顺的自然语言，但这并不意味着它能稳定地接入你的业务系统。系统需要的不是“差不多能看懂”的内容，而是字段、类型、数组、枚举和状态码必须一次都不能错地解析出来。

当模型负责抽取信息、调用接口、生成表单并将结果交给下游程序处理时，格式一旦混乱，整条链路就会断裂。因此，我们需要厘清两件事：结构化输出到底是什么，以及如何让模型真正稳定地输出 JSON。注意，这里的“稳定”是指真正的稳定，而非“大部分时候还行”。

结构化输出的定义与核心差异

结构化输出是指让模型按照预先定义好的结构返回结果，最常见的形态就是 JSON。

例如，系统需要知道用户意图、抽取到的实体、风险等级以及下一步动作。结构化输出要求每个字段对应一个明确的格子，规规矩矩地填充数据，可能包含数组、对象、枚举字段及嵌套结构。

它与普通回答的根本区别在于受众不同：

  • 普通回答：面向人读。评价标准是通顺、有条理、语气舒服。
  • 结构化输出：面向程序读。评价标准是机器可执行的严格规则。

程序在解析时只认五件事：

  1. 字段名是否正确。
  2. 数据类型是否正确。
  3. 必填项是否缺失。
  4. 括号是否闭合。
  5. 枚举值是否合法。

程序不会体谅，也不会“大概理解一下”。因此，结构化输出的关键词从来不是“像 JSON”，而是可解析、可校验、可接入。“像 JSON”只是给人看的错觉，这三个“可”才是给系统的承诺。

普通回答与结构化输出的本质区别

实现稳定 JSON 输出的三层约束

仅靠一句提示词无法让模型稳定输出 JSON，真正的做法是实施层层收紧的三层约束。

第一层：提示约束（地基）

这是成本最低的一层，也是最基础的地基。

  • 做法：明确告诉模型“只输出 JSON，不要解释，不要 Markdown 代码块，不要任何多余文本”，并提供字段说明和一个示例。
  • 局限：这层只是“请求”，不是“强制”。开场提到的“多写一句话”导致的翻车，往往就出在仅依赖这一层约束。

第二层：Schema 约束（规范）

  • 做法：使用 JSON Schema 或类似方式，将字段、类型、必填项、枚举值、数组结构全部定义清楚。
  • 意义：这一步将人脑中的需求翻译成了机器可以逐条检查的规范。从这一层开始，对错不再靠人眼判断，而是基于明确的规则。

第三层：解码或工具约束（强制）

这是最硬的一层约束。

  • 做法：利用模型和框架提供的结构化输出能力，如函数调用（Function Calling）、JSON Mode、受约束解码（Constrained Decoding）或专门的输出解析器。
  • 效果：从生成的那一刻起，就限制模型只能吐出合法结构。前两层是“告诉它该怎么写”，这一层是“让它写不出别的”。

实现稳定JSON输出的三层约束体系

工程兜底：解析、校验与修复

即使完成了三层约束，工程上仍必须做好兜底措施，不能假设模型输出一定是正确的。

  1. 解析校验：拿到结果后，先真正解析一遍。
  2. 失败重试：如果解析失败，应进行重试或自动修复，避免整条链路直接死掉。
  3. 业务规则检查：
    • 金额不能为负数。
    • 日期不能早于今天。
    • 枚举值不能由模型自行发明。
    • 这些业务逻辑层面的约束，模型本身管不了，必须由业务规则代码来管控。

工程兜底：解析、校验与修复闭环

关键边界：结构稳定不等于内容正确

这是最多人栽跟头的地方，也是结构化输出最重要的边界。

一个 JSON 可以语法完全合法，字段一个不少，类型全都对，但里面的值可能是模型编造的（Hallucination）。

常见的风险包括：

  • 字段编造：让模型抽取合同金额，它返回了一个漂亮的 number 类型，但数字来源不明。
  • 理由站不住：让模型判断风险等级，它老老实实返回了合法枚举值，但缺乏原文证据支持。
  • 引用不存在：让模型抽取引用，它给出了一段原文里压根不存在的句子。
  • 类型勉强合法但业务错误：例如该是整数却给了字符串包裹的数字，或者字段都对但组合起来在业务上完全说不通。

结论：结构化输出解决的是格式问题和接口问题，它不解决事实准确性问题。这是两条完全独立的战线。

如果只关注格式而忽略事实，你只是把一段不可靠的自然语言包装成了一个看起来很可靠的 JSON。而且，因为它长得规整，开发者反而更容易信任它，这比一眼就能看出胡说的回答危险得多。

结构稳定不等于内容正确：幻觉风险边界

真实系统中的应对策略

在真实系统中，为了弥补结构化输出在事实准确性上的不足，需要配套以下措施：

  • 提供原文引用。
  • 输出置信度。
  • 实施规则校验。
  • 结合检索增强生成（RAG）提供证据。
  • 必要时加入人工复核或下游工具验证。

面试视角：如何回答“让模型稳定输出 JSON”

如果在面试中被问到这个问题，仅回答“提示词写清楚”会直接暴露缺乏线上工程经验。建议按以下五层逻辑回答，层层递进：

  1. 定义：结构化输出是让模型按预定义的字段和类型返回结果。
  2. 目标：目标是让下游程序能稳定解析、校验和接入，而不是让人看着舒服。强调“面向程序”这一核心方向。
  3. 方法：用 Schema 描述结构，再用工具调用、JSON Mode、受约束解码或输出解析器去约束生成。强调“描述”加“约束”缺一不可。
  4. 兜底：对输出做 JSON 解析、Schema 校验、业务规则校验。失败时要重试、自动修复，必要时降级或转人工。这一层最能体现工程经验。
  5. 边界：明确格式正确不代表事实正确，仍需证据、校验和评估。

总结

稳定 JSON 从来不是一个提示词技巧，它是模型能力、结构约束和工程兜底三者合力完成的系统问题。

记住：稳定的 JSON 不是一句提示词，而是一整套结构约束加工程校验。