输出格式提前定：要表格给表格、要大纲给大纲，省掉后期排版返工

1. 问题的本质：为什么格式总是最后才对齐

在传统软件工程里，“输出格式”从来不是一个需要反复讨论的问题——接口定义一旦确定，序列化与反序列化由框架自动完成。但大模型引入之后，这条边界被打破了：模型的输出是自然语言，而自然语言天然是“格式自由”的。当内容生成与格式约束被放在同一个概率采样过程中时，格式就变成了一个需要额外博弈的变量。

笔者在多个内容生产与数据抽取项目中观察到一种高度重复的模式：第一轮对话拿到内容，第二轮对话要求“改成表格”，第三轮对话发现表格列名不对，第四轮对话要求“换成 JSON”，第五轮开始人工复制粘贴。这个过程被团队戏称为“格式乒乓”。它的代价并不只是时间——每一次往返都会引入新的语义漂移风险，模型在重排格式时可能悄悄改写、删减或补充内容。

1.1 格式返工的三类成本

把“格式返工”拆开看，它至少包含三类可观测成本。第一类是交互成本：每一轮格式调整都是一次完整的推理调用，Token 消耗与延迟线性叠加。第二类是语义成本：格式重排过程中内容可能被无意修改，这类错误往往难以察觉，却直接影响下游可信度。第三类是工程成本：为了兼容模型输出的不确定性，下游不得不编写大量容错解析代码，这些代码本身又成为新的维护负担。

本文评述：这三类成本中，最容易被低估的是语义成本。交互成本和工程成本是显性的，团队能感知到“又调了一轮”“又写了个正则”；但语义成本是隐性的，它表现为“这份数据和上一版对不上，但没人知道是哪一步改的”。因此，格式治理的目标不应只是“让输出好看”，而应是“让输出可验证、可追溯”。

1.2 一个可量化的观察

在公开的结构化输出评测中，格式合规性一直是独立于内容正确性的评估维度。以 JSON 输出为例，早期模型在无约束条件下生成合法 JSON 的成功率在不同任务上波动较大，而一旦引入 Schema 约束或受限解码，合法率可以显著提升。需要说明的是，不同模型、不同任务的具体数值差异较大，本文不引用单一来源的具体百分比，而是强调趋势：约束越前置，合规率越高，返工轮次越少。这一趋势在多份工程报告与学术评测中方向一致。

下表给出一个整合性的定性对比（模拟数据，用于说明趋势，非实测结果）：

约束层级	典型手段	格式合规趋势	返工轮次趋势
无约束	纯自然语言指令	低	高
提示词约束	模板 + 示例	中	中
Schema 约束	JSON Schema / 函数调用	较高	较低
受限解码	语法级 token 屏蔽	高	低

这张表的核心信息是：格式治理存在一条清晰的“约束强度阶梯”。团队不必一步到位，但应当明确自己当前处于哪一级，以及下一级能带来什么收益。

2. 概念重构：格式契约与“左移”原则

软件测试领域有一个广为人知的原则叫“缺陷左移”——越早发现缺陷，修复成本越低。本文认为，格式问题同样适用这一原则，并且可以把它形式化为一个更明确的概念：格式契约（Format Contract）。

2.1 什么是格式契约

格式契约是指：在内容生成开始之前，生成方与消费方就输出的结构、字段、类型、约束达成的一份显式约定。它包含四个要素——结构（有哪些层级）、字段（每个位置放什么）、类型（字符串/数字/枚举）、约束（必填、取值范围、长度）。这份约定不是“建议”，而是可被机器校验的规格。

本文评述：格式契约的价值不在于“写下来”，而在于“可校验”。一份写在文档里但无法自动检查的格式说明，本质上仍是口头约定。只有当契约能被解析器、Schema 校验器或类型系统执行时，它才真正具备约束力。这也是后文强调 Schema 层与校验层的原因。

2.2 左移的三个层次

