结构化输出提示词指南-含JSONXML表格格式2版

结构化输出提示词指南——含JSON/XML/表格格式结构化输出|JSON|XML|表格格式|提示词技巧2026年9月26日一、为什么结构化输出比“写得好看”更重要AI默认的输出方式是像人一样说话。你问它“提取这份合同的关键条款”，它回你一大段叙述性文字——条款一说了什么，条款二又规定了什么，中间还穿插几句总结性评论。人要读懂这段话需要几分钟，机器要解析这段话则需要写正则表达式、做NLP抽取、处理各种边界情况——而且大概率还是会出错。结构化输出的价值就在于此。它把“人能读懂”的输出变成“人和机器都能直接用”的输出。你不需要再花时间手动整理、复制粘贴、核对字段，生成的JSON直接入库，生成的表格直接进Excel，生成的XML直接被下游系统消费。在2026年，结构化输出已经从“可选技巧”变成了“生产级默认”。Thoughtworks的技术雷达将其列为应用消费LLM响应的“合理默认选项”，并指出结构化输出还能降低模型产生幻觉的概率。不采用结构化输出的团队，等于在每一步都多了一道人工清洗的工序。二、三种格式怎么选：各管一段JSON、XML、表格（CSV/Markdown）各自解决不同的问题。选错格式，要么增加了不必要的解析复杂度，要么牺牲了可读性。格式最适合的场景核心优势核心劣势典型用途JSON机器消费——API响应、数据库入库、工作流引擎字段稳定、结构清晰、几乎所有编程语言原生支持对嵌套层级深的内容可读性差，模型容易在括号和逗号上出错数据抽取、分类打标、字段提取XML提示词内部结构划分——区分指令、上下文、示例边界清晰、容错性好、嵌套结构不易出错冗长，解析需要专门的XML解析器复杂提示词的区块划分、多字段提取表格人类阅读——对比分析、清单呈现、报告展示直观易读，可直接复制到文档工具不适合表示层级关系，列数过多时可读性骤降竞品对比、参数列表、会议待办清单选型决策树：输出要被代码消费→JSON（配合Schema约束）输出要被人类阅读→Markdown表格提示词本身需要划分多个区块→XML标签需要生成大量数据供Excel分析→CSV一个常见的误解是“用一种格式解决所有问题”。实际上，最稳健的做法是在提示词内部用XML标签划分区块，在输出格式上根据消费方选择JSON或表格。三、JSON输出：字段稳定是第一优先级3.1JSON模式的两条路径目前主流模型平台提供两种JSON输出方式，可靠性和适用场景差异很大。路径一：JSONMode（提示级约束）告诉模型“请输出JSON”，但不强制指定结构。支持范围最广，几乎所有模型都支持。但只保证输出是“合法的JSON”，不保证字段名、字段类型、字段数量符合你的预期。路径二：StructuredOutputs（Schema强制约束）通过提供JSONSchema，让模型在生成时受到解码层的语法约束。OpenAI的strict模式可以保证100%的schema匹配率——模型在采样时无法生成违反schema的token。阿里云百炼的JSONSchema模式同样提供了精确的结构和类型控制，消除了额外的验证和重试。选型判断：如果你的下游代码依赖字段名来解析（比如data["name"]、data["score"]），必须用StructuredOutputs。JSONMode是过渡方案，适用于旧模型或无法编写Schema的临时场景。3.2提示词模板：JSONSchema约束版任务：【用动词开头，说明要做什么】。

输出格式：返回JSON，严格遵循以下Schema：

{

"type":"object",

"properties":{

"字段1":{"type":"string","description":"字段1的含义"},

"字段2":{"type":"number","description":"字段2的含义"},

"字段3":{

"type":"array",

"items":{"type":"string"},

"description":"字段3的含义"

}

},

"required":["字段1","字段2","字段3"]

}

约束：

-只输出JSON，不要包含任何解释性文字。

-字段值必须来自原文，不得编造。

-【其他约束条件】示例（从客户邮件中提取信息）：任务：从以下客户邮件中提取关键信息。

