Anthropic 的工程師 Thariq 最近發了一條推文 HTML is the new markdown，說他幾乎不再寫 markdown 檔案了，全部改用 Claude Code 直接生成 HTML。這條推文超過四百萬次觀看、一萬兩千個讚，還引來 Karpathy 的長篇回應。

小編覺得這個觀點蠻值得拆開來聊的，因為它背後的洞見不只是「換個格式」這麼簡單。

為什麼 HTML 比 Markdown 好看這麼多?

Markdown 的設計初衷是讓「原始檔」也能被人類閱讀 — 用 # 當標題、- 當列表、** 當粗體。這在純文字環境下確實堪用，但說到底它的視覺表達能力非常有限: 沒有版面配置、沒有色彩、沒有互動元素，所有東西都是線性排列的純文字。

HTML 就完全不同了。同樣的內容，用 HTML 呈現可以有卡片式佈局、資料圖表、摺疊面板、分頁切換、甚至簡單的互動功能 — 而且這些 AI 都能直接生成，不需要你寫任何 CSS 或 JavaScript。

Thariq 做了一個範例展示頁，列出了 20 種 HTML 輸出的實際用途。小編挑幾個特別有感的:

🔹 探索與規劃

🔹 Code Review 與程式碼理解

  • 帶註解的 PR diff — 在程式碼旁邊直接標註嚴重程度和評語
  • PR 說明文件 — 修改動機、前後對比、逐檔案說明，一頁搞定
  • 模組地圖 — 把不熟悉的程式碼結構畫成關聯圖，標出關鍵路徑

🔹 設計與原型

🔹 圖表、簡報、報告

  • 部署流程圖 — 可點擊的流程圖，每一步都能展開看細節和錯誤路徑
  • 方向鍵簡報 — 單一 HTML 檔就是一份完整簡報，不需要 PowerPoint
  • 週報儀表板 — 進度、延遲項目、圖表，週一早上打開就能用
  • 事件覆盤時間軸 — 逐分鐘時間軸、log 摘錄、後續追蹤清單

🔹 互動式編輯介面

全部都是單一 HTML 檔，不需要任何外部相依，瀏覽器打開就能用。小編點了幾個進去看，確實比同樣內容用 markdown 呈現的資訊密度和可讀性高很多。

Karpathy 的觀點: 人腦是視覺處理器

Karpathy 的回覆把這件事拉到更高的層次。他提出了 AI 輸出格式的進化路線:

  1. 純文字 — 費力閱讀
  2. Markdown — 粗體、斜體、標題、表格，稍微好讀一點 ← 目前的預設值
  3. HTML — 仍然是程式碼驅動，但在版面、圖形、互動性上靈活很多 ← 正在成形的新預設
  4. …
  5. 互動式神經影像/模擬 — 終極形態

他的核心論點是: 人類大腦有大約三分之一是專門做視覺處理的平行運算器，視覺是資訊進入大腦的「十線道高速公路」。既然如此，AI 的輸出格式當然應該往更視覺化的方向走。

小編覺得這個框架很有啟發性。我們現在用 LLM 產出的內容，大部分還停留在第二階段 — Markdown 渲染後的文字。但其實 LLM 完全有能力直接產出第三階段的 HTML，只是大多數人還沒有養成這個習慣而已。

關鍵區分: 這不是取代 Markdown

這裡有一個很重要的細微差別，dex 講得很精準:

Markdown 的價值其實有兩層:

  1. 給人類的清晰摘要 — 用結構化的方式呈現大量資訊，讓人更快理解
  2. 給模型的 token 效率格式 — 用最少的 token 傳遞最多的資訊或意圖

HTML 只解決了第一個問題。如果你的目標是給人看，HTML 當然更好; 但如果你的內容是要餵給下一個 AI 模型處理，HTML 的標籤會大幅膨脹 context window，反而是扣分的。

Viv 補充了一個很實際的例子: 她的「視覺文章 Skill」本身是用 markdown 寫的（因為是給 AI 讀的指令），但輸出是 HTML（因為是給人看的成品）。

所以正確的理解是:

  • Markdown 是 AI 讀寫的好格式 — 結構清楚、token 效率高、AI 原生就擅長處理
  • HTML 是給人類看的好格式 — 視覺豐富、版面靈活、互動性強

兩者不是取代關係，而是各有適用場景。關鍵是搞清楚你的輸出是給誰看的。

實測 20 個 Prompt: 哪些最值得學?

