提示词工程 编辑复核
结构化 JSON 输出契约
把模型输出设计成字段、类型、枚举、缺失值和错误处理清晰的 JSON 或表格契约。
PROMPT WORKBENCH
复制后替换变量
保留结构，先填真实信息，再把结果交给模型运行。
你是一名模型接口设计师。请设计机器可解析且人能审核的输出契约，明确未知、拒答、枚举和部分成功状态。
先区分已知事实、合理假设和待核验信息；没有依据的内容写“待验证”，不要为了完整而猜测。
请按以下结构输出：
1. 下游程序和用户真正需要的字段
2. 字段类型、必填、枚举和嵌套关系
3. 缺失、未知、冲突和拒答表达
4. 有效与无效示例及校验规则
5. 解析失败、重试、人工审核和版本兼容
输入变量：
- 模型任务（{{task}}）：说明模型要完成的抽取或生成任务。
- 下游消费者（{{consumer}}）：说明程序、编辑或工作流如何使用结果。
- 目标字段（{{fields}}）：提供字段、类型和来源要求。
- 错误策略（{{errors}}）：说明校验失败和人工介入方式。
约束：保留用户的真实语气和业务边界；把事实、推断与建议分开；涉及日期、价格、版本、法规或安全的内容写明来源和采集时间。HOW TO USE
使用说明
- Schema 先由下游调用方确认，再写提示词。
- 解析成功不等于事实正确，仍需要来源和人工门禁。
WHEN IT FITS
适用判断
适合这些情况
- 输出结构复杂，有嵌套和可选字段。
- 结构会被多方使用，需要正式定义。
- 需要考虑结构未来的扩展。
换个做法更好
- 你只需要一个简单的 JSON 约定：用《JSON 输出契约》。
- 结构还在变：过早固化会频繁破坏兼容。
- 输出直接给人看：结构化反而不便阅读。
FAILURE MODES
常见翻车与修正
- Schema 定义了字段但没说必填还是可选，各方理解不一。
要求每个字段明确标注必填性、类型、取值范围和为空时的含义。
- 嵌套层级过深，模型经常生成结构不完整的输出。
要求控制嵌套层级，过深的拆成扁平结构或分多次生成，并说明拆分后如何关联。
- 没考虑扩展，加字段就破坏了现有调用方。
要求说明扩展策略：新字段一律可选、不复用已废弃的字段名、变更需要版本标识。
ACCEPTANCE
怎么判断输出合格
- 每个字段有必填性、类型和取值范围。
- 嵌套层级受控，过深的已拆分。
- 有扩展策略，加字段不破坏现有调用方。
- 定义了错误和空结果的表示方式。
SAFETY BOUNDARY
使用边界
- 契约约束的是期望格式，不是保证；解析端要有校验和降级路径。
- Schema 一旦被多方使用就很难改，字段命名和结构在定稿前多推敲。