為什麼在 Claude Code 中應使用 HTML 而非 Markdown：來自 Anthropic 的見解

「AI 寫的東西太長了，我根本沒好好讀完 😅」

「我每個月付超過 15,000 日圓給 Claude Code，但感覺沒得到相應的回報。」

很多人只因為自己在用 AI 就感到滿足，但真正能把它轉換成成果的人卻很少。這是一種「好像用了，但其實沒用」的狀態。

你在使用 Claude Code 時，有過這些經驗嗎？

週一早上請它「總結上週的競爭對手趨勢」，結果它回傳一份超長的報告。你瞄了一眼，就放著沒讀。
你心想，如果連自己都沒好好讀 AI 生成的資料，那團隊成員肯定也不會讀。
每個月付超過 3,000 日圓給 Claude Code，但產出的內容從來沒在會議或提案中被使用過。
ChatGPT 和 Claude.ai 的輸出看起來很漂亮，但為什麼 Claude Code 只輸出 Markdown，讀起來這麼累？

這篇文章就是為這些人寫的。

當你讀完時，你將能夠自然地從 Claude Code 生成你和別人都會真正閱讀的資料。

你也會學到一個觀點：「輸出什麼格式」對使用者判斷的影響，遠比「你叫 Claude Code 做什麼」來得大。

Anthropic 的開發者 Thariq Shihipar（@trq212），他正是實際打造 Claude Code 的人，在 X 上分享了公司內部正在擴散的一種思維，而這則貼文已成為 Claude Code 社群中最多人儲存和分享的貼文之一。

貼文一發布就獲得巨大迴響。

這不只是給 AI 極客的小技巧，而是一個打造工具的人，對 AI 業界長期以來的隱性標準——Markdown——發起挑戰，說「這條路已經行不通了」。

我認為這很重要，所以決定立刻用日文來解釋。

開始閱讀前有兩件事：

把這篇文章加入書籤。就在這週，騰出一些時間試著用 HTML 輸出。
如果你有團隊成員在使用 Claude Code，把這篇文章分享給他們。從下週開始，你的週報和 PR 審查被「閱讀」的方式將會明顯改變。

我會一邊翻譯，一邊拆解內容，並說明它在日本商業場景中如何運作 👇

原始貼文在這裡：

https://x.com/trq212/status/2052809885763747935

Anthropic 開發者本人已不再使用 Markdown

這是起點。原始貼文的作者 Thariq Shihipar（@trq212）是在 Anthropic 打造 Claude Code 的開發者。Claude 在「計劃模式」中向使用者提問以釐清需求的行為，正是他親自實作的功能。

他說他不再接受自己正在打造的工具所產生的 Markdown。用他自己的話來說，Markdown 對他而言已成為一種限制性的格式。

這不只是個人偏好。Thariq 提到，在 Claude Code 團隊內部，HTML 的採用正在擴散。打造工具的人正在拋棄它產生的 Markdown，轉而使用 HTML。

而且證據是觸手可及的。在示範網站 https://thariqs.github.io/html-effectiveness/ 上，有 20 個自包含的 HTML 範例。比較了三種方法：防抖搜尋、能帶來任務完成成就感的小互動、設計系統代號清單、程式碼範例的分頁說明，以及附有邊欄詞彙表的閱讀材料。這些都是將「你只會瞄一眼的文件」替換成「會被讀到最後的文件」的真實案例。你現在就可以在瀏覽器中打開它們。

讀到這裡，你應該會意識到一件事。你平常在 ChatGPT 或 Claude.ai 中收到的 Artifacts——那些「有分頁的 UI」、「彩色圖表」和「互動按鈕」——其實都是輸出成 HTML。這裡的領悟是：「它們之所以看起來這麼漂亮，是因為格式本身的差異。」現在，同樣的世界也能透過 Claude Code 來到你的指尖。

直到現在，AI 生成的文字幾乎全是 Markdown。打造它的人正在悄悄地開始反對，說「不再是這樣了」。這就是這則消息的核心。但對每天使用 AI 的你來說，這是一個從週一早上就會開始見效的故事。

Markdown 曾是 AI 業界的隱性標準

讓我們先確認那些我們視為理所當然的前提。沒有這個前提，轉換到 HTML 可能只會被看作是一種品味問題。

