使用 Claude Code：HTML 令人難以置信的強大效能

Markdown 已成為 Agent 與我們溝通的主要檔案格式。它簡單、可攜帶、具備一些豐富文字功能，而且你很容易編輯。Claude 甚至已經相當擅長在 Markdown 檔案中使用 ASCII 來繪製圖表。

但隨著 Agent 變得越來越強大，我開始覺得 Markdown 成了一種受限的格式。我發現自己很難讀完超過一百行的 Markdown 檔案。我想要更豐富的視覺化、色彩和圖表，而且希望能夠輕鬆分享它們。

我也越來越不自己編輯這些檔案，而是把它們當作規格、參考文件、腦力激盪輸出等用途。當我真的需要編輯時，通常是請 Claude 來編輯，這反而消除了 Markdown 的一大優勢。

我開始偏好使用 HTML 作為輸出格式，而不是 Markdown，而且越來越常看到 Claude Code 團隊的其他成員也這麼做，原因如下。

（如果你想先看一些範例，這裡有一堆：https://thariqs.github.io/html-effectiveness，但記得回來繼續閱讀更多原因。）

為什麼是 HTML？

資訊密度

與 Markdown 相比，HTML 可以傳達更豐富的資訊。它當然可以處理簡單的文件結構，例如標題和格式，但它也能呈現各種其他資訊，例如：

使用表格呈現的表格資料
使用 CSS 呈現的設計資料
使用 SVG 呈現的插圖
使用 script 標籤呈現的程式碼片段
使用 HTML 元素搭配 JavaScript 和 CSS 呈現的互動
使用 SVG 和 HTML 呈現的工作流程
使用絕對定位和 Canvas 呈現的空間資料
使用圖片標籤呈現的圖片

我甚至敢說，幾乎沒有任何 Claude 能讀取的資訊，是無法用 HTML 有效呈現的。這使得它成為模型向你傳達深入資訊，以及讓你進行審查的高效方式。

我發現，如果無法做到這一點，模型可能會在 Markdown 中做一些效率較低的事情，例如 ASCII 圖表，或者我最喜歡的——用 Unicode 字元來表示顏色，就像這個來自 Claude Code 的截圖。

Claude Code 嘗試在 Markdown 中顯示顏色

視覺清晰度與易讀性

隨著 Claude 能夠處理更複雜的工作，它也會寫出越來越龐大的規格和計畫。實際上，我發現自己通常不會真正閱讀超過 100 行的 Markdown 檔案，而且我當然也無法讓我組織中的其他人去讀它。

但 HTML 文件更容易閱讀，Claude 可以在視覺上組織結構，使其非常適合透過分頁、插圖、連結等方式瀏覽。它甚至可以做到行動裝置響應式設計，讓你可以根據裝置形式以不同方式閱讀。

易於分享

Markdown 檔案相當難以分享，因為大多數瀏覽器無法很好地原生渲染它們。你通常必須將它們作為附件添加到電子郵件或訊息中。

使用 HTML，只要你上傳檔案（例如上傳到 S3），就可以輕鬆分享連結。你的同事可以在任何地方打開它，並輕鬆引用。

如果你的規格、報告或 PR 說明是以 HTML 呈現，那麼有人實際閱讀它的機率會高得多。

雙向互動

HTML 可以讓你與文件互動，例如，你可能想請它加入滑桿或旋鈕來調整設計，或者讓你能調整演算法中的不同選項，看看會發生什麼事。你也可以請它讓你把這些變更複製成提示詞，以便貼回 Claude Code。

閱讀更多關於我的遊樂場文章，以了解這種雙向互動的範例：https://x.com/trq212/status/2017024445244924382

資料攝取

為什麼要用 Claude Code 來製作 HTML 檔案，而不是用 ClaudeAI 或 Claude Design 呢？其中一個最大的原因是 Claude Code 能夠攝取大量上下文。

例如，在撰寫這篇文章時，我請 Claude Code 讀取我的程式碼資料夾，找出所有我產生的 HTML 檔案，將它們分組分類，然後製作一個包含所有代表每種類型圖表的 HTML 檔案。你在這篇文章中看到的圖表就是直接來自這個過程。

除了檔案系統之外，Claude Code 還可以使用你的 MCP（例如 Slack、Linear 等）、你的網頁瀏覽器（搭配 Chrome 中的 Claude）、你的 Git 歷史記錄等來尋找額外的上下文。

