使用 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 時，我感覺比以往任何時候都更有參與感。希望你也能如此。