直到現在，Markdown 一直是 AI 輸出的事實標準。回想一下你每天看到的文字：

專案根目錄的 CLAUDE.md、用於 Agent 定義的 *.md、用於技能的 SKILL.md。
Anthropic 的官方文件、Claude.ai 的說明、以及各種 Claude Code 指南。
競爭對手的 AI 開發工具、Cursor 規則、GitHub Copilot 指令、Cline 指令，全都基於 .md。
內部 Wiki、GitHub README、從 Notion 匯出的文字、貼到 Slack 的會議記錄。
從 ChatGPT 對話中複製的摘要文字。

一切都建立在 Markdown 的假設之上。在你處理 AI 時所接觸的文字資訊中，要找到 Markdown 以外的格式反而更難。

Karpathy 的 CLAUDE.md 模式在 GitHub 上獲得超過 80,000 顆星的現象，正是因為 Markdown 是業界的共通語言。

用 Thariq 的話來說，Markdown 已成為 Agent 的主流格式。他是一個長期在 Markdown 前提下打造工具的人。

而這個人現在明確表示：Markdown 對我來說已成為一種限制性的格式。這是 Anthropic 內部人士對整個業界一直以來依賴的前提投下的一顆石頭。

簡單來說：你從 Claude Code 得到的 Markdown、Cursor 讀取的規則、以及你內部 Wiki 上的 AI 輸出，全都屬於同一條「Markdown 就夠了」的流程。而創造它的人，已經開始畫出一條不同的渠道。

接下來，我們將深入探討為什麼 Markdown 無法觸及人心，以及該用什麼來取代它。

Markdown 不被閱讀的 5 個原因

讓我們整理一下 Markdown 的限制。這不是技術規格，而是你從週一到週五的日常體驗。我將原始文章中 HTML 的優點反過來列出，以顯示 Markdown 的缺點。

① 超過 100 行，連你也不會讀

Thariq 本人寫道，當 Markdown 檔案超過 100 行時，他就不再讀了。

當你請 Claude Code「總結上週的競爭對手趨勢」時，你很可能有過關掉那 120 行回應、沒有往下捲的經驗。如果產生它的人都不讀，團隊裡就沒有人會讀。現實是，不只是作者，組織內的其他成員也只是在掃讀。

② 即使分享出去，在瀏覽器中打開也不好看，所以沒人碰

Markdown 在瀏覽器中無法原生地漂亮呈現。在 Slack 中換行會跑掉，在電子郵件中格式會亂掉，要轉成 PDF 或截圖用於提案也很費工。

每次分享時，都有人得把它轉換成「可讀的形式」。Markdown 是一種每次分享都會產生摩擦的格式，甚至到了連結常常根本沒人點開的程度。

③ 沒有顏色或圖表，只能傳達大綱

你想強調數字的差異、用紅色顯示警告、或用箭頭顯示流程。要在 Markdown 中做到這些，你只能靠 ASCII 字元畫圖，或用 Unicode 框線字元來表達顏色。

沒有人想解讀那些東西，而且寫的人也累。即使 Claude 努力畫圖，最終還是會被掃讀過去。

④ 無法觸碰或移動，只能讀完就結束

你想試試稍微柔和一點的顏色、測試動畫的速度、或看看把某個值放大 1.5 倍會怎樣。

在商業場景中，經常需要「實際試試看」才能做出判斷。Markdown 做不到這一點。你讀完、在腦中模擬、然後用文字回傳指示——這是一個沒有效率的循環。

⑤ 在手機上打開會壞掉

在外出時用 Slack、電子郵件或 Notion 打開。在日本商業場景中，有一半的共享資料是在手機上第一次被打開的。

Markdown 的版面不會跟隨螢幕寬度。表格會橫向溢出、程式碼區塊的換行會變得很奇怪、標題層級會變得看不見。閱讀的意願在那一刻就消失了。

讓我們給這個現象一個名字。每次你產出沒人讀的 Markdown，發送者和接收者在打開之前就已經累積了疲勞。捲動 100 行的成本、在 Slack 中修正換行的成本、因為缺少圖表和顏色而導致的溝通失敗、因為無法互動而延遲的判斷、以及在手機上壞掉的問題。

