人類花了半個(gè)世紀(jì)把文檔從打字機(jī)搬到 Word，又花了二十年搬到云端。結(jié)果 AI 時(shí)代真正的通用格式，是一門 2004 年發(fā)明的純文本語言—— Markdown。

最近 Claude Code 工程師 Thariq 又提出了新的觀點(diǎn)，說自己已經(jīng)不用Markdown，HTML 才是未來，引發(fā)了大量討論。

▲ Claude Code 工程師 Thariq 分享的用 HTML 替代 Markdown 文章，當(dāng)前該內(nèi)容已在 X 上獲得千萬次瀏覽

文章里，他提出了 HTML 格式的輸出，是比 Markdown 文本更好的形態(tài)。對 AI 來說，從輸出 Markdown 到輸出 HTML，轉(zhuǎn)換的過程基本無痛，但對用戶來說卻是實(shí)打?qū)嵉捏w驗(yàn)優(yōu)化。

Karpathy 在今天凌晨也轉(zhuǎn)發(fā)了這篇文章，分享了他對于 HTML 的看法。

在他看來，音頻是大語言模型最好的輸入，視覺是最好的輸出。在他暢想的路線里，HTML 之后還有交互動(dòng)畫、神經(jīng)網(wǎng)絡(luò)直接生成的視頻、最終某種人機(jī)之間真正的感知融合。

在 Vibe Coding 和 Agent 產(chǎn)品成為主流的背景下，HTML 和 Markdown 對大多數(shù) AI 玩家可能并不陌生。

▲ 在 DeepSeek 內(nèi)要求它做一個(gè)小游戲，會(huì)直接給我們一段能運(yùn)行的 html 代碼文件

想做一個(gè)小游戲，告訴 ChatGPT，「幫我做一個(gè)貪吃蛇的單頁 HTML 網(wǎng)頁」。ChatGPT 會(huì)將代碼打包成成一個(gè)后綴名為 html 的文檔，雙擊打開，我們就能在瀏覽器里看到一個(gè)可交互、有動(dòng)效、圖文豐富的成果。

甚至在瀏覽器里面，任何一個(gè)網(wǎng)頁下，按下 CTRL+S，保存下來的本地文件，都有一個(gè) .html 的文檔。

而 Markdown 從 AI 要獲取網(wǎng)頁上下文的年代，就有大量的工具，直接將各種文件類型的文檔轉(zhuǎn)成 Markdown 格式。

微軟自己作為辦公三件套之王，有著 docx、pptx、xlsx 等職場常用的文件，早前也開源了一個(gè)將這些辦公文檔轉(zhuǎn)成 Markdown 格式的項(xiàng)目，目前在 GitHub 上已經(jīng)收獲超過 12 萬 Stars。

▲ 項(xiàng)目地址：https://github.com/microsoft/markitdown

OpenClaw 爆火之后，各種 AGENT.md、SOUL.md、CLAUDE.md、MEMORY.md……甚至是 Skills 工程里面，每個(gè) Skill 也是一個(gè) Skill.md 的文檔。

從記憶的保存、到提示詞和 Agent 的控制，Markdown 格式幾乎成為了 AI 獲取豐富上下文的不二選擇。

▲ OpenClaw 智能體會(huì)通過多個(gè)不同的 Markdown 文件來搭建最終的工作區(qū)｜圖片由 AI 生成

我們?nèi)粘９ぷ髦凶畛Ｊ褂玫?PDF、DOC、以及 PPT 反而在 AI 時(shí)代成了「最不被待見」的格式。

但現(xiàn)在冒出來的 HTML 的又是怎么一回事，它會(huì)有機(jī)會(huì)取代 Markdown 成為 AI 時(shí)代的新通用語言嗎？

Markdown 為什么最適合 AI

先說說為什么 Markdown 成為了 AI 時(shí)代的 Word，無論是 AI 的回答，還是我們丟給 AI 的上下文，現(xiàn)在大多都是以 Markdown 為主。

這門語言誕生于 2004 年，靈感來自 2000 年代電子郵件的文本排版慣例——豎線分隔、80 字符換行、星號表示強(qiáng)調(diào)。它的目標(biāo)是「寫起來像純文本，渲染出來像 HTML」。足夠簡單，足夠便攜，不需要任何工具，任何文本編輯器都能處理。

▲ Markdown 語法速查表｜圖片由 AI 生成

這套設(shè)計(jì)哲學(xué)在博客時(shí)代是完美的。2008 年前后隨著 Github 崛起，Markdown 直接成為程序員的標(biāo)準(zhǔn)寫作格式。各類技術(shù)文檔、Stack Overflow 回答、Github README、技術(shù)博客，Markdown 幾乎在所有這些場景里都工作得很好。

