摘要： 用同一条虚构订单对照三种输出格式，解释JSON语法、字段校验和事实正确的区别，并提供可复制提示词。
要求AI“用JSON回答”，能表达格式偏好，却不等于结果一定能被程序接收。真正稳定的流程要分别检查：能否解析、字段是否符合约定、内容是否来自原文。三项中的任何一项失败，都可能让后续自动化出错。
先决定结果给谁使用
| 格式 | 适合场景 | 需要特别检查 |
|---|---|---|
| 自由文本 | 给人解释原因、背景和建议 | 事实、遗漏、歧义 |
| 表格 | 人工对比少量记录 | 错列、换行、缺失值 |
| JSON | 程序读取字段、继续处理 | 语法、类型、必填项、内容来源 |
JSON很适合机器，但并不自动比文字更准确。把虚构金额写进合法JSON，解析器仍会接受。表格也不天然等于CSV，网页上整齐的Markdown表格，复制后未必就是规范的数据文件。
同一份资料的三种表达
原始资料：订单0078，买12个文件夹，单价8.50元，合计102元，尚未提供收货人。以下结果均为本站编写的教学示例，不是某模型的测试成绩。
自由文本：订单0078包含12个文件夹，金额102元；收货人尚未提供。它适合提醒人工补充资料。
| 订单号 | 数量 | 单价（元） | 金额（元） | 收货人 |
|---|---|---|---|---|
| 0078 | 12 | 8.50 | 102.00 | 未提供 |
{
"order_id": "0078",
"quantity": 12,
"unit_price": 8.5,
"amount": 102,
"recipient": null,
"currency": "CNY"
}编号用字符串，数量和金额用数字，缺失收货人用null。这里约定币种为人民币，与原始资料的“元”及教学背景一致。真实业务若币种未知，不应自行补CNY。
一段更完整的提示词
只从下面的订单原文抽取，不补猜的信息。
只返回一个JSON对象，不带Markdown代码围栏或解释。
键：order_id、quantity、unit_price、amount、recipient、currency。
order_id必须是字符串，保留前导零；数量是整数；金额是数字。
缺失字段用null，不能写"未知"或空字符串代替。
币种只有原文或已给定业务背景明确时才填写，否则null。
原文：……提示词里的字段名与接收程序要完全一致。若有时叫“price”，有时叫“unit_price”，即使人看得懂，程序也可能读取不到。需要变更字段时，同时修改校验规则与调用方。
三层验证怎么做
- 语法：使用JSON解析器读取，确认没有单引号、尾随逗号、注释或多余说明。
- 结构：校验必填键、数据类型和枚举。数量为字符串“12”与整数12，不应默认混用；收货人允许空值，也要在规则中写明。
- 语义：回看原文，确认编号、金额和姓名没有被“合理补齐”。再核对12×8.5＝102，发现矛盾时返回待核查状态。
本站已对上面的JSON执行解析和字段类型检查。你可以用Python的json.loads完成第一步，再用JSON Schema库处理结构约束。对钱的精确运算，可采用分为单位的整数或十进制计算，避免把浮点数显示误差当成业务差额。
API结构化输出解决了什么
部分API提供受支持的Schema约束或严格工具参数校验，比单纯在聊天框写“请输出JSON”更有结构保障。但不同服务支持的Schema范围、拒绝响应及中断处理不同，应按实际文档实现；结构保障也不替代事实核查。
失败后别只发一句“重来”
给出最小错误信息，例如“quantity应为整数，当前是字符串；请保留其余已核对字段，只修正类型”。同时保留原输入和失败输出。若内容缺失，应追问资料，而不是让AI再猜一个值。示例驱动的提示方法可接着看少样本提示的示例与边界。
资料来源与核查日期
资料核查：2026年10月22日至23日。产品条件可能调整，具体操作以当前官方页面为准。