先回答两个"为什么"
很多人第一次用大模型时都会困惑：为什么 AI 默认输出 Markdown？为什么不直接给 JSON？
原因一：大模型是文本模型，不是渲染引擎。 HTML 太重，一个 <div> 要占几十个 token，而 Markdown 用几个符号就能表达同样的结构层级，Token 成本低得多——这是 Token 即金钱的时代里最朴素的选择。
原因二：角色扮演是成本最低的"人格化"。 同一个模型，通过 System Prompt 指定角色，就能变成客服、面试官、代码审查员——角色 + 任务 + 上下文 + 约束 + 示例 + 格式，六要素一组合，行为就完全不一样。而"格式"正是六要素里和输出最直接相关的一环。
换句话说：提示工程决定了模型"说什么"，输出格式决定了模型"怎么说、怎么交"。 本文就把输出格式这件事掰开揉碎，用流式体验作为主线做一次硬核对比。
一、五种输出格式速览
1. 纯文本
零结构、零语法负担，最省 Token，但除了"人读"什么都做不了。适合聊天回复、简短结论、给人类看的摘要。
2. Markdown
大模型的事实默认值。人机两用：人读起来有层级，机器可以用 #/-/` 做轻量解析。缺点是语义靠"惯例"而非"规则"——模型偶尔漏一个 # 或缩进错位，解析就崩。
3. JSON
机器友好天花板。字段明确、嵌套清晰，JSON.parse 一次到位，配 JSON Schema 还能做校验与纠错。代价是结构开销高：{、"、, 全是 Token，且必须等整个 JSON 闭合才能解析。
4. YAML
可读性好、配置界老熟人，Token 介于纯文本和 JSON 之间。但缩进敏感 + 转义规则多，LLM 生成的 YAML 稍有缩进漂移就报废，是五种里"最容易翻车"的一个。
5. XML
语法最重（开闭标签翻倍），但换来的是明确的边界语义——<tag> 一出现就知道字段开始了，</tag> 一出现就知道字段结束了。这正是流式场景的杀手锏。
二、四个维度硬核对比
| 维度 | 纯文本 | Markdown | JSON | YAML | XML |
|---|---|---|---|---|---|
| 前端处理 | 无，整段展示 | 渲染器一次转换 | 解析一次出对象 | 需 YAML 解析器 | 流式解析 / 一次性解析 |
| Token 量 | 最低 | 低 | 较高 | 中 | 最高（标签翻倍） |
| 结构解析 | ✗ 无法提取字段 | △ 靠惯例，易错 | ✓ 强，可 Schema 校验 | △ 缩进敏感易崩 | ✓ 强，标签即边界 |
| 流式体验 | 逐字显示，无结构 | 逐字显示，无法提取字段 | 等全文闭合，解析一次 | 等全文，且易错 | 捕获标签 → 立刻渲染字段 |
| 容错性 | — | 中 | 中（可用 partial-json 补救） | 低 | 高（标签边界容错） |
| 最佳场景 | 聊天、摘要 | 博客、文档、对话 | API、Agent 工具调用 | 配置文件 | SSE 流式、结构化事件流 |
三、核心结论：流式体验决定一切
如果说 Token 量决定"贵不贵"，流式体验就决定"快不快、准不准"。三种主流格式在流式下的表现截然不同：
🟢 XML：捕获标签 → 立刻渲染字段
生成 <title>流式渲染</title> 时，前端读到 <title> 就开始挂载字段，读到 </title> 立刻完成该字段渲染。可以像 SAX 解析器一样边生成边消费，每个字段的"开始"和"结束"都有明确信号，天然适配 SSE（Server-Sent Events）。这是增量渲染的正解。
🟡 JSON：等全文 → 解析一次
{ 开始、} 结束才算完。流式到一半的 JSON 是非法 JSON，前端只能干等；要么用 partial-json / json-stream 这类增量解析库做 hack，要么接受"转圈圈直到全部生成"。延迟换取完整性和类型安全，适合工具调用这类"必须一次给对"的场景。
🔴 Markdown：逐字显示 → 无法提取字段
只能整段渲染：# 标题 要等这一行基本完整才敢上样式，更别提从流里抓一个字段——没有闭合语义，你永远不知道"这句话是不是已经完了"。它适合"给人看"，不适合"给程序抓"。
一句话总结
给人读，选 Markdown；给机器一次性消费，选 JSON；给机器边生成边消费，选 XML。
四、实战选型建议（决策树）
- 纯聊天气泡、周报、总结 → Markdown（或纯文本），渲染器一步到位。
- 结构化数据、Agent 函数调用、需要校验 → JSON + JSON Schema，配
partial-json兜底流式。 - SSE 流式输出、前端要逐字段渲染的复杂 UI → XML（或自建轻量标签协议如
<field>），增量解析。 - 配置文件、静态文档 → YAML 交给人类写，别让模型直接生成，翻车率太高。
- 混合方案：外层 JSON 传元信息 + 内层 Markdown 传正文（很多内容平台就是这么干的）。
五、写在最后
输出格式不是"编码习惯"，而是产品体验的一部分。选错格式，轻则多烧 Token，重则流式白做、字段抓不出来。记住这条主线：
Token 决定成本，结构决定可解析性，闭合语义决定流式体验。 下次设计 LLM 应用时，先问自己三个问题：这份输出给谁看？要不要拆字段？能不能边生成边消费？答案出来，格式自己就定了。