输出格式其实是一份接口契约
理解字段、类型、必填项和失败返回怎样决定结果能否被下一步使用。
先用本课建立“格式约束”的基本直觉,后面的判断和练习才不会只靠记结论。
建议按完整课程顺序先看上一课;如果术语陌生,可以随时回补。
- 无需安装新工具
- 直接阅读并完成本页理解检查
输出不是只给人阅读时,格式就不再是审美偏好。字段名、数据类型、缺失值和错误返回会决定结果能否进入表格、程序或下一位协作者。
能用接口契约视角解释为什么“请用表格输出”仍然不够明确。
核心概念
先把关键判断说清楚
形状与含义缺一不可
字段名规定形状,字段说明规定含义;只有 `score` 而不说明范围和依据仍不可用。
缺失值要显式
用 null、空数组或待确认状态表示缺失,不能让模型为了填满格式而猜。
失败也是合法响应
输入不完整或无法判断时,应返回规定的错误结构,而不是破坏 Schema。
案例拆解
“用表格列行动项”为何导入失败
不同运行有时输出三列,有时把日期写进事项文本,自动导入无法稳定解析。
- 01
固定字段为 task、owner、due_date、evidence、status。
- 02
规定 due_date 使用 YYYY-MM-DD,原文无日期时为 null。
- 03
无法确认负责人时 status=needs_review,并在 evidence 保留原句。
格式同时规定了字段、类型和不可判断时的返回,自动导入不再依赖人工猜列。
提交前练习
现在轮到你
把一个“用表格或 JSON 输出”的旧要求改成接口契约。
选做练习:本节练习可用于加速你巩固,但不影响继续学习。
查看参考答案与评分标准
参考答案
字段,claim=string,source_quote=string,confidence=high|medium|low,status=verified|needs_review;source_quote 缺失时为 null 且 status 必须 needs_review;解析失败返回 error_code 和 missing_fields。
评分标准
- 字段语义和类型齐全
- 缺失值不会诱导模型猜测
- 失败响应保持固定结构
本课收口 · 理解检查
用 30 秒确认你理解了
用 30 秒理解检查确认你抓住了重点;阅读标记、练习和总结都不设硬门槛。
资料来源
继续核对与延伸阅读
本课内容最近更新于 。
- JSON Schema Core Specification 2020-12↗standard · 核对日期 2026-08-23
- Prompt Engineering↗official-docs · 核对日期 2026-08-23