← 返回概念解读

Concept Fable精修版

结构化输出

Structured Outputs · Model interface

先读故事。这里不急着给定义,先让问题自己长出来。

寓言故事

城门不再只看像不像表格,而是按契约验每一栏

物流城的城门每天接收外来报单。早年车少,守门人能边看边猜:这行像重量,那行像目的地,漏了货类就问车夫。

车队多起来后,猜测害了事。有人把重量写成“很重”,有人把目的地写成俗称,有人把危险货混在备注里。城门放行了,仓库、计费和调度全跟着乱。有车夫嫌麻烦,故意把“城北第三仓”写成“北边仓”,守门人按经验放行,结果整车盐被送到布匹仓。

守门人先放宽规矩,能补就补,能猜就猜。短期队伍快了,月底账却对不上:同一城名有三种写法,同一货类被分到两个仓。

城主于是改成契约验单。报单必须按固定格子填写:货名、重量、目的地、车号、风险标记、随行凭证,哪格必填、哪格只能选规定值,都刻在木板上。第一次刻板太宽,只写“目的地、货物、数量”。看似整齐,调度仍不知道货物能否淋雨、是否需冷库、凭证缺了能不能先入城。

书记员写单时就照木板生成;城门收到后仍逐格验。合格的直接入队,不合格的退回补写,疑难的交给人工柜台。

新规也没有假装解决一切。格子填齐,不代表货物真实;风险写低,也可能需要开箱复核。契约只保证下游能读、能校验、能分派,判断仍要证据和规则。后来木板也会更新。新货类出现,先补格子和取值;旧格子废弃,要通知所有仓口同步改,免得一边收旧话,一边按新账算。

车行刚开始抱怨退单变多。几周后他们发现,退在城门口总比错在仓库深处便宜;越早发现格式不合,后面的搬运、收费和赔付越少返工。

城主后来对各车行说,可靠报单要让每个字段都落在可检查的位置上,光写得像公文没有用。下游不再猜,整座城才不会被一段漂亮话拖乱。

揭示

这个故事讲的是:结构化输出

Structured Outputs 通常指比普通 JSON Mode 更强的 schema-constrained 输出能力,让模型响应尽量符合开发者提供的 JSON Schema 或类似结构约束。它适合 API 参数、工作流决策、数据抽取和企业系统集成。相比只要求有效 JSON,它更强调字段、类型、枚举、必填和嵌套结构的一致性,但仍需要应用层验证、业务规则和异常处理。

它重要的地方在于:它不只是一个术语,而是在真实 AI / Agent 系统里会反复出现的结构性问题。理解它,才能判断什么时候该加模型,什么时候该改流程,什么时候该补治理。

隐喻映射

  • JSON 形状报单:普通 JSON Mode 或弱格式约束
  • 重量写成文字、漏代码:schema 不一致问题
  • 放宽解析规则:脆弱的容错后处理
  • 契约验单:JSON Schema / structured outputs
  • 贴着契约生成:schema-constrained generation
  • 校验后进入调度:validate then execute
  • API、数据库、工作流衔接:下游系统集成
  • 最后洞察:Structured Outputs 用明确 schema 提升模型输出接口可靠性

Soloharness 判断

这个概念的实战价值,是帮你把“看起来聪明的 AI 功能”拆成可交付、可验收、可治理的工作单元。

JSON modeschema validationfunction calling