它充滿樂趣

用 Claude 製作 HTML 文件就是更有趣，讓我感覺更投入、更參與創作過程，而這本身就足夠了。

如何開始

我有點擔心人們讀完這篇文章後，會把它變成一個 /html 技能或類似的東西。雖然這可能有些價值，但我想強調的是，你不需要做太多事情就能讓 Claude 做到這一點。你只需要請它「製作一個 HTML 檔案」或「製作一個 HTML 成品」。

訣竅在於知道你想要這個成品做什麼，以及你可能如何使用它。隨著時間推移，你可能會建立一個技能，但現在我建議直接從頭開始提示，以掌握如何在不同的情況下使用它。

使用案例

為了更具體說明，我為不同的使用案例製作了許多不同的 HTML 檔案。你可以在這裡查看所有檔案：https://thariqs.github.io/html-effectiveness/，但以下是概述。

規格、規劃與探索

HTML 是一個豐富的畫布，讓 Claude 可以深入探討問題。當我開始處理一個問題時，我不會只做一個簡單的 Markdown 計畫，而是預期會建立一個 HTML 檔案網絡。例如，我可能會先請 Claude Code 進行腦力激盪，並建立一些探索不同選項的內容。然後我會請它進一步擴展其中一個選項，可能製作模型或程式碼片段。最後，當我感覺不錯時，我會請它撰寫一個實作計畫。當我對計畫滿意時，我會建立一個新的對話，並將所有這些檔案傳遞給它來實作。

在驗證時，我也會請驗證 Agent 讀取這些檔案，它將對所需內容有更廣泛的上下文。

範例提示詞：

我不確定入門畫面該朝哪個方向發展。請產生 6 種截然不同的方法——在佈局、語氣和密度上有所變化——並將它們以網格形式排列在一個 HTML 檔案中，這樣我就可以並排比較。為每個方法標註它所做的取捨。
在一個 HTML 檔案中建立一個詳盡的實作計畫，務必製作一些模型、展示資料流程，並加入我可能想審查的重要程式碼片段。讓它易於閱讀和理解。

使用案例：

探索在程式碼中實作某個功能的其他方法
探索多種視覺設計

程式碼審查與理解

在 Markdown 檔案中閱讀程式碼可能很困難。但使用 HTML，我們可以渲染差異、註解、流程圖、模組等。利用這個來理解 Agent 所寫的程式碼、進行程式碼審查，或向審查你 PR 的人解釋程式碼。我發現這通常比預設的 GitHub 差異檢視效果更好，而且我現在每個 PR 都會附上一個 HTML 程式碼說明。

範例提示詞：

請幫我審查這個 PR，建立一個描述它的 HTML 成品。我對串流/背壓邏輯不太熟悉，所以請專注在這部分。渲染實際的差異，並在邊緣加上行內註解，根據嚴重程度對發現的問題進行顏色編碼，以及任何其他有助於清楚傳達概念所需的內容。

使用案例：

建立 PR
審查 PR
理解程式碼中的某個主題

設計與原型

Claude Design 是基於 HTML，因為 HTML 在設計方面具有極高的表現力，即使你的最終介面不是 HTML。Claude 可以用 HTML 勾勒出設計草圖，然後用你選擇的語言（例如 React、Swift 等）來實作。

你也可以製作互動原型，例如動畫、動作等。考慮請 Claude 製作滑桿、旋鈕等，來微調你想要的確切效果。

範例提示詞：

我想製作一個新的結帳按鈕原型，點擊時會播放一個動畫，然後快速變成紫色。建立一個 HTML 檔案，包含幾個滑桿和選項，讓我可以嘗試這個動畫的不同設定，並給我一個複製按鈕，用來複製效果良好的參數。

用於：

建立設計系統成品
調整元件
視覺化元件庫
製作有趣的動畫原型

報告、研究與學習

Claude Code 非常擅長綜合來自多個資料來源的資訊，並將其轉換為易於閱讀的報告。你可以提示 Claude 搜尋你的 Slack、程式碼庫、Git 歷史記錄、網路等，並用它來為你自己、管理層、你的團隊等產生極易閱讀的報告。

你可以將這些資訊組裝成一份長篇 HTML 文件、一個互動式說明，甚至是一個投影片/簡報。請 Claude 使用 SVG 繪製圖表來幫助視覺化。

