第11章 结构化输出：让大模型返回JSON、表格、代码

11.1 为什么需要结构化输出？

大模型默认返回自然语言文本，但在很多产品场景中，我们需要大模型返回结构化的数据——JSON、表格、代码、特定格式的文本。结构化输出是AI产品从"能聊天"到"能干活"的关键能力。

11.1.1 自然语言输出的局限性

大模型默认返回自然语言，在产品中存在以下局限性：

• 无法程序化处理：自然语言输出无法直接被程序解析和处理，需要额外的解析逻辑，而且解析容易出错
• 格式不稳定：同样的Prompt，大模型每次返回的格式可能不一样——有时候用列表，有时候用段落，有时候用表格，程序难以稳定处理
• 信息提取困难：从自然语言中提取关键信息（如金额、日期、姓名）需要额外的NLP处理，准确率不高
• 无法直接调用工具：Function Calling需要大模型返回结构化的工具调用参数（JSON格式），自然语言无法直接用于工具调用
• 无法保证完整性：自然语言输出可能遗漏关键字段，或者添加无关内容，程序无法判断输出是否完整
• 难以验证和纠错：自然语言输出的正确性难以自动验证，出错后也难以自动纠错

11.1.2 结构化输出的应用场景

结构化输出在AI产品中有广泛的应用场景：

11.2 结构化输出的4种方法

让大模型返回结构化输出，主要有4种方法，各有优缺点，适用于不同场景。

11.2.1 方法1：Prompt引导

原理：在Prompt中明确要求大模型返回特定格式的输出，给出格式说明和示例，引导大模型按照要求的格式输出。

示例：

你是一个信息提取助手。请从以下合同文本中提取关键信息，以JSON格式返回。

要求：
1. 只返回JSON，不要返回其他内容
2. JSON包含以下字段：
   - party_a: 甲方名称（字符串）
   - party_b: 乙方名称（字符串）
   - amount: 合同金额（数字，单位元）
   - sign_date: 签订日期（字符串，格式YYYY-MM-DD）
   - contract_type: 合同类型（字符串，可选值：采购合同、服务合同、租赁合同、其他）
   - key_terms: 关键条款（数组，每个元素是字符串）

示例输出：
{
  "party_a": "北京某某科技有限公司",
  "party_b": "上海某某贸易有限公司",
  "amount": 500000,
  "sign_date": "2024-01-15",
  "contract_type": "采购合同",
  "key_terms": ["交货期30天", "质保期1年", "违约金为合同金额的10%"]
}

合同文本：
{合同内容}

优点：

• 简单易用，不需要特殊的API支持，所有大模型都支持
• 灵活，可以定义任意格式的输出
• 不需要额外的开发成本

缺点：

• 格式不稳定，大模型偶尔会返回非JSON内容（如"好的，以下是提取的信息："），或者JSON格式有错误（如缺少引号、逗号错误）
• 复杂格式的成功率不高，嵌套结构、数组、枚举类型容易出错
• 需要额外的解析和验证逻辑，处理格式错误的情况
• Prompt较长，增加输入token成本

适用场景：简单的结构化输出、对格式稳定性要求不高的场景、快速原型验证、不支持JSON模式的模型。

11.2.2 方法2：JSON模式（JSON Mode / Response Format）

原理：通过API参数指定输出格式为JSON，大模型会强制返回合法的JSON格式。OpenAI、Anthropic、通义千问等主流模型都支持JSON模式。

示例（OpenAI API）：

from openai import OpenAI
client = OpenAI()

response = client.chat.completions.create(
    model="gpt-4o",
    messages=[
        {"role": "system", "content": "你是一个信息提取助手。请从合同文本中提取关键信息，以JSON格式返回。字段包括：party_a, party_b, amount, sign_date, contract_type, key_terms。"},
        {"role": "user", "content": "合同文本：{合同内容}"}
    ],
    response_format={"type": "json_object"}  # 强制返回JSON
)

