Markdown已死？ HTML才是未來？ 這可能是個巨大的誤解。

作者：效率火箭
日期：2026年5月10日 上午7:31
來源：WeChat 原文

✦整理版優先睇

速讀 5 個重點 高亮

反對用HTML取代Markdown：保持簡單先係知識工作嘅核心

整理版摘要

呢篇文章係由火箭君寫嘅，佢回應咗一篇Claude Code內部人員Thariq嘅文章《Using Claude Code: The Unreasonable Effectiveness of HTML》。Thariq提倡用HTML取代Markdown作為人同AI交流嘅基本格式，話HTML有更高信息密度、更好視覺體驗同互動能力。火箭君就認為呢個觀點充滿誤解，仲可能涉及商業利益衝突。

火箭君從六個角度反駁：信息密度、可讀性、分享體驗、雙向交互、生成速度同審查。佢指出HTML雖然渲染後好靚，但原始碼難讀、安全風險高、依賴託管服務，仲會稀釋AI注意力同增加成本。相反，Markdown專注內容，純文本就可讀，生態兼容性好，適合嚴肅生產力。

整體結論係：Markdown先係知識工作嘅基石，用HTML取代係本末倒置。火箭君提醒大家要保持思考能力，唔好只睇AI生成嘅華麗輸出。佢仲質疑Claude Code內部人士叫人用更耗token嘅方式，有商業倫理問題。

  • 結論：Markdown比HTML更適合知識工作，因為佢專注內容、可讀性強、生態完善，HTML只係追求視覺華麗嘅「AI玩具」。
  • 方法：火箭君從信息密度、可讀性、分享體驗、雙向交互、Token成本同審查六個方面逐一反駁Thariq嘅觀點。
  • 差異：HTML渲染後靚但原始碼難讀，Markdown無論原始碼定渲染都可讀；HTML需要託管服務，Markdown係現代協作工具嘅通用語言。
  • 啟發：唔好將思考過程外包畀AI，放棄讀源碼等於放棄自己嘅思考能力，要關注內容而唔係花哨形式。
  • 可行動點：堅持用Markdown做人機交互同協作，避免使用AI生成嘅未經審查JavaScript交互，保持簡單高效。
整理重點

背景：Markdown vs HTML 嘅爭論

Claude Code內部人員Thariq最近發文，話應該用HTML取代Markdown作為人同AI交流嘅格式，引起好大討論。火箭君就覺得呢個觀點充滿誤解，佢話「Markdown嘅核心哲學係內容與表現分離」，HTML反而會引入大量無意義嘅樣板代碼。

整理重點

信息密度與表現力

Thariq話HTML可以透過CSS同SVG傳達更豐富信息，取代Markdown嘅ASCII字符畫。火箭君就反駁，複雜唔等於高效，Markdown本身就可以用Mermaid或PlantUML整流程圖，聲明式圖表語法比HTML/SVG更乾淨。

火箭君強調，內容與表現應該分離，AI生成大量HTML標籤會引入海量無意義樣板代碼，反而降低效率。

整理重點

視覺清晰與源碼可讀性

Thariq話超過100行Markdown冇人願意睇，HTML可以用標籤頁、摺疊面板整理。火箭君認為源碼可讀性先係更重要，HTML只有渲染後先易讀，原始碼完全反人類。

佢話Markdown無論渲染前後都具備結構化可讀性，習慣喺終端或編輯器工作嘅人至關重要。放棄讀源碼就係放棄思考，只會對住AI輸出傻笑。

整理重點

分享、交互同成本問題

Thariq話Markdown冇原生渲染，HTML上傳S3就分享得。火箭君反駁，HTML需要託管服務，增加基礎設施成本同安全風險；Markdown喺GitHub、Notion等平台已經有原生渲染，係通用語言。

至於雙向交互，火箭君話AI生成JavaScript交互係過度工程化，有XSS風險同Bug調試成本，不如直接用文本解決問題。

  1. 1 分享HTML需要上傳至S3等服務，增加基礎設施成本同數據泄露風險。
  2. 2 AI生成嘅JavaScript代碼未經審查，可能導致安全漏洞。
  3. 3 生成HTML比Markdown慢2-4倍，消耗更多Token，打斷用戶心流。
  4. 4 冗餘HTML標籤會稀釋AI注意力，增加幻覺機會。