這些都是每天支付的隱藏費用。在這篇文章中，我們稱之為 「格式稅」。

這不是一筆小稅。Claude Code 的價值有一半以上不是由輸出的內容決定，而是由「它能觸及誰、觸及多遠」決定。透過輸出一個無法觸及人心的格式，你等於丟掉了一半的訂閱價值。

如何切換：只要加上「輸出成 HTML 檔案」

你不需要想得太複雜。要做的事情遠比你想像的少。

只要在你平常給 Claude Code 的請求結尾加上一行。以下三種說法意思相同：

「輸出成 HTML 檔案」
「輸出成單頁 HTML」
「做成 HTML，讓讀者可以直接打開」

如果你覺得用英文寫比較順手，「make a HTML file」或「make a HTML artifact」也可以。結果是一樣的。

Claude Code 可以從 MCP、瀏覽器、git 和檔案系統中提取上下文。Claude Code 的優勢在於，它能將比 ChatGPT 或 Claude.ai 的網頁聊天版本更廣泛的資訊來源，打包進單一 HTML 中。

這與我們稍早討論的內容相關。你在 ChatGPT 或 Claude.ai 中收到、並覺得「很漂亮」的 Artifacts，都是輸出成 HTML。

你現在可以在 Claude Code 端接收到同樣的世界。這不是什麼困難的技術故事；只要改變你提問方式中的一行，就能產出真正觸及人心的資料。

Thariq 在他的文章中強調一點：「我還不希望這個被做成 /html 技能；我希望大家先透過提示詞來習慣它。」儘管他是 Claude Code 團隊中會產出技能的開發者。

他並不是否定把它做成技能。他是說：「如果用法還沒確定就包裝起來，你會錯過真正有效的部分。」

在 Anthropic 內部，已經變得頻繁的 HTML 輸出，開始被元件化為 Playground 外掛之類的東西。與其從一開始就等待一個完成品，不如先用一行提示詞試試，找出適合你工作的模式。只有到了那個時候，才應該考慮把它做成技能。

在每個提示詞中都寫上「用 HTML 輸出」可能看起來像個任務，但選擇格式本身並不是任務。從 Claude 輸出 Markdown 切換到 Claude 輸出 HTML 的那一刻，你就已經朝著「在等待預先設計好的技能之前，先設計輸出」的方向邁進了半步。

只要切換到 HTML，就會改變的 5 個商業場景

這一章從週一到週五都能實際派上用場。我將原始文章中的五個使用案例，按照在日本商業場景中的出現頻率重新排序：週報/研究摘要、提案的並列比較、設計調整、決策編輯畫面、以及 PR/規格審查。

每個場景都總結了目前的問題、Before/After，最後是給 Claude Code 的範例指令。

[場景 1] 用圖表呈現週報和研究摘要

日本商業中常見的場景。週一早上，你的老闆說：「總結一下上週的趨勢。」

Before：你把 120 行的 Markdown 貼到 Slack。換行跑掉。老闆沒打開。沒有被放進管理會議的資料中。你最後只能口頭解釋：「我讓 Claude 做的。」

After：你將 Slack 記錄、Linear 或 Notion 的票務歷史、git 記錄和內部文件整合成一個單頁 HTML。用 SVG 加入簡單的商業流程圖，並在底部用彩色區塊放置三個重點。

如果你把這個放到內部儲存空間並分享 URL，你的老闆可以在通勤時用手機打開，管理階層可以引用它，也可以貼到會議記錄中。

這裡的關鍵是，Claude Code 可以從 MCP、瀏覽器、git 和檔案系統中提取上下文。即使你叫網頁聊天「做一個 HTML」，也很難將這麼多資訊來源打包成一個。這是只有 Claude Code 才能創造的週報。

Thariq 本人寫道，他讓 Claude Code 讀取他程式碼資料夾中的所有 HTML，並將它們總結成一頁，來製作他文章的圖表。一份「會被閱讀的週報」和一份「會被閱讀的說明文章圖表」，在結構上是相同的。

▼ 範例指令：

「讀取上週所有的 Slack 互動、Linear 票務完成情況和 git 記錄，並輸出成一個單頁 HTML 的週報，讓我的老闆能在 1 分鐘內掌握重點。用 SVG 加入簡單的商業流程圖，並在底部用彩色區塊放置三個重點。確保在智慧型手機上打開時不會壞掉。」

