为什么 Markdown 让大语言模型更聪明，而不只是更省钱
为什么 Markdown 让大语言模型更聪明，而不只是更省钱
大多数人是通过节省成本才发现 Markdown 与 AI 结合的工作流的。他们发现把网页从原始 HTML 转换为 Markdown 能将 token 用量削减 80–90%，一算账，立刻就切换了。
这种说法准确，但不完整。token 减少只是副作用。Markdown 更适合大语言模型的真正原因在于结构：Markdown 是一种文档结构与语义含义合二为一的格式，而 HTML 不是。这一差异比字符数量更重要。
大语言模型如何"阅读"内容
在解释为什么 Markdown 更胜一筹之前，有必要先理解语言模型在处理文本时实际做了什么。
大语言模型并不像人类那样"阅读"。它们将输入转换为 token——每个 token 大约对应 3–4 个字符——然后通过多层注意力机制处理这些 token，学习它们之间的关系。模型没有视觉渲染器，无法因为某段文字在浏览器中显示得又大又粗就推断它是标题。它只能处理接收到的 token 序列。
这意味着输入文本的信号质量——结构在 token 本身中编码得有多清晰——直接决定了模型对内容的理解程度。
问题所在：HTML 将结构与含义分离
HTML 是为浏览器设计的，而非为语言模型。浏览器会将 <div class="article-headline"> 渲染为一个又大又粗的标题。而模型看到的是这样的内容：
<div class="article-headline">Why Markdown Makes LLMs Smarter</div>
tokenize 之后大致变成：
< div class = " article - headline " > Why Markdown Makes LL Ms Sm arter </ div >
结构信号——"这是主标题"——被埋在一个 class 名称字符串里。模型必须通过训练来学习 article-headline 意味着重要性。它通常能猜对，但这是在与格式对抗，而不是顺势而为。
再看看深层嵌套，这在真实网页中是标配：
<div class="container">
<div class="content-wrapper">
<article class="post">
<div class="post-body">
<h2 class="section-title">Key Findings</h2>
<p>The results showed...</p>
</div>
</article>
</div>
</div>
等模型读到 Key Findings 时，已经处理了四层结构噪音。真正有意义的 <h2> 标签是唯一有效信号，却还要与一个可能强化、也可能不强化它的 class 名称（section-title）相互竞争。
为什么 Markdown 将结构与语义统一
Markdown 通过让结构与含义完全一致来解决这个问题。"看起来怎样"和"意味着什么"之间不再有任何分离。
## Key Findings
The results showed...
## 前缀本身就是语义信号，它明确无误地表示"二级标题"。没有 class 名称，没有包裹 div，没有竞争信号。模型接收到的恰好是它所需要的信息，直接编码在 token 序列中。
这一规律适用于所有 Markdown 元素：
| 内容类型 | HTML 信号 | Markdown 信号 |
|---|---|---|
| 主标题 | <h1> 或 <div class="title"> 或 <span id="headline"> | # |
| 子标题 | <h2> 至 <h6>，或带样式的 div | ## 至 ###### |
| 强调文本 | <strong>、<b>、<span class="bold"> | **文本** |
| 代码 | <code>、<pre>、<div class="highlight"> | `代码` 或围栏式代码块 |
| 列表 | <ul>/<li>，或 <div class="list-item"> | - 条目 |
| 链接 | 带周边标记的 <a href="..."> | [文本](url) |
在 HTML 中，每种语义元素通常有 3–5 种编码方式，且不同网站的实际用法各异。而在 Markdown 中，只有一种写法。这种一致性不只是更整洁——正是它让模型处理 Markdown 更加可靠。
实际效果对比
以下是一篇真实技术文章的某个章节，经两种方式处理后，用相同的提示词发送给 Claude："总结三个主要结论。"
输入 A：原始 HTML 提取（4,200 个 token）
<div class="article-body">
<div class="content-section" data-section="conclusions">
<h3 class="section-heading" id="section-3">Conclusions</h3>
<div class="paragraph-wrapper">
<p class="body-text">First, the researchers found that response latency...</p>
</div>
...
</div>
</div>
结果：模型正确识别出 3 个结论中的 2 个。第三个与附近 <aside> 标签中的方法论说明混淆了，模型未能识别该内容属于非主要内容。
输入 B：转换后的 Markdown（890 个 token）
## Conclusions
First, the researchers found that response latency...
结果：3 个结论全部正确识别。<aside> 中的内容已被转换器正确排除为补充内容，从未传达给模型。
token 数量下降了 79%，准确率在本例中从 67% 提升至 100%。两项改变来自同一个根源：更清晰的结构编码。
token 数据（以及为什么它是结果而非原因）
既然成本很重要，以下是处理一篇 1,500 字技术文章的数据：
| 输入格式 | Token 数量 | 费用（Claude Sonnet） | 信噪比 | |---|---|---|---| | 原始 HTML | 16,820 | $0.050 | ~6% | | 纯文本（去除 HTML 标签） | 3,450 | $0.010 | ~35% | | 清洁 Markdown | 1,890 | $0.006 | ~92% |
成本差异是真实的——比原始 HTML 便宜 88%。但请注意，纯文本（仅去除 HTML 标签）同样大幅削减了 token 数量，信噪比却只有 35%。纯文本丢失了所有结构信息：没有标题，没有强调，没有列表层级。你付得少了，但模型可用的信息也少了。
Markdown 达到了最优点：以最少的 token 成本传递最多的结构信息。这才是它作为大语言模型输入的正确格式的原因，而不仅仅是因为它更便宜。
三个格式质量影响结果的场景
1. 文章摘要
总结长文时，模型需要判断哪些章节是主要内容，哪些是补充内容。Markdown 标题层级（#、##、###）让这一点一目了然。纯文本和结构混乱的 HTML 则迫使模型仅凭内容本身去推断，这增加了摘要中混入侧边栏提示、作者简介或相关文章推荐的概率。
2. 基于网页内容的问答
当你粘贴一个网页并提出具体问题时，模型必须先定位相关章节。在结构清晰的 Markdown 文档中，标题 token 充当了模型可以导航的目录。在原始 HTML 中，找到相关章节需要先解析大量包裹 div 和 class 属性，然后才能触达内容——这会压缩上下文窗口的利用效率，并增加模型关注错误区域的概率。
3. 代码提取
技术页面通常包含与说明文字混排的代码示例。Markdown 围栏式代码块（```）创建了明确无误的边界，模型清楚地知道代码从哪里开始、在哪里结束。而在 HTML 中，代码可能被包在 <pre>、<code>、<div class="highlight"> 或完全没有标准标签的自定义组件里——同一种语义内容却对应各不相同的 token 模式。
实践建议
如果你要将网页内容输入任何大语言模型——无论是用于研究、摘要、问答还是数据提取——你使用的格式与你撰写的提示词同等重要。清洁的 Markdown 不是锦上添花，而是大语言模型在隐性训练中理解得最好的输入格式，因为其训练语料库中有相当大的比例（GitHub、Wikipedia、文档站点、Stack Overflow）本身就是 Markdown 或类 Markdown 格式。
节省成本是额外收获，提升质量才是重点。
一键将任意网页转换为整洁、适合大语言模型处理的 Markdown。试用 Web2MD — Chrome 免费版。