夜雨聆风星漫宇航｜AI名词百科 · 第23篇
销售同事刚结束一场客户沟通，需要把会议重点记录下来，方便后续跟进。
CRM（Customer Relationship Management，客户关系管理系统）是企业用来集中管理客户资料、沟通记录和销售进展的系统。过去，销售通常需要手动把客户需求、预算情况和后续安排分别填进不同字段。
现在，CRM 页面里多了一个“AI 整理跟进记录”按钮。点击后，系统需要的不是一段泛泛的会议总结，而是一组可以直接写回 CRM 的字段信息：客户需求、预算范围、决策进展、下一步动作、建议跟进时间和风险等级。
如果 AI 只返回一段自然语言，员工还能读懂，但 CRM 很难判断哪一句该填进“预算”，哪一句是“下一步动作”。更麻烦的是，同一种信息每次写法都可能不同。
上一期我们讲了 API（Application Programming Interface，应用程序编程接口）。它让软件能够向模型服务发送请求，并接收结果。接下来还有一个问题：软件收到一段自然语言后，怎样才能稳定地读取和使用？
这就是 Structured Output，也就是“结构化输出”要解决的事。
在本文讨论的企业应用场景中，Structured Output 可以理解为：让模型按照预先声明的数据结构返回结果，使软件能够更稳定地读取、校验和处理这些结果的能力或调用方式。
它不是让模型变得更懂业务，也不是让答案天然更正确。它解决的是：模型生成的内容怎样从“给人看的文字”，变成“软件可以接着处理的数据”。
先看结论
1. Structured Output 让模型按预先定义的字段、类型和规则返回结果，软件不必从一大段自然语言里反复猜测信息位置。
2. JSON（JavaScript Object Notation，一种常见的数据表达形式）用于装载字段内容。Schema（模式定义，用于明确需要哪些字段、字段应是什么类型、哪些字段必填，以及哪些值受到限制的规则）则像一份字段说明书。
3. 结构化输出能提高结果的可读取性，但不能保证内容真实。系统仍要校验业务规则，并为失败、拒答和异常结果准备处理路径。
4. API 解决“怎样调用模型”，Structured Output 解决“模型怎样返回可用结果”。Tool Calling（工具调用）则负责让模型提出调用外部程序或系统的请求。
一、自然语言好读，软件却不一定好用
人和人沟通时，同一句话可以有很多说法。客户说“这个季度预算有点紧”，销售可能理解为预算有限。客户说“先内部讨论一下”，销售可能判断为还没有形成明确决策。
人可以结合上下文理解这些表达。但软件要把信息写进 CRM，通常需要更明确的结果。例如，系统希望每次都拿到客户需求、预算范围、决策状态、下一步动作和风险等级。
如果模型返回的是一篇流畅的总结，信息可能都在，却散落在不同句子里。程序要继续解析、猜测和拆分，稳定性会变差。
所以，结构化输出的核心不是让回答“更像表格”，而是让模型的结果有一个可被程序识别的固定骨架。
同一份客户沟通内容：自然语言总结与结构化字段的区别
二、JSON 和 Schema：一个装内容，一个定规则
JSON 与 Schema：内容容器和字段说明书
JSON
在这个例子中，JSON 可以把信息写成“字段名 + 对应内容”的形式。客户需求、预算范围、风险等级都可以成为单独字段。软件收到后，不需要从段落里找关键词，可以直接读取相应位置。
不过，JSON 本身只说明数据怎样写，不说明数据一定符合业务需要。一个结果即使格式像 JSON，也可能缺少“下一步动作”，把风险等级写成系统不认识的词，或者把日期写错。
Schema
在这个例子中，它会把软件期待的结果结构提前写清楚。它会明确告诉模型和系统：需要返回哪些字段，每个字段是文字、数字、日期还是选项，哪些字段不能缺少，以及某些字段允许哪些值。
字段之间的业务关系，例如预算下限不能高于预算上限，通常还需要由应用在后续校验中判断。
例如，风险等级只能是“低”“中”“高”，建议跟进时间需要是日期，预算下限不能高于预算上限。
在很多模型 API 中，开发者会把这类 Schema 一起提交，由服务在生成阶段尽量约束模型按结构返回。不同产品对 Schema 的支持范围并不完全相同，因此企业仍要看清所用模型和接口实际能保证什么。JSON 是内容的装载形式，Schema 是内容应当遵守的结构规则。
三、一次结构化输出，通常怎样发生？
Structured Output 并不是模型凭空知道企业表单长什么样。系统需要先把“期待什么结果”说清楚。
1. 应用声明结果结构
CRM 先定义这次任务需要的字段，例如客户需求、预算范围、决策状态、下一步动作和风险等级。它还会说明哪些字段必填，哪些字段只能从固定选项中选择。
2. 应用发送任务和必要上下文
系统把可访问的会议记录、客户背景和整理要求发送给模型，同时附上这份结构说明。敏感数据是否可以进入调用，仍要由企业的权限和数据规则决定。
3. 模型按结构生成结果
模型不再只追求写出一段顺畅的总结，而是尝试把信息填入指定字段。某些 API 还会在生成时对结果结构施加约束，让返回内容更接近预期格式。
4. 系统校验并决定下一步
软件收到结果后，先检查它能否被读取，字段是否齐全，选项和日期是否符合规则。通过后，才可以展示给员工、写入 CRM 或进入后续流程。失败时，系统可以提示补充信息、重新请求，或者交给人工确认。
这里最容易被忽略的一点是：结构化输出不是把校验工作交给模型，而是让模型输出更适合被系统校验。
从会议记录到 CRM 字段：Structured Output 的四步流程
四、它能解决什么，又不能解决什么？
让结果更容易进入后续流程
有了稳定字段，软件可以把“下一步动作”写成待办，将“建议跟进时间”放入提醒列表，把“风险等级”为高的记录交给主管复核。这些动作的前提不是模型突然获得了执行权，而是软件终于能够明确读取模型给出的信息。
让异常更容易被发现
自然语言里藏着一个不完整字段，人不一定马上发现。结构化结果可以让系统直接检查：预算范围是否缺失，日期是否符合格式，风险等级是否在允许范围内。这会让错误更早暴露，而不是让错误消失。
它不保证事实正确
如果原始会议记录没有提到预算，模型仍可能根据上下文猜出一个数字。即使这个数字被放进了正确的“预算范围”字段，内容也可能是错的。因此，结构正确和事实正确是两件事。对于合同金额、客户承诺、财务数据等关键内容，系统仍应保留原文依据、人工确认或业务系统核验。
它也不能替代业务规则
Schema 可以规定“风险等级只能填低、中、高”，但不能单独判断某个客户到底应该被评为“高风险”。这仍需要清晰的业务标准、可靠的输入和必要的人为审核。Structured Output 解决的是“结果怎样被软件读懂”，不是“结果是否已经替企业做对了判断”。
五、Structured Output 在企业 AI 地图中的位置
把最近几篇连起来，关系会更清楚。Prompt（提示词，即向模型说明任务和要求的输入）帮助我们把任务说清楚。RAG（Retrieval-Augmented Generation，检索增强生成，即先检索相关资料再让模型回答）和 AI 知识库帮助模型参考企业资料。API 让软件能够调用模型并接收结果。
Structured Output 让模型返回的软件更容易读取和校验。Tool Calling 则让模型能够提出调用外部程序或系统的请求。
从 API 到 Tool Calling：Structured Output 所在的位置
因此，Structured Output 处在“模型生成结果”与“软件继续处理结果”之间。它让企业 AI 从“给出一段可读的回答”，走向“返回一份能够进入表单、流程和规则校验的数据”。
结尾总结
回到 CRM 的“AI 整理跟进记录”按钮。如果模型只写出一段总结，员工还需要自己摘取重点、填进不同字段。Structured Output 则让系统提前说明需要什么字段和规则，让模型的结果更像一份可以继续处理的记录。
记住一句话：API 负责把模型接进软件，Structured Output 负责让软件更稳定地接住模型的结果。
但字段整齐，不等于内容一定正确。对于会影响业务记录、客户承诺或后续操作的关键字段，系统仍要结合权限、原始依据和人工确认来使用模型结果。
注：文章插图均由 AI 辅助生成。
星漫宇航
概念学清，项目做实，前沿看懂。复盘迭代，持续精进。