火箭君仲質疑，Thariq叫人用更耗Token嘅方式，可能涉及商業利益衝突，因為Claude Code按Token收費。

整理重點

審查與總結：Markdown先係專業之選

Thariq承認HTML嘅Diff噪音大，難審查。火箭君話無法審查就註定係玩具，唔可以進入企業用途。佢強調審查係嚴肅生產力嘅必要環節。

火箭君總結，保持簡單、專注內容先係高效工作嘅真正解法。Markdown係知識工作嘅基石，HTML只係「AI玩具」。佢提醒大家要留意利益衝突，唔好盲目跟風。

圖片

突然之間嘅唱衰

呢個星期，突然之間有篇嚟自 Claude Code 內部人員 Thariq 嘅文章，喺圈子入面爆紅。引起咗非常熱烈嘅討論。
呢篇叫《Using Claude Code: The Unreasonable Effectiveness of HTML》嘅文章，大意係話，應該用 HTML 做人同 AI 交流嘅基本格式，而唔係目前廣泛用緊嘅 Markdown 格式。原作者列咗一大堆理由，亦都列舉咗利弊。
但係喺我睇嚟，呢篇唱衰 Markdown 嘅文章，並唔係咁簡單，包含咗唔少誤解。下面我會附上原文嘅翻譯摘要同我嘅觀點一齊解釋。
原文好長，但係翻來覆去都係幾句說話，大致核心係：AI 能力嘅提升，傳統嘅 Markdown 格式已經成為限制，AI 代理（例如 Claude Code）同人嘅互動應該全面轉向 HTML，以獲得更高嘅資訊密度、更好嘅視覺體驗同互動能力。

原文摘要同我嘅觀點

1. 關於「資訊密度同表現力」

原文觀點引用：
「HTML 可以傳達比 Markdown 豐富得多嘅資訊。佢唔單止可以處理文字，仲可以透過 CSS 呈現設計、用 SVG 畫插圖。呢個完美取代咗 Markdown 入面低效又難睇嘅 ASCII 字符畫。」

火箭君嘅觀點：複雜唔等於高效，內容同表現應該分離。
Markdown 嘅核心哲學正係「內容同表現分離」，佢強迫 AI 同用戶專注喺邏輯同文字本身。
叫 AI 生成包含大量 HTML 標籤、內聯 CSS 同 SVG 路徑嘅代碼，會引入大量冇意義嘅樣板代碼。另外，現代 Markdown 除咗可以完美嘅 HTML 渲染之外，仲可以透過整合 Mermaid 或者 PlantUML 完美實現流程圖同架構圖。呢種聲明式嘅圖表語法比起臃腫嘅 HTML/SVG 源碼更加乾淨、更加容易俾人類修改。

2. 關於「視覺清晰同易讀性」

原文觀點引用：
「超過 100 行嘅 Markdown 幾乎冇人會仔細睇。而 HTML 可以透過分頁、摺疊面板、響應式排版等視覺結構，將複雜嘅系統設計或者代碼邏輯整理得有條有理。」

圖片
火箭君嘅觀點：源碼嘅可讀性先係更重要嘅可讀性。
HTML 只有被渲染之後先易讀，佢嘅純文字源碼（Raw Source）係完全反人類閲讀嘅。
當然，依家有種觀點，人類未來唔需要閲讀源碼，無論係寫作、報告，定係 vibe coding，源碼都交俾 AI 就得。咁我只能夠話，放棄讀源碼，實際上係將自己嘅思考過程外判，等到大家都唔再思考源碼嗰陣，大家就冇咗自己嘅思考能力，只能夠望住 AI 生成嘅華麗輸出傻笑（目前已經明顯有呢個趨勢）。

3. 關於「分享體驗」

原文觀點引用：
「Markdown 喺瀏覽器入面缺乏原生渲染支援，往往要作為附件傳送。而 HTML 檔案只需要上傳（例如 S3）就可以生成連結，同事們可以喺任何裝置上直接㩒開閲讀，大大咁提高咗分享效率。」

