Structured Output：客服意图与参数提取｜课后复习
课程名称：Structured Output：客服意图与参数提取｜项目任务：客服意图与偏好对象｜编号：W04-D03
图中每次失败都可观察；只有语法、Schema/类型和业务规则全部通过，才产生对象。事实依据仍由 D04 API（应用程序接口） 提供。
今天的主线
json.loads只解决语法；- strict 类型、枚举、范围、required 和 extra 解决结构；
- 缺 ID/missing_slots 等属于跨字段业务规则；
- customer_id 永不来自模型；
- bounded repair 有上限、成本、首次错误和终点。
风险怎么防、怎么发现、怎么处理、怎么复验
| 风险 | 提前预防 | 怎样发现 | 怎样处理 | 怎样复验 |
|---|---|---|---|---|
| extra 被忽略 | extra=forbid | 注入 customer_id 仍通过 | 改严格配置 | extra 红测失败 |
| 错类型被转换 | strict 输入 | 字符串预算变整数 | 拒绝并修 Prompt/输入 | 类型红测 |
| repair 无限循环 | 固定上限 | usage/尝试持续增加 | 进入停止终态 | repair-exhausted 用例 |
| 改 Schema（数据结构约束） 破坏旧样本 | 先写兼容测试 | 全量回归失败 | 最小改动或版本策略 | 新旧用例全绿 |
自测
- JSON（结构化数据交换格式） Mode 与本地 Pydantic（Python数据校验库） 各自能保证什么？
- 为什么 extra customer_id 不应静默丢弃？
- 修复成功后为什么还要记第一次成本？
- 为一个可选偏好字段写兼容测试思路。
面试考点与面试题
考点：JSON Mode、JSON Schema、Pydantic、额外字段、跨字段校验、bounded repair。
- 为什么 json.loads 成功仍不能进入业务系统？
- 远端 strict 和本地验证各自负责什么？
- extra=forbid 在 LLM（大语言模型） 应用里有什么工程价值？
- 怎样设计有限修复，避免成本失控和事实漂移？
留给 D04
交付严格对象、校验器、失败对象、bounded repair 和结构评测。D04 只允许验证通过的对象进入固定商品筛选和受控只读 Function Calling（函数调用）。
和下次课的衔接：带去 D04 的是你自己跑出来的证据、失败复盘和已冻结的输入/输出约定。