日前， Anthropic Claude Code 團隊成員 Thariq Shihipar在 X 發了個小作文《Using Claude Code: The Unreasonable Effectiveness of HTML》，瞬間被 900 萬 人圍觀。

當下，Markdown是AI Agent 與人溝通的主流格式，但Thariq 指出，AI能力變強后，Markdown已成束縛，應改用HTML作為AI輸出的格式。

他直言：“我漸漸覺得，Markdown 已經成了一種受限的格式”，超過百行的Markdown“可讀性極差、分享不便、缺少交互”，且如今多由AI編輯，其易用優勢已失效。

Thariq還列出了HTML 的四大不可替代優勢，如信息密度更高、視覺清晰易讀、分享便捷、支持雙向交互，可承載表格、SVG、交互控件、自定義編輯器等復雜內容，還能讀取全量代碼、Git、項目工具上下文。

他直言：“幾乎沒有任何 Claude 能夠讀取的信息，是你無法用 HTML 相當高效地呈現出來的”。

文中還給出了實操用法，可用于方案規劃、代碼評審、原型設計、自定義編輯界面等場景。

盡管HTML生成耗時是Markdown的2–4倍、版本對比困難，但他認為，“和 Claude 協作時，我能更好地掌握整體情況、實時把控進度”，值得切換。

Thariq說，他已經幾乎停止為所有內容編寫 Markdown 文件，轉而使用 Claude Code生成 HTML，“HTML 是新的 Markdown”。

對此，很多人表示認同。比如，有網友說，“HTML 很重要，因為人類是視覺動物”。

有網友說，“現在我明白為什么 Claude Design 使用 HTML 作為默認格式了”。

但也有不同看法。比如，有行業人士只“部分同意”，認為 HTML非常適合用于原型、模型、測試和預覽，但 Markdown 在文本導向的內容方面更勝一籌，如代碼、計劃，“當插圖多于文本時，就使用 HTML”。

以下為博文全文——

《Markdown轉HTML:AI 交互的更好載體》

Markdown 已成為智能代理與我們溝通時最主流的文件格式。它簡潔、可移植，具備一定富文本能力，也方便人工編輯。

令人驚喜的是，Claude 甚至十分擅長在 Markdown 文件中用 ASCII 字符繪制圖表。

但隨著智能代理的能力越來越強，我漸漸覺得 Markdown 成了一種束縛。超過百行的 Markdown 文件，我讀起來就十分吃力。

我想要更豐富的可視化效果、色彩與圖表，還希望能便捷地分享這些內容。

同時，我越來越少親自編輯這類文件，而是將它們用作技術規范、參考文檔、頭腦風暴產出物等。

即便需要修改，大多也是通過指令讓 Claude 代勞，這就讓 Markdown 最大的優勢之一失去了意義。

于是，我開始更傾向于用 HTML 替代 Markdown 作為輸出格式，而且我發現 Claude Code 團隊里越來越多人也在這么做，背后原因如下。

（想先看示例的話，可以訪問這里：https://thariqs.github.io/html-effectiveness，看完記得回來了解背后邏輯）

為什么選擇 HTML？

信息密度

相較于 Markdown，HTML 能承載豐富得多的信息。它當然可以實現標題、格式排版這類基礎文檔結構，還能呈現各類其他信息，例如：

? 用表格展示結構化數據

? 用 CSS 呈現設計樣式

? 用 SVG 繪制插圖

? 用 script 標簽插入代碼片段

? 結合 HTML 元素、JavaScript 與 CSS 實現交互效果

? 用 SVG 和 HTML 梳理工作流程

? 通過絕對定位與畫布呈現空間數據

? 用圖片標簽插入圖像

我甚至可以說，只要是 Claude 能讀取的信息，幾乎都能用 HTML 高效呈現。這讓模型能高效地向你傳遞深度信息，你也能便捷審閱。

我發現，受限于 Markdown 的表達能力，模型常會采用低效的呈現方式，比如 ASCII 字符繪圖，或是我見過最特別的——像 Claude Code 的截圖里那樣，用 Unicode 字符模擬色彩。

（Claude Code 嘗試在 Markdown 中展示色彩）

視覺清晰度與易讀性

隨著 Claude 能處理更復雜的工作，它產出的技術規范、方案規劃文檔也越來越長。實際使用中我發現，百行以上的 Markdown 文檔我基本不會完整閱讀，團隊里其他人更是如此。

但 HTML 文檔可讀性要好得多。Claude 可以通過標簽頁、插圖、超鏈接等方式，對文檔結構進行可視化排版，優化瀏覽體驗；還能適配移動端，在不同設備上調整展示效果。

便捷分享