有人把 Thariq 的 20 個範例全部重新跑了一遍，用 Claude Code 分別產生 markdown 和 HTML 版本來比較。結果 HTML 在 17 個場景中勝出，只有 3 個輸給 markdown。代價是 token 用量中位數約 4.5 倍、生成時間約 4 倍。

但更有價值的是他的實測心得 — 哪些場景的 HTML 輸出真正改變了工作方式:

🔹 Code Review 是最大贏家。 同一個 612 行的 PR，markdown 版本他 90 秒掃完就跳過了; HTML 版本他讀了 11 分鐘，因為 margin 註解讓他直接看到「這裡把 backpressure 閾值從 8KB 改成 64KB」，而且在 HTML 版本中抓到了一個 off-by-one bug。一個 bug 就值回所有額外的 token 成本。

🔹 設計系統是「用了就回不去」的那種。 HTML 版本把色彩、字型、間距渲染成實際的色票和字型樣本，他兩天內開了 8 次。Markdown 版本? 一個表格，開了 0 次。

🔹 動畫原型最能體現「雙向互動」。 他請 Claude Code 設計一個「滑鼠懸停時卡片浮起」的微互動。Markdown 版本用文字描述 easing 曲線; HTML 版本直接跑動畫，附帶兩個滑桿可以即時調整時間和緩動參數，調好後把數值貼回 Claude Code 當下一輪 prompt。90 秒搞定。

🔹 分類看板是讓他「轉向」的那個範例。 把 32 個 GitHub issue 丟進去，產出一個可拖放的看板（Now / Next / Later / Cut），拖完按「copy as markdown」直接貼進規劃文件。Markdown 版本是一份清單，他說「眼睛在第 14 項就死了」。

🔹 週報的改變最容易量化。 同樣的內容改成 HTML（加上一個 shipped vs slipped 的小圖表），團隊的閱讀率從 4/12 人跳到 11/12 人。

而 Markdown 比較好的那三個場景也很有參考價值:

  1. Agent 之間傳遞的中間狀態 — 下一個 AI 不會渲染頁面，markdown 的 token 效率更高
  2. 需要 code review 的版控檔案 — 6,690 token 的 HTML 在 git diff 裡幾乎不可讀
  3. Terminal 串流輸出 — HTML 在終端機裡就是亂碼

一句話總結: HTML 用在 artifact（給人看的成品），markdown 用在 state（給 AI 處理的中間狀態）。

延伸: 社群的有趣應用

GitHub 上出現了 html-artifacts 這個開源專案，把「什麼時候該輸出 HTML」包裝成一個 Claude Code skill，讓 AI 自己判斷這次的輸出適合用 HTML 還是 markdown。

還有一個蠻有意思的概念: 有人把 AI 生成的 HTML 稱為「reWritable HTML」— 這份 HTML 文件本身就是一個可編輯的工作空間，你可以直接在上面繼續和 AI 互動、修改、迭代，不需要另外開編輯器。某種程度上，這回到了 Tim Berners-Lee 當初設計 Web 的初衷: 網頁本來就應該是可讀也可寫的。

實際應用: 用 HTML 追蹤 Codex 任務進度

OpenAI 的 Dominik Kundel（負責 Codex 和 DevX）分享了一個蠻聰明的應用: 在跑 Codex 的長時間任務時，在 steering 指令裡加一句「定期更新一個 goal.html 來顯示任務進度」。這樣你就有一個隨時可以用瀏覽器打開的視覺化進度儀表板，而不是去翻一堆 log 或 terminal 輸出。

Codex 內建瀏覽器顯示 goal.html 進度儀表板

這個思路可以延伸到很多場景: 讓 AI coding agent 在工作過程中維護一份 HTML 狀態報告、讓長時間跑的分析任務把中間結果即時渲染成圖表、或者用 HTML 做 debug 過程的視覺化紀錄。

怎麼開始?

其實很簡單，在你的 prompt 最後加一句「把回應用 HTML 格式輸出」就行了。或者更具體一點:

  • 要比較方案? 「用 HTML 做一個並排比較表，附帶優缺點標注」
  • 要做報告? 「輸出成 HTML 儀表板，包含圖表和摘要」
  • 要解釋概念? 「用 HTML 做一個互動式教學頁面」

存成 .html 檔，瀏覽器打開就能看。如果用 Claude Code 之類的工具，甚至可以直接在工作流程中產生這些檔案。

以上，重點不是「markdown 不好」，而是我們一直在用一種對 AI 友善但對人類次優的格式來消費 AI 的輸出。既然 AI 有能力直接產出更豐富的視覺呈現，何不善用它?