result = response.choices[0].message.content
data = json.loads(result)  # 可以直接解析，不需要担心格式错误

进阶：结构化输出（Structured Outputs / JSON Schema）
OpenAI最新的结构化输出功能，支持传入JSON Schema，大模型会严格按照Schema定义的字段、类型、枚举值、必填项返回，保证输出完全符合Schema定义。

from openai import OpenAI
from pydantic import BaseModel
from typing import List, Optional
from enum import Enum

class ContractType(str, Enum):
    PURCHASE = "采购合同"
    SERVICE = "服务合同"
    LEASE = "租赁合同"
    OTHER = "其他"

class ContractInfo(BaseModel):
    party_a: str
    party_b: str
    amount: float
    sign_date: str
    contract_type: ContractType
    key_terms: List[str]

client = OpenAI()
response = client.beta.chat.completions.parse(
    model="gpt-4o",
    messages=[...],
    response_format=ContractInfo,  # 传入Pydantic模型，自动生成JSON Schema
)

data = response.choices[0].message.parsed  # 直接返回解析后的对象，不需要json.loads
print(data.party_a, data.amount, data.contract_type)

优点：

• 格式稳定，大模型强制返回合法JSON，几乎不会出现格式错误
• 结构化输出（JSON Schema）能保证字段、类型、枚举值完全符合定义，甚至能自动校验
• 不需要复杂的Prompt引导，节省输入token
• 解析简单，可以直接json.loads，不需要处理格式错误

缺点：

• 不是所有模型都支持，部分开源模型和小模型不支持JSON模式
• JSON Schema（结构化输出）只有最新的模型支持（如GPT-4o、GPT-4 Turbo）
• 只能返回JSON，不能返回表格、代码等其他格式（但可以用JSON包裹）
• API调用方式和普通调用略有不同，需要额外开发

适用场景：对格式稳定性要求高的场景、工具调用、信息提取、数据分类、需要程序化处理的场景。

11.2.3 方法3：Function Calling（工具调用）

原理：通过Function Calling，让大模型返回结构化的工具调用参数（JSON格式），包括工具名和参数。Function Calling本质上是一种特殊的结构化输出，专门用于工具调用场景。

示例：

from openai import OpenAI
import json

client = OpenAI()

tools = [
    {
        "type": "function",
        "function": {
            "name": "search_flight",
            "description": "查询航班信息",
            "parameters": {
                "type": "object",
                "properties": {
                    "from": {"type": "string", "description": "出发城市"},
                    "to": {"type": "string", "description": "到达城市"},
                    "date": {"type": "string", "description": "出发日期，格式YYYY-MM-DD"},
                    "passengers": {"type": "integer", "description": "乘客人数", "default": 1}
                },
                "required": ["from", "to", "date"]
            }
        }
    }
]

response = client.chat.completions.create(
    model="gpt-4o",
    messages=[{"role": "user", "content": "帮我订下周五从北京到上海的机票，2个人"}],
    tools=tools,
    tool_choice="auto"
)

tool_call = response.choices[0].message.tool_calls[0]
print(tool_call.function.name)  # search_flight
print(json.loads(tool_call.function.arguments))
# {"from": "北京", "to": "上海", "date": "2024-10-18", "passengers": 2}

优点：

• 参数格式稳定，大模型严格按照function定义的参数类型、枚举值、必填项返回
• 专门为工具调用设计，支持多工具选择、多工具并行调用
• 主流大模型都支持（OpenAI、Anthropic、通义千问、文心一言、DeepSeek等）
• 可以和对话结合，大模型判断是否需要调用工具、调用哪个工具、传什么参数

缺点：

• 只能用于工具调用场景，不能用于通用的结构化输出（如信息提取、表格生成）
• 需要定义function schema，有一定的开发成本
• 部分小模型和开源模型支持不好
• 复杂参数（嵌套对象、数组）的准确率不如简单参数

