核心 GUIDE
PATTERNFOUNDATION6 分钟阅读
Structured Output 是应用契约
JSON 结构只有在应用同时验证语法与下游业务语义时，才真正成为可依赖的边界。
核心心智模型
Structured Output 把自由文本生成变成 Boundary Contract，但在无效值与语义上不可能的组合被拒绝之前，这个 Contract 仍然是不完整的。
为什么重要
JSON 能成功 Parse，不等于得到了有效的业务对象。生产系统需要在生成结果进入数据库、Tool 或用户可见操作之前，捕获缺失字段、错误 Enum、不可能组合以及 Schema Version Drift。
01
从格式升级为 Contract
强边界至少包含两层：Structural Validation 检查类型与 Required Field，Semantic Validation 检查领域规则。再加上版本管理与 Bounded Repair，失败就会成为显式证据，而不是被静默转换成看起来正常的数据。
02
例子：JSON 合法，但订单不可能成立
模型返回了合法 JSON，其中 quantity 是 -3，Shipping Method 也不允许用于当前目的地。Parser 会接受它；Schema 可以捕获负数；Semantic Validation 则负责发现目的地规则冲突。不同验证层保护的是不同 Invariant。
常见失败模式
- 把“合法 JSON”直接等同于有效应用数据。
- Validation 失败后盲目重复同一个 Prompt。
- Schema 变化时没有显式 Version Handling。
工程启发
- 把结构校验与业务语义校验分开。
- 将精确 Validation Error 反馈给有限次数的 Repair。
- 只有通过 Contract Boundary 后，才允许结果触发下游 Side Effect。
关键结论
- 01结构化能够减少歧义，但不能消除语义错误。
- 02Validation Error 是能够指导 Repair 的证据。
- 03Contract 应该存在于应用边界，而不只是写在 Prompt 中。
来自 Knowledge Graph 的相关知识点
这些关系直接来自 canonical graph，不维护第二套 Guide 分类体系。