把格式约束左移，可以拆解为三个递进层次。第一层是时间左移：从“生成后调整”变为“生成前声明”。第二层是责任左移：从“人工校对”变为“机器校验”，把格式正确性的责任交给校验器而非编辑。第三层是认知左移：从“模型自己理解要什么格式”变为“我们明确告诉模型格式是什么”，减少模型的猜测空间。

这三层中，认知左移最容易被忽略。很多团队写提示词时会说“请用表格输出”，但“表格”是一个高度歧义的概念——几列？列名是什么？是否允许合并单元格？Markdown 表格还是 HTML 表格？模型只能猜，猜错就返工。认知左移要求我们把这些歧义在提示词中消解掉。

2.3 与“输出解析”的区别

需要澄清一个常见混淆：格式契约不等于输出解析。输出解析是“拿到结果后努力理解它”，属于后处理；格式契约是“让结果从一开始就符合预期”，属于生成期控制。两者是互补关系而非替代关系——即使有了契约，解析层仍需保留容错能力，因为模型输出永远存在长尾异常。

3. 技术谱系：从提示词到受限解码的四层约束

把格式约束落到工程上，可以归纳为四层，从弱到强依次是：提示词层、Schema 层、校验层、渲染层。前三层作用于“生成什么”，第四层作用于“怎么呈现”。下面先给出全局视图，再逐层展开。

3.1 提示词层：最灵活也最脆弱

提示词层的优势是零依赖、跨模型通用；劣势是约束力弱，模型可能“选择性遵守”。它适合格式相对简单、对合规率要求不极端的场景。

3.2 Schema 层：结构化的主力

Schema 层通过 JSON Schema、Pydantic 模型或函数调用参数定义输出结构。它把“格式”从自然语言描述升级为形式化规格，是当前工程实践中最具性价比的一层。

3.3 校验层：把正确性交给机器

校验层在生成之后立即运行，检查结构、类型、枚举、必填项，并在失败时触发重试或修复。它是“格式契约”能否闭环的关键。

3.4 渲染层：一次生成、多端适配

渲染层把结构化数据转换为目标形态：Markdown 表格、HTML、Excel、PDF、前端组件。它的前提是上游已经产出干净的结构化数据——这正是前三层的目标。

4. 提示词层：把格式要求写成可执行规格

提示词层的核心原则是：能写成规格的，不要写成愿望。“请用表格输出”是愿望，“输出一个三列表格，列名依次为‘指标、数值、来源’”是规格。规格化的提示词能显著降低模型的猜测空间。

4.1 格式指令的五个必备要素

1. 载体类型：Markdown 表格 / JSON / YAML / 大纲列表 / HTML。
2. 结构骨架：层级、字段名、列名，最好给出一个空模板。
3. 字段约束：类型、取值范围、是否必填、长度上限。
4. 示例：一个最小可用的正例，必要时给一个反例。
5. 边界说明：信息缺失时填什么（如“未知”），是否允许空值。

本文评述：这五个要素中，最常被遗漏的是“边界说明”。模型遇到信息缺失时，倾向于编造或省略，而这两种行为都会破坏格式契约。明确“缺失时填 N/A”这类规则，能有效减少下游的空值处理逻辑。

4.2 可复用的提示词模板

下面给出一个通用的格式契约模板，可直接嵌入系统提示词：

【输出格式契约】
1. 载体：Markdown 表格
2. 结构：表头固定为 | 指标 | 数值 | 单位 | 来源 |
3. 约束：
   - 数值列只允许数字或 N/A
   - 来源列必须为可追溯的标识（URL 或文献编号）
   - 行数不超过 20 行，超出时按重要性截断并注明
4. 示例：
   | 指标 | 数值 | 单位 | 来源 |
   | --- | --- | --- | --- |
   | 示例指标 | 12.3 | % | [1] |
5. 边界：信息缺失填 N/A，禁止编造数值
6. 禁止：表格外不得输出解释性段落

