編輯 | 林芯

“我已經完全不再使用 Markdown 了”

剛剛，在X上Claude Code工程師Thariq的一篇分享——他幾乎停止使用 Markdown，轉而使用 Claude Code 生成 HTML 文件。在短短幾個小時里，這篇帖子的瀏覽量就突破了 200 萬。

評論區有網友對“使用 Claude Code 生成 HTML”的方式非常支持：

要知道，Markdown 憑借著簡潔、純文本、版本控制友好、幾乎隨處可編輯的特點，從技術文檔到 GitHub ，從筆記軟件到博客平臺，它幾乎成了輕量級標記語言的代名詞。

但如今，Claude Code 團隊里有許多人都更傾向于使用 HTML 作為輸出格式。難道 Markdown 一下子過時了嗎？

我們一起來看一下！

為什么大批開發者，開始放棄 Markdown？

“我也不親自編輯這些文件了，而是將其用作設計規范、參考文件、頭腦風暴的成果等等。當我確實需要修改時，通常會提示 Claude 來進行修改，但這卻削弱了 Markdown 最大的優點之一。”

Markdown簡單、便攜、富文本能力適中，還容易手動編輯。Claude 甚至能用ASCII 在 Markdown 里畫圖！

但是隨著 Agent 的能力越來越強，一系列問題就出現了：

• 長文件閱讀困難：超過100行的文件自己都難閱讀下去；

• 信息密度低：難以高效表達表格、顏色、復雜圖表等；

• 分享也不方便：瀏覽器的原生支持差，通常需要通過附件才能分享。

碾壓 Markdown！HTML 到底強在哪？

HTML 還是有“兩把刷子”的——Markdown 做不到的地方也就成為了HTML的優勢。

優勢1：超豐富的信息表達形式

HTML 除了能夠完成簡單的文檔結構功能，還能呈現 8 種類型的信息，包括表格、插圖等等。

“我甚至可以說，只要是對 Claude 能讀懂的信息，幾乎都可以通過 HTML 進行相當高效地呈現。”

優勢2：視覺清晰、閱讀友好

相對于Markdown，HTML 文檔更容易閱讀：Claude 可以從“界面”的角度去組織內容結構，通過標簽、插圖、鏈接等導航，它甚至還可以是移動響應式的！

優勢3：更容易分享

在分享 Markdown 文件時，通常需要作為附件添加到電子郵件或消息中。

如果使用的是 HTML ，只要上傳文件，就能輕松分享鏈接。

“如果你的報告或者公關稿件是 HTML 格式的，別人真正愿意打開并讀完它的概率會高得多。”

優勢4：支持雙向交互

更重要的是，HTML 不只是“更好看的文檔”，它甚至可以變成一個可交互的界面。比如加入滑塊、旋鈕、按鈕等交互組件，用來實時調整設計參數，或者修改算法中的不同選項，能夠直接觀察到結果。

甚至還可以讓 Claude 自動把這些調整后的參數整理成 prompt，一鍵復制回 Claude Code 。

選擇用 Claude Code 而不是Claude Design

可能會有人疑問：為什么選擇用 Claude Code 來生成 HTML，而不是直接使用 Claude AI 或 Claude Design？

Thariq 的回答是：Claude Code 能夠調用的“上下文”遠遠更多。它不僅能讀取當前文件，還能直接通過代 MCP（如 Slack、線性線性等）、瀏覽器（在 Chrome 中使用 Claude）、git 歷史記錄等來查找上下文。

并且 Thariq 在寫這篇文章時，他直接讓 Claude Code 掃描自己的代碼文件夾，找到過去生成的所有 HTML 文件，對它們進行分類、歸組，再自動生成一個包含不同類型圖表的 HTML 頁面。而文章里展示的那些圖表，就是 Claude Code 基于這些上下文生成的結果。

真實落地：工程師私藏的 5 大 HTML 使用場景

前面有關 HTML 的優勢說了那么多，實際落地會用到哪里呢？

Thariq 給出了 5 個可參考的使用場景！

場景1：發散性思考探索

如果說 markdown 是一個單線程的計劃，那么 HTML 就是多線程發散式的。

當他用 Markdown 時，流程是線性的：想法 → 計劃 → 實現，

但切換到 HTML 時，流程變成了一個“發散式網絡”：先讓 Claude 頭腦風暴探索，把每個方向擴展成獨立 HTML 頁面；再選擇一個滿意方向深入撰寫成實施方案；最后匯總成實現計劃，再開啟新的對話去執行。

甚至在驗證階段：另一個 Agent 會重新“讀整個 HTML 網絡”，而不是只看一段總結

Thariq還給了提示詞案例：“我不確定如何設計引導界面。生成 6 種截然不同的方法——變化布局、語氣和密度——并將它們以網格形式放在一個 HTML 文件中，以便我可以并排比較它們。”