适用场景：Agent工具调用、智能客服（查询订单、申请退款）、AI助手（设置提醒、发送邮件）、需要调用外部API的场景。

11.2.4 方法4：微调（Fine-tuning）

原理：用大量结构化输出的示例数据微调大模型，让模型学会按照特定格式输出。微调后，即使不用复杂的Prompt引导，模型也能稳定返回指定格式的输出。

示例：

# 微调数据格式（JSONL）
{"messages": [
    {"role": "system", "content": "你是一个信息提取助手，从合同中提取关键信息，返回JSON。"},
    {"role": "user", "content": "合同文本：甲方北京科技公司，乙方上海贸易公司，金额50万元，签���日期2024年1月15日..."},
    {"role": "assistant", "content": "{"party_a": "北京科技公司", "party_b": "上海贸易公司", "amount": 500000, "sign_date": "2024-01-15", "contract_type": "采购合同", "key_terms": ["交货期30天", "质保期1年"]}"}
]}
# ... 几百到几千条类似的示例数据

# 微调后，只需要简单的Prompt就能稳定返回JSON
response = client.chat.completions.create(
    model="ft:gpt-4o:xxx",  # 微调后的模型
    messages=[{"role": "user", "content": "提取这份合同的关键信息：{合同内容}"}]
)
# 稳定返回JSON，不需要复杂的Prompt引导

优点：

• 格式最稳定，微调后模型能稳定返回指定格式，几乎不出错
• Prompt可以很简单，节省输入token成本
• 可以学习复杂的格式和规则，Prompt难以描述的格式可以通过示例学习
• 可以同时提升输出质量和格式稳定性

缺点：

• 需要大量标注数据（通常几百到几千条），数据准备成本高
• 微调成本高（API微调费用 + 数据标注费用）
• 微调周期长（数据准备 + 微调训练 + 验证，通常需要几天到几周）
• 灵活性差，格式变更需要重新微调
• 只有部分模型支持微调（OpenAI、通义千问等，Claude不支持微调）

适用场景：对格式稳定性要求极高、有大量标注数据、格式固定不常变更、高并发场景（节省Prompt成本）。

11.2.5 4种方法对比和选择

选择建议：

• 优先用JSON模式（结构化输出），格式稳定、实现简单、成本低
• 工具调用场景用Function Calling
• 简单场景或不支持JSON模式的模型用Prompt引导
• 高并发、格式固定、有数据的场景考虑微调
• 可以组合使用：JSON模式 + Prompt引导（双重保证）、Function Calling + JSON模式（工具参数用JSON Schema）

11.3 JSON输出设计

JSON是最常用的结构化输出格式。设计好JSON输出，能让大模型返回稳定、准确、可用的结构化数据。

11.3.1 JSON Schema设计原则

1. 字段定义清晰
每个字段都要有明确的名称、类型、描述，让大模型知道这个字段是什么、应该填什么。

# 好的定义
"amount": {
    "type": "number",
    "description": "合同总金额，单位为人民币元，只填数字，不要加单位和千分位"
}

# 差的定义
"amount": {
    "type": "string",
    "description": "金额"
}

2. 用枚举限制取值范围
对于有限取值的字段，用enum限制取值范围，避免大模型返回任意值。

# 好的定义
"contract_type": {
    "type": "string",
    "enum": ["采购合同", "服务合同", "租赁合同", "其他"],
    "description": "合同类型"
}

# 差的定义
"contract_type": {
    "type": "string",
    "description": "合同类型"
}

3. 明确必填字段和可选字段
用required数组明确哪些字段是必填的，哪些是可选的。必填字段大模型会尽量填充，可选字段可以为空。

"required": ["party_a", "party_b", "amount", "sign_date"],
# contract_type和key_terms是可选的

4. 嵌套结构不要太深
嵌套结构太深（超过3层）会降低大模型输出的准确率。尽量扁平化，或者用数组+对象的方式组织。