火箭君嘅觀點：增加咗基礎設施依賴同安全風險。
實際上，HTML 嘅分享門檻遠高過 Markdown。分享稍微複雜啲嘅 HTML 需要專門嘅託管服務（例如 AWS S3、Vercel 等），呢個唔單止增加咗基礎設施成本，仲帶嚟咗權限控制同資料洩露嘅安全風險。
相反，Markdown 係現代協作工具嘅「通用語言」。你可以直接將 Markdown 貼去 GitHub、GitLab、Notion 或者 Slack 度，佢哋都會提供完美嘅原生渲染。唔需要任何「上傳檔案並生成連結」嘅繁瑣步驟。
我個人亦都介紹咗好多 Markdown 編輯器（包含渲染），Windows Notepad 都開始支援 MD 啦，呢個已經係一種預設嘅新文字檔案格式。好難想像，2026年，一個認真嘅知識工作者居然會打唔開 Markdown 檔案。

4. 關於「雙向互動同自訂編輯器」

原文觀點引用：
「HTML 支援雙向互動。當文字框難以描述需求嗰陣，你可以叫 AI 幫你寫一個『一次性編輯器』（例如拖曳式嘅工單看板、功能開關表單），調整滿意之後再將數據導出返俾 AI。」

圖片
火箭君嘅觀點：過度工程化同充滿安全隱患。
叫 AI 寫帶有 JavaScript 嘅「一次性互動界面」真係太過度工程化咗。
首先，運行 AI 生成嘅未經審查嘅 JavaScript 代碼可能會導致 XSS 攻擊或者本地資料洩漏。原本只要好好咁睇文字，依家變咗仲要運行代碼。
其次，AI 生成嘅互動邏輯往往存在瑕疵 Bug，難道仲要為咗除錯呢啲「一次性工具」，去花費時間？直接用文字解決原本問題，唔係更好咩？我一直主張，關注內容，關注問題本身，而唔係花巧嘅形式。純粹係屎上雕花。

5. 關於「生成速度同 Token 成本」

原文觀點引用：
「雖然生成 HTML 通常比 Markdown 慢 2-4 倍，而且消耗更多 Token，但係喺目前百萬級上下文窗口之下，呢啲消耗微不足道，結果絕對物有所值。」

火箭君嘅觀點：稀釋用戶同 AI 雙方嘅注意力。
姑且我哋相信淨係慢咗 2-4 倍。唔講呢啲問題，因為 AI 算力，我假設以後會一路增長，一年後或者真係唔係大問題。
但係喺互動式 AI 體驗入面係災難性嘅。就算慢 2-4 倍，等幾分鐘只係為咗睇一個排版花巧嘅報告，會嚴重打斷用戶嘅心流。
更重要嘅係，即使上下文窗口夠大，生成大量冗餘嘅 HTML 標籤都會嚴重稀釋 AI 嘅注意力（Attention 機制），導致模型喺長文字中迷失核心邏輯，增加產生幻覺嘅機會。同時，輸出 Token 嘅倍數增加直接等同於 API 成本嘅激增。
而呢一切，原本都係冇必要嘅。（哦，係喇，你哋係按 token 用量賣套餐嘅，咁就解釋得通啦）

6. 關於審查同版本控制

原文觀點引用：
「呢個係最大嘅缺點。HTML 嘅 Diff 噪音好大，確實唔及 Markdown 容易審查。」

火箭君嘅觀點：冇辦法進行審查，註定只係玩具。
原文作者輕描淡寫咁承認咗呢點。但係審查同版本管理，尤其係審查係無可避免嘅，如果我哋討論嘅係認真嘅生產力嘅話。
審查意味住有人參與嘅閲讀理解，或者工具輔助嘅比較（例如 diff，但係多數情況下，非代碼類嘅可能用唔到 diff，但肉眼審查仍然需要）
冇辦法被審查，意味住唔能夠進入合規嘅企業用途，亦都好難成為效率生產嘅一部分（之後會帶嚟混亂），只可以喺好淺嘅應用入面打轉，接近輕娛樂同自嗨呢類，我一直鍾意講，呢個就係另一個「AI 玩具」，閃閃發光，好玩，有新意，但係然並卵，熱情退咗之後，乜都唔係。
Claude Code 原本係一個真正嘅生產力工具，最後竟然要同一大堆 AI 玩具爭市場？

最後