場景2：代碼審查與理解

在 Markdown 文件中，代碼可能難以閱讀。但使用 HTML，我們可以渲染差異、注釋、流程圖、模塊等。利用這個方法，可以更好地理解 Agent 編寫的代碼，進行代碼審查。

“我發現這通常比默認的 Github 差異視圖效果更好，現在我會在每個 PR 中附加一個 HTML 代碼解釋器。”

場景3：設計與原型交互

HTML 在設計表達上具有極強的表現力。

即使你最終的產品界面完全不是 HTML，也完全沒問題：Claude 可以先用 HTML 快速勾勒出高保真設計圖，呈現出布局、交互和視覺效果，然后再用你指定的語言（React、Swift、Kotlin 等）將其真正實現出來。

除此之外，還可以直接進行原型化交互：Claude 直接構建一些可操作的組件，比如動畫效果、按鈕交互，甚至是滑塊、旋鈕等參數控制器。

場景4：輸出清晰易讀的報告

Claude Code 非常擅長整合多個數據源信息并轉化為報告。

通過提示 Claude 搜索 Slack、代碼庫、git 歷史記錄、互聯網等，能夠利用它生成非常易于閱讀的報告；并且還可以將其組裝成 HTML 文檔、交互式解釋器，甚至是一個演示文稿。

場景5：自定義編輯界面

有時候很難只用文本描述出想實現的效果。

在這種情況下，Thariq 會讓 Claude 構建一個一次性編輯器，用于正在處理的具體事情。

“不是產品，也不是可重用的工具，而是一個專門為這一份數據構建的單一 HTML 文件。”

靈魂三問：

更耗 Token、生成慢、版本控制差怎么辦？

在 Thariq 從 Markdown 切換到 HTML 之后，總會被問到一些問題：

這不會更消耗 token 嗎？

“雖然 Markdown 通常使用更少的 token，但 HTML 的表達能力更強，而且我更有可能閱讀它，這意味著可以得到更好的整體輸出。在 Opus 4.7 的 1百萬字上下文窗口中，token 使用量的增加在上下文窗口中并不明顯。”

這會不會比 Markdown 生成得更慢？

“確實要花更長的時間！HTML 生成的時間可能比 Markdown 多 2-4 倍，但我發現結果值得。”

版本控制怎么樣？

“這是 HTML 最大的缺點之一，HTML 在版本對比時會顯得非常“嘈雜”，結構變化、標簽層級、樣式調整都會被放大成大量無關噪音，使得代碼審查變得不夠清晰、也不夠高效。”

網友：超贊！工作效率提高了！

對于用 HTML 來替代 Markdown 的這種操作，網友的態度大多是肯定的：“讓 AI 用 HTML 幫你做軟件原型，你實際上可以在其中構建交互來測試空狀態等。保真度更高，可以檢查可用性。”

“我之前不知道該怎么編輯 HTML 代碼。Claude 直接給了我帶內聯注釋的可編輯 HTML 代碼。問題解決了，我的工作效率也提高了！"

除此之外，還有一些對操作細節的詢問：“對于我們這些在終端中使用 Claude Code 的人來說，你建議我們如何利用 HTML？剛剛讓它生成文件并在瀏覽器中打開？”

Thariq 之所以選擇使用 HTML，除了上面提到的原因之外，更核心的是“它讓我在與 Claude 的協作中始終保持“參與感”。

“我曾開始擔心，因為我不再深入閱讀它生成的計劃，我可能最終不得不完全放手，讓 Claude 自己做出所有決策，而我只負責接受結果。”

在這篇帖子的評論區，有網友發出疑問：“這是否意味著其他允許手動編輯的工具，比如 Excalidraw，也會被淘汰？"

在小編看來，答案是否定的。

每一種工具都有它的“生態位”。Markdown 的極簡、純文本、版本控制友好。Excalidraw 的手繪風格和白板體驗，在頭腦風暴和快速草稿上仍有一席之地。

各位大佬體驗過了嗎？覺得其他編輯的工具會被淘汰嗎？

https://x.com/trq212/status/2052809885763747935?s=20

https://thariqs.github.io/html-effectiveness/

最后，給大家介紹一下我們做的AI跨境。

我把項目實操過程中的核心干貨，提煉成了一份★獨家AI跨境秘籍★，直接免費送給大家。

如何免費獲取？

下面是下方微信號二維碼：添加后會自動發送這份資料，朋友圈也有更多案例可以查看!

識別上方二維碼聯系我

加好友請務必備注“微笑”，贈送★獨家AI跨境秘籍★：只送不賣，關鍵的案例、方法、經驗、踩過的坑，都在手冊里了。