模型写得流畅却缺字段，往往是因为你先写「请写得专业」，却没先写「必须有哪些键」。Schema First：先冻结输出结构，再补语气与示例。

适用场景

生成周报 JSON、客服工单字段、RAG 引用列表、或任何要对进表格/数据库的结果。

流程概览

  1. 列出字段名、类型、是否必填、枚举值
  2. 给 1 个合法示例与 1 个非法示例（可选）
  3. 再写任务背景与语气
  4. 要求模型先输出结构，再填内容；或只输出结构实例
  5. 用校验脚本/人工表头核对

提示词模板

【输出 Schema】（严格遵守，不要增删字段）
- title: string, 必填
- items: array of {name: string, status: enum[open,done]}
- risks: string[], 可空
- needs_human: boolean
【任务】根据下列材料填充 Schema。
【材料】：
【规则】只输出一个 JSON 对象；未知字段填 null 并在 risks 说明；不要 Markdown 围栏外的解释。

与少样本的关系

少样本应示范「结构如何填」，而不是示范文笔。选例方法见少样本示例怎么选。

技巧与坑

  • 枚举写全；模型爱发明近义状态名。
  • 长散文字段单独放，避免破坏整表解析。
  • 若平台支持 JSON mode / tool calling，优先用平台能力，提示词作补充。

对照：结构后置 vs 结构先行

结构后置常见结果：漂亮段落但缺 needs_human。结构先行常见结果：字段齐、语气稍后用第二轮润色。

小结

先锁 Schema，再谈文采。对接系统的提示词，结构就是合约。

第二轮再润色

先产出合法 JSON，再用另一轮提示把某个字符串字段润色成对外文案。两轮分离，可避免「为了通顺而改字段名」。

校验失败怎么办

自动重试时应固定 Schema，只允许模型改字段值；不要在重试时顺便「优化」字段结构，否则对接方崩溃。

与工具调用的关系

若平台支持 function calling，把 Schema 定义成工具参数，通常比纯文本 JSON 更稳。提示词仍需写清「何时调用」与「缺字段怎么办」。本地开源模型若无可靠 JSON 模式，用更严的少样本与校验重试；校验失败不要把坏 JSON 写入生产库。

团队协作时，把 Schema 放进仓库的 schemas/ 目录，提示词只引用版本号。这样改字段会经过评审，而不是某次聊天里随手加键。对接方（表格、数据库、工作流）以 Schema 为合约，生成端与校验端共用同一份定义。若必须兼容旧版，显式写 schema_version 字段，便于迁移。润色轮不得改版本与键名。

相关阅读