《HTML 超乎想象嘅有效性》一文確實展示咗 AI 喺前端生成方面嘅強大能力，HTML 亦確實可以做得出好靚嘅「演示工具」或者「AI 玩具」，呢個係事實。
圖像
但是，Markdown 先係知識工作實踐嘅基石。用 HTML 替代 Markdown 互動，本質上係為咗追求視覺上嘅「華麗」，而犧牲咗源碼可讀性、安全性、生態兼容性同審查控制能力。
喺生產力嘅領域入面，呢個唔係專業嘅做法，亦都無疑係本末倒置嘅做法。無論 AI 以咩方式介入我哋嘅工作，保持簡單、專注內容，先係高效工作或者協作嘅真正解法，呢個亦都係我咁多年嚟嘅經驗之談。
順便一提，Claude Code 透過內部人士把口，鼓勵大家用更耗 token 嘅方式使用 AI，屬於利益衝突（COI），本身就有商業倫理上嘅可疑之處，值得我哋留意。
圖片
圖片

突如其來的唱衰

這周，突然一篇來自 Claude Code 內部人員 Thariq 的文章，在圈內大火。 引起了非常熱烈的討論。
這篇名為《Using Claude Code: The Unreasonable Effectiveness of HTML》的文章，大意是說，應該用 HTML 作為 人與AI交流的基本格式； 而不是目前廣泛採用的 Markdown 格式。 原作者列出了一堆理由，也列舉出了利弊。
但是在我看來，這篇唱衰 Markdown 的文章，並不是那麼簡單，複合了不少的誤解。下面我會附原文的翻譯摘要和我的觀點一起進行講解。
原文很長，但是翻來覆去就是幾句話，大致核心是：AI 能力的提升，傳統的 Markdown 格式已經成為限制，AI 代理（如 Claude Code）和人的交互應該全面轉向 HTML，以獲得更高的信息密度、更好的視覺體驗和交互能力。。

原文摘要及我的的觀點

1. 關於“信息密度與表現力”

原文觀點引用：
“HTML 能傳達比 Markdown 豐富得多的信息。它不僅能處理文本，還能通過 CSS 呈現設計、用 SVG 繪製插圖。這完美替代了 Markdown 中低效且難看的 ASCII 字符畫。”

火箭君的觀點：複雜不等於高效，內容與表現應該分離。
Markdown 的核心哲學正是「內容與表現分離」，它強迫 AI 和 用戶專注於邏輯和文本本身。
讓 AI 生成包含大量 HTML 標籤、內聯 CSS 和 SVG 路徑的代碼，會引入海量的無意義樣板代碼。此外，現代 Markdown 除了可以 完美的HTML 渲染以外，還可以通過集成 Mermaid 或 PlantUML 完美實現流程圖和架構圖。這種聲明式的圖表語法比臃腫的 HTML/SVG 源碼更乾淨、更易於人類修改。

2. 關於“視覺清晰與易讀性”

原文觀點引用：
“超過 100 行的 Markdown 幾乎沒人願意仔細看。而 HTML 可以通過標籤頁、摺疊面板、響應式排版等視覺結構，將龐雜的系統設計或代碼邏輯整理得井井有條。”

圖片
火箭君的觀點：源碼的可讀性才是更重要的可讀性。
HTML 只有被渲染後才易讀，其純文本源碼（Raw Source）是完全反人類閲讀的。而 Markdown 無論是否經過渲染，其純文本本身就具備極強的結構化和可讀性，這對於習慣在終端或代碼編輯器中工作的知識工作者至關重要。無論是寫文章還是寫代碼都是一樣的，這是參與思考的過程。
當然，現在有種觀點，人類未來不需要閲讀源碼，無論是寫作，報告，還是 vibe coding， 源碼都交給 AI 就好了。那我只能說，放棄讀源碼，實際是在外包自己的思考過程，等到大家都不再思考源碼時，大家也就沒有了自己的思考能力，只能看着 AI 生成的華麗輸出傻笑了（目前已經明顯有這個趨勢了）。

3. 關於“分享體驗”

原文觀點引用：
“Markdown 在瀏覽器中缺乏原生渲染支持，往往需要作為附件發送。而 HTML 文件只需上傳（如 S3）即可生成連結，同事們可以在任何設備上直接點開閲讀，大大提高了分享效率。”

火箭君的觀點：增加了基礎設施依賴與安全風險。
實際上，HTML 的分享門檻遠高於 Markdown。分享稍微複雜一點的 HTML 需要專門的託管服務（如 AWS S3、Vercel 等），這不僅增加了基礎設施成本，還帶來了權限控制和數據泄露的安全風險。
相反，Markdown 是現代協作工具的“通用語言”。你可以直接將 Markdown 粘貼到 GitHub、GitLab、Notion 或 Slack 中，它們都會提供完美的原生渲染。不需要任何“上傳文件並生成連結”的繁瑣步驟。
我個人也介紹了很多 Markdown 編輯器（含渲染），Windows Notepad 也開始支持 MD 了， 這已經是一種默認的新文本文件格式了。 很難想象，2026年，一個嚴肅的知識工作者居然會打不開 Markdown 文件。

