Markdown 已死，HTML 當立？

人類花了半個世紀把文檔從打字機搬到 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 的標題和列表

或者

• 要省得多，此外，HTML 的

要等到

才閉合，語義跨度長，模型生成時需要「記住」更遠的狀態。對模型生成來說負擔更重，出錯概率更高。

所以無論是從大語言模型注意力機制的技術角度，還是 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。它不會被取代，只會被遺忘。而在技術的世界里，被所有人遺忘，恰恰是一種格式最終勝利的方式。

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