# 好的设计（2层嵌套）
{
    "order_id": "ORD123",
    "customer": {"name": "张三", "phone": "138xxxx"},
    "items": [
        {"product": "笔记本电脑", "quantity": 1, "price": 5999},
        {"product": "鼠标", "quantity": 2, "price": 99}
    ]
}

# 差的设计（4层嵌套）
{
    "order": {
        "info": {"id": "ORD123", "customer": {"name": "张三", "contact": {"phone": "138xxxx"}}},
        "items": {"list": [{"product": {"name": "笔记本电脑", "price": 5999}, "quantity": 1}]}
    }
}

5. 数组元素结构统一
数组中的每个元素应该有相同的结构，不要出现有的元素有A字段有的没有的情况。

6. 字段命名规范
用有意义的英文小写下划线命名（snake_case），不要用拼音、缩写、中文。字段名本身就能帮助大模型理解字段含义。

11.3.2 Prompt设计技巧

即使使用JSON模式，好的Prompt也能提升输出质量和准确率。

1. 明确输出要求
在System Prompt中明确要求：只返回JSON，不要返回其他内容（如解释、说明、Markdown代码块标记）。

你是一个信息提取助手。
要求：
1. 只返回JSON对象，不要返回任何其他内容
2. 不要用Markdown代码块包裹（不要```json ... ```）
3. 严格按照指定的字段和格式返回
4. 不确定的字段填null，不要编造

2. 给示例
给1-2个输入输出示例，让大模型更清楚应该返回什么格式。Few-shot示例能显著提升结构化输出的准确率。

3. 处理不确定的情况
明确告诉大模型，不确定的字段应该怎么处理（填null、填"未知"、还是留空），避免大模型编造信息。

4. 分步处理
对于复杂的信息提取，可以分步处理：第一步先提取原始信息，第二步再格式化和校验。或者用Chain of Thought让大模型先思考再输出（但注意CoT会增加输出，需要确保最终只返回JSON）。

11.3.3 输出验证和纠错

即使使用JSON模式，也应该对输出进行验证和纠错，确保数据质量。

1. JSON格式校验
用json.loads解析，如果解析失败，说明格式有错误。可以：

• 自动重试1-2次，让大模型重新输出
• 用正则提取JSON部分（如果大模型返回了额外内容）
• 用JSON修复工具（如json-repair）修复常见的格式错误

2. Schema校验
用JSON Schema校验字段、类型、枚举值、必填项。如果校验失败：

• 把校验错误信息反馈给大模型，让它修正后重新输出
• 对可选字段缺失的情况，用默认值填充
• 对必填字段缺失的情况，标记为异常，人工审核或转人工

3. 业务规则校验
除了Schema校验，还要做业务规则校验：

• 金额是否在合理范围内（如合同金额>0）
• 日期格式是否正确、日期是否合理（如签订日期不在未来）
• 枚举值是否在允许的范围内
• 关联字段是否一致（如开始日期早于结束日期）

4. 置信度评估
对于重要的字段，可以让大模型同时返回置信度，低置信度的字段标记为待人工审核。

{
    "party_a": {"value": "北京科技公司", "confidence": 0.95},
    "amount": {"value": 500000, "confidence": 0.8},
    "sign_date": {"value": "2024-01-15", "confidence": 0.6}  // 低置信度，待审核
}

11.4 表格输出设计

表格是AI产品中常用的输出格式——竞品对比、数据分析、价格对比、参数对比等场景都需要表格。

11.4.1 Markdown表格 vs HTML表格

大模型生成表格主要有两种格式：Markdown表格和HTML表格。

选择建议：

• 大部分场景用Markdown表格，简洁、稳定、易读
• 需要在网页直接渲染、需要复杂样式和交互时用HTML表格
• 可以让大模型返回Markdown，前端再转换为HTML表格渲染（如用marked.js），兼顾稳定性和展示效果

