大多数团队在无意中做出的上下文格式选择：JSON vs Markdown vs 纯文本

大多数团队在开发初期选择一次上下文格式后，就再也不会重新审视它。一位开发者选择 JSON 是因为它看起来结构化且机器可读。另一位开发者则选择 Markdown，因为他们在 README 文件中一直使用它。当似乎没有其他必要时，普通文本（Plain text）就成了默认选择。这些并不是工程决策——它们只是习惯。并且它们在无形中塑造了你的模型如何进行推理。

你传递给 LLM 的格式并非死板的包装。它本身就是一条指令。结构化的 JSON 上下文会引导模型进入遵循模式（schema-following）的行为。Markdown 鼓励层次化的综合。普通文本则开启了更灵活的推理。即使只是选错了一个格式类别，也可能导致准确率下降 40% 或更多——而且你无法在日志中查看到这种错误。

格式改变的是模型的思考方式，而不仅仅是输出内容

近期关于提示词（prompt）格式化的实证研究中最重大的发现是，格式会影响推理模式，而不仅仅是输出结构。当你向模型输入 JSON 编码的上下文时，你实际上是在暗示它以模式提取（schema-extraction）模式运行。当你需要返回结构化数据时，这很有用，但它会主动抑制灵活的推理，而这种推理正是 LLM 擅长处理综合任务、消除歧义或生成代码的关键。

针对 GPT-3.5 和 GPT-4 模型的基准测试结果显示，在某些特定任务中，仅仅由于格式选择的不同，其表现差异就可能超过 300%。在代码生成基准测试中，GPT-4 在处理普通文本上下文时表现最佳，而使用 JSON 编码相同信息时表现则显著下降。在表格理解任务中，Markdown 键值对格式的表现比 CSV 高出近 20 个百分点——这并不是因为底层数据不同，而是因为格式赋予了模型不同的结构引导（structural priming）。

这种影响因模型而异。GPT-4 偏好 Markdown，并在格式变化时表现出相对稳定的行为。GPT-3.5 对格式更敏感，通常在使用 JSON 时表现更好。参数量较小的开源模型（约 3B）在很大程度上对格式不敏感，在 JSON、YAML、XML 和 Markdown 之间的差异小于 5%——但它们的绝对准确率也较低，这意味着当你转向更强大的模型时，格式问题变得更加重要。

JSON 并非你想象中那样安全的默认选择

JSON 给人一种严谨的感觉。它强制执行结构，可由机器解析，并表明你的系统正在“规范地运行”。但这种直觉会让团队陷入两种不同的失败模式。

第一种是推理约束（reasoning constraint）。当结构化的 JSON 上下文被传递给需要灵活推理的任务（如创意综合、开放式分析、代码生成）时，模型的 Token 分布会被拉向符合模式的补全（schema-consistent completions）。它在填充字段，而不是在自由推理。这与使结构化输出发挥作用的机制相同：模型保持在你定义的轨道内。但当轨道成为限制而非引导时，你得到的输出虽然在语法上有效，但在语义上却很平淡。

第二种失败模式是模式脆弱性（schema fragility）。在没有显式模式强制的情况下，JSON 上下文产生的输出会出现字段名偏移、类型隐式转换以及必填字段缺失。对智能体（agentic systems）的研究表明，格式错误的 JSON——缺失括号、错误的转义、类型不匹配——占生产环境中智能体失败原因的 60% 以上。模型并不知道你的下游解析器在它写入字符串的地方期望一个整数。解决方法是在边界处进行显式的模式验证，并通过错误反馈强制其自我修正。强制执行 JSON Schema 验证可以将输出合规性从不足 40% 提高到接近 100%。但这并不是偏好 JSON 的理由；而是应该将 JSON 输出视为一个可靠性工程问题，而不是一个默认假设。

一个行之有效的实践模式是：仅将 JSON 严格用于需要机器解析的输出，并通过显式的模式验证和修正循环来强制执行，永远不要将其作为模型需要进行推理的上下文输入格式。

Markdown 的隐藏优势

Markdown 在大多数推理任务中表现出色，原因很直白：它是 LLM 训练数据中权重最高的格式。GitHub 仓库、Jupyter Notebook、文档网站以及 Stack Overflow 的回答都大量使用 Markdown。当你用 Markdown 编写上下文时，你是在用模型的母语进行沟通。

这在基准测试中得到了体现。对于表格数据，Markdown 键值对格式在相同理解任务中的准确率约为 61%，而 CSV 仅为 44%。对于 RAG 检索，基于标题边界的 Markdown 分块比非结构化文本的检索准确率提高了多达 35%。对于思维链（chain-of-thought）推理，带有编号步骤的 Markdown 优于 JSON 包装的推理链。

Markdown 在 Token 效率上也优于 JSON。对于相同的信息，Markdown 通常比 JSON 少用 30–40% 的 Token。JSON 的属性名、引号和结构标点符号带来的开销会累积。在大规模应用中，为上下文编码选择 JSON 而非 Markdown 会在大多数任务中增加一倍的推理成本，且不会带来准确率的提升。