然后大語言模型來了。

一邊是剛好訓(xùn)練數(shù)據(jù)里有大量 Markdown 格式的文本，模型學(xué)會(huì)了用它表達(dá)結(jié)構(gòu)。即訓(xùn)練數(shù)據(jù)上，那些技術(shù)博客論壇里「聰明人寫的東西」大量是 Markdown。模型學(xué)到的不只是格式，還有「用 Markdown 寫作 = 認(rèn)真、結(jié)構(gòu)化、專業(yè)」這個(gè)關(guān)聯(lián)。

另一邊是 Markdown 的結(jié)構(gòu)信號非常局部化，一個(gè)標(biāo)題只需要一個(gè) #，一個(gè)列表只需要一個(gè) -，** 出現(xiàn)就是加粗。模型也不需要看很遠(yuǎn)的上下文就能判斷當(dāng)前 token 的語義角色。

▲ 同樣一篇文章，HTML 意味著繁多的標(biāo)簽、各種區(qū)塊的分隔，以及樣式控制等

對比 HTML 的標(biāo)題和列表

或者

• 要省得多，此外，HTML 的

要等到

才閉合，語義跨度長，模型生成時(shí)需要「記住」更遠(yuǎn)的狀態(tài)。對模型生成來說負(fù)擔(dān)更重，出錯(cuò)概率更高。

所以無論是從大語言模型注意力機(jī)制的技術(shù)角度，還是 Token 經(jīng)濟(jì)學(xué)的角度，「能用 Markdown 就不用 HTML」在長文檔、多輪對話、大量 API 調(diào)用的場景里，成了工程師和模型雙方的偏好。

總結(jié)下來，Token 效率高、結(jié)構(gòu)清晰、解析簡單的核心價(jià)值，讓模型天然愛 Markdown，它愛 Markdown 格式的輸入，也愛 Markdown 格式的輸出。

這種偏好在大語言模型訓(xùn)練時(shí)，也變得更加明顯。

模型通過人類反饋強(qiáng)化學(xué)習(xí) RLHF 的時(shí)候，標(biāo)注員給高分的回答大概率是：有清晰標(biāo)題、有分點(diǎn)列舉、結(jié)構(gòu)一目了然的回答。而這種視覺結(jié)構(gòu)，在純文本環(huán)境里就是 Markdown。

于是模型學(xué)到的獎(jiǎng)勵(lì)信號也是：用 Markdown 格式化 = 看起來更認(rèn)真、更完整、更值得高分。即使問題根本不需要列表，模型也會(huì)傾向于加列表。

▲ 知名的 Markdown 編輯器 Typora

這大概也是為什么我們隨便問 ChatGPT 一個(gè)問題，它都想給三個(gè)要點(diǎn)、加粗關(guān)鍵詞、再來個(gè)小結(jié)。以及大多數(shù)時(shí)候，在 AI 的對話界面，復(fù)制 AI 的回答，粘貼到其他輸入框，都會(huì)發(fā)現(xiàn)自動(dòng)多了 #、**、---、等 Markdown 標(biāo)識。

我們看到的每一條 AI 回復(fù)的文字消息，基本上都是以 Markdown 的格式在渲染。

為什么不是 PDF、Word、PPT

Markdown 好用，但是我們?nèi)粘Ｉ钪惺褂玫奈臋n格式，大多還是 PDF 和 Word。老板發(fā)來一個(gè)文件，我丟給 AI 去處理，這個(gè)文件往往要比我直接復(fù)制粘貼，消耗更多的時(shí)間。

本質(zhì)原因還是模型只認(rèn)識 token，不認(rèn)識文件。

大語言模型的輸入，在進(jìn)入模型之前必須先被轉(zhuǎn)換成 token 序列。模型看不到「一個(gè) PDF」，它看到的是 PDF 被解析出來的文本內(nèi)容，然后再切成 token。所以哪種格式在解析成純文本之后，損失的信息最少、引入的噪聲最少，這種格式就是更好的格式。

▲ Claude 官方的 PDF Skill，需要調(diào)用專門的工具庫才能實(shí)現(xiàn) PDF 文件讀取

PDF 設(shè)計(jì)的目標(biāo)是「打印出來好看」，不是「機(jī)器好讀」。在 PDF 內(nèi)部存儲(chǔ)的是每個(gè)字符的坐標(biāo)位置，而不是文本的邏輯順序。一個(gè)兩列布局的 PDF，解析出來的文本順序很可能是左列第一行、右列第一行、左列第二行、右列第二行，直接就完全亂掉。

