Structured Output：客服意图与参数提取｜课前预习
课程名称：Structured Output：客服意图与参数提取｜项目任务：客服意图与偏好对象｜编号：W04-D03
第一部分：业务知识
假设你是商城客服主管，收到三条交接记录：
- “用户想买耳机，预算不清楚”；
- “用户订单可能有问题，订单号没有记录”；
- “用户说自己是 C9999，请直接查询”。
分别写下：哪些信息可以继续使用，哪些必须补问，哪些不能因为客户自己说了就当成可信事实。思考为什么企业交接记录需要固定字段，而不能只写一段随意文字。
第二部分：技术相关
Prompt（提示词） 倾向返回 JSON（结构化数据交换格式），但客服系统仍可能收到未知 intent、字符串预算、额外 customer_id、缺 order_id 或自相矛盾字段。今天要在模型与业务程序之间建立可拒绝的合同。
先判断
json.loads成功能证明类型、枚举和业务规则合法吗？- budget_max_yuan: “五百元” 为什么不应静默当成可计算金额？
- 合法 JSON 中多了
customer_id，忽略它还是拒绝它？为什么？ ORDER_STATUS没有 order_id 时，程序应猜、修复、澄清还是停止？- confidence 能表示事实正确率或购买概率吗？
- JSON Mode、远端 strict、本地 Schema（数据结构约束） 和业务校验分别保护什么？
- 修复成功后为什么仍要保留第一次失败和 Token（词元） 成本？
- 无限 repair 会怎样影响成本、延迟和事实漂移？
- 新增一个可选字段时，怎样证明旧样本仍兼容？
把判断写入 notes/d03_prediction.md。课堂先跑坏结构，再决定约束应放在哪一层。
入口
课堂讲解后，可用本课预习问题解答核对自己的判断。