Markdown 文件很難分享，大多數瀏覽器無法原生良好渲染，往往只能作為附件發送郵件或消息。

而 HTML 文件只需上傳（例如上傳至對象存儲 S3），就能直接分享鏈接。同事可在任意設備打開查閱，引用內容。

如果技術規范、報告或代碼合并申請文檔采用 HTML 格式，他人完整閱讀的概率會大幅提升。

雙向交互

HTML 支持文檔交互功能。比如你可以讓它添加滑塊、旋鈕，用來調整設計參數，或是修改算法的各項配置，實時查看效果；還能將調整后的配置一鍵復制成指令，直接粘貼回 Claude Code。

想查看這類雙向交互的示例，可以閱讀我的演示項目文章：https://x.com/trq212/status/2017024445244924492

數據讀取能力

為什么用 Claude Code 生成 HTML 文件，而非 ClaudeAI 或 Claude Design？

核心原因是， Claude Code 可讀取海量上下文信息。

舉個例子，撰寫本文時，我讓 Claude Code 遍歷我的代碼文件夾，找出所有我生成的 HTML 文件，進行分類整理，再制作一份包含各類示意圖的 HTML 文檔。

本文中的所有配圖，都是這樣生成的。

除本地文件系統外，Claude Code 還能通過 MCP 工具（如 Slack、Linear 項目管理工具）、Chrome 瀏覽器插件、Git 提交記錄等獲取更多上下文。

使用體驗更愉悅

用 Claude 制作 HTML 文檔本身就更有趣，能讓我深度參與創作、更有投入感，單憑這一點就足夠了。

如何上手

我有點擔心大家看完這篇文章后，會把它做成 /html 指令模板之類的功能。

雖說這類模板或許有用，但我想強調，讓 Claude 生成 HTML 并不復雜，你只需直接指令它“生成一個 HTML 文件”或“制作 HTML 成果物”即可。

關鍵是，明確你想要這個成果物實現什么功能、如何使用。

你可以后續慢慢打磨專屬指令模板，但現階段建議從零開始直接發指令，熟悉不同場景下的用法。

適用場景

為了更具象地說明，我針對不同場景制作了大量 HTML 文件，可在此查看：https://thariqs.github.io/html-effectiveness/，以下是場景概覽：

技術規范、方案規劃與思路探索

HTML 為 Claude 深度分析問題提供了廣闊空間。我處理問題時，不再只用簡單的 Markdown 方案，而是會搭建一系列 HTML 文檔。

比如，我會先讓 Claude Code 頭腦風暴，生成多種方案思路；接著讓它深化某一方向，制作原型或代碼片段；方案成熟后，再生成落地執行計劃。確認計劃無誤后，新建對話會話，導入所有 HTML 文檔，讓模型按方案開發。

驗證環節，我也會讓校驗代理讀取全部文檔，全面掌握需求細節。

示例指令

1. 我不確定引導頁該采用哪種設計方向，請生成6種風格迥異的方案，在布局、語氣、信息密度上做出區分，整合在一份網格布局的 HTML 文件中，方便我橫向對比，標注每種方案的優缺點。

2. 用 HTML 文件生成一份詳盡的落地執行方案，務必包含原型圖、數據流示意圖與我需要審閱的關鍵代碼片段，排版清晰易讀。

適用場景

? 探索代碼的多種實現方式

? 對比多款視覺設計方案

代碼審閱與理解

Markdown 格式下的代碼可讀性很差。但通過 HTML，我們可以展示代碼差異、添加批注、繪制流程圖、梳理模塊結構等。

可用來理解模型編寫的代碼、開展代碼評審，或是向他人講解代碼合并申請內容。

我發現這種方式比 GitHub 自帶的代碼差異視圖效果更好，現在我每次提交代碼合并申請，都會附上 HTML 格式的代碼解讀文檔。

示例指令

幫我審閱這份代碼合并申請，生成一份 HTML 解讀文檔。我不熟悉限流/背壓邏輯，請重點分析該部分；展示完整代碼差異，在側邊欄添加批注，按問題嚴重程度用顏色標注風險點，確保內容清晰易懂。

適用場景

? 提交代碼合并申請

? 審閱他人代碼合并申請

? 理解代碼中的技術邏輯

設計與原型制作

Claude Design 本身就基于 HTML 開發，因為 HTML 的設計表現力極強，即便最終產品并非網頁端也適用。Claude 可先用 HTML 繪制設計草圖，再轉換成你需要的開發語言，如 React、Swift 等。

你還能制作交互原型，例如動畫、點擊效果等?？梢宰?Claude 添加滑塊、旋鈕，精準調試各項效果參數。

示例指令