输出格式：返回JSON，严格遵循以下Schema：

{

"type":"object",

"properties":{

"customer_name":{"type":"string","description":"客户姓名"},

"product":{"type":"string","description":"涉及的产品名称"},

"issue_type":{"type":"string","enum":["质量问题","物流问题","售后咨询","其他"],"description":"问题类型"},

"urgency":{"type":"string","enum":["紧急","一般","低"],"description":"紧急程度"},

"requested_action":{"type":"string","description":"客户要求的动作，没有则填null"}

},

"required":["customer_name","product","issue_type","urgency","requested_action"]

}

约束：字段值必须来自邮件原文，不得推测或编造。

邮件原文：【粘贴邮件内容】3.3JSON提示词的四个关键操作操作一：在提示词中同时给出Schema和示例FireworksAI的官方文档明确指出，最佳实践是同时在提示词和response_format参数中提供Schema——“模型不会自动看到Schema，Schema是在生成过程中被执行的”。提示词中的Schema让模型理解你要什么，response_format中的Schema在解码层强制约束。操作二：明确要求“只输出JSON”如果不明确指示，模型可能在JSON前后添加解释性文字（如“以下是提取结果：”），导致解析失败。在提示词中加上“只输出JSON，不要包含任何解释性文字”。操作三：用enum限定枚举字段对于分类、状态、优先级等字段，用enum明确列出所有合法值。不限定枚举值，模型可能自由发挥——该填“紧急”的地方填了“非常紧急”或“urgent”，下游系统无法识别。操作四：required字段全部列出StructuredOutputs模式下，required数组中的每个字段都必须在输出中出现。不要依赖模型的“自觉”——不确定的字段，就用nullable类型，让模型显式返回null，而不是省略该字段。3.4各平台JSON模式对比平台JSONModeSchema强制关键注意事项OpenAI✅json_object✅json_schema+strictstrict模式要求所有字段在required中Claude✅提示词方式✅output_config.formatClaude无原生json_object，需通过提示词约束Gemini✅json_object✅responseSchema响应Schema支持有限类型集阿里云百炼✅json_object✅json_schemaJSONMode要求提示词必须包含“JSON”关键词Fireworks✅json_object✅json_schema建议同时在提示词和response_format中提供Schema四、XML标签：提示词内部的结构化4.1XML标签在提示词中的作用XML标签的核心作用是在提示词内部划分区块，让模型清楚地区分“这段是指令”“这段是上下文”“这段是示例”“这段是输出格式要求”。Claude的官方文档明确指出，当提示词包含多个组件时，“XML标签可以成为改变游戏规则的工具”。XML标签的四个价值：清晰度——清晰区分提示词的不同部分；准确性——减少模型因混淆指令与示例而犯的错误；灵活性——轻松找到、添加、移除或修改提示词的某个区块，无需重写全部内容；可解析性——让模型在输出中也使用XML标签，使后续处理更容易提取特定部分。4.2提示词模板：XML区块划分版<role>你是一名【具体职位/身份】。</role>

<context>

【提供背景信息，如项目背景、数据来源、业务场景】

</context>

<instructions>

1.【第一步做什么】

2.【第二步做什么】

3.【第三步做什么】

</instructions>

<constraints>

-必须包含：【必要内容】

-禁止出现：【排除内容】

-【其他约束】

</constraints>

<formatting>

【描述输出的结构和格式要求】

</formatting>

<input>

【需要处理的实际内容】

</input>示例（生成财务报告）：<role>你是示例公司的财务分析师。</role>

<context>

示例公司是一家B2BSaaS企业。投资者重视透明度和可行的见解。

</context>

<data>

【粘贴财务数据】

</data>

<instructions>

1.包括以下部分：收入增长、利润率、现金流量。

2.突出优势和需要改进的领域。

3.使用简洁专业的语气。

</instructions>

<formatting_example>

【粘贴上一季度的报告作为格式示例】

