Markdown 涼了？Claude Code 工程師親口說：我已經全面切換到 HTML 了
整理版優先睇
Claude Code工程師Thariq主張用HTML取代Markdown作為AI輸出格式，因為HTML信息密度更高、互動性更強，更適合AI時代嘅閲讀與協作需求。
呢篇文章係關於Anthropic旗下Claude Code嘅團隊成員Thariq提出嘅一個觀點：HTML先係AI時代更好嘅輸出格式，Markdown應該退場。佢喺X上發文之後獲得667萬次瀏覽同1萬個讚，引起廣泛討論。作者整理咗Thariq嘅完整論證，解釋點解佢會全面轉用HTML嚟寫需求文檔、技術方案同代碼審查報告，並且加入自己嘅分析同建議。
Thariq指出，Markdown一直係AI嘅默認輸出格式，因為簡潔、便攜、易讀同易於人工編輯。但隨住Agent越來越能幹，Markdown本身變成瓶頸。佢提到三個原因：超過100行嘅Markdown文件好難讀完；編輯習慣改變咗，因為佢而家主要係讓Claude代勞，自己只看結果；信息表達能力有天花板，例如冇辦法加顏色對比、做交互式設計或者畫真正嘅流程圖。
Thariq認為HTML嘅核心優勢係信息密度，可以表達table、CSS、SVG、code syntax highlighting、交互元素等等，幾乎所有Claude能讀懂嘅信息都能用HTML高效表達。除此之外，HTML仲有可讀性（可以做成好讀嘅格式）、容易分享（直接瀏覽器打開）、雙向交互（加滑塊、按鈕）同埋上下文整合（整合文件系統、MCP工具、Git歷史）等優勢。作者嘅結論係：喺AI時代，人類方便直接編輯已經唔再係文件格式最重要嘅特性，HTML更適合複雜輸出，但全面放棄Markdown唔現實，建議從代碼審查場景開始試用HTM…
- Thariq認為HTML信息密度遠高於Markdown，能承載表格、圖表、交互元素等多種資訊，係AI輸出更好嘅格式。
- Markdown嘅三個瓶頸：超過100行難讀、人類直接編輯嘅優勢不再、信息表達有天花板。
- HTML嘅優勢包括可讀性（可做tab導航、插圖）、分享便利（直接瀏覽器打開）、雙向交互（滑塊、按鈕）、上下文整合（整合多個數據源）。
- 實際應用場景：技術方案文檔、代碼審查報告、設計原型、臨時編輯界面、技術學習文檔，都可以用HTML生成更高質量嘅輸出。
- 建議從代碼審查呢個場景開始試用HTML，因為PR說明好唔好讀直接影響有冇人認真睇。
Thariq嘅HTML示例文件
包含各種用途嘅HTML格式文檔，可以直接體驗HTML輸出嘅效果。
代碼審查HTML輸出提示詞
用嚟讓Claude Code生成HTML格式嘅代碼審查報告，包含真實diff、顏色區分問題嚴重程度等。
背景：Markdown唔夠用？
Anthropic內部有個觀點正在流傳：HTML先係AI時代更好嘅輸出格式，Markdown應該退場。講呢句嘢嘅係Claude Code團隊成員Thariq，佢話自己幾乎所有嘢都唔再用Markdown，需求文檔、技術方案、代碼審查報告，全部改用Claude Code生成HTML。
呢篇文章喺X上獲得667萬次瀏覽同1萬個讚
初聽落有啲怪，HTML同Markdown唔係同一賽道嘅嘢咩？但睇完佢嘅完整論證，覺得相當有說服力，甚至改變咗對「AI應該輸出乜嘢格式」嘅諗法。
- Markdown最大優勢：簡潔、便攜、易讀、易於人工編輯。
- Claude仲用ASCII字符畫圖表，算係盡力。
- Thariq指出：隨住Agent越嚟越能幹，Markdown本身變成瓶頸。
點解係HTML？信息密度同互動能力
Thariq嘅答案係：信息密度。作為前端開發者，你最清楚HTML可以承載幾多嘢。
- 用 <table> 做真正嘅表格，有實際嘅行列結構
- 用CSS傳遞設計信息：顏色、字體、間距
- 用內聯SVG畫圖表同示意圖
- 用 <code> 配語法高亮展示代碼片段
- 用HTML + JavaScript + CSS 做交互元素，例如滑塊、開關、下拉選擇
- 用絕對定位同Canvas表達空間關係
- 用 <img> 嵌入圖片
Claude能讀懂嘅幾乎所有信息，都能用HTML高效表達，Markdown只係其中一個極小子集。
除咗信息密度，仲有幾個優勢：可讀性（HTML可以做成tab導航、可點擊連結、插圖，甚至響應式佈局）、分享（HTML直接丟S3發連結，瀏覽器打開）、雙向交互（滑塊調整參數、按鈕導出配置，再塞返Claude Code）、上下文整合（整合文件系統、MCP工具、Git歷史等）。
實際應用場景：前端/Node.js開發者會心一笑
Thariq分享咗幾個具體用法，對於前端/Node.js開發者應該好有感觸：
- 1 技術方案同需求文檔：讓Claude Code生成HTML，包含方案對比、代碼片段、示意圖、組件mockup，仲可以作為context傳畀新session實現。
- 2 代碼審查：HTML可以渲染真實diff、加行內註釋、畫模塊關係圖。佢每次提PR都會附上HTML格式代碼說明，比GitHub默認diff更好讀。
- 3 設計原型：用HTML畫組件原型，加交互滑塊調動畫參數，最後加複製按鈕帶走參數。
- 4 臨時編輯界面：當文字好難描述需求時，讓Claude做一個專用HTML編輯器，用完即棄，導出結果。
- 5 技術學習文檔：Claude Code讀Git歷史，綜合多個數據源生成HTML報告，例如研究prompt caching嘅文章。
示例提示詞：「幫我審呢個PR，生成一個HTML artifact。我不熟悉streaming/backpressure嘅邏輯，重點講嗰部分。」
呢啲用法共通點係：HTML唔單止係文檔，仲可以變成互動工具，提升工作效率。
常見問題同總結
評論區問得比較多嘅問題，Thariq都整理咗：
- HTML消耗更多token？係，但更高表達力帶嚟嘅收益大過成本，Opus 4.7有100萬上下文，多出嘅token感受唔到。
- 生成速度慢？係，大約係Markdown嘅2-4倍，佢認為結果值得等。
- 版本控制點算？最大缺點：HTML嘅diff好難睇，遠不如Markdown乾淨，暫時冇好解法。
- 點查看HTML文件？直接用瀏覽器打開本地文件，或者上傳S3攞分享連結。
比較合理嘅做法：複雜、需要畀人睇嘅輸出用HTML；簡單內部草稿、快速記錄用Markdown。版本控制場景下Markdown依然更友好。如果你用緊Claude Code開發，可以從代碼審查呢個場景開始試下HTML輸出，因為PR說明好唔好讀直接決定有冇人認真睇。
佢整理嘅示例文件放喺 https://thariqs.github.io/html-effectiveness ，可以直觀感受效果。
Anthropic 內部有個講法流緊：HTML 先至係 AI 時代更好嘅輸出格式，Markdown 要退場喇。
講呢句嘢嘅係 Claude Code 團隊成員 Thariq。佢話佢幾乎所有嘢都唔再用 Markdown 喇，需求文件、技術方案、代碼審查報告，全部改用 Claude Code 生成 HTML。呢篇文章喺 X 出咗之後，667 萬次瀏覽，1 萬個讚好。
初初聽落有啲怪，HTML 同 Markdown 根本唔係同一個跑道嘅嘢？但係睇曬佢完整論證之後，我覺得相當有說服力，甚至改變咗我對「AI 應該輸出咩格式」呢件事嘅睇法。
Markdown 邊度唔夠用？
Markdown 一直係 AI 嘅默認輸出格式，理由好充分：簡潔、便攜、易讀、容易手動編輯。Claude 甚至學識用 ASCII 字符喺 Markdown 度畫各種圖，表格、流程圖，算係盡咗力。
但 Thariq 指出一個越來越明顯嘅趨勢：隨住 Agent 越來越能幹，Markdown 本身變咗瓶頸。
佢提到幾個令佢逐漸放棄 Markdown 嘅原因：
第一係可讀性。超過 100 行嘅 Markdown 文件，佢基本上唔會認真讀完。當 Claude Code 生成一個幾百行嘅需求文件或實現計劃時，佢掃一眼開頭就跳到結尾。更唔好講俾團隊其他成員睇，基本上冇戲。
第二係編輯習慣變咗。Markdown 嘅最大優勢之一係「人類容易直接編輯」，但佢而家對呢啲文件嘅操作，基本都係叫 Claude 做，自己只睇結果。呢個優勢就冇咗。
第三係信息表達能力有限。想加顏色對比？ASCII 勉強。想做個交互式設計方案？做唔到。想要真正嘅流程圖而唔係一堆短橫線？一係插圖片，一係就咁將就。
呢三點加埋一齊，令佢開始重新諗：AI 時代，文件格式最重要嘅嘢係咩？
點解係 HTML？
佢嘅答案係：信息密度。
作為前端開發者，你比任何人都清楚 HTML 可以承載幾多嘢。Thariq 列咗一張清單，HTML 可以表達嘅信息類型包括：
用 <table>做到真正嘅表格，有實際嘅行列結構用 CSS 傳遞設計信息：顏色、字體、間距 用內聯 SVG 畫圖表同示意圖 用 <code>配語法高亮展示代碼片段用 HTML + JavaScript + CSS 做交互元素，例如滑塊、開關、下拉選擇 用絕對定位同 Canvas 表達空間關係 用 <img>嵌入圖片
佢嘅結論係：Claude 讀得明嘅幾乎所有信息，都可以用 HTML 高效表達。Markdown 只係其中一個極細嘅子集。
除咗信息密度，佢仲提到另外幾個優勢：
可讀性。 HTML 文件可以做成真正好讀嘅格式，tab 導航、可點擊嘅連結、插圖，甚至響應式佈局。一個 HTML 報告同一個 100 行嘅 Markdown 文件，被人認真讀完嘅概率差距好大。
分享。 Markdown 文件分享好麻煩，大多數瀏覽器唔可以直接渲染。HTML 掉去 S3 發一個連結，對方用瀏覽器直接打開。呢個細節直接影響你嘅 spec 文件或 PR 說明有冇人睇。
雙向交互。 呢個係 Markdown 完全做唔到嘅。HTML 入面可以加滑塊調整參數、加按鈕導出配置，最後加一個「複製為提示詞」按鈕，將操作結果塞返去 Claude Code 繼續工作。文件變咗工具。
上下文整合。 用 Claude Code 生成 HTML 報告，可以將文件系統、MCP 工具（Slack、Linear 等）、Git 歷史、瀏覽器入面嘅內容全部整合入去。呢個係直接用 Claude.ai 對話做唔到嘅。
幾個實際用法
理論睇完咗，講幾個具體場景，對於前端/Node.js 開發者嚟講應該好有感觸。
技術方案同需求文件
唔再寫 Markdown 嘅實現計劃，而係叫 Claude Code 生成 HTML 文件，入面有方案對比、代碼片段、示意圖，甚至組件 mockup。然後將呢啲 HTML 文件作為上下文，傳俾新 session 嚟實現。
示例提示詞：
“我唔確定 onboarding 頁面應該向邊個方向行，幫我生成 6 種完全唔同嘅設計思路，佈局、風格、信息密度都要有差異，用一個 HTML 文件並排展示，每種方案標註佢喺做嘅取捨。
代碼審查
HTML 可以渲染真實嘅 diff，加行內註釋，畫模塊關係圖。佢而家每次提 PR 都會附上一個 HTML 格式嘅代碼說明，佢話呢個通常比 GitHub 默認嘅 diff 視圖好讀，亦都更有可能被認真審查。
示例提示詞：
“幫我審呢個 PR，生成一個 HTML artifact。我唔熟悉 streaming/backpressure 嘅邏輯，重點講嗰部分。渲染真實嘅 diff，用顏色區分問題嚴重程度。
設計原型
Claude Design 本身就係基於 HTML。你可以叫 Claude 用 HTML 畫出組件原型，再轉成 React 代碼。亦都可以加交互滑塊，調動畫曲線、顏色參數，最後加複製按鈕，將滿意嘅參數直接帶走。
示例提示詞：
“我想做一個結賬按鈕，點擊後播一段動畫然後變紫色，用 HTML 做幾個滑塊俾我調動畫參數，加複製按鈕將調好嘅參數輸出嚟。
臨時編輯界面
呢個用法我覺得最有意思。有時你好難用文字描述你要啲咩，可以叫 Claude 臨時做一個專用嘅 HTML 編輯器，目的只係用一次，最後加一個「導出 JSON」或「複製為提示詞」嘅按鈕將操作結果轉返做文字。
示例提示詞：
“我需要對 30 個工單重新排優先級，做一個 HTML 文件，將每張工單做成可拖拽嘅卡片，分 Now / Next / Later / Cut 四列，按你嘅判斷預先排好，加一個「複製為 Markdown」按鈕導出最終結果。
技術學習文件
呢個 Thariq 都提到，Claude Code 可以讀 Git 歷史，綜合多個數據源生成 HTML 報告。佢舉咗一個例子，為咗寫一篇關於 prompt caching 嘅文章，佢叫 Claude Code 讀完 Git 歷史，生成一份詳細嘅 HTML 研究文件俾自己閲讀。
示例提示詞：
“我唔係好理解我哋嘅限流器係點樣運作，讀相關代碼後生成一個 HTML 說明頁：token-bucket 流程圖、3-4 個關鍵代碼片段加註釋、底部加一個「坑」彙總。面向睇一次就明嘅人嚟寫。
幾個常見問題
呢篇文章評論區問得比較多嘅問題，佢都整理咗：
HTML 唔係消耗更多 token 咩？
係多啲，但佢認為更高嘅表達力帶嚟嘅收益大過多出嘅 token 成本。Opus 4.7 有 100 萬上下文窗口，多出嗰啲 token 喺實際使用中感受唔到。
生成速度慢唔慢？
確實慢，大概係 Markdown 嘅 2-4 倍時間。佢認為結果值得等，呢個就見仁見智喇。
版本控制點算？
佢坦承呢個係最大嘅缺點：HTML 嘅 diff 好難睇，亦都好難審查，遠不如 Markdown 嘅 diff 乾淨。呢個問題目前佢冇好嘅解法。
點樣睇 HTML 文件？
直接用瀏覽器打開本地文件就得，或者上載去 S3 獲取分享連結。Claude Code 都可以幫你直接打開。
真係要全面轉向 HTML 咩？
Thariq 自己話佢可能行到咗「HTML 極端主義者」呢一側，普通用戶唔需要做到咁徹底。
我嘅睇法係，佢嘅核心論點站得住：喺 AI 時代，「人類方便直接編輯」已經唔再係文件格式最重要嘅特性喇。我哋越嚟越多將呢啲文件當作 AI 讀寫嘅中間產物，而唔係自己親手維護嘅文件。喺呢個前提下，HTML 可以承載嘅信息確實比 Markdown 豐富得多。
但全面放棄 Markdown 對大多數人嚟講既不現實亦冇必要。比較合理嘅做法係：複雜嘅、需要俾人睇嘅輸出用 HTML；簡單嘅內部草稿、快速記錄用 Markdown。版本控制場景下 Markdown 依然更友好，呢個短期內唔會變。
如果你用緊 Claude Code 開發，可以由代碼審查呢個場景開始試下 HTML 輸出，因為 PR 說明呢啲嘢，好唔好讀直接決定有冇人認真睇。
佢整理咗一批示例文件放喺呢度： https://thariqs.github.io/html-effectiveness ，涵蓋各種用途嘅 HTML 格式文件，可以直觀感受一下效果，比睇文字描述更有說服力。
Anthropic 內部有一個觀點正在流傳：HTML 才是 AI 時代更好的輸出格式，Markdown 該退場了。
說這話的是 Claude Code 團隊成員 Thariq。他說他幾乎所有東西都不再用 Markdown 了，需求文檔、技術方案、代碼審查報告，全部改用 Claude Code 生成 HTML。這篇文章在 X 上發出來之後，667 萬次瀏覽，1 萬個點贊。
初聽起來有點怪，HTML 和 Markdown 不是壓根不是一個賽道的東西嗎？但把他的完整論證看下來，我覺得相當有說服力，甚至改變了我對"AI 該輸出什麼格式"這件事的看法。
Markdown 哪裏不夠用了？
Markdown 一直是 AI 的默認輸出格式，理由很充分：簡潔、便攜、易讀、易於人工編輯。Claude 甚至學會了用 ASCII 字符在 Markdown 裏畫各種圖，表格、流程圖，算是盡力了。
但 Thariq 指出了一個越來越明顯的趨勢：隨着 Agent 越來越能幹，Markdown 本身變成了瓶頸。
他提到了幾個讓他逐漸放棄 Markdown 的原因：
一是可讀性。超過 100 行的 Markdown 文件，他基本不會認真讀完。當 Claude Code 生成一個幾百行的需求文檔或實現計劃時，他掃一眼開頭就跳到結尾了。更別說讓團隊裏其他人讀，基本沒戲。
二是編輯習慣變了。Markdown 的最大優勢之一是"人類容易直接編輯"，但他現在對這些文件的操作，基本都是讓 Claude 代勞，自己只看結果。這個優勢就不存在了。
三是信息表達能力有天花板。想加顏色對比？ASCII 湊合。想做個交互式設計方案？做不到。想要真正的流程圖而不是一堆短橫線？要麼插圖片，要麼將就。
這三點加在一起，讓他開始重新思考：AI 時代，文件格式最重要的事情是什麼？
為什麼是 HTML？
他的回答是：信息密度。
作為前端開發者，你比任何人都清楚 HTML 能承載多少東西。Thariq 列了一張清單，HTML 可以表達的信息類型包括：
用 <table>做真正的表格，有實際的行列結構用 CSS 傳遞設計信息：顏色、字體、間距 用內聯 SVG 畫圖表和示意圖 用 <code>配語法高亮展示代碼片段用 HTML + JavaScript + CSS 做交互元素，比如滑塊、開關、下拉選擇 用絕對定位和 Canvas 表達空間關係 用 <img>嵌入圖片
他的結論是：Claude 能讀懂的幾乎所有信息，都能用 HTML 高效表達。Markdown 只是其中一個極小的子集。
除了信息密度，他還提到了另外幾個優勢：
可讀性。 HTML 文檔可以做成真正好讀的格式，tab 導航、可點擊的連結、插圖，甚至響應式佈局。一個 HTML 報告和一個 100 行的 Markdown 文件，被人認真讀完的概率差距很大。
分享。 Markdown 文件分享很麻煩，大多數瀏覽器不能直接渲染。HTML 丟到 S3 發一個連結，對方用瀏覽器直接打開。這個細節直接影響你的 spec 文檔或 PR 說明有沒有人看。
雙向交互。 這是 Markdown 完全做不到的。HTML 裏可以加滑塊調整參數、加按鈕導出配置，最後加一個"複製為提示詞"按鈕，把操作結果塞回 Claude Code 繼續工作。文檔變成了工具。
上下文整合。 用 Claude Code 生成 HTML 報告，可以把文件系統、MCP 工具（Slack、Linear 等）、Git 歷史、瀏覽器裏的內容全部整合進去。這是直接用 Claude.ai 對話做不到的。
幾個實際用法
理論看完了，講幾個具體場景，對於前端/Node.js 開發者來說應該很有感觸。
技術方案和需求文檔
不再寫 Markdown 的實現計劃，而是讓 Claude Code 生成 HTML 文件，裏面有方案對比、代碼片段、示意圖，甚至組件 mockup。然後把這些 HTML 文件作為上下文，傳給新 session 來實現。
示例提示詞：
“我不確定 onboarding 頁面該往哪個方向走，給我生成 6 種完全不同的設計思路，佈局、風格、信息密度都要有差異，用一個 HTML 文件並排展示，每種方案標註它在做的取捨。
代碼審查
HTML 可以渲染真實的 diff，加行內註釋，畫模塊關係圖。他現在每次提 PR 都會附上一個 HTML 格式的代碼說明，他說這通常比 GitHub 默認的 diff 視圖好讀，也更有可能被認真審查。
示例提示詞：
“幫我審這個 PR，生成一個 HTML artifact。我不熟悉 streaming/backpressure 的邏輯，重點講那部分。渲染真實的 diff，用顏色區分問題嚴重程度。
設計原型
Claude Design 本身就是基於 HTML 的。你可以讓 Claude 用 HTML 畫出組件原型，再轉成 React 代碼。也可以加交互滑塊，調動畫曲線、顏色參數，最後加複製按鈕，把滿意的參數直接帶走。
示例提示詞：
“我想做一個結賬按鈕，點擊後播一段動畫然後變紫色，用 HTML 做幾個滑塊讓我調動畫參數，加複製按鈕把調好的參數輸出來。
臨時編輯界面
這個用法我覺得最有意思。有時候你很難用文字描述你要什麼，可以讓 Claude 臨時做一個專用的 HTML 編輯器，目的只是用一次，最後加一個"導出 JSON"或"複製為提示詞"的按鈕把操作結果轉回文本。
示例提示詞：
“我需要對 30 個工單重新排優先級，做一個 HTML 文件，把每張工單做成可拖拽的卡片，分 Now / Next / Later / Cut 四列，按你的判斷預先排好，加一個"複製為 Markdown"按鈕導出最終結果。
技術學習文檔
這個 Thariq 也提到了，Claude Code 能讀 Git 歷史，綜合多個數據源生成 HTML 報告。他舉了一個例子，為了寫一篇關於 prompt caching 的文章，他讓 Claude Code 讀完 Git 歷史，生成一份詳細的 HTML 研究文檔給自己閲讀。
示例提示詞：
“我不太理解我們的限流器是怎麼工作的，讀相關代碼後生成一個 HTML 說明頁：token-bucket 流程圖、3-4 個關鍵代碼片段加註釋、底部加一個"坑"彙總。面向讀一遍就能理解的人來寫。
幾個常見問題
這篇文章評論區問得比較多的問題，他也整理了：
HTML 不是消耗更多 token 嗎？
是更多，但他認為更高的表達力帶來的收益大於多出的 token 成本。Opus 4.7 有 100 萬上下文窗口，多出那些 token 在實際使用中感受不到。
生成速度慢嗎？
確實慢，大概是 Markdown 的 2-4 倍時間。他認為結果值得等，這個就見仁見智了。
版本控制怎麼辦？
他坦承這是最大的缺點：HTML 的 diff 很難看，也很難審查，遠不如 Markdown 的 diff 乾淨。這個問題目前他沒有好的解法。
怎麼查看 HTML 文件？
直接用瀏覽器打開本地文件就行，或者上傳到 S3 獲取分享連結。Claude Code 也可以幫你直接打開。
真的要全面轉向 HTML 嗎？
Thariq 自己說他可能走到了"HTML 極端主義者"這一側，普通用戶不需要做到那麼徹底。
我的看法是，他的核心論點站得住：在 AI 時代，"人類方便直接編輯"已經不再是文件格式最重要的特性了。我們越來越多地把這些文件當作 AI 讀寫的中間產物，而不是自己親手維護的文檔。在這個前提下，HTML 能承載的信息確實比 Markdown 豐富得多。
但全面放棄 Markdown 對大多數人來說既不現實也沒必要。比較合理的做法是：複雜的、需要給人看的輸出用 HTML；簡單的內部草稿、快速記錄用 Markdown。版本控制場景下 Markdown 依然更友好，這個短期內不會變。
如果你在用 Claude Code 開發，可以從代碼審查這個場景開始試試 HTML 輸出，因為 PR 說明這種東西，好不好讀直接決定有沒有人認真看。
他整理了一批示例文件放在這裏： https://thariqs.github.io/html-effectiveness ，涵蓋各種用途的 HTML 格式文檔，可以直觀感受一下效果，比看文字描述更有說服力。