11.4.2 表格生成的Prompt设计

1. 明确表格结构
在Prompt中明确表格的列名、列顺序、每列的含义和数据格式。

请生成一个3款AI大模型的对比表格，包含以下列：
1. 模型名称：字符串
2. 开发商：字符串
3. 发布时间：字符串，格式YYYY-MM
4. 最大上下文：数字，单位K tokens
5. 输入价格：数字，单位$/M tokens
6. 输出价格：数字，单位$/M tokens
7. 多模态支持：是/否
8. 核心优势：字符串，不超过20字

用Markdown表格格式返回，不要返回其他内容。

2. 给示例
给1-2行示例数据，让大模型更清楚格式和内容要求。

3. 限制内容长度
明确每列的内容长度限制，避免大模型生成过长的内容导致表格过宽。

4. 数据来源说明
明确数据应该来自哪里（基于提供的资料、基于你的知识、基于搜索结果），避免大模型编造数据。

11.4.3 表格生成的常见问题和解决

问题1：列数不对或列顺序错
解决：在Prompt中明确列名和顺序，给完整的表头示例；用JSON模式先返回结构化数据，再由程序转换为表格（最稳定的方式）。

问题2：单元格内容包含管道符|或换行
解决：在Prompt中说明"单元格内容不要包含|和换行符，如果内容较长用简短描述"；程序后处理，替换特殊字符。

问题3：数据不准确或编造
解决：明确数据来源，要求基于提供的资料生成；对重要数据做校验；低置信度数据标注"待核实"。

问题4：表格过宽或内容过长
解决：限制每列内容长度；拆分大表格为多个小表格；重要列放前面，次要列可以折叠。

最佳实践：JSON→表格
最稳定的方式是让大模型返回JSON格式的结构化数据，然后由程序（前端或后端）转换为表格。这样：

• 格式100%稳定（JSON模式保证）
• 表格样式可以完全自定义（程序控制）
• 可以做排序、筛选、分页等交互
• 可以同时支持Markdown和HTML等多种渲染方式

11.5 代码输出设计

代码生成是AI产品的重要功能——AI编程助手、低代码平台、自动化脚本生成等场景都需要代码输出。

11.5.1 代码输出的格式要求

1. 用Markdown代码块
要求大模型用Markdown代码块包裹代码，并指定语言，方便前端渲染和语法高亮。

```python
def hello():
    print("Hello, World!")
```

2. 只返回代码，不返回多余解释
在需要直接执行代码的场景（如AI编程助手生成代码后直接插入编辑器），要求只返回代码，不要返回解释说明。

3. 代码结构完整
要求生成的代码是完整可运行的——包含必要的import、函数定义、主程序入口，不要只返回片段（除非用户明确要求片段）。

4. 注释清晰
要求代码有清晰的注释，特别是关键逻辑和复杂部分，方便用户理解和修改。

11.5.2 代码生成的Prompt设计

你是一个Python编程助手。请根据需求生成Python代码。

要求：
1. 用Markdown代码块包裹代码，指定语言为python
2. 代码完整可运行，包含必要的import和函数定义
3. 关键逻辑加中文注释
4. 遵循PEP 8编码规范
5. 代码末尾不要返回解释说明

需求：
写一个函数，输入一个文件路径，读取文件内容，统计每个单词出现的次数，按出现次数降序返回前10个单词。

11.5.3 代码输出的验证和执行

1. 代码提取
从大模型输出中提取代码部分——用正则提取Markdown代码块中的内容，或者用JSON模式让大模型返回结构化的代码字段。

2. 语法检查
对生成的代码做语法检查——Python用ast.parse或py_compile，JavaScript用eslint或node --check，SQL用SQL解析器。语法错误时自动重试或提示用户。

3. 安全检查
对生成的代码做安全检查——禁止危险操作（如删除文件、执行系统命令、网络请求到恶意地址），特别是在自动执行的场景。可以用沙箱执行代码，限制权限。