表格更糟糕。PDF 里的表格通常是用絕對坐標(biāo)定位的文本塊，沒有任何「這是一行」「這是一列」的語義信息。對 AI PDF 解析器來說，只能靠猜。

掃描版 PDF 就更不用說了，直接是圖片，要先過 OCR 文本識別，而 OCR 的錯(cuò)誤率直接進(jìn)入模型上下文。

.docx 和 .pptx 本質(zhì)上是 ZIP 壓縮包，里面是一堆 XML（可擴(kuò)展標(biāo)記語言）文件。解析出來的原始內(nèi)容里有大量樣式標(biāo)記，字體、顏色、段落間距、主題、修訂記錄，這些對模型理解內(nèi)容毫無幫助，但會(huì)占用大量 token，稀釋真正有用的信息。

對 PPT 來說，信息密度本來就低，一張幻燈片可能只有一句話、幾個(gè)關(guān)鍵詞，解析出來是碎片化的文本，沒有上下文連接，模型很難重建完整的邏輯。

有人會(huì)說那 TXT 呢，其實(shí) Markdown 和 Word 這類文本，本質(zhì)上都可以轉(zhuǎn)成 TXT 文檔，它沒有額外的噪聲，但也沒有任何結(jié)構(gòu)信號。

模型很難定位到哪里是標(biāo)題、哪里是列表、哪里是代碼塊、哪里是引用。對于長文檔，還意味著模型要靠自然語言線索去猜結(jié)構(gòu)，準(zhǔn)確率不穩(wěn)定。

▲ 圖片由 AI 生成

類似的語言還有 JSON/XML，它們確實(shí)對機(jī)器更友好，但「機(jī)器」指的不是語言模型。

JSON 和 XML 是為程序解析設(shè)計(jì)的，鍵值對、層級結(jié)構(gòu)、嚴(yán)格語法。傳統(tǒng)軟件讀 JSON 很舒服，因?yàn)樗梢灾苯?json.parse()，得到一個(gè)結(jié)構(gòu)化對象。

而語言模型的「理解」是通過 token 之間的統(tǒng)計(jì)關(guān)聯(lián)實(shí)現(xiàn)的。對語言模型來說，讀 JSON 和讀自然語言的方式是一樣的，逐 token 處理，靠注意力機(jī)制建立關(guān)聯(lián)。把這種嚴(yán)格結(jié)構(gòu)化的格式喂給一個(gè)為模糊輸入設(shè)計(jì)的系統(tǒng)，本身是一種錯(cuò)配。

Markdown 剛好在這兩者之間，它是純文本，但帶有輕量結(jié)構(gòu)信號。

▲ 部分工具像 Jina Reader，在網(wǎng)頁 URL 前添加 r.jina.ai 前綴，就能將任何網(wǎng)頁轉(zhuǎn)換為 LLM 友好的 Markdown

解析 Markdown 不需要任何特殊工具，直接讀文本就行，不會(huì)有 PDF 那種坐標(biāo)混亂，不會(huì)有 Word 那種 XML 噪聲。同時(shí) # ** - 這些符號給了模型足夠的結(jié)構(gòu)線索，讓它知道這段是標(biāo)題、這段是列表、這段是代碼。

這些符號本身就在 token 詞表里，模型直接處理，不需要任何預(yù)處理步驟。

Markdown 也要過時(shí)了？

在 Claude Code 工程的那篇文章里，細(xì)數(shù)了 HTML 的幾大優(yōu)點(diǎn)。

▲ 圖片由 AI 生成

信息密度更高，HTML 能傳達(dá)的信息遠(yuǎn)比 Markdown 豐富。它能做基礎(chǔ)的文檔結(jié)構(gòu)、標(biāo)題格式，但它還能表示各種其他信息，像是 CSS 樣式、SVG 圖片、canvas 空間數(shù)據(jù)、流程圖、img 標(biāo)簽插入圖片等等。

他還提到，Claude 能處理越來越復(fù)雜的工作，它寫的需求文檔和計(jì)劃也越來越長。而超過 100 行的 Markdown 文件根本讀不下去，更別說讓其他人去讀。

但 HTML 文檔的閱讀體驗(yàn)就更輕松。Claude 可以用標(biāo)簽頁、插圖、鏈接等方式把結(jié)構(gòu)組織得清晰易導(dǎo)航。它甚至能做到響應(yīng)式布局，在不同設(shè)備上都能舒服地閱讀。

