人类花了半个世纪把文档从打字机搬到 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。它不会被取代，只会被遗忘。而在技术的世界里，被所有人遗忘，恰恰是一种格式最终胜利的方式。
每一代人都在争论下一个界面是什么。但真正活下来的，从来不是界面，是协议。