[場景 2] 將 6 個提案/研究選項並排顯示

下週的提案該走哪個方向？在企劃、業務和企業規劃中，經常需要製作多個選項並與決策者對齊。

Before：你把六個選項分別用六個 Markdown 檔案寄出。客戶無法一個一個打開比較。他們問：「你最推薦哪一個？」然後你才發現自己也沒完整比較過。

After：你將六個不同調性、密度和目標受眾的選項，在一個單頁 HTML 中以網格方式排列。在每個選項下方加上一行取捨說明。決策者在一個畫面上比較所有選項，並立即回應：「我想要混合這個和這個」或「用 #3 的目標受眾搭配 #1 的密度」。當你並列展示時，討論的決議速度就會改變。

對決策者來說，收到六個檔案和一個畫面上並列六個選項，判斷所需的時間是天差地別的。這與其說是「讓他們閱讀」，不如說是「讓他們能夠做出決定」。

▼ 範例指令：

「為下週的簡報製作 6 個不同調性、密度和目標受眾的提案選項，並在一個單頁 HTML 中以網格方式排列。在每個選項下方寫上一行取捨說明。另外，在底部加一個按鈕，可以在決定後將結果複製成 Markdown。」

[場景 3] 透過觸碰來決定設計和原型

在決定顏色、大小或動態時，你應該放棄用文字來對齊。這是行銷、公關和企劃在感謝信或登陸頁面按鈕上反覆來回多次的場景。

Before：你用「稍微柔和一點的藍色」或「讓動態變得蓬鬆一點」這類文字來溝通。接收者的想像每次都會偏離。看到一輪來回後回來的版本，你又加了更多文字：「不，不是那種柔和。」

After：你讓 Claude Code 建立一個 HTML，裡面有可以調整顏色和動畫速度的滑桿。你為感謝信按鈕或 LP CTA 按鈕建立原型，做成單頁 HTML 並將 URL 寄給利害關係人。每個人都可以觸碰它，決定最佳數值，然後直接把那些數值複製回 Claude。文字來回減少，達成共識的時間縮短。

與此相關的是，Anthropic Labs 正在開始將這種「觸碰決定，然後將操作複製回 Claude」的概念正式化為 Playground 外掛。HTML 輸出不僅是一個小技巧，更是 Anthropic 本身正在培育為一種模式的方向。

▼ 範例指令：

「建立一個 HTML，讓我可以透過三種滑桿來決定感謝信中按鈕的顏色和動畫速度。在底部加一個按鈕，可以複製決定的數值。」

[場景 4] 在 3 分鐘內做出判斷畫面

下個季度哪些措施該分配到 Now、Next、Later 或 Cut？將 30 張票排序以決定優先順序，是 PdM、企劃和企業規劃典型的「判斷任務」。

Before：你在試算表中列出 30 個項目，然後手動一個一個填寫優先順序欄位。你排序、重新思考、移到另一個工作表、再移回來。有時候花了 30 分鐘還是沒有結論。

After：你請 Claude Code「做一個 HTML，讓我可以把項目拖放到 Now、Next、Later 和 Cut 四個欄位中。」一個專用的編輯畫面在 3 分鐘內就準備好了。你拖放那 30 張卡片，完成後複製結果。判斷任務的時間縮短了一個數量級。

這裡有一個容易被忽略但非常有效的設計原則。那就是 Thariq 寫的這句話：「永遠以匯出作結。」在製作編輯畫面時，一定要包含「複製為 JSON」、「複製為提示詞」或「複製為 Markdown」的按鈕。

沒有這個，你就無法將排序結果回傳給 Claude，它就會只是一個任務工具。只有當你建立一個循環——在 HTML 中判斷，然後將結構化的文字結果回傳給 Claude——編輯畫面才能成為一個判斷裝置。

同樣的概念也可以用於編輯功能旗標、並排的系統提示詞編輯器、或資料集的核准/拒絕/標記。「在 3 分鐘內建立一個專用的、一次性的 UI」正是 Claude Code 最能展現其真正價值的地方。

▼ 範例指令：