4. 测试验证
对关键代码自动运行测试——用用户提供的测试用例，或者自动生成简单的测试用例，验证代码的正确性。

5. 沙箱执行
需要自动执行代码时，在沙箱环境中执行——限制文件系统访问、网络访问、系统调用，设置超时和资源限制，确保安全。

11.5.4 代码生成的常见问题

问题1：代码有bug，不能正常运行
解决：自动运行测试，发现bug后把错误信息反馈给大模型，让它修复（多轮修复）；提供详细的错误信息和上下文，提升修复成功率。

问题2：代码不符合需求
解决：在Prompt中详细描述需求，包括输入输出、边界条件、性能要求；让大模型先理解需求（复述需求）再生成代码；生成后让大模型自查是否满足需求。

问题3：代码风格不一致
解决：在Prompt中明确编码规范（如PEP 8、Google Style）；提供代码风格示例；用代码格式化工具（如black、prettier）自动格式化。

问题4：生成的代码过时或用了废弃的API
解决：在Prompt中指定库的版本和推荐用法；用RAG提供最新的文档和最佳实践；定期更新训练数据和知识库。

11.6 实战案例：智能客服的结构化输出设计

11.6.1 背景

某电商平台的智能客服，需要处理用户的各种问题——查询订单、申请退款、咨询商品、投诉建议等。客服AI需要理解用户意图，调用相应的工具，返回结构化的结果。

11.6.2 结构化输出设计

1. 意图分类（JSON输出）
用户输入后，第一步是意图分类，用JSON模式返回结构化的分类结果。

# JSON Schema
{
    "type": "object",
    "properties": {
        "intent": {
            "type": "string",
            "enum": ["order_query", "refund_request", "product_consult", "complaint", "logistics_query", "invoice_request", "other"],
            "description": "用户意图分类"
        },
        "confidence": {
            "type": "number",
            "description": "分类置信度，0-1之间"
        },
        "entities": {
            "type": "object",
            "properties": {
                "order_id": {"type": "string", "description": "订单号"},
                "product_name": {"type": "string", "description": "商品名称"},
                "reason": {"type": "string", "description": "退款/投诉原因"}
            }
        },
        "need_human": {
            "type": "boolean",
            "description": "是否需要转人工"
        }
    },
    "required": ["intent", "confidence"]
}

# 输出示例
{
    "intent": "refund_request",
    "confidence": 0.92,
    "entities": {
        "order_id": "ORD20241015001",
        "reason": "商品有质量问题"
    },
    "need_human": false
}

2. 工具调用（Function Calling）
根据意图分类结果，调用相应的工具，用Function Calling返回结构化的工具调用参数。

# 工具定义
tools = [
    {
        "type": "function",
        "function": {
            "name": "query_order",
            "description": "查询订单信息",
            "parameters": {
                "type": "object",
                "properties": {
                    "order_id": {"type": "string", "description": "订单号"}
                },
                "required": ["order_id"]
            }
        }
    },
    {
        "type": "function",
        "function": {
            "name": "apply_refund",
            "description": "申请退款",
            "parameters": {
                "type": "object",
                "properties": {
                    "order_id": {"type": "string", "description": "订单号"},
                    "reason": {"type": "string", "description": "退款原因"},
                    "amount": {"type": "number", "description": "退款金额"}
                },
                "required": ["order_id", "reason"]
            }
        }
    }
]

# 工具调用输出示例
{
    "tool_calls": [
        {
            "function": {
                "name": "apply_refund",
                "arguments": "{"order_id": "ORD20241015001", "reason": "商品有质量问题", "amount": 299}"
            }
        }
    ]
}

3. 回复生成（结构化+自然语言）
工具调用完成后，生成给用户的回复。回复可以同时包含结构化数据（用于前端展示）和自然语言（用于对话）。