例如，在我關於提示快取的文章中，我請 Claude 在讀取 Git 歷史記錄後，準備一份關於我們所有提示快取變更的深入研究 HTML 檔案供我閱讀。

範例提示詞：

我不了解我們的速率限制器實際上是如何運作的。請閱讀相關程式碼，並產生一個單一的 HTML 說明頁面：一個權杖桶流程的圖表、3-4 個帶有註解的關鍵程式碼片段，以及底部一個「注意事項」區塊。針對只讀一次的人進行最佳化。

用於：

總結某個功能如何運作
向我解釋某個概念
向你的老闆提交每週狀態報告
向你的管理層提交事件報告
SVG 插圖、流程圖、技術圖表等

自訂編輯介面

有時很難單純在文字框中描述你想要的東西。在這種情況下，我會請 Claude 為我正在處理的特定內容建立一個一次性的編輯器。不是一個產品，也不是一個可重複使用的工具，而是一個單一的 HTML 檔案，專門為這一份資料量身打造。

訣竅總是以匯出功能結尾：一個「複製為 JSON」或「複製為提示詞」的按鈕，可以將我在 UI 中所做的任何操作轉換回可以貼到 Claude Code 中的內容。

範例提示詞：

我需要重新排列這 30 個 Linear 工單的優先順序。幫我做一個 HTML 檔案，將每個工單顯示為一個可拖曳的卡片，放在「現在 / 下一個 / 稍後 / 刪除」這幾個欄位中。根據你的最佳判斷預先排序。加入一個「複製為 Markdown」按鈕，匯出最終排序，並為每個區塊附上一行理由。
這是我們的功能開關設定。為它建立一個表單式編輯器，按區域分組開關，顯示它們之間的依賴關係，如果我啟用了一個其前置條件已關閉的開關，請警告我。加入一個「複製差異」按鈕，只輸出變更的鍵值。
我正在調整這個系統提示詞。建立一個並排編輯器：左側是可編輯的提示詞，變數插槽已標示出來；右側是三個範例輸入，會即時重新渲染填滿的模板。加入一個字元/權杖計數器和一個複製按鈕。

用於：

重新排序、分類或分組任何東西（工單、測試案例、回饋）
編輯結構化設定（功能開關、環境變數、帶有約束的 JSON/YAML）
調整提示詞、模板或文案，並即時預覽
策劃資料集、核准/拒絕行、標記範例、匯出選取內容
註解文件、逐字稿或差異，並匯出註解
選取難以用文字表達的值：顏色、緩動曲線、裁切區域、Cron 排程、正規表達式

常見問題

我已經告訴很多人我改用 HTML 了，而且我注意到一些重複出現的問題。

這不是會消耗更多權杖嗎？

雖然 Markdown 通常使用較少的權杖，但我發現 HTML 增加的表現力，以及我閱讀它的可能性大大提高，意味著我整體上獲得了更好的輸出。在 Opus 4.7 的 100 萬上下文視窗中，增加的權杖使用量在上下文視窗中並不明顯。

你現在什麼時候會用 Markdown？

老實說，我已經幾乎完全停止使用 Markdown 了，但我可能屬於 HTML 極大化主義者那一端。

我要如何檢視 HTML 檔案？

我通常會在瀏覽器中本地打開它（你可以請 Claude 打開它），或者如果你想獲得一個可分享的連結，就上傳到 S3。

這不是比產生 Markdown 花更長時間嗎？

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

那版本控制呢？

這老實說是 HTML 最大的缺點之一，與 Markdown 相比，HTML 的差異雜訊很多，難以審查。

我要如何讓 Claude 符合我的品味 / 不讓它變得很醜？

前端設計外掛有助於 Claude 製作出好看的 HTML 檔案。但要符合你自己公司的風格，你可以透過讓 Claude 指向你的程式碼庫，來建立一個單一的設計系統 HTML 檔案。然後你可以將這個設計系統檔案作為其他 HTML 檔案的參考。

保持參與感

以上所有內容都是為了說明，我認為我使用 HTML 的真正原因是，我覺得與 Claude 的參與感更強了。我曾經開始擔心，因為我不再深入閱讀計畫，所以我只能讓 Claude 自行做出選擇。

但我很高興地說，相反地，在使用 HTML 時，我感覺比以往任何時候都更有參與感。希望你也能如此。

為什麼是 HTML？