我需要制作一個新的結算按鈕原型，點擊后播放動畫并快速變為紫色。生成一份 HTML 文件，內置多個滑塊和參數選項，方便我調試動畫效果，添加復制按鈕，導出最優參數。

適用場景

? 制作設計系統文檔

? 調整組件樣式

? 可視化組件庫

? 制作趣味交互動畫原型

報告撰寫、調研與知識學習

Claude Code 擅長整合多源信息，生成可讀性極強的報告。你可以指令它讀取 Slack 聊天記錄、代碼庫、Git 記錄、網絡資料等，為自己、管理層、團隊生成各類深度報告。

報告形式可以是長篇 HTML 文檔、交互式解讀頁，甚至演示幻燈片，可要求 Claude 用 SVG 繪制示意圖輔助理解。

例如，我撰寫提示詞緩存相關文章時，讓 Claude 讀取 Git 記錄，整理出一份 HTML 深度調研文檔，梳理提示詞緩存的所有更新內容。

示例指令

我不理解我們的限流器工作原理，請讀取相關代碼，生成單頁 HTML 解讀文檔：包含令牌桶流程圖、3–4 段帶批注的核心代碼片段，底部添加常見踩坑點說明，排版適配快速閱讀。

適用場景

? 梳理功能實現邏輯

? 講解專業技術概念

? 給上級提交每周工作匯報

? 向管理層提交故障復盤報告

? 制作 SVG 示意圖、流程圖、技術架構圖等

自定義編輯界面

有些需求很難純用文字描述。這時我會讓 Claude 制作臨時專用編輯器，不是完整產品或通用工具，而是僅針對當前數據的單份 HTML 文件。

核心技巧是增加導出功能：設置“復制為 JSON”或“復制為指令”按鈕，將界面上的所有操作，轉換成可粘貼回 Claude Code 的格式。

示例指令

我需要重新調整30條 Linear 工單的優先級，生成一份 HTML 文件，將每個工單做成可拖拽卡片，分為「立即處理/后續處理/延后處理/剔除」四列；由模型初步排序，添加“導出為 Markdown”按鈕，導出最終排序結果，并為每類工單標注一句優先級理由。

這是我們的功能開關配置，請制作表單式編輯器：按業務模塊分組開關，展示開關間的依賴關系，若啟用前置條件未開啟的開關則給出警告；添加“復制變更內容”按鈕，僅導出修改后的配置項。

我正在調試系統提示詞，請制作左右分欄編輯器：左側為可編輯提示詞，高亮變量占位符；右側為3個示例輸入，實時渲染填充后的模板；添加字符/令牌計數與復制按鈕。

適用場景

? 工單、測試用例、反饋信息的排序、分級、歸類

? 編輯結構化配置（功能開關、環境變量、帶約束的 JSON/YAML）

? 實時調試提示詞、模板、文案

? 整理數據集，篩選、標注樣本并導出

? 批注文檔、文稿、代碼差異并導出批注內容

? 調試文字難以精準表達的參數：顏色、緩動曲線、裁剪區域、定時任務、正則表達式等

常見問題

我向很多人分享了改用 HTML 的經驗，收到了一些高頻問題，在此統一解答：

1. HTML 會不會更消耗 token？
雖然 Markdown 通常占用 token 更少，但 HTML 更強的表達能力，加上我完整閱讀文檔的概率大幅提升，整體產出效果反而更好。

Opus 4.7 支持百萬級上下文窗口，token 消耗的增加基本可以忽略。

2. 那你現在還會用 Markdown 嗎？
說實話，我幾乎所有場景都不再使用 Markdown，不過我算是 HTML 的重度使用者。

3. 如何查看 HTML 文件？
我一般直接在本地瀏覽器打開（可讓 Claude 幫你打開），需要分享鏈接的話，上傳至對象存儲 S3 即可。

4. 生成 HTML 會不會比 Markdown 更耗時？
確實會！HTML 的生成時長是 Markdown 的 2–4 倍，但我認為最終效果值得付出這份時間。

5. 版本控制怎么辦？
這確實是HTM最大的缺點：對比 Markdown，HTML 的代碼差異雜亂，很難審閱。

6. 如何讓 Claude 做出符合我審美/企業風格的 HTML，避免樣式粗糙？
前端設計插件可以輔助 Claude 優化 HTML 樣式。若要匹配企業風格，可讓 Claude 讀取代碼庫，生成一份專屬設計系統 HTML 文件，后續所有 HTML 文檔均以此為參考。

總而言之，我選擇 HTML 的核心原因，是能與 Claude 的協作更可控、信息同步更充分。

我曾擔心，因為不再深度閱讀 Claude 生成的方案，只能被動接受它的決策。

但改用 HTML 后，我反而能比以往更全面地把控項目進度與細節。希望你也能有同樣的體驗。