Markdown過時了？Claude Code工程師：當文件只給AI看，用HTML更合理
重點一：Anthropic 工程師 Thariq 公開棄用 Markdown，改以 HTML 作為 AI agent 的主力輸出格式。
重點二：拐點不是技術優劣，而是「人類已不再手改 AI 產出」，當 Claude 變成編輯者，介面語言該服務閱讀而非編輯。
重點三：HTML 生成時間比 Markdown 多 2 到 4 倍，token 用量也明顯增加，但 100 萬 token 上下文時代讓這個帳單變得可承受。
如果你最近用 Claude Code、Cursor 或任何 AI 編輯器工作，會發現它們吐出來的檔案幾乎清一色是 Markdown。簡潔、純文字、可移植，是過去三年 AI 對人類輸出的事實標準。
但 Anthropic Claude Code 團隊工程師 Thariq（X 帳號 @trq212），在 5 月 8 日發布的長文中拋出一個反共識主張：他幾乎完全棄用 Markdown，改用 HTML 作為 AI agent 與他溝通的主力格式，而且他發現團隊內部越來越多人這樣做。
這篇文章在開發者圈引發討論，原因不只是格式偏好之爭。Thariq 點到一個業內已感受到、但少有人明說的拐點：當人類已經不再親手編輯 AI 產出的檔案，介面語言該服務的對象就改變了。
為什麼 Markdown 曾經是最優解？
回到 2022 年到 2024 年的 AI agent 設計慣例，Markdown 幾乎是無懸念的預設選項。理由很直觀：純文字、跨平台、git 友善、人類能直接打開記事本改一行字。 主流 AI 工具（ChatGPT、Notion AI、Cursor、GitHub Copilot）大多以 Markdown 作為長輸出的預設格式。
從工程經濟學角度看，Markdown 也是壓倒性的贏家。一份規格用 HTML 表達會比 Markdown 多吃可觀的 token，而且生成時間會拉長到 2 至 4 倍（這個倍率是 Thariq 文中明確給出的數字）。在 GPT-4 時代上下文窗口僅 8K 到 32K token 的環境下，這個成本足以勸退所有理性決策者。
換言之，Markdown 是「人類仍是主要編輯者」這個前提下的最優解。
轉向 HTML 的拐點在哪？
這句話是整篇文章最重的判斷句，也是 Thariq 整個論述的錨點。
他寫道，當 agent 越來越強，他發現自己其實已經很少手動編輯這些 Markdown 檔案了，它們的用途變成是規格書、參考資料、腦力激盪輸出。 需要修改時，他會直接讓 Claude 改，而不是自己打開編輯器。
這意味著 Markdown 的最大優勢「人類好編輯」已經失效。當編輯權實質上交還給 AI，輸出檔案的核心功能就從「可被人改」變成「能被人快速理解」。Thariq 也坦白：超過一百行的 Markdown 檔案他自己根本讀不完，更別說要同事讀。
而 HTML 的優勢是，不只更好寫，還更好讀。
它能在同一個檔案裡同時放結構化文字、表格、SVG 流程圖、CSS 樣式、可點擊的元件，甚至是 JavaScript 互動。對於 AI 生成的長規格、技術 review、設計草稿，這種資訊密度是 Markdown 給不出來的。
編按：以上配件由 Codex 生成，就是一種從 Markdown 轉向 HTML 的範例。如果說檔案純粹是要給人類閱讀而非編輯的話，HTML 確實有更視覺化的發揮空間。
100 萬 token 的解放：當 token 帳單不再是天花板
Thariq 在 FAQ 段落直接點名了讓這個選擇成為可能的關鍵變量：Opus 4.7 的 100 萬 token 上下文窗口。
用具體場景翻譯這個變化：一份用 Markdown 寫要 8 千 token 的技術規格，改成 HTML 後 token 數會明顯增加。放在 8K 上下文模型裡，這個操作會直接撐爆對話；放在 200K 上下文模型裡，仍會吃掉可觀比例。但放在 100 萬 token 的上下文中，Thariq 寫道「幾乎察覺不到」。
這是一個容易被忽略的產業訊號。當前沿模型的上下文進入百萬 token 量級，過去十年 AI 介面設計被「省 token」這個約束綁住的所有選擇，都該重新檢視一次。
不只是輸出格式，包括 prompt 寫法、context 拼裝策略、工具呼叫的回應結構，很多在 32K 時代被視為金科玉律的最佳實踐，可能正在過期。
編按：HTML 優勢之一，就是不只是顯示結果，而是可以用一個臨時做的 HTML 小工具，把「人類直覺調參」和「AI 自動改碼」接在一起，形成真正的 two-way interaction。
反共識也有代價：版本控制與時間成本
Thariq 沒有迴避 HTML 路徑的明顯缺點。他直白承認三個取捨。
第一是生成時間。HTML 比 Markdown 多花 2 到 4 倍的時間生成，原因是 token 數變多，而模型逐字輸出的速度有上限。一份原本 30 秒能拿到的 Markdown 規格，HTML 版可能要等一到兩分鐘。
第二是版本控制。HTML 的 diff 又雜又難 review，跟 Markdown 簡潔的行級差異天差地遠。對於需要 PR review、Git blame 的場景，這是實打實的痛點。Thariq 自己也說這是 HTML 最大的弱點。
第三是分享門檻。HTML 檔案要在瀏覽器才能正確渲染，他自己的做法是把檔案上傳到 S3 之類的儲存服務，拿到一個可分享連結再給同事。這對個人開發者是額外摩擦，對組織則需要對應的基礎設施配套。
介面語言之爭的擴散效應
Thariq 的個人實驗會擴散嗎？這要分兩個層面看。
對個人開發者，這個模板有清楚的複製條件：一，你已經把 AI 當主要編輯者，自己很少手改檔案；二，你用的模型上下文夠大，吃得起 HTML 的 token 膨脹；三，你的工作主要是「閱讀、決策、再交辦」，不是「逐行編輯」。三個條件都符合，HTML 路徑的效益就會浮現。
對 AI 工具廠商，這是更深的挑戰。目前主流的 AI 編輯器與 agent 工具，大多圍繞 Markdown 設計。如果 Anthropic 內部已有越來越多工程師走 HTML 路線，這個訊號可能預示未來 Claude Design、Artifacts、甚至 Claude Code 本身的預設輸出策略調整。
值得注意的是，Thariq 在文末特別提醒：「我有點擔心讀者會把這個變成一個 /html skill。」他想強調的不是格式本身，而是「想清楚輸出物的用途」這件事。換言之，HTML 不是新的最佳實踐，而是一個邀請——邀請開發者重新思考自己跟 AI 之間的工作關係到底是什麼。
邊界與啟示
反方論點也站得住腳。Markdown 的可移植性、git 友善度、人類最低成本可讀，這些優勢在很多場景下仍然壓倒一切。對於需要團隊跨工具協作、輸出物要進入既有文件系統、或是受嚴格版本控制流程約束的場合，HTML 路徑的摩擦成本可能高於收益。
更根本的問題是：「人類已不再手改」這個前提，到底適用於多大比例的開發者？Thariq 本人是 Anthropic 內部工程師，每天浸泡在 Claude Code 環境裡，他的工作流程未必能套用到還在過渡期的多數團隊。
但這篇文章的真正價值，不在於它給出了一個新的最佳實踐，而在於它讓一個正在發生卻少被討論的變化浮上檯面：AI 介面設計的核心變量，正在從「省 token」轉向「省人類認知頻寬」。
當模型能力與上下文窗口持續放大，這個轉向會逼出更多原本被視為理所當然的設計決策重新被審視。
延伸閱讀：Markdown是什麼？一個部落客為了上稿催生的格式，如何成為當代AI的底層語言？
資料來源：Using Claude Code: The Unreasonable Effectiveness of HTML（@trq212）
本文初稿為AI編撰，整理．編輯/ 李先泰