# 结构化回复（JSON模式）
{
    "type": "object",
    "properties": {
        "reply_type": {
            "type": "string",
            "enum": ["info", "success", "error", "need_confirm", "human_transfer"]
        },
        "message": {"type": "string", "description": "给用户的自然语言回复"},
        "data": {
            "type": "object",
            "description": "结构化数据，用于前端展示"
        },
        "actions": {
            "type": "array",
            "description": "用户可以执行的操作按钮",
            "items": {
                "type": "object",
                "properties": {
                    "text": {"type": "string"},
                    "action": {"type": "string"}
                }
            }
        }
    },
    "required": ["reply_type", "message"]
}

# 输出示例
{
    "reply_type": "need_confirm",
    "message": "好的，为您查询到订单ORD20241015001，商品为XX耳机，金额299元。请问您确定要申请退款吗？退款原因是商品有质量问题。",
    "data": {
        "order_id": "ORD20241015001",
        "product": "XX耳机",
        "amount": 299,
        "refund_reason": "商品有质量问题"
    },
    "actions": [
        {"text": "确认退款", "action": "confirm_refund"},
        {"text": "修改原因", "action": "modify_reason"},
        {"text": "取消", "action": "cancel"}
    ]
}

11.6.3 效果

通过结构化输出设计，智能客服实现了：

• 意图分类准确率95%+：JSON模式+明确的枚举值，分类稳定准确
• 工具调用成功率90%+：Function Calling+严格的参数校验，工具调用参数准确
• 回复格式稳定：结构化回复包含message、data、actions，前端可以稳定渲染按钮、卡片等交互元素
• 用户体验提升：用户可以直接点击按钮操作，不需要打字，交互更流畅
• 开发效率提升：结构化输出可以直接被程序处理，不需要复杂的自然语言解析

11.7 本章小结

结构化输出是AI产品从"能聊天"到"能干活"的关键能力。掌握结构化输出的设计和实现方法，是AI产品经理的核心技能之一。

核心内容回顾：

为什么需要结构化输出：自然语言输出无法程序化处理、格式不稳定、信息提取困难、无法直接调用工具、难以验证纠错。结构化输出适用于工具调用、信息提取、数据分类、表格生成、代码生成、表单填充、报告生成、多步骤任务等场景。

4种结构化输出方法：

1. Prompt引导：在Prompt中明确格式要求和示例，简单灵活但格式不稳定，适合简单场景和原型验证
2. JSON模式：通过API参数强制返回JSON，格式稳定、实现简单，是首选方法；进阶的结构化输出（JSON Schema）能保证字段、类型、枚举值完全符合定义
3. Function Calling：专门用于工具调用，参数严格校验，支持多工具选择和并行调用，适合Agent和智能客服场景
4. 微调：用大量示例数据微调模型，格式最稳定但成本高、周期长，适合高并发、格式固定、有数据的场景

JSON输出设计：Schema设计原则（字段定义清晰、用枚举限制取值、明确必填可选、嵌套不要太深、数组元素结构统一、命名规范）；Prompt设计技巧（明确输出要求、给示例、处理不确定情况、分步处理）；输出验证和纠错（JSON格式校验、Schema校验、业务规则校验、置信度评估）。

表格输出设计：Markdown表格（简洁易读，适合简单对比）vs HTML表格（功能强大，适合网页展示）；Prompt设计（明确列名和顺序、给示例、限制内容长度、说明数据来源）；常见问题和解决（列数不对、特殊字符、数据不准确、表格过宽）；最佳实践是JSON→表格，程序转换渲染。

代码输出设计：格式要求（Markdown代码块、只返回代码、结构完整、注释清晰）；Prompt设计（明确需求、指定语言和规范、给示例）；验证和执行（代码提取、语法检查、安全检查、测试验证、沙箱执行）；常见问题（代码有bug、不符合需求、风格不一致、API过时）。

