# Markdown 已死，HTML 当立？
- 作者：张子豪
- 发布时间：2026-05-12 14:15
- 分类：软件
- 原文：https://www.ifanr.com/1665516
人类花了半个世纪把文档从打字机搬到 Word，又花了二十年搬到云端。结果 AI 时代真正的通用格式，是一门 2004 年发明的纯文本语言—— Markdown。
最近 Claude Code 工程师 Thariq 又提出了新的观点，说自己已经不用Markdown，HTML 才是未来，引发了大量讨论。
▲ Claude Code 工程师 Thariq 分享的用 HTML 替代 Markdown 文章，当前该内容已在 X 上获得千万次浏览
文章里，他提出了 HTML 格式的输出，是比 Markdown 文本更好的形态。对 AI 来说，从输出 Markdown 到输出 HTML，转换的过程基本无痛，但对用户来说却是实打实的体验优化。
Karpathy 在今天凌晨也转发了这篇文章，分享了他对于 HTML 的看法。
在他看来，音频是大语言模型最好的输入，视觉是最好的输出。在他畅想的路线里，HTML 之后还有交互动画、神经网络直接生成的视频、最终某种人机之间真正的感知融合。
在 Vibe Coding 和 Agent 产品成为主流的背景下，HTML 和 Markdown 对大多数 AI 玩家可能并不陌生。
▲ 在 DeepSeek 内要求它做一个小游戏，会直接给我们一段能运行的 html 代码文件
想做一个小游戏，告诉 ChatGPT，「帮我做一个贪吃蛇的单页 HTML 网页」。ChatGPT 会将代码打包成成一个后缀名为 html 的文档，双击打开，我们就能在浏览器里看到一个可交互、有动效、图文丰富的成果。
甚至在浏览器里面，任何一个网页下，按下 CTRL+S，保存下来的本地文件，都有一个 .html 的文档。
而 Markdown 从 AI 要获取网页上下文的年代，就有大量的工具，直接将各种文件类型的文档转成 Markdown 格式。
微软自己作为办公三件套之王，有着 docx、pptx、xlsx 等职场常用的文件，早前也开源了一个将这些办公文档转成 Markdown 格式的项目，目前在 GitHub 上已经收获超过 12 万 Stars。
▲ 项目地址：https://github.com/microsoft/markitdown
OpenClaw 爆火之后，各种 AGENT.md、SOUL.md、CLAUDE.md、MEMORY.md……甚至是 Skills 工程里面，每个 Skill 也是一个 Skill.md 的文档。
从记忆的保存、到提示词和 Agent 的控制，Markdown 格式几乎成为了 AI 获取丰富上下文的不二选择。
▲ OpenClaw 智能体会通过多个不同的 Markdown 文件来搭建最终的工作区｜图片由 AI 生成
我们日常工作中最常使用的 PDF、DOC、以及 PPT 反而在 AI 时代成了「最不被待见」的格式。
但现在冒出来的 HTML 的又是怎么一回事，它会有机会取代 Markdown 成为 AI 时代的新通用语言吗？
## Markdown 为什么最适合 AI
先说说为什么 Markdown 成为了 AI 时代的 Word，无论是 AI 的回答，还是我们丢给 AI 的上下文，现在大多都是以 Markdown 为主。
这门语言诞生于 2004 年，灵感来自 2000 年代电子邮件的文本排版惯例——竖线分隔、80 字符换行、星号表示强调。它的目标是「写起来像纯文本，渲染出来像 HTML」。足够简单，足够便携，不需要任何工具，任何文本编辑器都能处理。
▲ Markdown 语法速查表｜图片由 AI 生成
这套设计哲学在博客时代是完美的。2008 年前后随着 Github 崛起，Markdown 直接成为程序员的标准写作格式。各类技术文档、Stack Overflow 回答、Github README、技术博客，Markdown 几乎在所有这些场景里都工作得很好。
然后大语言模型来了。
一边是刚好训练数据里有大量 Markdown 格式的文本，模型学会了用它表达结构。即训练数据上，**那些技术博客论坛里「聪明人写的东西」大量是 Markdown**。模型学到的不只是格式，还有「**用 Markdown 写作 = 认真、结构化、专业**」这个关联。
另一边是 Markdown 的结构信号非常局部化，一个标题只需要一个 #，一个列表只需要一个 -，\*\* 出现就是加粗。模型也不需要看很远的上下文就能判断当前 token 的语义角色。
▲ 同样一篇文章，HTML 意味着繁多的标签、各种区块的分隔，以及样式控制等
对比 HTML 的标题和列表<h1> </h1> 或者 <li> </li> 要省得多，此外，HTML 的 <div class=”section”> 要等到 </div> 才闭合，语义跨度长，模型生成时需要「记住」更远的状态。对模型生成来说负担更重，出错概率更高。
所以无论是从大语言模型注意力机制的技术角度，还是 Token 经济学的角度，「能用 Markdown 就不用 HTML」在长文档、多轮对话、大量 API 调用的场景里，成了工程师和模型双方的偏好。
**总结下来，Token 效率高、结构清晰、解析简单的核心价值，让模型天然爱 Markdown，它爱 Markdown 格式的输入，也爱 Markdown 格式的输出。**
这种偏好在大语言模型训练时，也变得更加明显。
模型通过人类反馈强化学习 RLHF 的时候，标注员给高分的回答大概率是：有清晰标题、有分点列举、结构一目了然的回答。而这种视觉结构，在纯文本环境里就是 Markdown。
于是模型学到的奖励信号也是：**用 Markdown 格式化 = 看起来更认真、更完整、更值得高分。**即使问题根本不需要列表，模型也会倾向于加列表。
▲ 知名的 Markdown 编辑器 Typora
这大概也是为什么我们随便问 ChatGPT 一个问题，它都想给三个要点、加粗关键词、再来个小结。以及大多数时候，在 AI 的对话界面，复制 AI 的回答，粘贴到其他输入框，都会发现自动多了 #、\*\*、—、等 Markdown 标识。
我们看到的每一条 AI 回复的文字消息，基本上都是以 Markdown 的格式在渲染。
## 为什么不是 PDF、Word、PPT
Markdown 好用，但是我们日常生活中使用的文档格式，大多还是 PDF 和 Word。老板发来一个文件，我丢给 AI 去处理，这个文件往往要比我直接复制粘贴，消耗更多的时间。
本质原因还是模型只认识 token，不认识文件。
大语言模型的输入，在进入模型之前必须先被转换成 token 序列。模型看不到「一个 PDF」，它看到的是 PDF 被解析出来的文本内容，然后再切成 token。所以哪种格式在解析成纯文本之后，损失的信息最少、引入的噪声最少，这种格式就是更好的格式。
▲ Claude 官方的 PDF Skill，需要调用专门的工具库才能实现 PDF 文件读取
PDF 设计的目标是「打印出来好看」，不是「机器好读」。在 PDF 内部存储的是每个字符的坐标位置，而不是文本的逻辑顺序。一个两列布局的 PDF，解析出来的文本顺序很可能是左列第一行、右列第一行、左列第二行、右列第二行，直接就完全乱掉。
表格更糟糕。PDF 里的表格通常是用绝对坐标定位的文本块，没有任何「这是一行」「这是一列」的语义信息。对 AI PDF 解析器来说，只能靠猜。
扫描版 PDF 就更不用说了，直接是图片，要先过 OCR 文本识别，而 OCR 的错误率直接进入模型上下文。
.docx 和 .pptx 本质上是 ZIP 压缩包，里面是一堆 XML（可扩展标记语言）文件。解析出来的原始内容里有大量样式标记，字体、颜色、段落间距、主题、修订记录，这些对模型理解内容毫无帮助，但会占用大量 token，稀释真正有用的信息。
对 PPT 来说，信息密度本来就低，一张幻灯片可能只有一句话、几个关键词，解析出来是碎片化的文本，没有上下文连接，模型很难重建完整的逻辑。
有人会说那 TXT 呢，其实 Markdown 和 Word 这类文本，本质上都可以转成 TXT 文档，它没有额外的噪声，但也没有任何结构信号。
模型很难定位到哪里是标题、哪里是列表、哪里是代码块、哪里是引用。对于长文档，还意味着模型要靠自然语言线索去猜结构，准确率不稳定。
▲ 图片由 AI 生成
类似的语言还有 JSON/XML，**它们确实对机器更友好，但「机器」指的不是语言模型。**
JSON 和 XML 是为程序解析设计的，键值对、层级结构、严格语法。传统软件读 JSON 很舒服，因为它可以直接 json.parse()，得到一个结构化对象。
而语言模型的「理解」是通过 token 之间的统计关联实现的。对语言模型来说，读 JSON 和读自然语言的方式是一样的，逐 token 处理，靠注意力机制建立关联。**把这种严格结构化的格式喂给一个为模糊输入设计的系统，本身是一种错配。**
Markdown 刚好在这两者之间，它是纯文本，但带有轻量结构信号。
 