在分享這點(diǎn)上，他也認(rèn)為 HTML 的傳播要比 Markdown 容易。 把 HTML 文件隨便放到某個(gè)云平臺(tái)上，發(fā)這個(gè)鏈接給朋友和發(fā)一份 Markdown 文檔，一定是點(diǎn)開鏈接閱讀的幾率更大。

就像現(xiàn)在做報(bào)告，展示幾十頁的 PPT，不然直接打開一個(gè)網(wǎng)頁。市面上常見的深度研究產(chǎn)品，在生成 PPT 時(shí)，所采用的格式也是從渲染 HTML 網(wǎng)頁開始。

還有 HTML 的交互性，我們可以點(diǎn)擊不同的按鈕、使用滑塊或旋鈕來調(diào)節(jié)不同的信息展示。

在提到 Markdown 輸出的 Token 要比 HTML 少時(shí)，以及更耗時(shí)間時(shí)，他說 HTML 可能比 Markdown 慢 2-4 倍，但覺得值得；而 HTML 帶來的表達(dá)力提升、以及真正去讀它的概率大幅提高，最終產(chǎn)出反而更好。

我們也嘗試把 Thariq 這篇長文轉(zhuǎn)成 HTML 的格式，相較于 X 推文的長截圖，HTML 呈現(xiàn)的內(nèi)容會(huì)對讀者更友好。

針對 HTML 更合適給人閱讀這點(diǎn)，文章所列的優(yōu)點(diǎn)聽起來確實(shí) Markdown 很難做到，但直接把 HTML 描繪成新的 AI 通用語言，還為時(shí)尚早。

難道我們未來的會(huì)話，每一次都要等 AI 輸出一個(gè)所謂樣式精美、交互友好的網(wǎng)頁嗎？

我想我們和朋友閑聊的時(shí)候，不會(huì)希望它盛裝打扮，更不會(huì)想他要化妝一小時(shí)，要我們原地等待他。

更不用說，在大多數(shù)用戶接觸到的 AI，即那些不針對編程、設(shè)計(jì)等特定領(lǐng)域的 AI，全部都是以對話的形式在交互，我們的會(huì)話或許并不需要一份精美的 HTML，現(xiàn)有的 Markdown 就已經(jīng)足夠了。

Claude Code 工程師這篇文章里也提到了 HTML 適用于哪些項(xiàng)目，例如要求 AI 生成一份詳細(xì)的需求文檔，包括規(guī)劃項(xiàng)目和探索不同的設(shè)計(jì)方案、或是可視化代碼審查和理解、制作交互原型，比如動(dòng)畫和動(dòng)作效果、以及研究報(bào)告等使用場景。

而這些場景本來就是適合網(wǎng)頁呈現(xiàn)的場景，用它來挑戰(zhàn) Markdown 的地位稍微有點(diǎn)勝之不武。

作者在最后得出的論點(diǎn)是 HTML 作為 AI 交付給人類的最終產(chǎn)物更好讀。但他并沒有主張用 HTML 作為 AI 的工作記憶或上下文格式，因?yàn)?Markdown 在這一領(lǐng)域目前就是所有 AI 的唯一解決方案。

Markdown 還是 AI 時(shí)代的 Word，那 Markdown 最終會(huì)走向哪里？

Markdown 是 AI 的工作語言，是上下文的載體，是 agent 之間傳遞信息的格式，但它可能不需要是用戶最終看到的東西。HTML 或者未來某種更好的格式，是 Markdown 被渲染之后的界面。

HTML 挑戰(zhàn)不用挑戰(zhàn) Markdown 的地位，它只需要承擔(dān)補(bǔ)上 Markdown 從來就不需要承擔(dān)的那個(gè)角色。

Markdown 可以是 HTML 的一部分，我們在網(wǎng)頁上和 AI 聊天，AI 給我們的回復(fù)使用 Markdown，它此時(shí)是被嵌入到了 HTML 里。

未來的 Markdown 就像一塊積木一樣，它會(huì)被嵌入到 HTML、甚至是某種更精美的 XTML 語言里。

▲ 圖片由 AI 生成

格式會(huì)一直往前走。HTML 是此刻的前臺(tái)，但也只是此刻的。下一站可能是可交互的 3D 空間，再下一站可能是直接寫進(jìn)視網(wǎng)膜的信號流。

但無論前臺(tái)換成什么，后臺(tái)跑的還是 Markdown。它不會(huì)被取代，只會(huì)被遺忘。而在技術(shù)的世界里，被所有人遺忘，恰恰是一種格式最終勝利的方式。

每一代人都在爭論下一個(gè)界面是什么。但真正活下來的，從來不是界面，是協(xié)議。