OpenAI API Docs
Structured outputs
提供结构化输出和 JSON Schema 约束的官方能力说明，是本课“输出契约”部分的直接基础。
打开原始资料返回学习路线查看内容标准
Mindset
Free从会写提示到会立契约：提示设计与输出契约
真正可用的 AI 系统，不靠模型自由发挥，而靠清晰任务 framing、结构化输出和可验证的结果约束。
26 分钟
Beginner
Trust Layer
这节课为什么值得学
内容不是从碎片信息拼出来的，而是按“官方资料定义 + 产品实践抽象 + 可执行练习”三层整理。
Learning Objectives
理解提示词的作用是定义任务边界和输出责任，而不是让下游系统继续猜意思
区分自然语言要求、结构化输出和函数调用三种控制层级
学会把一个真实工作流改造成带 schema、验证和失败处理的输出契约
Practice Task
选一个你常用的 AI 场景，把当前自由文本输出改写成结构化契约：列出字段、字段类型、必填项、失败时该怎么处理，再判断这件事更适合结构化输出还是函数调用。
Editorial Review
已审核 · DepthPilot Editorial · 2026-03-09
课程中的结构化输出、函数调用和任务 framing 原则都锚定在官方文档。
课程强调“失败显性化”和“机器可验证”，避免把输出控制停留在表层格式建议。
本课目标是让用户开始掌控系统接口，而不是继续依赖模型自由发挥。
知识链路
这节课不是孤立文章，而是知识网络里的一个节点。先知道它连接了哪些底层能力，再决定下一步该补哪一层。
打开完整知识网络学会的证据
你能把一个真实任务从自由文本输出改写成字段、类型、必填项都清楚的契约。
你能判断这件事更适合结构化输出还是函数调用，并说明理由。
最容易掉进去的误区
把“请输出 JSON”误当成完整契约，实际没有字段约束和失败规则。
明明下游需要可验证结果，却继续依赖自然语言猜意思。
01
提示不是越详细越好，而是越清楚越好
很多人写 prompt 时，其实是在和下游系统一起猜意思。模型给一段看起来像结果的文本，后面的代码、人工或流程再去猜它到底想表达什么。更成熟的设计是先定义任务目标、输入边界和输出责任，让模型知道它要交付的不是“看起来差不多”，而是“满足约束的结果”。
02
没有输出契约，下游系统只能猜
当输出格式不稳定、字段名称漂移、缺失值默默混进结果里时，问题不在模型文采，而在系统没有契约。输出契约的本质，是把“应该返回什么”从模糊描述升级成机器和人都能检查的协议。这样失败时你能明确报错、重试或回退，而不是把坏结果静默吞掉。
03
什么时候用结构化输出，什么时候用函数调用
如果你要的是可解析、可验证的数据结果，例如分类标签、字段提取、计划草案、评估记录，结构化输出通常更合适；如果你要的是让模型触发某个真实动作，例如查数据库、发请求、创建资源，那么函数调用更合适。关键不是哪个词更酷，而是系统到底需要“返回受约束的数据”，还是“触发外部动作”。
04
真正成熟的系统，会让失败显性化
最危险的不是模型报错，而是模型输出看起来还行，下游也继续跑了，但里面已经埋了错误字段、错误类型或缺失信息。可靠系统的做法是：契约不满足就 loud fail；字段缺失就拒绝继续；版本变了就显式迁移。这样你训练的不是“模型更会说”，而是“系统更会约束、验证和止损”。
即时小测
用一组判断题验证你是否真的理解了核心边界，而不是只记住了表面说法。
问题 1
下面哪种情况最适合优先设计结构化输出契约？
问题 2
为什么“请用 JSON 返回”通常不等于真正的输出契约？
问题 3
当模型输出缺失关键字段，但语气看起来很完整时，最成熟的系统行为是什么？
全部答对后会自动记入本地学习进度。
用你自己的话解释
反思不是附属品，而是把知识变成能力的关键步骤。
你现在最常用的一个 AI 输出，最容易让人或系统“猜意思”的地方在哪里？如果你要把它改成真正的输出契约，你会固定哪些字段、哪些类型、哪些必填项，以及失败时怎么止损？
内容保存在浏览器本地。
知识卡片
把当前课程压缩成一个可复用的工作记忆单元。
Concept
Output Contract
Explanation
把模型输出从模糊自然语言升级成可解析、可验证、可失败显性化的协议。
Practical Use
用于信息提取、评估结果、计划生成、工作流中间状态等任何需要被系统稳定消费的结果。
收藏后可在本地知识库页面回看。