想把 JSON 结构化输出用好，先要知道哪些写法会拖后腿。先回顾一下：结构化输出是让 AI 按照固定的字段和格式返回结果，例如 JSON、表格或固定标题的清单。下面逐个拆解 5 个最常见的错误。

错误 1：字段名含糊

为什么不行：字段名含糊，比如“信息”“备注”看似省事，实际会让后续修改更费劲。

正确做法：每个字段写清含义和格式，比如“截止日期，YYYY-MM-DD”

错误 2：不说明缺失值怎么处理

为什么不行：不说明缺失值怎么处理。很多人第一次使用时都会这样写。

正确做法：明确“未提及填 null”，否则 AI 可能自己编一个值。

错误 3：要求 JSON 却允许附带解释

为什么不行：要求 JSON 却允许附带解释。看似省事，实际会让后续修改更费劲。

正确做法：写明“只输出 JSON”，程序解析时才不会因为多余文字报错。

错误 4：一次提取的字段过多

为什么不行：一次提取的字段过多。这样做的结果通常是输出偏离预期，还得花时间返工。

正确做法：字段太多时拆成两次，先提取核心字段，再补充次要字段。

错误 5：拿到 JSON 不做校验就入库

为什么不行：拿到 JSON 不做校验就入库。这样做的结果通常是输出偏离预期，还得花时间返工。

正确做法：用程序校验格式和必填字段，抽查内容是否与原文一致。

这些错误的共同根源

设计字段时要从“下一步怎么用”倒推。如果结果要做数据透视，字段值就要标准化；如果要人工复核，就需要保留原文依据；如果要导入系统，字段名最好与系统字段一致。先想清楚用途，结构化输出才真正省事。

顺带回答一个常见疑问——一次能处理多少条数据？取决于工具的上下文长度和稳定性，建议每次几条到十几条，批量更大时用脚本分批调用。

修正后的标准写法

把上面的修正综合起来，以自由职业者的场景为例，一个更可靠的写法是：

请从下面的项目提案片段中提取信息，只输出 JSON，不要解释。
字段要求：
{
  "主题": "字符串，不超过 20 字",
  "负责人": "字符串，原文未提及填 null",
  "截止日期": "YYYY-MM-DD 格式，未提及填 null",
  "风险点": ["字符串数组，最多 3 条"],
  "需要客户决策的事项": ["字符串数组"]
}
原文：
[粘贴内容]

如果你是自由职业者，还要额外注意一点：用 AI 把提案、报价说明和合同要点标准化，节省每次从零写的时间。

最后一个建议

批量处理时保持字段顺序不变，方便后续合并。记住结构化输出的原理——自由文本每次结构都不同，后续整理很费时；预先定义字段相当于给 AI 一张要填的表，结果更一致，也更容易检查遗漏——遇到新情况时就能自己判断怎么写。

一个简单的自查方法

把你的提示词发给一位不了解背景的同事看，如果对方需要追问才能动手，AI 多半也会理解偏差。把同事会问的问题提前写进提示词，效果往往立刻改善。

相关阅读