🔍 TL;DR
JSON mode 只强制 JSON 语法，而非 schema 合规性 —— 缺失字段、错误类型和无效列举值都需要在提示词层面修复。三种技巧可弥合这一差距：(1) 把 schema 作为 JSON 模板直接嵌入提示词，(2) 包含一个有效的输出示例，(3) 为每个字段添加一条涵盖类型、格式和 null 处理的指令。部署前目标是在 20 个用例的测试集上达到 95%+ 的通过率。对于没有 API 强制的自由提示词，用 YAML 代替 JSON —— 模型产生的语法错误更少。
提示词设计决定结构化输出的可靠性
📍 In One Sentence
结构化输出可靠性是指模型响应中可解析、包含所有必填字段、使用正确数据类型且列举值有效的比例 —— JSON mode 只保证这四项中的第一项。
💬 In Plain Terms
把 JSON mode 想象成拼写检查：它能抓出语法错误，却抓不出含义错误。一份文档可以通过拼写检查却依然是错的。只依赖 JSON mode 的提示词就像通过了拼写检查的文档 —— 结构合法，却可能不完整或类型错误。
JSON mode 和 tool_use API 强制生成可解析的 JSON，但它们并不保证字段完整、数据类型正确或列举值有效 —— 这些失败需要在提示词层面修复，而非改动 API。 最常见的结构化输出失败都发生在语法合法的 JSON 内部：因为模型把必填字段当作可选而缺失、日期被格式化为相对字符串（"上周二"）而非 ISO 8601、列举值拼写错误或被缩写，以及可空字段返回空字符串而非 null。
三种提示词层面的干预能持续弥合可靠性差距。嵌入 schema 让输出结构无歧义。单个有效的输出示例消除格式歧义。字段级指令消除类型和 null 处理错误。三者结合，可在 GPT-5.6、Claude Sonnet 5 和 Gemini 2.5 Pro 上将结构化输出可靠性提升到 95%+ —— 无论是否使用原生 JSON mode。
| 失败类型 | 提示词中的成因 | 提示词修复方法 |
|---|---|---|
| 必填字段缺失 | 模型从自然语言描述中推断该字段为可选 | 为每个必填字段明确标注："title REQUIRED"，或单独列出必填字段 |
| 错误的数据类型 | 字段名含糊且无类型标注 | 在提示词中添加类型标注："amount (integer, not string)" |
| 无效的列举值 | 列举未完整列出 —— 模型编造一个看似合理的值 | 明确列出所有列举值："status: one of 'active', 'inactive', 'pending'" |
| null 与空字符串混淆 | 没有区分 null 与 "" 的指令 | 添加："Return null if unknown. Never return empty string for unknown values." |
| 多余的未声明字段 | 模型添加了 schema 之外的"有用"上下文 | 添加："Return only the fields specified. Do not add fields not listed in the schema." |
🔍 JSON mode 还不够
即便使用 API 强制的 JSON mode，仍然需要提示词内嵌 schema、字段指令和输出示例。JSON mode 与提示词 schema 设计是互补的 —— 而非二选一。JSON mode 防止语法失败；提示词设计防止合规性失败。
直接把 schema 嵌入提示词
把预期的输出 schema 作为 JSON 模板直接嵌入提示词，而不是用自然语言描述。相比只收到你想要什么的散文描述的模型，先看到结构再生成的模型产生的字段遗漏和类型错误更少。
提示词内嵌 schema 使用你期望在输出中出现的确切格式：字段名、嵌套深度和值占位符。把 schema 模板放在任务指令之后、任何示例之前。使用能传达预期类型的占位值：`"amount": 0` 传达整数；`"amount": 0.00` 传达浮点数；`"created_at": "YYYY-MM-DDTHH:MM:SSZ"` 传达你期望的 ISO 8601 格式。
🔍 使用 TypeScript 风格的类型标注
对于无法使用 JSON mode 的提示词，在 schema 模板内以注释形式添加 TypeScript 风格的类型标注：`"amount": 0 // float, USD, 2 decimal places`。这能在 schema 结构内部提供类型信息，而无需单独的字段指令部分。
🔍 字段顺序很重要
在 schema 模板中先列必填字段，其次是可选字段，最后是可空字段。模型在决定包含什么时会更看重靠前的元素 —— 排在最前的可空字段，在模型对其值不确定时更容易被遗漏。
❌ 仅自然语言描述
从下面的文本中提取订单详情，并以 JSON 形式返回。包括订单 ID、客户姓名、总金额、所订商品和订单状态。 Text: {{text}}
✅ 以 JSON 模板嵌入 schema
从下面的文本中提取订单详情，并返回与以下确切 schema 匹配的 JSON： { "order_id": "string", "customer_name": "string", "total_amount": 0.00, "status": "string", "items": [ { "name": "string", "quantity": 0, "unit_price": 0.00 } ] } 只返回有效的 JSON。不要包含 JSON 对象之外的任何文本。 Text: {{text}}
给模型看一个有效的输出示例
相比仅有 schema 的提示词，在提示词中加入一个具体、真实的输出示例可将结构化输出可靠性提高 5–8 个百分点。 该示例向模型展示你期望的确切格式、字段顺序、取值风格和引号约定 —— 减少仅靠 schema 定义无法消除的歧义。
把示例放在 schema 模板之后，并清晰标注（"Example output:" 或 "Here is a valid response:"）。使用真实的占位值 —— 而非 "foo"、"bar" 或 "example" —— 因为模型会从取值风格中学习。如果你的日期是 ISO 8601，就展示一个 ISO 8601 日期。如果你的价格有两位小数，就展示 `12.99`，而非 `13`。
🔍 一个示例通常就够了
只有当你的数据会因输入条件而具有明显不同的结构时，第二个示例才有价值 —— 例如某些字段会根据产品类型有条件地出现。超过两个示例后，对大多数结构化输出任务而言，提示词长度的成本会超过可靠性收益。
⚠️ 避免琐碎的占位值
以 "foo"、"bar"、"test" 或 `0` 作为占位符的示例，会让模型以为这些是有效值。请使用能代表你真实数据的值 —— 真实的产品名、真实的评分、真实的日期字符串。
❌ 仅 schema —— 无输出示例
从下面的评论中提取产品详情，并返回符合此 schema 的 JSON： { "product_name": "string", "rating": 0, "sentiment": "string", "key_features": ["string"] } Review: {{review}}
✅ schema + 一个真实的输出示例
从下面的评论中提取产品详情，并返回符合此 schema 的 JSON： { "product_name": "string", "rating": 0, "sentiment": "string", "key_features": ["string"] } Example output: { "product_name": "WH-1000XM5 Headphones", "rating": 4, "sentiment": "positive", "key_features": ["noise cancellation", "30-hour battery", "comfortable fit"] } Review: {{review}}
为高风险输出编写字段级指令
对于字段正确性至关重要的生产提示词，为每个必填字段添加一条指令：数据类型、预期格式、null 处理，以及适用时的允许列举值。 字段级指令能消除导致类型错误的歧义 —— 一个名为 "amount" 的字段，在没有明确类型指令时可能是字符串、整数或浮点数。
字段指令放在一个单独的部分，位于 schema 模板之后、示例之前。将该部分标注为 "Field requirements:" 或 "Schema rules:"。每条指令保持一句话。
| 字段类型 | 指令模式 | 示例指令 |
|---|---|---|
| String | 格式、最大长度、禁用字符 | "title (string, max 100 characters, no HTML tags)" |
| Number | 整数还是浮点数、精度、单位 | "price (float, exactly 2 decimal places, USD, no currency symbol)" |
| Date | 格式、时区 | "created_at (string, ISO 8601: YYYY-MM-DDTHH:MM:SSZ, UTC timezone)" |
| Enum | 逐字列出所有允许值 | "status (string, exactly one of: 'active', 'inactive', 'pending')" |
| Boolean | 仅 true/false —— 拒绝 yes/no/1/0 | "is_verified (boolean, true or false only — not 1/0 or yes/no)" |
| Nullable | 何时返回 null、空字符串还是省略 | "description (string or null — return null if unknown, empty string if known to be blank)" |
| Array | 最少/最多项数、项类型、空数组处理 | "tags (array of strings, 0–5 items, return [] if none — never return null)" |
🔍 何时添加字段指令
在以下情况添加字段指令：(1) 字段有特定格式要求（ISO 日期、货币精度），(2) 字段是列举，(3) 字段可空且 null 与空字符串的区分很重要，或 (4) 你的测试集显示该字段在超过 10% 的用例中失败。对于像 "title" 或 "name" 这样简单、无歧义的字符串字段，可跳过字段指令。
❌ 仅 schema —— 无字段指令
Return JSON with these fields: { "invoice_id": ..., "amount": ..., "due_date": ..., "status": ..., "line_items": [...] }
✅ schema + 字段级指令
Return JSON with these fields: { "invoice_id": "string", "amount": 0.00, "due_date": "YYYY-MM-DD", "status": "string", "line_items": [{"description": "string", "quantity": 0, "unit_price": 0.00}] } Field requirements: - invoice_id: string, format INV-XXXXXX (e.g. INV-004821) - amount: float, 2 decimal places, USD total including tax - due_date: string, ISO 8601 date (YYYY-MM-DD), not a datetime - status: string, exactly one of: 'paid', 'unpaid', 'overdue', 'cancelled' - line_items: array of objects, 1 or more items, return [] if no line items found - If any field cannot be determined, return null for that field
API 用 JSON，提示词用 YAML，表格数据用 CSV
当输出送入具备 JSON 强制能力的 API 或数据库时，使用 JSON。对于没有 API 强制的自由提示词，使用 YAML —— 由于 YAML 不需要闭合花括号、转义序列和尾随逗号处理，模型在其中产生的语法错误更少。仅在扁平表格数据时使用 CSV。
在自由（无 API 强制）提示中，JSON 与 YAML 之间的可靠性差异源于语法复杂度。JSON 要求每个字符串都加引号、每个对象都用花括号闭合、每个逗号都正确。YAML 则改用缩进 —— 模型对此处理得更稳定。代价是：YAML 输出在送入期望 JSON 的下游系统前需要先转换。
- 如果你的下游系统有 JSON 解析器且可以使用 API 强制，就用 JSON —— 强制能完全消除语法错误
- 如果你在没有 API 强制的情况下生成，且团队会在下游处理前转换为 JSON，就用 YAML
- 仅在扁平表格数据时使用 CSV —— 一旦你需要在单元格中放入嵌套对象或数组，就改用 JSON 或 YAML
- 仅在人类可读输出时使用 Markdown 表格 —— 若没有额外工具，它们无法被机器解析
| 格式 | 无 API 强制时的可靠性 | 适用场景 | 避免场景 |
|---|---|---|---|
| JSON | 提示词内嵌 schema 时 80–85% | API、数据库、类型安全的消费方 | 无 API 强制且涉及复杂嵌套时 |
| YAML | 提示词内嵌 schema 时 88–92% | 人类可读输出、配置型数据、无 API 强制 | 下游系统需要 JSON 且没有转换步骤时 |
| XML | 提示词内嵌 schema 时 85–90% | 文档转换、遗留系统集成 | 简单的键值数据（XML 带来不必要的冗长） |
| CSV | 扁平数据 95%+ | 表格数据、电子表格导出、数据管道 | 数据具有嵌套或层级结构时 |
| Markdown 表格 | 简单表格时较高 | 报告、文档、人类可读的表格输出 | 需要机器可读的下游处理时 |
⚠️ YAML 转 JSON 的成本
如果你为提高提示词可靠性使用 YAML，而下游处理需要 JSON，请在管道中加入一个转换步骤。Python 的 yaml.safe_load() 和 Node.js 的 js-yaml 一行代码即可完成。在团队全面采用 YAML 之前，先把这一点纳入架构考量。
让模型修复自己格式错误的输出
当结构化输出提示词未通过验证时，发送一条更正提示词，其中包含原始指令、格式错误的输出和具体的验证错误。在 60–75% 的情况下，模型无需完全重写提示词就能从自己格式错误的响应中恢复出有效输出。
一条更正提示词有三个必需部分：(1) 重申输出应有的样子（schema 或格式），(2) 模型原样返回的格式错误输出，以及 (3) 具体的验证错误 —— "required field 'invoice_id' missing"、"amount is a string, expected float"。这种三段式结构给了模型足够的上下文去修复具体问题，而不是重新生成一个带着不同错误的不同响应。
🔍 当更正两次失败时，修复基础提示词
如果更正提示词在第二次尝试时仍无法产生有效输出，那么问题出在基础提示词，而非输入数据。停止重试，诊断失败模式：哪个字段失败、在什么输入条件下失败。添加一条字段指令或修改 schema，从源头上防止失败。
⚠️ 更正提示词会增加延迟和成本
每条更正提示词都会使该次调用的 API 成本和延迟翻倍。仅将更正提示词用于边界情况失败（少于 10% 的输出）。如果你的结构化输出提示词失败率超过 10%，请修复基础提示词，而不是在生产中构建更正循环。
❌ 模糊重试 —— 无错误上下文
你返回了无效的输出。请重试并返回有效的 JSON。 {{original_prompt}}
✅ 包含 schema、输出和具体错误的更正提示词
你之前的响应未通过验证。只修复下面列出的错误，并返回更正后的 JSON。 Expected schema: { "invoice_id": "string", "amount": 0.00, "status": "string" } Your previous response: { "invoice_id": null, "amount": "150.00", "status": "PAID" } Validation errors: - invoice_id is null but is a required string field — extract it from the input - amount is a string ("150.00") but must be a float (150.00) - status must be lowercase: use 'paid', not 'PAID' Return only the corrected JSON object.
数组、列举和可空字段的提示词模式
数组、列举和可空字段是提示词内嵌 schema 本身无法防止的三大最常见结构化输出失败来源。每一类都需要在提示词中使用特定的指令模式。
| 数据类型 | 常见失败 | 可预防的提示词模式 |
|---|---|---|
| 数组（0 项） | 模型返回 null 而非 [] | "Return an empty array [] if no items are present. Never return null for array fields." |
| 数组（1 项及以上） | 只找到一项时，模型返回单个对象而非数组 | "Always return an array, even when there is only one item. Single items must be wrapped: {...}" |
| 列举（2–5 个值） | 模型缩写或编造类似的值 | "status: exactly one of: 'active', 'inactive', 'pending' — no abbreviations or variants" |
| 列举（6 个及以上值） | 模型编造清单之外的值 | 用编号列表列出所有值，然后："Use only values from the list above. Do not abbreviate or combine values." |
| 可空字段 | 模型返回 "" 而非 null，或完全省略该字段 | "Return null if the value is unknown. Return empty string '' only if the field is known to be blank. Always include the field — do not omit it." |
| 整数还是浮点数 | 期望整数时模型返回浮点数，或两者都返回字符串 | "score (integer — no decimal places, e.g. 4 not 4.0)" or "price (float — exactly 2 decimal places, e.g. 12.99 not 13)" |
| 嵌套对象 | 模型把嵌套对象压平成扁平键（例如 "address.city" 而非 {"address": {"city": ...}}） | 在 schema 模板中以正确缩进展示完整的嵌套结构。用自然语言描述嵌套常常会被压平成扁平键。 |
⚠️ null、undefined 与省略
JSON 没有 undefined 值，但模型有时表现得好像有 —— 当它们认为值未知时，会完全省略某个字段，而不是返回 null。如果下游代码使用 obj.hasOwnProperty() 或类似检查，被省略的字段与值为 null 的字段是不同的。添加："Always include every field in the schema, even if the value is null."
🔍 嵌套列举需要额外的明确性
嵌套对象内部的列举比顶层列举更容易被拼写错误或缩写。如果你在嵌套对象内有一个列举，请在 schema 模板中该字段出现的位置附近重复该指令，而不仅仅放在通用的字段规则部分。
衡量你的结构化输出提示词的可靠性
在将任何结构化输出提示词部署到生产前，目标是在 20 个用例的测试集上达到 95%+ 的通过率。低于 95% 时，生产失败发生得足够频繁，需要一个下游更正循环 —— 这会增加延迟，并使每次失败调用的 API 成本翻倍。
在字段层面衡量可靠性，而不只是整体。一个整体通过率 95% 但某个列举字段通过率仅 60% 的提示词，是一个带有已知生产失败模式的提示词。字段级衡量能准确告诉你该添加或强化哪条指令。
- 1为每个 schema 字段定义通过/失败标准。 对每个字段：类型正确、必填字段存在、列举值在允许清单内、日期格式匹配所需模式。把这些写成程序化检查 —— 而非肉眼检查。这一步会产出你的测试判定基准（test oracle）。
- 2构建一个 20 个用例的测试集。 十个正常路径输入（典型、格式良好的数据）、五个边界情况（缺失可选字段、长文本、异常值、多语言内容）、五个对抗性输入（嵌在字段值中的指令、极端日期、含糊类型）。使用来自你实际数据领域的真实输入。
- 3在 temperature 0 下运行，并逐字段记录通过/失败。 在 temperature 0 下执行全部 20 个用例，以获得确定、可重复的结果。记录每个测试用例中每个字段是通过还是失败 —— 而不只是整体结果。字段级失败模式能识别出缺少哪条指令。
- 4修复通过率最低的字段并重新测试。 添加或强化一条字段指令：类型、格式、null 处理或列举值。重新运行全部 20 个用例。一次有针对性的指令添加通常能将整体通过率提高 5–15 个百分点。重复此过程，直到整体通过率达到 95% 或更高。
- 5在第二个模型上验证提示词。 用同一提示词对第二个模型运行完整的 20 用例集。在 GPT-5.6 上达到 95%+ 但在 Claude Sonnet 5 上仅 70% 的提示词是依赖于模型的。要么添加足够明确、能在两者上都通过的指令，要么记录该提示词已针对哪个模型验证，并且不经重新测试就不要切换。
🔍 在 temperature 0 下运行测试
在 temperature 0 下运行结构化输出测试集，以获得确定、可重复的结果。在 temperature 0 下通过的提示词是设计上可靠 —— 而非运气。只有当提示词在确定性条件下达到 95%+ 通过后，才提高 temperature，然后在新的 temperature 下重新运行测试集，以确认可靠性依然成立。
🔍 使用 PromptQuorum 进行多模型对比
PromptQuorum 会同时用你的 20 用例测试集对 GPT-5.6、Claude Sonnet 5 和 Gemini 2.5 Pro 运行，并并排显示字段级通过率。这能在一次运行中识别出依赖于模型的失败，而不是分三次。
5 个常见的结构化输出提示词错误
五个最常见的结构化输出提示词错误都会产生相同的症状 —— 间歇性或系统性失败 —— 但需要不同的修复方法。在添加指令之前先诊断你犯的是哪种错误，能节省时间。
❌ 用自然语言描述 schema，而不是嵌入它
Why it hurts: 自然语言描述是含糊的 —— "a list of items" 可能指数组、逗号分隔的字符串或编号列表；"the total" 可能是字符串或浮点数
Fix: 把预期的 schema 作为 JSON 模板直接嵌入提示词。模板通过其结构而非散文描述来展示字段名、嵌套深度和值类型。
❌ 没有指明如何处理缺失或未知的值
Why it hurts: 模型会为未知字段编造看似合理的值，而不是返回 null —— 日期变成 "unknown"，金额变成 0，缺失的 ID 变成 "N/A" —— 它们都通不过类型验证
Fix: 为每个可空字段添加明确的 null 处理："Return null if the value cannot be determined from the input. Do not guess or invent values. Do not return empty string."
❌ 只在你开发提示词所用的模型上测试
Why it hurts: 结构化输出可靠性在不同模型间差异显著 —— 由于在 schema 约束上的指令遵循行为不同，一个在 GPT-5.6 上 95% 的提示词可能在 Claude Sonnet 5 上只有 70%
Fix: 在把每个结构化输出提示词当作与模型无关之前，至少在 2 个模型上运行它。使用 PromptQuorum 或直接 API 调用，一步跨模型测试提示词。
❌ 用完全相同的提示词重试失败的输出
Why it hurts: 在 temperature 0 下重试失败的提示词每次都会产生相同的失败。在更高 temperature 下，它会产生各不相同但仍然失败的输出 —— 错误不同，根因相同
Fix: 使用一条带有具体验证错误和格式错误输出的更正提示词，或诊断失败模式（哪个字段、哪种输入类型）并向基础提示词添加一条有针对性的字段指令。
❌ 把 JSON mode 当作完整的结构化输出解决方案
Why it hurts: JSON mode 能防止无法解析的输出，却防止不了 schema 合规性失败 —— 使用 JSON mode 的模型仍可能返回缺字段、错类型和无效列举值的合法 JSON，它们都通不过下游验证
Fix: 即便使用 API 强制的 JSON mode，也始终包含提示词内嵌 schema 和字段指令。API 配置参见结构化输出与 JSON Mode —— 本指南涵盖的是提示词层面的补充。
常见问题
关于结构化输出提示的最常见问题，涵盖 JSON mode 与提示词设计的边界、该包含多少个示例，以及如何系统性地改进一个失败的提示词。
JSON mode 是否让提示词内嵌 schema 变得多余？
不会。JSON mode 强制的是可解析的 JSON 语法，而非 schema 合规性。使用 JSON mode 的模型仍可能返回缺失必填字段、使用错误数据类型或包含无效列举值的合法 JSON。提示词内嵌 schema 和字段指令解决的是 schema 合规性失败；JSON mode 只防止无法解析的输出。两种方法是互补的，而非二选一。
我应该在提示词中包含多少个输出示例？
一个示例通常就足够，并带来最大的可靠性提升。只有当你的数据会因输入条件而具有明显不同的结构时，第二个示例才有价值 —— 例如某些字段会根据输入类型有条件地成为必填。超过两个示例后，对大多数结构化输出任务而言，提示词长度的成本会超过可靠性收益。
在没有 API 强制的情况下，结构化输出该用 JSON 还是 YAML？
当在没有 API 强制的情况下生成，且输出不需要被期望 JSON 的系统解析时，使用 YAML。由于 YAML 不需要闭合花括号、转义序列或尾随逗号跟踪，模型在其中产生的语法错误更少。当输出直接送入需要 JSON 的 API、数据库或下游系统时，使用 JSON。无论哪种格式，都始终解析并验证。
改进一个结构化输出通过率为 70% 的提示词，最快的方法是什么？
在字段层面运行测试集，而不只是整体。找出单独通过率最低的字段，添加一条涵盖类型、格式和 null 处理的明确指令，然后重新运行。一条有针对性的字段指令通常能将整体通过率提高 5–15 个百分点。重复直到达到 95% 或更高。
如何从没有原生 JSON mode 的模型获得可靠的结构化输出？
把完整的 JSON schema 作为模板嵌入提示词，包含一个有效的输出示例，添加字段级指令，并在 temperature 0 下运行。解析并验证每一个输出；对任何验证失败发送一条更正提示词。设计良好的提示词在没有原生 JSON mode 的情况下，也能在大多数模型上以 temperature 0 达到 85–92% 的可靠性。
结构化输出提示词合适的测试集规模是多少？
至少 20 个用例：10 个正常路径输入（典型、格式良好的数据）、5 个边界情况（异常值、缺失可选字段、长输入），以及 5 个对抗性输入（可能误导模型的值、嵌在字段值中的指令、含糊类型）。这个规模能识别出最常见的失败类别，又不会耗费过多的搭建时间。
我应该在什么时候使用更正提示词，而不是修复基础提示词？
当失败罕见 —— 少于 10% 的输出 —— 且由异常的边界情况输入引起时，使用更正提示词。当失败是系统性的时，修复基础提示词：同一字段缺失，或同一类型错误在多个测试用例中出现。更正提示词会为每次失败增加延迟和 API 成本；更好的基础提示词能彻底防止失败。
schema 中字段的顺序会影响结构化输出的可靠性吗？
会。把必填字段放在最前，可选或可空字段放在最后。模型在决定包含什么时会更看重靠前的 schema 元素。当模型对某个值不确定时，排在前面的可空字段比排在后面的必填字段更容易被遗漏。这种排序效应在 GPT-5.6 和 Claude Sonnet 5 上是一致的。
相关阅读
- 结构化输出与 JSON Mode：何时以及如何使用 —— 面向 GPT-5.6、Claude 和 Gemini 的 API 层 JSON mode 配置，附模型合规性对照表
- 结构化输出的最佳工具（2026） —— 面向结构化抽取工作流对比 Instructor、Outlines、Pydantic AI 和 LangChain
- 如何控制输出：格式、Temperature 与受约束解码 —— 受约束解码的机制、面向结构化任务的 temperature 和 top-p、停止序列
- 如何评估提示词质量：指标、测试与清单 —— 20 用例测试集的构建、二元通过/失败评分，以及 LLM-as-judge 评分标准
- 如何跨模型测试提示词 —— 用同一提示词对 GPT-5.6、Claude Sonnet 5 和 Gemini 2.5 Pro 运行，以发现特定于模型的失败
- 零样本与少样本提示 —— 何时向提示词添加示例，以及针对不同任务类型该包含多少个
来源
- OpenAI Structured Outputs 文档 —— OpenAI API 中 response_format 和 JSON mode 的技术规范
- Anthropic 工具使用文档 —— Claude 的 tool_use 参数如何在 API 层强制结构化输出
- Google Gemini GenerationConfig 文档 —— Gemini 用于原生 JSON 输出的 responseMimeType 配置
- BAML 基准测试：结构化输出准确性的权衡 —— 关于各模型受约束与不受约束生成之间可靠性差异的证据
- NIST AI 风险管理框架 —— 面向生产系统中 AI 输出验证的治理原则