实战案例：智能客服的结构化输出设计——意图分类（JSON输出）、工具调用（Function Calling）、回复生成（结构化+自然语言），实现了意图分类准确率95%+、工具调用成功率90%+、用户体验和开发效率双提升。

记住：结构化输出的核心是"让大模型的输出可以被程序稳定处理"。根据场景选择合适的方法，设计清晰的Schema和Prompt，做好验证和纠错，就能让AI产品从"能聊天"升级为"能干活"。

📝 本章练习（5题）

答案与解析请在 互动学习看板 中作答查看。

📚 AI产品经理实战训练营 课程目录（44 章）

1. 第1章 AI产品经理是做什么的？和传统PM有什么区别？
2. 第2章 2026年AI产品经理就业市场：哪些行业在招？薪资多少？
3. 第3章 零经验转行AI产品经理的3条路径
4. 第4章 AI产品全景图：从聊天机器人到Agent，一文搞懂
5. 第5章 AI产品经理能力模型：你需要掌握哪些技能？
6. 第6章 实战：拆解3个你每天在用的AI产品
7. 第7章 大模型是什么？用大白话讲清楚
8. 第8章 主流大模型对比：GPT-4o、Claude、DeepSeek、豆包、Kimi怎么选？
9. 第9章 Prompt入门：写好提示词的5个原则
10. 第10章 Prompt进阶：System Prompt、COT思维链、Few-shot示例
11. 第11章 结构化输出：让大模型返回JSON、表格、代码
12. 第12章 Prompt优化实战：从垃圾Prompt到高质量Prompt
13. 第13章 大模型的"幻觉"问题：产品经理怎么应对？
14. 第14章 实战：为一个智能客服设计完整Prompt体系
15. 第15章 RAG是什么？为什么企业都在做知识库？
16. 第16章 RAG工作原理：文档→分块→向量→检索→生成
17. 第17章 向量数据库选型：Milvus、Pinecone、Chroma、pgvector怎么选？
18. 第18章 Embedding模型选型：OpenAI、BGE、M3E、GTE对比
19. 第19章 Reranker重排序：让检索结果更精准
20. 第20章 查询改写与混合检索：提升召回率的实战技巧
21. 第21章 知识库运营：文档治理、更新机制、效果监控
22. 第22章 实战：从零搭建一个企业知识库（完整流程）
23. 第23章 Agent是什么？和聊天机器人有什么区别？
24. 第24章 Agent核心能力：感知、规划、工具调用、记忆
25. 第25章 主流Agent框架与协议：Agent Harness、MCP、A2A全解析
26. 第26章 工具调用（Function Calling）原理与实战
27. 第27章 Agent记忆系统：短期记忆、长期记忆、向量记忆
28. 第28章 多Agent协作：多个智能体怎么分工配合？
29. 第29章 Agent评估体系：成功率、成本、延迟怎么监控？
30. 第30章 实战：设计一个制造业生产异常处理Agent
31. 第31章 AI产品需求分析：怎么识别真需求还是伪需求？
32. 第32章 AI产品竞品分析：怎么调研和拆解竞品？
33. 第33章 AI产品PRD撰写：技术可行性、数据需求、评估指标
34. 第34章 AI产品原型设计：对话流、状态机、异常处理
35. 第35章 AI产品数据指标体系：从DAU到模型准确率，全面监控
36. 第36章 AI项目管理：从需求到上线的全流程管控
37. 第37章 实战项目1：从零搭建制造业AI智能质检系统
38. 第38章 实战项目2：从零搭建企业级AI知识库（RAG系统）
39. 第39章 AI产品经理简历优化：让HR一眼看中你
40. 第40章 项目经验包装：把普通项目讲成亮眼案例
41. 第41章 AI产品经理面试常见问题：提前准备，从容应对
42. 第42章 案例分析面试：用结构化思维征服面试官
43. 第43章 薪资谈判：拿到你应得的报酬
44. 第44章 入职前3个月：快速站稳脚跟，建立信任