如何约束输出格式：让 AI 的答案可以直接阅读、复制和处理
根据任务选择段落、清单、表格或 JSON，并用字段、顺序、数量和校验规则约束输出，让结果更稳定地进入下一步工作。
相关工具
格式不是装饰，而是交付接口
让 AI 写一段说明，结果好不好，通常可以直接靠阅读判断；让 AI 提取一批资料，情况就不一样了。你可能需要把结果粘贴进表格、交给同事继续处理，或者让程序读取字段。此时，内容大致正确还不够，字段是否齐全、顺序是否稳定、格式是否可解析，都会影响下一步工作。
《LLM 入门资料》中，文本总结、转换和推断是不同类型的任务，后续的输出检查和评估又把结果是否符合要求单独拿出来处理。这个安排很有启发：Prompt 不只是告诉模型写什么，也要告诉它交付成什么样。格式越贴近使用场景，结果越容易被复核和复用。
给人读、给人执行、给人比较，还是给系统继续处理，决定了输出格式。段落、清单、表格和 JSON 各有自己的适用范围，选错格式，即使内容正确，也可能无法直接使用。
解释用段落，执行用清单，对比用表格，系统处理优先使用 JSON。
段落、清单和表格分别解决什么问题
段落适合解释概念、说明背景和展开因果关系。它的优点是自然，缺点是信息位置不固定，后续很难批量比较。要求 AI 写教程、说明原因或改写文章时，段落通常是合适的，但仍然应该给出标题层级、篇幅和读者范围。
清单适合行动。待办事项、发布前检查、故障排查和会议任务，都可以用清单把动作拆开。清单最好让每一项只承担一个动作，并说明完成条件。例如“检查接口”太宽，可以写成“确认请求方法、路径、鉴权方式和错误码是否与文档一致”。
表格适合横向比较和字段对齐。比较方案、整理用户反馈、列出风险和负责人时，表格能让缺项很快暴露。表格的列名要先确定，还要说明空值怎么写、同一单元格能否放多条内容、是否允许增加额外列。
JSON 适合机器读取，但不等于随便加几个大括号
JSON 的价值在于结构稳定、字段明确、便于程序解析。它适合信息抽取、分类、接口传递和自动化流程。但如果只要求“请用 JSON 输出”，模型仍然可能漏字段、改变类型、添加解释文字，甚至把不合法的尾逗号带进结果。JSON 需要字段规则，不能只指定外观。
至少要说明字段名、字段类型、是否必填、允许的取值和缺失时的写法。例如，“age 必须是数字，未知时使用 null；tags 必须是字符串数组，没有标签时使用 []；只输出 JSON，不要加 Markdown 代码围栏和解释”。这些规则正是机器能够稳定接收的前提。
如果任务较复杂，可以给出一个最小示例，但示例要覆盖边界情况。只展示完整对象，模型可能不知道缺失值怎么处理；只展示一种分类，模型可能照抄示例里的取值。示例负责说明形状，规则负责说明边界，两者不能互相替代。
Markdown 表格强调可读性，JSON 强调可解析性，清单强调可执行性，选择取决于后续用途。
把字段、顺序和数量写成验收条件
格式约束最好能够被逐项检查。字段约束回答必须有哪些内容；顺序约束回答先输出什么；数量约束回答输出几项；类型约束回答每项应该是什么形式。例如，“输出 5 条风险，每条包含风险、影响、证据和建议，按严重程度从高到低排列”，就比“整理一下风险”更容易验收。
需要固定顺序时，直接列出来。需要控制长度时，说明是总字数、每条字数还是字段长度。需要避免套话时，写成禁止规则，例如“不要输出开场说明、总结语和与 JSON 无关的解释”。不要把“简洁”“完整”“专业”当成唯一标准，它们必须落成具体要求。
还要处理冲突。比如一边要求最多 300 字，一边要求覆盖所有背景和例子；一边要求只输出 JSON，一边又要求先解释判断过程。Prompt 应该给出优先级，告诉模型准确性、字段完整性、长度和说明哪个更重要。
用一个清楚的模板约束结构
对于固定任务，可以直接把输出模板写出来。模板不一定要很长，但要让模型看到字段关系和边界。例如：
请从下面的客户反馈中提取结构化信息。
只输出合法 JSON，不要输出解释文字或 Markdown 代码围栏。
字段要求：
- issue：问题类型，字符串，必填
- quote：用户原话，字符串，必填
- severity：严重程度，只能是 high、medium、low
- evidence：支持判断的原文片段，没有时写 null
- suggestion：处理建议，字符串数组，没有时写 []
输出结构：
{
"items": [
{
"issue": "",
"quote": "",
"severity": "medium",
"evidence": null,
"suggestion": []
}
]
}
材料：
<<<
在这里粘贴客户反馈
>>>这个模板告诉模型三件事：要抽取什么、用什么结构交付、哪些值不能越界。示例里的空值和数组也有作用，它们比一句“请规范输出”更能减少结构漂移。对于实际项目，还可以把模板保存为版本，记录字段变更和失败样本。
常见失败：内容对了，格式却不能用
第一类失败是漏字段。模型回答了核心问题，却没有输出来源、优先级或时间。通常是字段清单不够醒目，或者任务太长导致格式要求被忽略。解决办法是把必填字段集中列出，并说明缺失时写什么。
第二类失败是类型不一致。同一个字段有时输出数字，有时输出“高”，有时输出“严重”，程序就很难处理。要明确类型和可选值，最好给出边界示例。第三类失败是额外解释，系统只接受 JSON 时，必须明确除 JSON 外不输出任何文字。
第四类失败是顺序和数量失控。要求列出三个建议时，模型可能给出四个；要求按优先级排序时，可能把理由和建议混在一起。遇到这类问题，不要只重复“请严格遵守”，而要把数量、排序字段和每项结构写得更具体。
输出之后还要检查，格式约束不是一次性命令
在教程 相关的应用系统部分，输入检查、输出检查和评估被当成独立环节。这个思路同样适合日常 Prompt：生成不是结束，至少要检查字段是否齐全、类型是否正确、数量和顺序是否符合要求，必要时还要检查内容有没有依据。结构化输出尤其不能只靠肉眼看起来像。
如果发现格式失败，先定位是哪一种失败：漏字段就补字段规则；类型错误就写明可选值；多出解释就强化纯格式要求；内容和字段错位就提供更清楚的示例。每次只改一类问题，比较前后结果，Prompt 才会逐渐稳定。
依次检查字段、类型、数量和顺序；不通过时定位具体问题，再修改提示词或重新生成。
选择格式时，先看结果要去哪里
给人阅读的内容，优先考虑标题、段落和列表；给人执行的内容，优先考虑清单和明确动作；给人比较的内容，优先考虑表格和统一维度；给程序读取的内容，优先考虑 JSON 和固定字段。不要因为 JSON 看起来专业，就把所有回答都变成 JSON，也不要因为表格整齐，就把需要完整解释的内容硬塞进表格。
格式选择最终服务于后续工作。能直接粘贴、能快速检查、能被程序解析、能让责任人知道下一步，这些都是好格式的实际标准。格式越清楚，模型的自由发挥空间越小，但有用的表达空间反而越大。
把输出要求写清楚，不是为了把 AI 变成只会填空的工具，而是为了让它的语言能力接入真实流程。先确定交付对象，再确定格式；先定义字段，再要求生成；生成之后继续检查。这样，Prompt 才从一句请求变成可复用的工作接口。
常见问题
所有任务都应该用 JSON 吗？
不应该。解释概念适合段落，执行任务适合清单，对比信息适合表格，只有需要机器读取或稳定传递时才优先考虑 JSON。
只写“严格按照格式输出”为什么不稳定？
因为模型不知道格式具体包含哪些字段、类型、数量和边界。把字段清单、示例、缺失值写法和禁止内容列出来，约束会更容易执行。
输出格式不对时，是不是要把 Prompt 写得更长？
不一定。先定位是漏字段、类型错误、额外解释还是数量失控，再只补充对应规则。针对性修改通常比无关地增加篇幅更有效。