4. 關於“雙向交互與自定義編輯器”

原文觀點引用：
“HTML 支持雙向交互。當文本框難以描述需求時，你可以讓 AI 為你寫一個‘一次性編輯器’（如拖拽式的工單看板、特性開關表單），調整滿意後再將數據導出回 AI。”

圖片
火箭君的觀點：過度工程化且充滿安全隱患。
讓 AI 編寫帶有 JavaScript 的“一次性交互界面”實在是過度工程化了。
首先，運行 AI 生成的未經審查的 JavaScript 代碼可能導致 XSS 攻擊或本地數據泄露。 原本只要好好的看文本，現在變成了還要運行代碼。
其次，AI 生成的交互邏輯往往存在 瑕疵 Bug，難道還要為調試這些“一次性工具”，去花費的時間？直接用文本解決原問題，不是更好嗎？我一直主張，關注內容，關注問題本身，而不是花哨的形式。 純純的 shi 上雕花。

5. 關於“生成速度與 Token 成本”

原文觀點引用：
“雖然生成 HTML 通常比 Markdown 慢 2-4 倍，且消耗更多 Token，但在當前百萬級上下文窗口下，這點消耗微乎其微，結果絕對物有所值。”

火箭君的觀點：稀釋 用戶 和 AI 兩方的注意力。
姑且我們相信僅僅慢了2-4 倍。 拋開這些問題，因為AI算力，我假設以後一直會增長，一年後或許的確不是大問題了。
但在交互式 AI 體驗中是災難性的。哪怕慢2-4倍，等待幾分鐘只為了看一個排版花哨的報告，會嚴重打斷用戶的心流。
更重要的是，即使上下文窗口足夠大，生成大量冗餘的 HTML 標籤也會嚴重稀釋 AI 的注意力（Attention 機制），導致模型在長文本中迷失核心邏輯，增加產生幻覺的概率。同時，輸出 Token 的成倍增加直接等同於 API 成本的激增。
而這一切，原本都是沒有必要的。（哦，對了，你們是按 token 用量賣套餐的，這就解釋得通了）

6. 關於審查和版本控制

原文觀點引用：
“這是最大的缺點。HTML 的 Diff 噪音很大，確實不如 Markdown 容易審查。”

火箭君的觀點：無法進行審查，註定只能是玩具。
原文作者輕描淡寫地承認了這一點。但是審查和版本管理，尤其是審查是不可避免的，如果我們討論的是嚴肅的生產力的話。
審查意味着有人蔘與的閲讀理解，或者工具輔助的比較（比如 diff，但是多數情況下，非代碼類的可能用不到 diff，但肉眼審查還是需要的）
不能被審查，意味着不能進入合規的企業用途，也很難成為效率生產的一部分（後續會帶來混亂），只能在很淺的應用裏打轉，接近於輕娛樂和自嗨這類，我一直喜歡說的，這就是另一個“AI玩具”，閃閃發光，好玩，有新鮮感，然並卵，熱度褪去後，什麼也不是。
Claude Code 原本是一個真正的生產力工具，最後卻要和一眾 AI 玩具爭奪市場？

最後

《HTML 超乎想象的有效性》一文確實展示了 AI 在前端生成方面的強大能力，HTML 也確實能做出好看的“演示工具” 或者 “AI玩具”，這是事實。
圖像
但是，Markdown 才是知識工作實踐的基石。用 HTML 替代 Markdown 交互，本質上是為了追求視覺上的“華麗”，而犧牲了源碼可讀性、安全性、生態兼容性和審查控制能力。
在生產力的領域裏，這不是專業的做法，也無疑是本末倒置的做法。無論 AI 以什麼方式介入我們的工作，保持簡單、專注內容，才是高效工作或協作的真正解法，這也是我這麼多年的經驗之談。
順便一說，Claude Code 借內部人士之口，鼓勵大家用更耗 token 的方式使用 AI， 屬於利益相反（COI），本身就有商業倫理上的可疑之處，值得我們注意。
圖片