</formatting_example>Claude的官方示例显示，使用XML标签后，输出的报告结构更清晰、语气更一致，因为模型不会再混淆“数据源”和“指令”的边界。4.3XML标签使用的最佳实践保持命名一致性：在整个提示词中使用相同的标签名称，并在谈论内容时引用这些标签名称。例如，用<contract>标签包裹合同内容后，在指令中写“使用<contract>标签中的合约条款进行比对”，模型能精确对应。嵌套标签处理层级内容：对于有层级关系的内容，使用嵌套标签。例如，用<documents>包裹多个文档，每个文档用<documentindex="n">包裹，表示“第n个文档”。标签名称要有描述性：用<instructions>、<example>、<formatting>这类有明确含义的标签名，不要用<a>、<b>、<part1>这种无信息量的名称。模型没有“最佳标签”的预设：Claude并没有被专门训练过哪些是“最佳”的XML标签，标签名称与其包含的信息相符即可。4.4XMLvsJSON：什么时候用哪个判断维度用XML用JSON用途提示词内部的区块划分输出的结构化数据嵌套深度深嵌套结构更不易出错（无逗号/括号匹配问题）浅层结构清晰，深层嵌套可读性骤降解析方式提示词内部不需要解析，模型直接理解下游代码直接解析容错性更高——缺少闭合标签模型仍能理解语义更低——缺少逗号或括号直接导致解析失败模型兼容Claude对XML标签的识别最准确所有模型都支持实操建议：在提示词内部用XML标签划分指令、上下文和示例，在输出格式上根据消费方选择JSON或表格。两者不互斥，而是互补。五、表格输出：人类阅读的首选5.1Markdown表格vsCSV：什么时候用哪个表格格式分为两种，适用场景差异明显。Markdown表格：适合人类阅读。输出的表格可以直接粘贴到Notion、飞书、网页或任何支持Markdown的编辑器中。列数控制在5列以内，超过7列时移动端可读性骤降。CSV格式：适合大量数据供Excel分析。字段用逗号分隔，可直接保存为.csv文件用Excel或GoogleSheets打开。不包含格式化信息（如表头加粗、合并单元格），但数据密度高。格式适合场景列数限制数据量限制是否包含格式Markdown表格对比分析、清单呈现≤7列≤50行支持加粗、对齐CSV大批量数据导出无硬限制无硬限制不支持格式5.2提示词模板：Markdown表格版任务：【说明要对比或整理的内容】。

输出格式：使用Markdown表格，列分别为：【列1名称】、【列2名称】、【列3名称】、【列4名称】。

约束：

-表头加粗。

-如果没有提到【某个字段】，填“待定”。

-【其他约束】。示例（提取会议待办）：任务：阅读以下会议记录，提取所有待办事项。

输出格式：使用Markdown表格，列分别为：任务内容、负责人、截止时间、优先级。

约束：如果没有提到截止时间，填“待定”；优先级分为“高/中/低”三档。

会议记录：【粘贴会议记录】5.3提示词模板：CSV版任务：【说明要生成或提取的数据】。

输出格式：输出CSV格式，字段为：【字段1】,【字段2】,【字段3】。

约束：

-不包含表头。

-每行一条记录。

-【其他约束】。示例（生成模拟数据）：任务：生成50条模拟用户数据。

输出格式：输出CSV格式，字段为：id,name,email,role。

