HTML 的輪迴：這次不是讓你寫，而是幫你更好的閲讀與理解
整理版優先睇
用HTML輸出代替Markdown，令你真正參與AI協作，而唔係等結果
呢篇文章係Anthropic嘅Claude Code工程師Thariq寫嘅，佢發現自己同團隊成日唔會認真讀超過100行嘅Markdown文件，即使係AI生成嘅規劃同報告。呢個問題令佢反思：AI輸出再高質，如果人唔消化，就等於冇發生過。佢嘅解決方案係叫Claude Code直接生成HTML文件，而唔係Markdown。
HTML有更高嘅資訊密度，可以做表格、SVG圖表、交互按鈕，而且可以直接開瀏覽器睇，share連結俾同事。佢列咗好多場景，由需求規劃到代碼Review，由設計原型到內部報告，核心都係同一個：令輸出更加可讀、可審查、可討論。佢甚至話自己而家比以前任何時候都覺得自己喺個迴路入面。
所以呢篇文章嘅核心論點係：AI時代嘅核心能力唔係寫格式，而係做選擇方向、定規則、讀輸出、做判斷嗰個人。HTML只係一個手段，真正重要嘅係保持參與，唔好變咗喺迴路終點等結果。
- 結論：用HTML輸出可以大幅提高AI成果嘅可讀性同分享性，令用家真正參與協作。
- 方法：直接要求Claude Code「做一個HTML文件」或「做一個HTML artifact」，而唔係用Markdown。
- 差異：HTML比Markdown有更高資訊密度，可包含表格、圖表、交互、顏色等，而且易於分享連結。
- 啟發：核心問題唔係格式，而係人有冇喺迴路中做判斷；AI越強，人越要主動消化輸出。
- 可行動點：由聽日開始，試嚇叫Claude Code用HTML輸出規劃、報告或code review，睇嚇自己會唔會更願意閲讀同討論。
HTML Effectiveness 示例頁面
Thariq 製作嘅HTML使用場景示例集合，包括規範、代碼審查、設計、報告等
由Markdown到HTML嘅轉變原因
Thariq 發現自己同團隊成日唔會認真讀超過100行嘅Markdown文件，即使係Claude Code生成嘅規劃。佢話：「我發現閲讀超過一百行的Markdown文件很困難。」呢個問題令佢開始揾替代方案。
Markdown已經變得冇人真正會讀
佢想要更豐富嘅可視化、顏色、圖表，而且想輕鬆分享。於是佢開始叫Claude Code輸出HTML，發現效果好好。
HTML嘅五大優勢
- 1 資訊密度：HTML可以做到表格、CSS設計、SVG插圖、script代碼、交互、工作流、空間數據、圖像等。
- 2 視覺清晰度：HTML文件更容易閲讀，Claude可以對結構做視覺組織，適合用標籤頁、插圖、連結導航。
- 3 易於分享：上傳HTML去S3就可以share連結，同事喺瀏覽器直接睇，毋須額外操作。
- 4 雙向交互：可以加滑塊、旋鈕調整設計，或者將更改複製成prompt貼返入Claude Code。
- 5 數據提取：Claude Code可以讀取文件系統、MCPs、web瀏覽器、git history等上下文，整合成HTML報告。
實際使用場景
- 規範、規劃與探索：叫Claude Code brainstorm，製作HTML文件網絡，再擴展其中一個選項，最後制定實施計劃。
- 代碼審查與理解：用HTML渲染diff、註釋、流程圖，PR附帶HTML代碼解釋器。
- 設計與原型：用HTML草擬設計，加滑塊、旋鈕調校效果。
- 報告、研究與學習：整合多個數據源，生成可讀報告，加入SVG圖表。
- 自定義編輯界面：為特定任務製作一次性編輯器，例如拖拽排序tickets、表單編輯config。
示例提示：
「幫我 review 呢個 PR，通過創建一個描述佢嘅HTML artifact。我唔係好熟悉 streaming/backpressure 邏輯，所以請將重點放喺度。用內聯邊緣 annotations 渲染實際嘅 diff，按嚴重程度對發現嘅問題進行顏色編碼。」保持喺迴路入面
Thariq 話：「我之前開始擔心，因為我已經停止深入閲讀計劃了，我只能放任Claude去自己做決定。但我好開心咁話，使用HTML時，我比以往任何時候都更喺迴路入面。」
核心唔係格式，而係你係咪做緊選方向、定規則、讀輸出、做判斷嗰個人
呢篇文章提醒我哋：AI越嚟越強，但如果人只係等結果，唔參與審查，咁只係外包，唔係協作。HTML只係一種工具，真正重要嘅係保持主動，消化AI嘅輸出。
記得啱啱接觸互聯網嘅時候，求咗父母好耐先買咗一本 Dreamweaver 嘅書，日日坐喺書桌前面死啃，唔分日夜。
嗰陣時覺得呢本書就好似一本聖經咁。
因為佢可以幫你由零開始快趣咁整出一個網頁，甚至砌出一個完整嘅網站。
後尾熟咗 HTML 同 CSS 嘅規範同邏輯之後，我就開始嘗試甩咗 Dreamweaver，直接喺 TXT 檔案入面裸寫。雖然開始難，但嗰個方法的確係可以令你快趣理解同掌握一門語言嘅最快方式。
好奇怪，上面呢段記憶係喺我睇完 Anthropic 嘅 Claude Code 工程師 Thariq 寫嘅呢篇文章《Using Claude Code: The Unreasonable Effectiveness of HTML》之後突然彈出嚟嘅。
呢篇文章冇諗到會咁爆，可能係觸發到好多人嘅真實感受，文章出咗之後閲讀量達到咗 564 萬，轉發接近 2200 次。由國外火到國內，呢兩日相信你刷到嘅關於佢嘅文章或者討論應該唔少。
我睇完原文之後，腦入面第一個反應就係：
編程圈有啲似時尚界，有輪迴。
HTML 曾經係互聯網嘅起點，後來被 React、被各種框架、被工具鏈層層封裝，普通人越來越唔需要直接面對佢。但係而家佢又返咗嚟，重新出現喺一個頂級工程師嘅日常工作流程入面。
但係仔細諗嚇，我覺得今次都係有啲唔同。
上次 HTML 流行、大行其道嘅時候，係因為你要寫。你要識語法，要知道標籤點樣嵌套，要記住屬性名。嗰陣時識寫 HTML 係一種門檻，你要過咗呢道門檻先可以參與落去。
但係今次呢？
Thariq 話佢根本唔自己寫，佢都係叫 Claude Code 寫，佢最後負責讀。
但你有冇發現，同樣係 HTML，同樣係呢個格式，但係人喺呢件事入面嘅位置已經完全唔同咗。
以前寫係門檻，而家讀係能力。
以前你要識點樣生產，而家你只需要知道點樣要求同判斷。
呢個轉變背後其實藏住一個更加值得傾嘅問題。
過去呢一兩年，大家討論 AI 最多嘅話題係佢可唔可以更加智能咁幫用戶做好一件事，佢夠唔夠聰明，夠唔夠準確。係咪？
但有一件事大家從來冇提過，就係：**AI 做曬，你到底有冇認真睇佢幫你輸出嘅嘢？
Thariq 喺文章入面有一句話令我印象好深。佢話：「佢發現自己基本上唔會認真讀超過 100 行嘅 Markdown 文件」。
注意，講呢句話嘅人唔係一個普通用戶，而係 Claude Code 團隊內部嘅技術工程師。佢比任何人都更加熟悉呢個工具，但佢都冇避開呢個問題。
AI 寫咗大量嘅規劃、方案、文檔，但人喺實際使用入面，根本冇消化呢啲輸出。
呢個先係佢換格式嘅真正動機。
唔係因為 HTML 更加「先進」，亦都唔係因為 Markdown 技術上有咩「缺陷」，而係因為佢發現 Markdown 已經喺實際工作入面變成一個冇人真正會讀嘅格式。
所以佢開始叫 Claude Code 輸出 HTML 檔案。
HTML 可以做表格、可以加顏色、可以畫 SVG 圖表、可以加互動按鈕，可以直接上傳到伺服器，然後將連結 send 俾同事，對方開瀏覽器就睇到，唔使任何額外操作。
呢啲能力夾埋解決嘅其實係同一件事：點樣令人願意讀、讀得入、讀完之後仲可以討論同推進決策。
佢喺文章入面列舉咗好多具體場景，由需求規劃到 Code Review，由設計原型到內部報告，每個場景嘅核心邏輯都係一樣嘅：
AI 嘅輸出質量再高，如果冇人消化佢，就等於冇發生過。
文章嘅最後一句話，係佢成篇文章入面我覺得最重要嘅一句話，但係寫關於呢篇文章嘅人幾乎冇人傾到佢。
佢話：「佢而家比以前任何時候都更加覺得自己喺迴路入面"。
」呢句話好值得回味，值得停低諗一諗。
AI 越來越強，越來越自主，佢可以寫規劃、可以改 Code、可以生成報告、可以整合多個數據源。
但人如果根本唔讀規劃、唔參與審查、唔理解 AI 做咗咩或者輸出咗咩，就一味係等結果，跟住繼續落去。
咁呢個只係外判，唔係協作。
喺呢種狀態下，你其實已經唔喺迴路入面，你只係喺迴路嘅終點等接收一個你判斷唔到好壞嘅輸出。
Thariq 換成 HTML 呢件事，喺我睇嚟唔止係一個格式上嘅偏好選擇，而係佢主動將自己重新拉返入迴路嘅一種方式。
因為 HTML 令輸出變得可讀、可審查、可以轉發俾同事一齊討論同共同決策，亦都代表令人可以真正參與落去，而唔係淨係喺輸入框打一句話然後等結果。
其實講到尾 MD 同 HTML 之間邊個重要啲邊個唔重要，根本就冇呢個問題。
Markdown 似係元數據，可以轉成 PDF，可以轉成 HTML，亦都可以轉成任何你需要嘅形式，本身冇錯。
問題從來唔係你用咩格式，而係你有冇喺成個過程入面做嗰個揀方向、定規則、讀輸出、做判斷嘅人。
呢個先係 AI 時代普通人真正需要掌握嘅核心能力。
無論語言點樣輪迴、格式點樣轉變、工具點樣迭代，都唔會被取代。
原文譯，作者 Thariq
使用 Claude Code：HTML 不可思議嘅有效性
Markdown 已經成為 agents 同我哋溝通時使用嘅主要文件格式。佢簡單、便攜，有一定嘅 rich text（富文本）能力，而且易於你做編輯。Claude 甚至喺用 ASCII 喺 Markdown 文件入面製作圖表方面變得異常咁叻。
但隨住 agents 變得越來越強大，我感覺到 Markdown 已經成為一種受限嘅格式。我發現閲讀超過一百行嘅 Markdown 文件好睏難。我想要更加豐富嘅 visualizations（可視化）、顏色同圖表，而且我希望可以輕鬆咁分享佢哋。
我都越來越少自己編輯呢啲文件，反而將佢哋用作 specs（規範）、參考文件、腦力激盪輸出等等。當我真係需要做編輯嘅時候，我通常會 prompt（提示）Claude 幫手編輯，呢個消除咗 Markdown 最大嘅優勢之一。
我開始傾向於用 HTML 做輸出格式而唔係 Markdown，而且越來越常見到 Claude Code 團隊嘅其他人都在用，原因如下。
如果你想你由一啲例子開始，你可以喺呢度睇到好多：
https://thariqs.github.io/html-effectiveness
不過請記得返嚟睇多啲關於點解要咁做嘅原因。
點解揀 HTML？
資訊密度
同 Markdown 相比，HTML 可以傳達豐富得多嘅資訊。佢當然可以處理簡單嘅文檔結構（例如 headers 同格式化），但佢仲可以表示各種其他資訊，例如：
使用 tables（表格）嘅 tabular data（表格數據） 使用 CSS 嘅設計數據 使用 SVG 嘅插圖 使用 script tags 嘅 code snippets（代碼片段） 使用 HTML 元素結合 javascript + CSS 嘅互動 使用 SVG 同 HTML 嘅 workflows（工作流程） 使用絕對定位同 canvases（畫布）嘅空間數據 使用 image tags（圖像標籤）嘅圖像
我發現，喺做唔到嘅情況下，model 可能會喺 Markdown 入面執行更低效率嘅操作，例如 ASCII 圖表，或者我最鍾意嘅——用 unicode 字符嚟估算顏色，好似呢張來自 Claude Code 嘅截圖咁。
Claude Code 試圖喺 Markdown 入面顯示顏色
視覺清晰度同閲讀便捷性
隨住 Claude 能夠處理更加複雜嘅工作，佢都在編寫越來越大份嘅 specs（規範）同計劃。實際上，我發現自己往往唔會去讀超過 100 行嘅 Markdown 文件，而且我肯定冇辦法令我組織嘅其他人去讀佢。
但 HTML 文檔更加容易閲讀，Claude 可以對結構進行視覺上嘅組織，令佢非常適合透過 tabs（標籤頁）、插圖、連結等等進行導航。佢甚至可以係 mobile responsive（流動裝置響應式）嘅，所以你可以根據你嘅裝置型態以唔同嘅方式閲讀佢。
容易分享
Markdown 文件好難分享，因為大多數瀏覽器冇辦法原生咁好咁渲染佢哋。你通常要將佢哋當作附件加到電郵或者訊息入面。
用 HTML，只要你上傳咗個檔案（例如上傳到 S3），你就可以輕鬆分享連結。你嘅同事可以喺佢哋想嘅任何地方打開佢，而且輕鬆咁 reference（引用）佢。
如果用 HTML，有人真正閲讀你嘅 spec、報告或者 PR writeup（拉取請求說明）嘅機會會高好多。
雙向互動
HTML 容許你同文檔互動，例如，你可能想叫佢加 sliders（滑塊）或者 knobs（旋鈕）嚟調整設計，或者容許你喺算法入面微調唔同嘅選項嚟睇嚇會發生咩事。你仲可以叫佢令你可以將呢啲更改複製成一個 prompt，貼返入 Claude Code 度。睇嚇我關於 playgrounds 嘅帖子，睇嚇呢種雙向互動嘅例子：
https://x.com/trq212/status/2017024445244924382
數據提取
點解要用 Claude Code 嚟製作 HTML 檔案，而唔係例如 ClaudeAI 或者 Claude Design？最大嘅原因之一係 Claude Code 可以 ingest（提取）所有嘅 context（上下文）。例如，喺寫緊呢篇文章嘅時候，我叫 Claude Code 讀取我嘅代碼文件夾，揾曬我生成嘅所有 HTML 檔案，將佢哋分組同分類，然後製作一個包含代表每種類型嘅圖表嘅 HTML 檔案。你喺呢篇文章見到嘅圖表就係嗰個操作嘅直接結果。
除咗文件系統之外，Claude Code 仲可以用你嘅 MCPs（例如 Slack、Linear 等）、你嘅網頁瀏覽器（透過 Chrome 嘅 Claude）、你嘅 git history 等嚟揾額外嘅 context。
令人愉快
用 Claude 製作 HTML 文檔就係更加好玩，令我覺得更加投入同參與創作，單係呢點已經好足夠。
點樣開始
我有啲擔心人哋睇完呢篇文章之後，會將佢變成一個 /html skill（技能）或者類似嘅嘢。雖然呢個可能有一啲價值，但我想強調嘅係，你唔需要做太多嘢就可以令 Claude 做到呢件事。你只需要叫佢「製作一個 HTML 檔案（make a HTML file）」或者「製作一個 HTML artifact」。
竅門在於你知道你希望呢個 artifact 做啲咩以及你可能會點樣用佢。隨住時間推移，你可能會創建一個 skill，但係而家，我建議直接由頭開始 prompting，以掌握喺唔同 cases 底下點樣用佢。
使用場景
為咗令呢件事更加具體，我為唔同嘅 use cases 製作咗好多個唔同嘅 HTML 檔案。你可以喺呢度睇曬佢哋：
https://thariqs.github.io/html-effectiveness/
但以下係一個概述。
規範、規劃與探索
對於 Claude 嚟講，HTML 係一個用嚟深入研究問題嘅豐富畫布。當我開始處理一個問題嘅時候，我期望嘅唔係一個簡單嘅 Markdown 計劃，而係製作一個 HTML 檔案嘅網絡。例如，我可能會先叫 Claude Code 進行 brainstorm（腦力激盪）同創建針對唔同選項嘅一啲探索。然後，我會叫佢進一步擴展其中一個選項，可能製作 mockups（視覺稿）或者 code snippets。最後，當我覺得感覺唔錯嘅時候，我會叫佢編寫一個實施計劃。如果我對計劃滿意，我會創建一個新嘅 session（會話）並將所有呢啲檔案傳入令佢執行。
喺做驗證嘅時候，我都會叫驗證 agent 讀取呢啲檔案，咁樣佢就可以對所需內容有更廣泛嘅 context。
示例提示：
我唔確定 onboarding screen（引導界面）應該採取邊個方向。生成 6 種截然不同嘅方法——喺佈局、基調同密度上做變化——並將佢哋作為一個單獨嘅 HTML 檔案排列喺一個 grid（網格）入面，令我可以並排比較佢哋。為每一個標註佢哋所作嘅取捨。 喺 HTML 檔案入面創建一個詳盡嘅實施計劃，請一定要製作一啲 mockups，展示 data flow（數據流），並添加我可能會想 review 嘅重要 code snippets。令佢容易閲讀同消化。
探索喺代碼入面實現某項功能嘅其他方式 探索多種視覺設計
代碼審查與理解
喺 Markdown 檔案入面閲讀代碼可能好睏難。但係用 HTML，我哋可以渲染 diffs（差異）、annotations（註釋）、flowcharts（流程圖）、模塊等。你可以利用呢一點嚟理解 agent 編寫嘅代碼，獲取 code review，或者向審查你代碼嘅人解釋一個 PR。我發現呢個通常比預設嘅 Github diff 視圖效果更加好，我而家為我提交嘅每個 PR 都會附帶一個 HTML 代碼解釋器。
示例提示：
幫我 review 呢個 PR，通過創建一個描述佢嘅 HTML artifact。我唔係好熟 streaming/backpressure（流式/背壓）邏輯，所以請將重點放喺嗰度。用內聯邊緣 annotations 渲染實際嘅 diff，按嚴重程度對發現嘅問題進行 color-code（顏色編碼），以及用其他任何可能有助於好好傳達概念嘅方法。
使用場景：
創建一個 PR Review 一個 PR 理解 Code（代碼）入面嘅某個主題
設計與原型
Claude Design 係基於 HTML 嘅，因為 HTML 喺設計上好有表現力，就算你最終嘅展現層唔係 HTML。Claude 可以用 HTML 草擬一個設計，然後用你揀嘅語言（無論係 React、Swift 等）將佢編寫出嚟。
你仲可以 prototype（製作原型）互動操作，例如動畫、動作等。考慮叫 Claude 製作 sliders、knobs 等，用嚟精確校準你正在揾嘅效果。
示例提示：
我想 prototype 一個新嘅 checkout 按鈕，撳落去嘅時候佢會播放動畫然後快趣變成紫色。創建一個包含幾個 sliders 同選項嘅 HTML 檔案，令我可以喺呢個動畫上面試唔同嘅選項，並俾我一個複製按鈕用嚟複製嗰啲效果唔錯嘅參數。
將佢用於：
創建 design system（設計系統）artifacts 調整組件 可視化組件庫 Prototyping（原型設計）令人愉快嘅動畫
Claude Code 喺整合多個數據源嘅資訊並將佢哋轉化為具有良好可讀性嘅報告方面非常出色。你可以 prompt Claude 搜索你嘅 Slack、你嘅 codebase（代碼庫）、git history、互聯網等，並利用佢為你自己、為領導層、為你嘅團隊等生成極具可讀性嘅報告。
你可以將佢哋組合成長篇 HTML 文檔、互動式解釋器，甚至係 slideshow/deck（幻燈片/演示文稿）嘅形式。叫 Claude 用 SVG 製作圖表以幫助將佢可視化。例如，對於我關於 prompt caching 嘅文章，喺閲讀 git history 之後，我叫 Claude 準備一份 HTML 格式嘅深入研究文件，俾我閲讀有關我哋對 prompt caching 所做嘅所有更改。
示例提示：
我唔理解我哋嘅 rate limiter（限流器）究竟係點樣運作。請閲讀相關代碼並生成一個單獨嘅 HTML 解釋頁面：一個 token-bucket（令牌桶）流程嘅圖表，附帶 annotations 嘅 3-4 個關鍵 code snippets，並喺底部包含一個「gotchas（避坑指南）」部分。針對只讀一次嘅讀者對其進行優化。
將佢用於：
總結一個特性嘅運作原理 向我解釋一個概念 俾你老細嘅每週 status reports（進度報告） 俾領導層嘅 Incident reports（事故報告） SVG 插圖、flowcharts、技術圖表等
自定義編輯界面
有時，純粹用一個文本框好難描述你想要咩。喺呢種情況下，我會叫 Claude 為我正在處理嘅具體事項構建一個 throwaway（一次性）編輯器。唔係一個產品，亦唔係一個可重用嘅工具，而係一個為呢份數據度身訂造嘅、單一嘅 HTML 檔案。
其中嘅竅門係始終以一種導出嚟結尾：一個「作為 JSON 複製」或者「作為 prompt 複製」嘅按鈕，將我喺 UI 所做嘅一切轉換返做我可以貼入 Claude Code 嘅內容。
示例提示：
我需要重新確定呢 30 個 Linear tickets 嘅優先次序。俾我製作一個 HTML 檔案，將每個 ticket 作為一個 draggable card（可拖拽卡片），分佈喺 Now / Next / Later / Cut 幾列入面。根據你嘅最佳猜測對佢哋進行預先排序。添加一個「作為 Markdown 複製」嘅按鈕，導出最終嘅排序，並為每個 bucket 提供一行理由。 呢個係我哋嘅 feature flag config（特性開關配置）。為佢構建一個基於表單嘅編輯器，按區域對 flags 進行分組，顯示佢哋之間嘅依賴關係，如果我啓用咗一個其先決條件已關閉嘅 flag，請警告我。添加一個「複製 diff」按鈕，只俾我發生咗更改嘅 keys。 我正在調優呢個 system prompt。製作一個 side-by-side（並排）編輯器：左側為可編輯嘅 prompt，高亮顯示 variable slots（變量槽位），右側為三個 sample inputs（樣本輸入），實時重新渲染填好嘅模板。添加一個 character/token（字符/令牌）計數器同一個複製按鈕。
將佢用於：
重新排序、分類（triaging）或分組（bucketing）任何嘢（tickets、test cases、反饋） 編輯結構化 config（帶有約束嘅 feature flags、env vars、JSON/YAML） 透過 live preview（實時預覽）調優 prompts、模板或文案 整理 datasets，批准/拒絕數據行，為例子打標籤（tag），導出選中內容 註釋文檔、transcript 或 diff，並導出 annotations（註釋） 挑選喺文本入面難以表達嘅值：顏色、easing curves（緩動曲線）、crop regions（裁剪區域）、cron schedules（定時任務計劃）、regexes（正則表達式）。
常見問題解答
我一直同好多人講我係點樣切換到 HTML 嘅，我都見到一啲反覆出現嘅問題。
呢個難道唔係更加缺乏 token 效率嗎？
雖然 Markdown 通常用少啲 tokens，但我發現 HTML 增加嘅表現力同我閲讀佢嘅極高可能性意味住我總體上得到更好嘅輸出。靠住 Opus 4.7 中 1MM 嘅 context window（上下文窗口），增加嘅 token 用量喺上下文入面唔明顯。
你而家咩時候會用 Markdown？
老實講，對於幾乎所有嘢，我已經完全停止用 Markdown 喇，但我可能好大程度上係一個 HTML 最大主義者。
我應該點樣睇 HTML 檔案？
我傾向於直接喺本地瀏覽器打開佢（你可以叫 Claude 打開佢），或者如果你想要一個可分享嘅連結，可以上傳到 S3。
呢個生成起上嚟係咪比 Markdown 更加耗時？
的確係耗時啲！HTML 嘅耗時可能比 Markdown 長 2-4 倍，但我覺得結果係值得嘅。
咁版本控制點算？
老實講，呢個係 HTML 最大嘅缺點之一，同 Markdown 相比，HTML 嘅 diffs 好雜亂而且難啲 review。
我點樣令 Claude 符合我嘅品味 / 唔好整得咁樣衰？
前端設計 plugin（插件）有助於 Claude 製作高質量嘅 HTML 檔案。但係為咗符合你自己公司嘅風格，你可以透過將 Claude 指向你嘅 codebase 嚟創建一個單獨嘅 design system（設計系統）HTML 檔案。然後，你可以將嗰個 design system 檔案用作其他 html 檔案嘅 reference（參考）。
保持參與
總括嚟講，我認為我用 HTML 嘅真正原因係，我覺得同 Claude 嘅互動更加 in the loop（保持喺循環/參與狀態）。我先前開始擔心，因為我已經停止深入閲讀計劃，我只能夠放任 Claude 自己去作決定。
但我好開心咁話，喺用 HTML 嘅時候，我比以往任何時候都更加覺得自己 in the loop。我希望你都係咁。
既然睇到呢度，如果覺得都仲唔錯，幫手順手㩒個「讚」、「睇緊」、「轉發」三連；如果想第一時間收到推送，都可以幫我加個星標★，非常多謝！
記得剛接觸互聯網的時候，求着父母給我買了一本 Dreamweaver 的書，天天坐在書桌前死啃，不分白天黑夜。
那時候覺得這本書就像一本聖經。
因為它能幫你從零快速創建出一個網頁，甚至搭建出一個完整的網站。
後來熟悉了 HTML 和 CSS 的規範與邏輯後，我開始試圖甩掉 Dreamweaver，直接在 TXT 文本文件裏裸寫。雖然開始很難，但那確實是能讓你快速理解並掌握一門語言的最快方式。
很奇怪，上面這段記憶是在我看完 Anthropic 的 Claude Code 工程師 Thariq 寫的這篇文章《Using Claude Code: The Unreasonable Effectiveness of HTML》之後突然冒出來的。
這篇文章沒想到能火成這樣，也許是觸發到了很多人的真實感悟，文章發出來之後閲讀量達到了 564 萬，轉發將近 2200 次。從國外火到國內，這兩天相信你刷到的關於它的文章或者討論應該不少。
我把原文看完之後，腦子裏第一個反應就是：
編程圈有點兒像時尚界，有輪迴。
HTML 曾經是互聯網的起點，後來被 React、被各種框架、被工具鏈層層封裝，普通人越來越不需要直接面對它。但現在它又回來了，重新出現在一個頂級工程師的日常工作流裏。
但仔細想了一下，我覺得這次還是有些不一樣。
上一次 HTML 流行，大行其道的時候，是因為你要寫。你得懂語法，得知道標籤怎麼嵌套，得記住屬性名。那時候能寫 HTML 是一種門檻兒，你得過了這道檻兒才能參與進來。
但這一次呢？
Thariq 說他根本不自己寫，他也是讓 Claude Code 寫，他最後來讀。
但你有沒有發現，同樣是 HTML，同樣是這個格式，但人在這件事兒裏的位置已經完全不同了。
以前寫是門檻，現在讀是能力。
以前你要懂怎麼生產，現在你只需要知道怎麼要求和判斷。
這個轉變背後其實藏着一個更值得聊的問題。
過去這一兩年，大家討論 AI 最多的話題是它能不能更智能的幫用戶做好一件事兒，它夠不夠聰明，夠不夠準確。對吧？
但有一件事兒大家從來沒有提過，就是：**AI 做完了，你到底有沒有認真看它幫你輸出的東西？
Thariq 在文章裏有一句話讓我印象很深。他說："他發現自己基本不會認真讀超過 100 行的 Markdown 文件"。
注意，說這話人的不是一個隨隨便便的普通用戶，而是 Claude Code 團隊內部的技術工程師。他比任何人都更熟悉這個工具，但他也沒能逃過這個問題。
AI 寫了大量的規劃、方案、文檔，但人在實際使用中，根本沒有消化這些輸出。
這才是他換格式的真正動機。
不是因為 HTML 更「先進」，也不是因為 Markdown 技術上有什麼「缺陷」，而是因為他發現 Markdown 已經在實際工作中變成了一個沒人真正讀的格式。
所以他開始讓 Claude Code 輸出 HTML 文件。
HTML 可以做表格、可以加顏色、可以畫 SVG 圖表、可以加交互按鈕，可以直接上傳到服務端，然後把連結發給同事，對方打開瀏覽器就能看，不需要任何額外操作。
這些能力合在一起解決的其實是同一件事兒：怎麼讓人願意讀、讀得進去、讀完之後還能討論和推進決策。
他在文章裏列舉了很多具體場景，從需求規劃到代碼 Review，從設計原型到內部報告，每一個場景的核心邏輯都是一樣的：
AI 的輸出質量再高，如果沒有人消化它，就等於沒有發生。
文章的最後一句話，是他整篇文章裏我覺得最重要的一句話，但寫關於這篇文章的人幾乎沒有人聊到它。
他說："他現在比以前任何時候都更覺得自己在迴路裏"。
這句話很值得回味，值得停下來思考一下。
AI 越來越強，越來越自主，它能寫規劃、能改代碼、能生成報告、能整合多個數據源。
但人如果根本不讀規劃、不參與審查、不理解 AI 做了什麼或者輸出了什麼，就只是一味地在等結果，然後繼續往下。
那這只是外包，並非協作。
在這種狀態下，你其實已經不在迴路裏了，你只是在迴路的終點等着接收一個你無法判斷好壞的輸出。
Thariq 換成 HTML 這件事，在我看來不只是一個格式上的偏好選擇，而是他主動把自己重新拉回迴路的一種方式。
因為 HTML 讓輸出變得可讀、可審查、可以轉發給同事一起討論與共同決策，也就意味着讓人可以真正的參與進來，而不只是在輸入框裏打一句話然後等結果。
其實說到底 MD 和 HTML 之間沒有什麼誰更重要誰不重要的問題。
Markdown 更像是元數據，它可以轉成 PDF，可以轉成 HTML，也可以轉成任何你需要的形式，本身並沒有錯。
問題從來不是你用什麼格式，而是你有沒有在整個過程裏做那個選方向、定規則、讀輸出、做判斷的人。
這才是 AI 時代普通人真正需要掌握的核心能力。
不管語言怎麼輪迴、格式怎麼轉變、工具怎麼迭代，都不會被替代掉。
原文譯，作者 Thariq
使用 Claude Code：HTML 不可思議的有效性
Markdown 已經成為 agents 與我們交流時使用的主要文件格式。它簡單、便攜，具有一定的 rich text（富文本）能力，並且易於你進行編輯。Claude 甚至在使用 ASCII 在 Markdown 文件中製作圖表方面變得出奇地優秀。
但隨着 agents 變得越來越強大，我感覺 Markdown 已經成為一種受限的格式。我發現閲讀超過一百行的 Markdown 文件很困難。我想要更豐富的 visualizations（可視化）、顏色和圖表，並且我希望能輕鬆地分享它們。
我也越來越少自己去編輯這些文件，而是將它們用作 specs（規範）、參考文件、頭腦風暴輸出等。當我確實需要進行編輯時，我通常會 prompt（提示）Claude 來編輯它們，這消除了 Markdown 最大的優勢之一。
我開始傾向於使用 HTML 作為輸出格式而不是 Markdown，並且越來越頻繁地看到 Claude Code 團隊的其他人也在使用它，原因如下。
如果你想從一些例子開始，你可以在這裏看到很多：
https://thariqs.github.io/html-effectiveness
只是請務必回來閲讀更多關於為什麼這樣做的原因。
為什麼選擇 HTML？
信息密度
與 Markdown 相比，HTML 可以傳達豐富得多的信息。它當然可以處理簡單的文檔結構（如 headers 和格式化），但它還可以表示各種其他信息，例如：
使用 tables（表格）的 tabular data（表格數據） 使用 CSS 的設計數據 使用 SVG 的插圖 使用 script tags 的 code snippets（代碼片段） 使用 HTML 元素結合 javascript + CSS 的交互 使用 SVG 和 HTML 的 workflows（工作流） 使用絕對定位和 canvases（畫布）的空間數據 使用 image tags（圖像標籤）的圖像
我發現，在無法做到這一點的情況下，model 可能會在 Markdown 中執行更低效的操作，比如 ASCII 圖表，或者我最喜歡的——使用 unicode 字符來估算顏色，就像這張來自 Claude Code 的截圖一樣。
Claude Code 試圖在 Markdown 中顯示顏色
視覺清晰度與閲讀便捷性
隨着 Claude 能夠處理更復雜的工作，它也在編寫越來越龐大的 specs（規範）和計劃。在實踐中，我發現自己實際上往往不會去讀超過 100 行的 Markdown 文件，而且我肯定也沒辦法讓我組織裏的其他人去讀它。
但 HTML 文檔更容易閲讀，Claude 可以對結構進行視覺上的組織，使其非常適合通過 tabs（標籤頁）、插圖、連結等進行導航。它甚至可以是 mobile responsive（移動端響應式）的，因此你可以根據你的設備形態以不同的方式閲讀它。
易於分享
Markdown 文件很難分享，因為大多數瀏覽器無法原生很好地渲染它們。你通常不得不將它們作為附件添加到電子郵件或消息中。
使用 HTML，只要你上傳該文件（例如上傳到 S3），你就可以輕鬆分享連結。你的同事可以在他們希望的任何地方打開它，並輕鬆地 reference（引用）它。
如果使用 HTML，有人真正閲讀你的 spec、報告或 PR writeup（拉取請求說明）的幾率要高得多。
雙向交互
HTML 允許你與文檔進行交互，例如，你可能想讓它添加 sliders（滑塊）或 knobs（旋鈕）來調整設計，或者允許你在算法中微調不同的選項以查看會發生什麼。你還可以要求它讓你將這些更改複製成一個 prompt，以便粘貼回 Claude Code 中。閲讀我關於 playgrounds 的帖子，查看這種雙向交互的示例：
https://x.com/trq212/status/2017024445244924382
數據提取
為什麼使用 Claude Code 來製作 HTML 文件，而不是例如 ClaudeAI 或 Claude Design？最大的原因之一是 Claude Code 可以 ingest（提取/攝取）所有的 context（上下文）。例如，在撰寫本文時，我要求 Claude Code 讀取我的代碼文件夾，找到我生成的所有 HTML 文件，對它們進行分組和分類，然後製作一個包含代表每種類型的圖表的 HTML 文件。你在本文中看到的圖表就是該操作的直接結果。
除了文件系統之外，Claude Code 還可以使用你的 MCPs（如 Slack、Linear 等）、你的 web 瀏覽器（通過 Chrome 中的 Claude）、你的 git history 等來查找額外的 context。
令人愉悦
使用 Claude 製作 HTML 文檔就是更有趣，讓我感覺更多地參與和投入到創作中，單憑這一點就足夠了。
如何開始
我有點擔心人們讀了這篇文章後，會把它變成一個 /html skill（技能）或類似的東西。雖然這可能有一些價值，但我想強調的是，你不需要做太多事情就能讓 Claude 做到這一點。你只需要要求它“製作一個 HTML 文件（make a HTML file）”或“製作一個 HTML artifact”。
訣竅在於知道你希望這個 artifact 做什麼以及你可能會如何使用它。隨着時間的推移，你可能會創建一個 skill，但就目前而言，我建議直接從頭開始 prompting，以掌握在不同 cases 下如何使用它。
使用場景
為了讓這更具體，我為不同的 use cases 製作了許多不同的 HTML 文件。你可以在這裏查看所有這些文件：
https://thariqs.github.io/html-effectiveness/
但以下是一個概述。
規範、規劃與探索
對於 Claude 來說，HTML 是一個用來深入研究問題的豐富畫布。當我開始處理一個問題時，我期望的不是一個簡單的 Markdown 計劃，而是製作一個 HTML 文件的網絡。例如，我可能會先要求 Claude Code 進行 brainstorm（頭腦風暴）並創建針對不同選項的一些探索。然後，我會要求它進一步擴展其中一個選項，也許製作 mockups（視覺稿）或 code snippets。最後，當我感覺不錯時，我會要求它編寫一個實施計劃。如果我對計劃感到滿意，我會創建一個新的 session（會話）並將所有這些文件傳入讓其執行。
在進行驗證時，我也會要求驗證 agent 讀取這些文件，這樣它就能對所需內容擁有更廣泛的 context。
示例提示：
我不確定 onboarding screen（引導界面）該採取什麼方向。生成 6 種截然不同的方法——在佈局、基調和密度上進行變化——並將它們作為一個單獨的 HTML 文件排列在一個 grid（網格）中，以便我可以並排比較它們。為每一個標註其所作出的權衡。 在 HTML 文件中創建一個詳盡的實施計劃，請務必製作一些 mockups，展示 data flow（數據流），並添加我可能想要 review 的重要 code snippets。使其易於閲讀和消化。
探索在代碼中實現某項功能的其他方式 探索多種視覺設計
代碼審查與理解
在 Markdown 文件中閲讀代碼可能很困難。但使用 HTML，我們可以渲染 diffs（差異）、annotations（註釋）、flowcharts（流程圖）、模塊等。你可以利用這一點來理解 agent 編寫的代碼，獲取 code review，或者向審查你代碼的人解釋一個 PR。我發現這通常比默認的 Github diff 視圖效果更好，我現在為我提交的每個 PR 都會附帶一個 HTML 代碼解釋器。
示例提示：
幫我 review 這個 PR，通過創建一個描述它的 HTML artifact。我不是很熟悉 streaming/backpressure（流式/背壓）邏輯，所以請將重點放在那上面。使用內聯邊緣 annotations 渲染實際的 diff，按嚴重程度對發現的問題進行 color-code（顏色編碼），以及使用其他任何可能有助於很好地傳達概念的方法。
使用場景：
創建一個 PR Review 一個 PR 理解 Code（代碼）中的某個主題
設計與原型
Claude Design 基於 HTML，因為 HTML 在設計上具有極強的表現力，即使你的最終展現層不是 HTML。Claude 可以在 HTML 中草擬一個設計，然後用你選擇的語言（無論是 React、Swift 等）將其編寫出來。
你還可以 prototype（製作原型）交互操作，比如動畫、動作等。考慮讓 Claude 製作 sliders、knobs 等，以精確調校出你正在尋找的效果。
示例提示：
我想 prototype 一個新的 checkout 按鈕，點擊時它會播放動畫然後快速變成紫色。創建一個包含幾個 sliders 和選項的 HTML 文件，讓我可以在這個動畫上嘗試不同的選項，並給我一個複製按鈕以複製那些效果不錯的參數。
將其用於：
創建 design system（設計系統）artifacts 調整組件 可視化組件庫 Prototyping（原型設計）令人愉悦的動畫
Claude Code 在整合多個數據源的信息並將其轉化為具有良好可讀性的報告方面極其出色。你可以 prompt Claude 搜索你的 Slack、你的 codebase（代碼庫）、git history、互聯網等，並利用它為你自己、為領導層、為你的團隊等生成極具可讀性的報告。
你可以將其組合成長篇 HTML 文檔、交互式解釋器，甚至是 slideshow/deck（幻燈片/演示文稿）的形式。要求 Claude 使用 SVG 製作圖表以幫助將其可視化。例如，對於我關於 prompt caching 的文章，在閲讀了 git history 之後，我要求 Claude 準備一份 HTML 格式的深入研究文件，供我閲讀有關我們對 prompt caching 所做出的所有更改。
示例提示：
我不理解我們的 rate limiter（限流器）究竟是如何工作的。請閲讀相關代碼並生成一個單獨的 HTML 解釋頁面：一個 token-bucket（令牌桶）流的圖表，附帶 annotations 的 3-4 個關鍵 code snippets，並在底部包含一個“gotchas（避坑指南）”部分。針對只閲讀一次的讀者對其進行優化。
將其用於：
總結一個特性的工作原理 向我解釋一個概念 給你老闆的每週 status reports（進度報告） 給領導層的 Incident reports（事故報告） SVG 插圖、flowcharts、技術圖表等
自定義編輯界面
有時候，純粹用一個文本框很難描述你想要什麼。在這種情況下，我會讓 Claude 為我正在處理的具體事項構建一個 throwaway（一次性）編輯器。不是一個產品，也不是一個可重用的工具，而是一個為這份數據量身定製的、單一的 HTML 文件。
其中的訣竅是始終以一種導出來結尾：一個“作為 JSON 複製”或“作為 prompt 複製”的按鈕，將我在 UI 中所做的一切轉換回我可以粘貼到 Claude Code 中的內容。
示例提示：
我需要重新確定這 30 個 Linear tickets 的優先級。給我製作一個 HTML 文件，將每個 ticket 作為一個 draggable card（可拖拽卡片），分佈在 Now / Next / Later / Cut 幾列中。根據你的最佳猜測對它們進行預先排序。添加一個“作為 Markdown 複製”的按鈕，導出最終的排序，併為每個 bucket 提供一行理由。 這是我們的 feature flag config（特性開關配置）。為它構建一個基於表單的編輯器，按區域對 flags 進行分組，顯示它們之間的依賴關係，如果我啓用了一個其先決條件已關閉的 flag，請警告我。添加一個“複製 diff”按鈕，只給我發生了更改的 keys。 我正在調優這個 system prompt。製作一個 side-by-side（並排的）編輯器：左側為可編輯的 prompt，高亮顯示 variable slots（變量槽位），右側為三個 sample inputs（樣本輸入），實時重新渲染填好的模板。添加一個 character/token（字符/令牌）計數器和一個複製按鈕。
將其用於：
重新排序、分類（triaging）或分組（bucketing）任何東西（tickets、test cases、反饋） 編輯結構化 config（帶有約束的 feature flags、env vars、JSON/YAML） 通過 live preview（實時預覽）調優 prompts、模板或文案 整理 datasets，批准/拒絕數據行，為示例打標籤（tag），導出選中內容 註釋文檔、transcript 或 diff，並導出 annotations（註釋） 挑選在文本中難以表達的值：顏色、easing curves（緩動曲線）、crop regions（裁剪區域）、cron schedules（定時任務計劃）、regexes（正則表達式）。
常見問題解答
我一直告訴很多人我是如何切換到 HTML 的，我也看到了一些反覆出現的問題。
這難道不是更缺乏 token 效率嗎？
雖然 Markdown 通常使用更少的 tokens，但我發現 HTML 增加的表現力以及我閲讀它的極高可能性意味着我總體上獲得了更好的輸出。藉助 Opus 4.7 中 1MM 的 context window（上下文窗口），增加的 token 使用量在上下文中並不明顯。
你現在什麼時候會使用 Markdown？
說實話，對於幾乎所有事情，我已經完全停止使用 Markdown 了，但我可能在很大程度上是一個 HTML 最大主義者。
我該如何查看 HTML 文件？
我傾向於直接在本地瀏覽器中打開它（你可以讓 Claude 打開它），或者如果你想要一個可分享的連結，可以上傳到 S3。
這生成起來是不是比 Markdown 耗時更長？
這確實耗時更長！HTML 的耗時可能比 Markdown 長 2-4 倍，但我發現結果是值得的。
那版本控制怎麼辦？
說實話，這是 HTML 最大的缺點之一，與 Markdown 相比，HTML 的 diffs 非常雜亂且難以 review。
我如何讓 Claude 契合我的品味 / 不做得那麼難看？
前端設計 plugin（插件）有助於 Claude 製作高質量的 HTML 文件。但為了契合你自己公司的風格，你可以通過將 Claude 指向你的 codebase 來創建一個單獨的 design system（設計系統）HTML 文件。然後，你可以將該 design system 文件用作其他 html 文件的 reference（參考）。
保持參與
綜上所述，我認為我使用 HTML 的真正原因是，我感覺與 Claude 的交互更加 in the loop（保持在循環/參與狀態中）。我之前開始擔心，因為我已經停止深入閲讀計劃了，我將只能放任 Claude 去自己做決定。
但我很高興地說，在使用 HTML 時，我比以往任何時候都感覺更 in the loop。我希望你也是如此。
既然看到這兒了，如果覺得還不錯，幫忙隨手點個「贊」、「在看」、「轉發」三連；如果想第一時間收到推送，也可給我加個星標★，非常感謝！