这个模板的关键在于第 6 条“禁止”。模型有强烈的“补充说明”倾向，如果不显式禁止，它往往会在表格前后加上一段“以下是整理后的表格……”，破坏纯结构化输出。

4.3 大纲类输出的写法

“要大纲给大纲”是本文标题中的另一半。大纲输出的常见问题是层级混乱、编号不一致。解决方法是把大纲的层级规则写死：

【大纲格式契约】
- 一级标题用 "1." "2." "3."，二级用 "1.1" "1.2"，三级用 "1.1.1"
- 每级标题不超过 20 字
- 每个一级标题下至少 2 个二级标题
- 只输出大纲，不展开正文
- 不使用 Markdown 的 # 号，使用纯文本编号

这里有一个细节值得注意：是否使用 Markdown 的 # 号，取决于下游渲染器。如果大纲要直接喂给文档系统，纯文本编号更稳；如果要渲染成网页，Markdown 标题更合适。格式契约必须与下游消费方式对齐，否则就是自找返工。

4.4 提示词层的局限

提示词层再精细，也无法保证 100% 合规。原因在于它作用于概率分布，而非硬性语法。模型可能在长输出后段“忘记”前面的约束，也可能在遇到复杂内容时优先保证语义而牺牲格式。因此，提示词层必须与后续的 Schema 层和校验层配合使用。

5. Schema 层：用 JSON Schema 与 Pydantic 锁死结构

如果说提示词层是“口头约定”，Schema 层就是“书面合同”。它把输出结构用形式化语言定义下来，让模型和校验器都能读懂。

5.1 JSON Schema：跨语言的结构描述

JSON Schema 是目前最通用的结构化输出描述方式。它支持类型、枚举、必填、嵌套、数组约束等能力。下面是一个用于“技术文章大纲”的 Schema 示例：

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "required": ["title", "sections"],
  "properties": {
    "title": { "type": "string", "maxLength": 60 },
    "sections": {
      "type": "array",
      "minItems": 3,
      "items": {
        "type": "object",
        "required": ["heading", "level", "points"],
        "properties": {
          "heading": { "type": "string", "maxLength": 40 },
          "level": { "type": "integer", "enum": [1, 2, 3] },
          "points": {
            "type": "array",
            "items": { "type": "string" },
            "minItems": 1
          }
        }
      }
    }
  }
}

这个 Schema 把“大纲”这个模糊概念拆成了可校验的字段：标题长度、章节数量、层级枚举、每章要点数。模型在生成时必须满足这些约束，否则校验层会拒绝。

5.2 Pydantic：Python 生态的工程化选择

在 Python 工程中，Pydantic 模型比裸 JSON Schema 更易维护，因为它同时提供类型提示、校验和序列化。许多模型 SDK 支持直接传入 Pydantic 模型作为输出结构。下面是一个等价实现：

from pydantic import BaseModel, Field
from typing import List, Literal

class Section(BaseModel):
    heading: str = Field(max_length=40)
    level: Literal[1, 2, 3]
    points: List[str] = Field(min_length=1)

class Outline(BaseModel):
    title: str = Field(max_length=60)
    sections: List[Section] = Field(min_length=3)

本文评述：Pydantic 的真正优势不在定义，而在“定义即文档、定义即校验、定义即类型”。当 Schema 以代码形式存在时，它可以进入版本控制、参与 CI、被 IDE 提示，这比维护一份独立的 JSON 文件要可靠得多。对于长期项目，笔者建议优先选择代码化的 Schema 定义。

5.3 函数调用与工具模式

主流模型 API 普遍支持“函数调用”或“工具调用”模式，其本质是把 Schema 作为参数传给模型，由模型填充。相比纯提示词，这种方式的结构合规率通常更高，因为模型在训练阶段就见过大量“按 Schema 填参数”的样本。

需要提醒的是，函数调用并不等于“绝对合规”。模型仍可能返回不符合 Schema 的参数，尤其是在嵌套层级较深或字段较多时。因此校验层不可省略。

