DP

DepthPilot AI

System-Level Learning

Assessment

输出契约实战:把结果做成接口,而不是做成一段看起来像 JSON 的话

这一课要求你把一个真实任务改造成机器可验证的输出接口。DepthPilot 关心的不是“模型会不会吐 JSON”,而是字段、类型、失败路径和下游消费方式是否已经明确。学完后你要交的是 contract spec、schema review 结果和失败策略,而不是一句“我已经要求它输出 JSON”。

最后要交什么

一份 output contract spec、一份 schema review checklist 结果,以及一套明确的失败策略。

真正的通过标准

不是模型大多数时候像 JSON,而是下游系统可以不靠猜测地验证字段、拒绝坏结果、并决定何时重试或停止。

我们的增值部分

这页把 framing 顺序、contract ladder、常见坏 schema 模式和交付模板变成了站内 runbook。

DepthPilot Summary

这节课真正教你的,是把模型结果变成可验证接口

很多团队说自己已经在做结构化输出,但下游仍然在猜字段、猜缺失值、猜失败原因。DepthPilot 在这里强调的是:先把任务类型分清,再写字段契约,再定义 invalid output 和失败策略。用户学完之后,应该能判断一个结果为什么不能直接进入系统,而不是只看它像不像 JSON。

先分清任务类型

  • 不是所有输出都该用 schema;有些任务本质上应该是工具调用。
  • 如果任务目标没有分清,后面的 contract 再严也会用错地方。
  • 结构化输出服务的是系统接口,不是视觉整齐。

再写字段契约

  • 字段、类型、必填项、枚举值和约束要先于示例存在。
  • 示例是帮助理解,不是代替契约本身。
  • 只说“返回 JSON”而不定义坏结果,等于把不确定性留给下游。

最后定义失败语义

  • parse 成功不等于语义正确,invalid output 也必须有处理策略。
  • 系统要知道何时 retry、何时 loud fail、何时停止向下游传播。
  • 真正的交付物是一个可验证接口,而不是一段看起来整洁的返回值。

Framing order

先判断这到底是数据返回任务,还是工具动作任务。

先明确下游系统需要什么字段、什么类型、什么失败语义,再写 prompt。

把 style、policy 和 schema 分开,别混成一段模糊要求。

最后才决定该用 response schema 还是 function calling。

Contract ladder

先写字段表和约束,再写例子,不要反过来。

为每个高风险字段写必填、枚举或范围约束。

明确什么叫 invalid output,失败时系统要 loud fail 还是 retry。

用最小样例验证解析成功并不等于语义正确。

High-signal bad patterns

只写“请返回 JSON”,却没有字段、类型和失败规则。

输出契约明明给机器消费,却塞进大量自由文本说明。

应该调用工具的任务却先做成结构化回答,导致后续还得再猜。

把 validation failure 静默吞掉,坏结果继续进入系统。

上线前必须保留的证据

一份字段、类型、必填项和约束都写清楚的 contract spec。

一份 schema review 结论,说明哪里会让下游继续猜。

一组样例,证明 success 和 failure 都可被系统识别。

一段你自己的复盘:这个任务为什么不该继续依赖自由文本输出。

Search Cluster

把输出契约接进可搜索的可靠性路径

高意图用户常常先从 structured outputs、prompt engineering、workflow course 进入,再决定是否做真正的契约设计和验收。

参考附录

这些来源是方法锚点。课程主体是上面的 framing order、contract ladder、坏模式识别和交付模板。

输出契约实战:把模型结果变成可验证接口,而不是继续猜意思 | DepthPilot AI