反对 Markdown 的理由很直接：它没有原生的模式强制，如果你的下游系统需要结构化输出，你需要一个单独的解析层。但这并不是在上下文中避免使用 Markdown 的理由——而是应该将输出格式与上下文格式分开的理由，而大多数系统本来就应该这样做。

纯文本胜出的时刻

文献中最反直觉的发现是，在那些你认为结构化会有所帮助的任务中，纯文本的表现有时反而优于 JSON 和 Markdown。

在代码生成基准测试中，GPT-3.5 和 GPT-4 使用纯文本上下文时的得分高于使用相同底层信息的 Markdown 或 JSON 格式。这种效果在 GPT-4 的 HumanEval 基准测试中尤为明显。一种假设是，结构化格式在模型做出决策之前的早期解码步骤中限制了其 Token 生成。纯文本为模型在确定输出结构之前解决问题留出了更多空间。

纯文本在处理事实检索任务时也表现稳健。当你传递一大段密集的参考资料并要求模型提取特定事实时，只要资料连贯且检索问题清晰，纯文本通常与结构化方案表现一样好。但在多实体消歧方面，纯文本往往会失败：当上下文中包含多个具有相似属性的实体，且模型需要跟踪哪个属性属于哪个实体时，非结构化文本产生幻觉（confabulation）的比例高于键值对格式。

实际的启发式方法是：当你需要模型自由地对散文内容进行推理时，使用纯文本；当上下文包含多个实体或需要明确归属的结构化记录时，切换到键值对格式（Markdown-KV、YAML 或极简 JSON）。

混合格式的问题

大多数真实的智能体（Agent）系统不会只选择一种格式，而是混合使用。系统提示词用 Markdown，从 API 响应中检索到的上下文用 JSON，工具结果用结构化文本，而对话历史用纯文本。这种混合正是格式诱发幻觉的风险所在。

当上下文中包含格式不一致的部分时，模型倾向于将一个部分的推理模式套用到另一个部分。将 JSON 格式的 API 结果与 Markdown 指令混合，可能会导致模型将 Markdown 视为待提取的数据，而不是要遵循的指令。在单个提示词中切换列表格式和编号格式会引入不一致性，在实践中，这会增加幻觉率。

解决这一问题的工程准则是确保每个逻辑层的格式一致性。系统指令采用一致的风格（Markdown 或纯文本，任选其一，但不要混用）。检索到的上下文采用一致的格式，并带有明确的小节标题，告诉模型接下来是什么内容。工具结果每次都以同样的方式处理，并在进入上下文窗口之前进行验证。

更广泛的原则是：混合格式的代价是模型的推理负载。每一次格式切换都是一个隐含信号，模型必须在继续之前进行解释。通过标准化每个上下文层来最小化这种负载，并且在无法避免混合时，始终提供明确的转换提示（例如：“以下是来自 API 的结构化数据：”、“以下是指令：”）。

实践中行之有效的决策框架

大多数团队应该从三个不同的层面考虑格式：上下文输入、思维链（CoT）工作区和结构化输出。

对于上下文输入（你传递给模型用于定向的信息），Markdown 是散文类上下文的最佳默认选择；对于结构化记录，使用 Markdown 键值对；当你需要类似 Schema 的结构且要求比 JSON 更高的 Token 效率时，使用 YAML。仅在数据来自机器且你只需进行极少转换即可透传的情况下，才保留 JSON 输入。

对于思维链工作区（如果你的系统使用了推理草稿板），纯文本或带有编号步骤的 Markdown 表现始终优于 JSON 封装的推理。模型在做出最终决定之前需要探索的自由度。

对于结构化输出（模型移交给下游系统的部分），带有明确 Schema 强制执行的 JSON 是正确选择。使用验证网关将 Schema 违规作为反馈返回，而不是任其静默失败。这是结构化真正发挥作用的地方：下游代码需要一份契约，而 Schema 就是这份契约。

有效的格式选择准则是：为每个层面明确做出选择，在投入生产环境之前针对特定模型和任务进行测试，并将格式视为可以衡量的超参数——而不是一种不影响结果的风格偏好。

在锁定格式之前评估选择

格式的影响是高度特定于任务和模型的。了解哪种格式最适合你的生产案例的唯一可靠方法是进行衡量。设置一个极简的评估（eval），针对目标模型运行各个候选格式的代表性提示词。衡量准确性、延迟、 Token 成本和输出合规性。在将格式投入生产之前运行这些测试。

这不是一次性的工作。模型更新会改变对格式的敏感度。从 GPT-4 到更新的推理模型（o3, o4）的过渡降低了某些任务对格式的敏感度，但并未消除。在每次模型升级时对格式性能进行基准测试，特别是当你观察到没有明显解释的质量退化时。

那些发现格式诱发退化的团队往往是偶然发现的——在模型升级后、在更换 API 提供商后，或者在添加了改变上下文构成的新数据源之后。而那些不会感到意外的团队，是将格式视为具有基准测试支持的可衡量系统属性的团队，而不是将其视为从第一个原型开发者那里继承下来的历史偶然。

格式不是中性的。请像对待其他工程决策一样对待它。