5.4 受限解码：语法级的硬约束

受限解码（Constrained Decoding）是约束强度最高的一层。它在每一步采样时，根据目标语法（如 JSON、正则、上下文无关文法）屏蔽掉不合法的 token，从而在数学上保证输出符合语法。相关研究在 2020 年前后开始系统化，近三年随着开源推理框架的普及而进入工程实践。

本文评述：受限解码的代价是可能影响生成质量——过度约束会压缩模型的表达空间，尤其在需要自由推理的任务上。笔者的经验是：对纯结构化抽取任务，受限解码收益明显；对需要推理链的任务，应谨慎使用，或仅在最终输出阶段启用。

6. 校验层：自动检测与自修复回路

校验层是格式契约的“守门人”。它的职责是：拿到模型输出后，立即判断是否符合契约；不符合则触发修复流程，而不是把问题抛给人。

6.1 校验的三个维度

维度	检查内容	失败处理
语法	JSON 是否可解析、括号是否闭合	提取 + 重试
结构	必填字段、类型、枚举	带错误信息重试
语义	数值范围、引用可追溯、逻辑一致	标记人工复核

语法和结构校验可以完全自动化；语义校验往往需要领域规则，部分场景只能做到“标记可疑”而非“自动判定”。

6.2 自修复回路的设计

当校验失败时，最朴素的做法是“重试”。但无信息重试的收益很低——模型很可能犯同样的错误。更有效的做法是把校验错误作为反馈传回模型：

def generate_with_repair(prompt, schema, max_rounds=3):
    for i in range(max_rounds):
        raw = call_model(prompt)
        errors = validate(raw, schema)
        if not errors:
            return raw
        prompt = prompt + f"\n\n上一次输出存在以下格式错误：\n{errors}\n请仅修正格式，不要改动内容。"
    return None  # 交由人工处理

这个回路有三个要点：一是限制重试轮次，避免无限循环；二是明确告知只改格式，防止模型顺手改写内容；三是失败后降级到人工，而不是继续消耗 Token。

本文评述：自修复回路的隐藏风险是“内容漂移”。模型在修格式时可能微调措辞，而这类改动很难被格式校验发现。笔者的建议是：在修复回路中同时做一次内容哈希比对，若内容变化超过阈值则拒绝该次修复，改为人工介入。

6.3 校验器的实现建议

在工程上，校验器应满足三个条件：快、可组合、错误信息可读。快意味着它不能成为瓶颈；可组合意味着能同时检查语法、结构和自定义规则；错误信息可读意味着它能直接作为重试提示的一部分。Python 生态中，jsonschema、Pydantic、pandera 等库都能满足这些要求。

7. 渲染层：一次生成、多端适配的管线设计

渲染层的目标是把结构化数据转换为最终呈现形态。它的设计原则是：数据与呈现分离。同一份结构化数据，应该能渲染成 Markdown、HTML、Excel、PDF，而不需要重新调用模型。

7.1 渲染管线的四个阶段

1. 归一化：把模型输出统一为内部数据模型（如 dict / DataFrame）。
2. 校验：确认数据符合契约，否则走修复回路。
3. 模板绑定：用模板引擎（Jinja2、Mustache）把数据填入目标格式。
4. 后处理：转义、样式注入、分页、导出。

这个管线的关键收益是“一次生成、多端复用”。例如同一份产品参数数据，可以同时渲染成网页表格、Excel 附件和 PDF 报告，而不需要三次模型调用。

7.2 表格渲染的注意事项

表格是最常见的结构化输出形态，也是问题最多的。几个高频坑点：列宽溢出、单元格内换行、特殊字符转义、空值显示。这些都应该在渲染层统一处理，而不是让模型去操心。例如空值统一渲染为“—”，数字统一千分位，长文本统一截断加省略号。

7.3 大纲渲染