「建立一個 HTML，讓我可以將下個季度的 30 項措施拖放到 Now、Next、Later 和 Cut 四個欄位中。最後放一個『複製為 Markdown』按鈕，讓我可以輸出排序結果，每行附上原因。」

[場景 5] 用顏色標記差異來交接 PR 審查和規格共享

最後是與工程師協作的場景。即使你不讀程式碼，作為 PdM、總監或編輯，你可能還是會被叫去參與 PR 審查或規格確認。

Before：你被要求打開 GitHub 的 diff 畫面。光看 diff，你無法分辨哪個部分重要、哪個可以忽略。你必須閱讀留言才能跟上故事。不讀程式碼的人通常只會說「有什麼再跟我說」，然後就關掉。

After：你請 Claude Code「把這個 PR 變成一個 HTML 審查文件，讓不讀程式碼的人也能在 30 秒內掌握重點。」在 diff 旁邊附上留言，用顏色標記影響範圍，並在最後總結三個疑慮。如果你把這個上傳到內部儲存空間並分享 URL，PdM 和總監就可以用一個按鈕提供回饋。與工程師協作的人終於可以參與審查。

HTML 不是工程師的語言；它是傳遞故事的工具。diff 的意義、風險和影響範圍——這些「需要解讀的資訊」——透過註解、顏色和版面來傳達。這就是 HTML 轉換的意義。

▼ 範例指令：

「把這個 PR 變成一個 HTML 審查文件，讓不讀程式碼的人也能在 30 秒內掌握重點。在 diff 旁邊附上留言，用顏色標記影響範圍，並在最後總結三個疑慮。」

當你繼續用 Markdown 輸出這五個場景時，格式稅正在悄悄地、但每天不斷地累積。你是否在注意到的那一刻就停止它，將是從下週開始的差異。

切換時會出現的 6 個問題

讀到這裡，你心裡應該會浮現幾個問題。我將原始文章中的 FAQ 部分，按照日本商業讀者可能遇到的順序重新排列。

■ 會消耗更多 token 嗎？

是的，會。原始文章指出，生成時間比 Markdown 多 2 到 4 倍。不過，Opus 4.7 有 100 萬 token 的上下文，所以因為回傳 HTML 而導致對話因上下文限制中斷的風險幾乎不存在。

Thariq 的結論是：「數字會增加，但如果你選擇了會被閱讀的結果，對整體工作來說是划算的。」這是一個選擇：要用你每月超過 3,000 日圓的合約來產出 1,000 行沒人讀的 Markdown，還是產出一頁會被打開的 HTML。

■ 設計會不會很醜？

這是合理的擔憂，但有對策。

一個是使用 Claude Code 的前端設計外掛。另一個是提供 Claude 一個來自你公司網站或現有資料的 HTML 範例。如果你提供一個參考檔案，並說「用這個調性」或「用這個字型和色板」，Claude 就會輸出符合你公司風格的 HTML。在你的程式碼庫中保留一個像 design-system.html 這樣的檔案，就可以每次參考它。

■ 編輯 HTML 不是很麻煩嗎？

你不需要自己編輯。

Thariq 本人寫道，他不會直接碰 HTML。如果你告訴 Claude「把這個顏色調柔和一點」或「把第三個區塊縮小一點」，它就會幫你修正。只要你是用於規格、腦力激盪或參考資料，所有編輯都可以交給 Claude。

■ 要怎麼打開？要怎麼分享？

打開很簡單。只要把 Claude Code 產生的 HTML 檔案在本機用瀏覽器打開就行了。

你甚至可以請 Claude「打開這個檔案」，它可能會幫你在瀏覽器中打開。分享時，最簡單的方法是上傳到內部儲存空間或 S3，然後提供 URL。如果你把連結貼到 Slack 或電子郵件中，收件者就可以在他們的瀏覽器中打開。那個把 Markdown 轉成 PDF 的額外步驟完全消失了。

■ 版本控制怎麼辦？

老實說，HTML 不太適合 Git diff 管理。修正一行可能會因為格式化工具的設定而讓 diff 跑到其他地方。Thariq 本人寫道，HTML 是版本控制的最大弱點。

因此，實用的解決方案是：「給人看的交付物」用 HTML，「想保留歷史的規格或記錄」用 Markdown。不是要廢除 Markdown，而是要切換到根據輸出目的選擇格式的心態。