约束：不包含表头。每行一条。id从1开始递增。5.4表格输出的常见问题问题一：列数太多导致可读性差。超过7列的表格在移动端和聊天窗口中几乎无法阅读。如果确实需要展示多个维度，拆成两张表，或只保留最关键的3-5列。问题二：模型自由添加列或改变列顺序。在提示词中明确指定列名和顺序，并在约束中加上“严格按指定的列名和顺序输出，不添加或删除列”。问题三：缺失值处理不一致。明确约定缺失值的填充规则——填“待定”、填“N/A”、还是留空。不约定，模型可能在不同位置用不同方式处理。六、进阶技巧：让结构化输出更稳定6.1在提示词末尾强调输出格式模型对提示词末尾的内容有更强的注意力（近因偏误）。把格式指令放在提示词的末尾，比放在开头效果更好。6.2用少量示例锚定格式给2-3条完整的输入-输出示例，比文字描述格式更有效。示例中要包含“正确格式的样子”，而不是“错误格式的样子”——模型倾向于模仿示例，而不是遵循否定指令。6.3输出包裹在代码块中对于JSON和XML输出，要求模型将结果包裹在代码块中，便于后续提取：输出格式：将JSON结果包裹在```json和```之间。6.4验证与重试机制即使使用了StructuredOutputs，也建议在应用层做字段级校验。结构化输出保证的是“形状”而非“内容”的正确性。GPT-5.6在2026年9月的测试中返回了87次全部合法的JSON，但其中10次的内容是错的。Schema校验通过不代表数据准确——需要额外检查字段值的合理性。七、不同场景的格式选择速查场景推荐格式推荐约束方式关键注意事项数据抽取（从文档提取字段）JSONSchema强制+enum约束字段值必须来自原文，不得编造分类打标JSONenum限定所有合法值明确每个类别的定义多维度对比分析Markdown表格指定列名和顺序列数控制在5列以内批量数据导出CSV指定字段和分隔符约定缺失值填充规则提示词内部区块划分XML标签描述性标签名+嵌套结构保持命名一致性会议待办提取Markdown表格指定列名+缺失值规则明确优先级的分档标准API响应JSONjson_schema+strictrequired列出所有必须字段报告生成（带格式）XML（提示词内）+Markdown（输出）用XML划分提示词，用表格输出数据确保格式示例完整展开八、不同规模团队的适配方案8.1三套方案核心差异维度标准版简化版微型版适用团队有开发能力，输出直接对接系统有基础技术能力，输出供人工整理无技术背景JSON使用Schema强制+Pydantic/Zod解析JSONMode+手动校验不用JSONXML标签全面使用，提示词模板化管理按需使用，划分关键区块不使用表格输出Markdown+CSV，按场景切换只用Markdown表格只用Markdown表格验证机制字段级校验+自动重试人工抽查人工逐条核对提示词管理团队共享模板库+版本管理个人模板库不需要8.2标准版：Schema强制+验证闭环核心动作：①所有输出使用StructuredOutputs模式，用Pydantic或Zod定义Schema，SDK自动生成JSONSchema并解析响应；②在Schema中用enum限定所有枚举值，用required列出所有必须字段；③建立字段级校验规则，对数值型字段检查范围，对字符串字段检查长度，对枚举字段检查合法性；④校验失败时自动重试，重试仍失败则标记为人工处理。8.3简化版：JSONMode+人工校验核心动作：用JSONMode输出，提示词中明确给出字段名和类型。拿到输出后人工检查字段是否完整、值是否合理。不需要写Schema文件，也不需要自动校验代码。适合每天处理不超过20条结构化数据的场景。8.4微型版：只用Markdown表格核心动作：所有结构化输出都用Markdown表格。提示词中说清楚列名和列顺序，约定缺失值的填法。输出后人工核对一遍即可使用。不需要JSON、不需要XML、不需要任何技术工具。九、完整案例：从合同提取到结构化输出背景：某法务团队需要从供应商合同中提取关键条款，录入合同管理系统。第1步：选择格式输出要被系统消费，选择JSON格式，使用Schema强制约束。第2步：编写提示词任务：从以下合同中提取关键条款信息。

输出格式：返回JSON，严格遵循以下Schema：

{

"type":"object",

"properties":{

"contract_id":{"type":"string","description":"合同编号"},

"supplier_name":{"type":"string","description":"供应商名称"},

"contract_amount":{"type":"number","description":"合同金额（元）"},

"payment_terms":{"type":"string","description":"付款条件"},

"delivery_deadline":{"type":"string","description":"交付截止日期，格式YYYY-MM-DD"},

"penalty_clause":{"type":"string","description":"违约金条款摘要，没有则填null"}

},

"required":["contract_id","supplier_name","contract_amount","payment_terms","delivery_deadline","penalty_clause"]

}

约束：

-只输出JSON，不要包含任何解释性文字。

-字段值必须来自合同原文，不得推测或编造。

-合同金额只