大纲渲染相对简单，但要注意编号一致性。如果模型输出的是纯文本编号，渲染层应负责转换为目标格式的编号（如 HTML 的 ol/li 嵌套）。这样即使模型输出的编号有细微偏差，最终呈现仍是规范的。

8. 评测体系：格式合规率与返工成本量化

没有度量就没有改进。格式治理需要一套可量化的指标，否则团队无法判断“这次优化到底有没有用”。

8.1 四个核心指标

指标	定义	目标方向
格式合规率	首次输出通过校验的比例	越高越好
平均返工轮次	从首次输出到通过的平均调用次数	越低越好
单次交付 Token 成本	含重试在内的总 Token / 成功交付数	越低越好
人工介入率	需要人工修正的交付占比	越低越好

这四个指标应作为常规监控项，按任务类型分别统计。因为不同任务的格式复杂度差异很大，混在一起看会掩盖问题。

8.2 评测集构建

建议为每类格式契约构建一个小型评测集（30–100 条），覆盖典型输入、边界输入和对抗输入。每次调整提示词或 Schema 后跑一遍，观察指标变化。评测集应纳入版本控制，避免“改完提示词忘了之前的效果”。

本文评述：很多团队把格式优化当成“一次性调参”，改完就完事。但模型版本会更新、业务输入会漂移、Schema 会演进，格式合规率是一个会自然衰减的指标。把它纳入持续监控，比一次调优更重要。

9. 工程案例：三类典型场景的落地路径

9.1 场景一：数据抽取到表格

任务是从非结构化文本中抽取字段并输出表格。落地路径：提示词层给出列名与边界规则 → Schema 层定义字段类型 → 校验层检查数值范围与来源标注 → 渲染层输出 Markdown 或 Excel。关键点是“来源列必填”，这能显著降低编造风险。

9.2 场景二：长文大纲生成

任务是为一篇长文生成层级大纲。落地路径：Schema 层约束层级与数量 → 校验层检查编号连续性 → 渲染层转换为目标格式。关键点是“只输出大纲”，避免模型提前展开正文。

9.3 场景三：多端内容分发

任务是同一份内容分发到网页、公众号、邮件。落地路径：先生成结构化数据 → 校验 → 用不同模板渲染。关键点是“数据与呈现分离”，避免为每个渠道单独调用模型。

10. 前沿与边界：Agent、多模态与格式演化

格式契约的思路正在向更多场景延伸。在 Agent 系统中，工具调用的参数本质上就是格式契约；在多模态场景中，图文混排的输出同样需要结构定义；在长上下文场景中，格式契约还承担着“压缩信息、稳定检索”的作用。

本文评述：格式契约的边界在于“过度约束”。当任务需要创造性表达时，过强的格式约束会损害内容质量。因此，格式治理应遵循“够用即可”原则——约束到下游能消费的程度，而不是追求形式上的完美。

11. 反模式清单与实施检查表

11.1 五个常见反模式

1. 口头契约：格式要求只存在于聊天记录里，没有可执行定义。
2. 无限重试：校验失败后无上限重试，成本失控。
3. 格式与内容同改：修复格式时允许模型改内容，导致语义漂移。
4. 渲染层兜底一切：把格式问题全部推给后处理，模型输出越来越随意。
5. 无评测：改完提示词不做回归，问题反复出现。

11.2 实施检查表

• 是否为每类输出定义了显式格式契约？
• 契约是否可被机器校验？
• 是否有失败重试与降级策略？
• 是否有格式合规率监控？
• 渲染层是否与生成层解耦？

12. 结论

“输出格式提前定”不是一句口号，而是一套可落地的工程方法。它的核心是把格式从后处理问题重新定义为生成期契约，通过提示词层、Schema 层、校验层、渲染层的协同，把返工成本降到最低。本文给出的模板、代码与指标，均可直接用于实际项目。格式治理的终点不是“让模型听话”，而是“让系统可控”。