■ 我可以完全停止使用 Markdown 嗎？

不行。記錄、變更歷史、以及你想保留在儲存庫中的結構化文字，應該繼續使用 Markdown。

CLAUDE.md 和 SKILL.md 如果保持為 Markdown，會更容易管理和追蹤 diff。HTML 適合用於「傳遞給人」、「讓人觸碰」、「並列多個選項」和「讓人用顏色判斷」。如果你大致理解為「與 AI 互動用 Markdown，分發給人用 HTML」，就不會迷失方向。

到現在為止，你最初的疑慮應該已經消除了。一篇包含缺點的文章更值得信賴——這是我作為作家的信念。

你要繼續支付格式稅，還是轉向設計的一方？

最後，讓我們拉高視角來做個總結。

我們之前討論過「提示稅」——也就是在 Claude 中重複輸入相同前提的成本。接著，我們談到了透過 .claude 資料夾進入設計層的故事。而這個「格式稅」是該系列的第三個主題。在對話層和設計層之後，我們現在解決了輸出層的問題。

讓我們定義「格式稅」，以便與讀者分享：

如果你一直選擇沒人看的輸出格式，疲勞感會在打開之前就累積起來，無論對你還是對其他人。你每個月為 Claude Code 支付超過 3,000 日元，但交付成果卻從未在會議中使用。那種感覺來自於沒有對格式選擇做出判斷。這就是格式稅。

輸出 Markdown 是一項任務。選擇 HTML 是一個判斷。即使使用相同的 Claude Code，格式選擇上的一個判斷就能顯著改變交付成果能觸及的距離。

而且 HTML 不是工程師的語言。它是用來製作會被閱讀的資料的工具。先別想著建立網站。只要試著把你這週要寫的週報、提案或審查文件輸出成 HTML 就行了。這樣就夠了。

讓我們談談更大的圖景。

Markdown 曾是 AI 產業隱含標準的時代，正在 Anthropic 內部悄然結束。雖然 CLAUDE.md、SKILL.md 和 Cursor 規則都建立在 Markdown 的前提上，但輸出格式已經開始率先轉變。見證標準改變時刻的讀者，可以領先半步。

當然，一旦你意識到「我每週都這樣做」，你就可以選擇將其進化為一個技能。

在 Anthropic 內部，像設計相關的 Playground 這類高頻率使用 HTML 輸出的模式，正逐漸被培養成元件。不過，在第一週，一行提示就夠了。今晚，試著只把一份週報輸出成 HTML。下週，試著在一個網格中排列六個提案選項。從那裡開始，格式稅就會悄悄開始減少。

Thariq 本人在文章結尾寫道：「我曾害怕停止深入閱讀 Markdown，並將所有判斷完全交給 Claude。自從改用 HTML 後，我覺得自己更像是重新與 Claude 一起參與其中，而且最重要的是，創作本身就很有趣。」

選擇格式是一個開關，讓你在與 AI 合作時重新掌握主動權，同時也是為日常工作帶來一點熱情的開關。

你會繼續產出沒人看的 Markdown，還是會轉向選擇格式的那一邊？接下來的一週將是分界線。

摘要

在 Anthropic 開發 Claude Code 的開發者宣布他不再使用 Markdown。HTML 的採用正在內部團隊中擴散。
直到現在，Markdown 一直是 AI 的隱含標準——從 Claude Code 和 Cursor 到 GitHub Copilot、Cline、內部 Wiki 和 ChatGPT 輸出。創作者現在挑戰了這個行業標準。
Markdown 不被閱讀的原因有 5 個：超過 100 行就無法重讀 / 分享時會壞掉 / 沒有顏色或圖表 / 無法觸摸來判斷 / 在手機上會壞掉。這些隱藏成本就是「格式稅」。
要切換，只需加一行：「輸出為 HTML 檔案。」將其變成技能可以等到使用習慣穩定之後。
5 個商業場景——週報、平行提案、設計調整、判斷畫面、PR 審查——只要切換到 HTML，就能轉變成會被打開、判斷和回覆的資料。
選擇格式是一個判斷，而不是一項任務。輸出 Markdown 是一項任務；選擇 HTML 是一個判斷。Claude Code 使用者的差異就在這裡顯現。

對於覺得這篇文章有幫助的人：