▲ 部分工具像 Jina Reader，在网页 URL 前添加 r.jina.ai 前缀，就能将任何网页转换为 LLM 友好的 Markdown
解析 Markdown 不需要任何特殊工具，直接读文本就行，不会有 PDF 那种坐标混乱，不会有 Word 那种 XML 噪声。同时 # \*\* – 这些符号给了模型足够的结构线索，让它知道这段是标题、这段是列表、这段是代码。
这些符号本身就在 token 词表里，模型直接处理，不需要任何预处理步骤。
## Markdown 也要过时了？
在 Claude Code 工程的那篇文章里，细数了 HTML 的几大优点。
▲ 图片由 AI 生成
信息密度更高，HTML 能传达的信息远比 Markdown 丰富。它能做基础的文档结构、标题格式，但它还能表示各种其他信息，像是 CSS 样式、SVG 图片、canvas 空间数据、流程图、img 标签插入图片等等。
他还提到，Claude 能处理越来越复杂的工作，它写的需求文档和计划也越来越长。而超过 100 行的 Markdown 文件根本读不下去，更别说让其他人去读。
但 HTML 文档的阅读体验就更轻松。Claude 可以用标签页、插图、链接等方式把结构组织得清晰易导航。它甚至能做到响应式布局，在不同设备上都能舒服地阅读。
在分享这点上，他也认为 HTML 的传播要比 Markdown 容易。 把 HTML 文件随便放到某个云平台上，发这个链接给朋友和发一份 Markdown 文档，一定是点开链接阅读的几率更大。
就像现在做报告，展示几十页的 PPT，不然直接打开一个网页。市面上常见的深度研究产品，在生成 PPT 时，所采用的格式也是从渲染 HTML 网页开始。
还有 HTML 的交互性，我们可以点击不同的按钮、使用滑块或旋钮来调节不同的信息展示。
在提到 Markdown 输出的 Token 要比 HTML 少时，以及更耗时间时，他说 HTML 可能比 Markdown 慢 2-4 倍，但觉得值得；而 HTML 带来的表达力提升、以及真正去读它的概率大幅提高，最终产出反而更好。
我们也尝试把 Thariq 这篇长文转成 HTML 的格式，相较于 X 推文的长截图，HTML 呈现的内容会对读者更友好。
针对 HTML 更合适给人阅读这点，文章所列的优点听起来确实 Markdown 很难做到，但直接把 HTML 描绘成新的 AI 通用语言，还为时尚早。
难道我们未来的会话，每一次都要等 AI 输出一个所谓样式精美、交互友好的网页吗？
我想我们和朋友闲聊的时候，不会希望它盛装打扮，更不会想他要化妆一小时，要我们原地等待他。
更不用说，在大多数用户接触到的 AI，即那些不针对编程、设计等特定领域的 AI，全部都是以对话的形式在交互，我们的会话或许并不需要一份精美的 HTML，现有的 Markdown 就已经足够了。
**Claude Code 工程师这篇文章里也提到了 HTML 适用于哪些项目，例如要求 AI 生成一份详细的需求文档，包括规划项目和探索不同的设计方案、或是可视化代码审查和理解、制作交互原型，比如动画和动作效果、以及研究报告等使用场景。**
而这些场景本来就是适合网页呈现的场景，用它来挑战 Markdown 的地位稍微有点胜之不武。
作者在最后得出的论点是 HTML 作为 AI 交付给人类的最终产物更好读。但他并没有主张用 HTML 作为 AI 的工作记忆或上下文格式，因为 Markdown 在这一领域目前就是所有 AI 的唯一解决方案。
Markdown 还是 AI 时代的 Word，那 Markdown 最终会走向哪里？
Markdown 是 AI 的工作语言，是上下文的载体，是 agent 之间传递信息的格式，但它可能不需要是用户最终看到的东西。HTML 或者未来某种更好的格式，是 Markdown 被渲染之后的界面。
HTML 挑战不用挑战 Markdown 的地位，它只需要承担补上 Markdown 从来就不需要承担的那个角色。
Markdown 可以是 HTML 的一部分，我们在网页上和 AI 聊天，AI 给我们的回复使用 Markdown，它此时是被嵌入到了 HTML 里。
未来的 Markdown 就像一块积木一样，它会被嵌入到 HTML、甚至是某种更精美的 XTML 语言里。
▲ 图片由 AI 生成
格式会一直往前走。HTML 是此刻的前台，但也只是此刻的。下一站可能是可交互的 3D 空间，再下一站可能是直接写进视网膜的信号流。
但无论前台换成什么，后台跑的还是 Markdown。它不会被取代，只会被遗忘。而在技术的世界里，被所有人遗忘，恰恰是一种格式最终胜利的方式。
每一代人都在争论下一个界面是什么。但真正活下来的，从来不是界面，是协议。