HTML 會成為新的 Markdown 嗎？
整理版優先睇
HTML 取代 Markdown 做 AI 輸出格式，人先睇得明方案
呢篇文章係作者分享佢同 Thariq Shihipar（Claude Code 團隊工程師）嘅觀察：用 AI 寫嘅 Markdown 文檔越來越長，幾百行上千行，自己同團隊都唔願睇曬，結果方案冇人 review，問題留到好後期先發現。作者自己就成日叫 AI 一次過完成大功能，然後寫份長 Markdown 交畀人，但接手嘅人通常直接扔畀 AI 睇，唔會自己睇。
Thariq 提出一個解決方案：HTML 係新嘅 Markdown。佢話同一份內容，用 HTML 整成有 tab、圖表、可摺疊、可互動嘅頁面，人睇嘅時候可以掃讀、按需要跳轉，資訊密度高好多。佢仲整咗 20 個示範，包括方案對比、code review 界面、設計 token 展示、自定義編輯器等等，全部獨立 HTML 檔案，開瀏覽器就睇到，分享只需一個連結。
作者認為，人係視覺動物，83% 資訊靠視覺，線性文字效率低。AI 之間傳遞可以繼續用 Markdown，但輸出畀人嘅時候，HTML 更有效率。佢進一步諗，將來可能係可互動影片或者語音，進一步擴闊人同 AI 之間嘅資訊帶寬。
- 結論：HTML 比 Markdown 更適合人類閲讀 AI 生成嘅方案，提升 review 效率。
- 方法：用 Claude Code 直接生成 HTML 檔案，包含 tab、圖表、代碼高亮、交互組件。
- 差異：Markdown 係一維線性，HTML 係二維空間加互動，人眼處理快好多。
- 啟發：AI 輸出畀人睇時，要用返人嘅認知習慣，視覺化係關鍵。
- 可行動點：叫 AI 幫你整一次性 HTML 編輯器或報告，而唔係寫長 Markdown；分享時用 S3 連結或局域網開 port。
Thariq 原文：HTML is the new markdown
Thariq Shihipar 在 X 上發表的長文，解釋點解轉用 HTML 代替 Markdown 做 AI 輸出。
HTML 示例站
Thariq 製作的 20 個示範 HTML 檔案，涵蓋 9 大類場景，可直接瀏覽體驗。
長 Markdown 文檔冇人睇
作者發現自己同團隊都唔願睇長 Markdown 文檔。佢習慣叫 AI 一次過搞掂大任務，寫成三五百行甚至過千行嘅技術方案，但接手嘅人通常直接扔畀 AI，或者頭痛咁睇，好少有人認真 review。呢個情況同 Thariq 講嘅一模一樣：超過 100 行嘅 Markdown 文件，佢基本唔會認真讀完。
Markdown 文檔越嚟越長，人越嚟越唔睇，問題延遲先發現。
點解 HTML 更好？
Thariq 嘅核心論點係 HTML 嘅資訊密度同互動性遠遠高過 Markdown。一份 240 行嘅 Markdown，同樣內容用 HTML 可以做到 tab 切換、數據圖表、關鍵指標高亮，人掃一眼就捉到重點。
- 資訊密度：表格、CSS 樣式、SVG 插圖、代碼高亮、交互組件、工作流程圖、空間佈局、嵌入圖片，HTML 通通裝得曬，Markdown 連顏色都要靠 Unicode 估。
- 讀得動：HTML 用 tab、導航連結、摺疊面板組織內容，讀者可以跳轉，唔使由頭滾到尾。
- 分享門檻低：HTML 上傳 S3 或開局域網 port 就畀到人睇，唔似 Markdown 要轉發附件或貼去其他平台。
- 雙向互動：Thariq 示範咗一個按鈕動畫調參面板，可以喺瀏覽器拉 slider 改參數，然後一鍵複製成 prompt 俾返 Claude Code，實現互動式調整。
20 個示範，涵蓋 9 大場景
Thariq 整咗個示例站，入面有 20 個獨立 HTML 檔案。以下係幾個值得留意嘅例子。
- 1 方案探索：三個方案並排對比，底下有 Choose 按鈕，直接揀一個。
- 2 代碼審查：PR Review 界面，diff 帶註釋氣泡（紅色 blocking、灰色 nit、綠色 nice），比 GitHub 默認 diff 仲好用。
- 3 設計系統：顏色 Token 直接渲染成色塊，唔使靠想像 #D97757 係咩色。
- 4 研究報告：Rate Limiting 技術文檔，流程圖、代碼、注意事項佈局清晰。
- 5 自定義編輯器：Feature Flag 編輯器，左邊開關列表，紅框標出依賴衝突，右邊剪貼板預覽 diff，一鍵貼回 Claude Code。
HTML 嘅代價同點揀
Thariq 冇迴避問題：生成 HTML 比 Markdown 慢 2-4 倍，版本控制 diff 噪聲大。有人質疑佢想呃多啲 token，佢反駁話 Opus 4.7 有 100 萬 token 窗口，多嗰啲 token 幾乎可忽略；關鍵係寫咗份冇人睇嘅 Markdown 定係一份有人真係會睇嘅 HTML。
選擇嘅重點：你係想慳 token，定係想方案有人 review？
至於 AI 之間溝通，Markdown 仍然係更好選擇，因為佢資訊濃度高、冇視覺噪聲，token 效率更高。作者總結：AI-AI 用 Markdown，AI-人用 HTML。
資訊帶寬：人係視覺動物
作者引用認知科學：人類 83% 資訊靠視覺，11% 靠聽覺，大腦 30% 皮層處理視覺。Markdown 係一維線性，人睇得辛苦；HTML 可以用二維佈局、色彩、互動嚟配合人眼掃視習慣。
有冇發現，Markdown 文件，越嚟越長？
我最近做咗啲調整：當有咗一個新嘅諗法或者一件新嘅事要做，如果唔係我俾 AI 直接搞得掂嘅、複雜度比較高嘅，我會俾 AI 連續口噴 10 分鐘幾千字，然後叫佢幫我將個諗法完善。
完善嘅過程，我會同多個 AI 做深入嘅討論，會交替用 Claude Code 同 Codex，最後俾出一個文件。
呢個文件可能會有三五百行，甚至 1000 幾行。
我嘅習慣上，我更傾向於俾 AI 一次性解決一個好大、好完整嘅功能，或者一堆細需求細 bug 嘅大集合（例如「請完成下面所有任務」——大約有 20 個咁上下）。
喺呢度，我已經唔太鍾意小步快跑，而係一次過俾 AI 完成比較大嘅任務。原因係，AI 已經有能力一次過完成複雜任務啦。而我就要減少同 AI 溝通嘅頻率，減少我喺裏面 loop 嘅次數。
雖然呢個好易明，但我都係舉個例。
假如你要去街市買餸，你當然唔會先買一棵白菜返屋企，然後再去買一個番茄返屋企，然後再買一次辣椒返屋企；你會一次過喺街市買齊，然後全部帶返屋企，咁樣可以大大減少你喺路上嘅時間。
但如果你買齊返到屋企發現漏咗樣嘢冇買，你會鬧自己一句蠢，然後再跑一趟……
而喺 AI coding 嘅過程中，呢樣「路上嘅時間」就係 AI 話：「我做曬啦，你嚟睇睇。」之後你要一次又一次對呢啲細任務做嘅多次檢查驗收。
所以準備好呢個好長嘅 Markdown 文件之後，偷懶嘅我通常會開一個分支，然後交俾團隊入面某位同事去完成。呢度我唔係直接自己做，係因為 AI 完成之後，我要去驗收，然後發佈到生產，仲要加相關嘅數據統計，持續做數據分析同效果追蹤。
雖然我係省咗事，但係睇咁大個文件，的確仲係好大壓力。
我發現接手嘅人要唔係唔會一行行睇，要唔係會認真同好頭痕咁睇。更多時候，我發現佢哋會直接扔俾 AI 討論分析然後開工。
但我其實，更希望接手嘅人可以有啲唔同意見同觀點，喺方案環節就做 review 提出大嘅質疑同建議，而唔係完成之後再 review 我初始方案入面嘅問題，令問題可以更左移而唔係右移。
呢度我哋會習慣性揀 Markdown，原因係佢的確輕量、通用、夠用，而且 AI 同 AI 之間傳遞信息亦都足夠順暢。
但係睇一份詳細嘅 Markdown 文件，實在太唔容易啦。
幾百行、上千行，一個大項目嘅技術方案，終於寫好咗，但問題都嚟啦：你/其他人真係會由頭到尾睇完咩？
雖然我俾 AI 嘅指令入面帶得最多嘅，就係「精煉」呢個詞，我會成日講「用精煉嘅文字俾出嚟，唔好要冇用嘅廢話」。
對應嘅就係，而家用 AI 寫本書真係越嚟越易（唔好覺得寫書嘅人幾犀利啦……我拒絕咗好多出版社嘅寫書邀請），點樣喺同人進行信息傳遞時，用精煉嘅語言、更少嘅 token 嚟表達同樣嘅內容，反而係 AI 時代更重要嘅一項技能。
但就算係咁，我同 AI 最後產出嘅文件，都仲係會長到自己都睇唔曬，甚至唔小心入面仲會藏住啲前後矛盾嘅地方。
我一直喺度諗點樣改進呢件事。
然後昨日，我見到 Claude Code 嘅工程師 Thariq Shihipar 出咗篇文章，講嘅都係呢件事。
01關於 Thariq Shihipar
Thariq Shihipar，Anthropic 嘅 Claude Code 團隊成員。
佢嘅履歷可以話好豐富：MIT Media Lab 碩士畢業，YC W20 嘅創業者，創辦過一間拎咗 1700 萬美元融資嘅遊戲公司，賣過一個 SaaS 產品，做過非牟利組織。
大概一年多前，Thariq 加入咗 Anthropic，佢自己話：因為「AI 精神病」發作，覺得 Claude Code 就係軟件開發嘅未來，於是放低一切 all in 咗入嚟。
佢喺 Claude Code 團隊入面有一個你一定會知道嘅貢獻：設計咗「ask user question」工具，即係叫 Claude 喺 Plan 模式底下反過來向用戶提問、澄清需求嗰個功能。
佢喺 X 出咗篇長文，標題叫：
Using Claude Code: The Unreasonable Effectiveness of HTML
即：HTML 唔講道理咁好用。
Thariq 喺推文入面話：
“ HTML is the new markdown. I've stopped writing markdown files for almost everything and switched to using Claude Code to generate HTML for me.
HTML 係新嘅 Markdown。我已經幾乎唔寫 Markdown 檔案，全部換成叫 Claude Code 幫我生成 HTML。
呢篇文章好快喺開發者社區引發大量討論，我哋一齊睇下。
02點解係 HTML
Thariq 嘅核心論點，可以用一張圖概括：
左邊係一個 240 行嘅 Markdown 檔案，底部寫住「仲有 214 行」。
右邊係同樣嘅內容，用 HTML 呈現：有 tab 切換、有數據圖表、有關鍵指標高亮。同樣嘅信息，一個係要你碌嚟睇嘅文件，一個係畀你睇一眼就捉到重點嘅頁面。
佢喺文章入面列咗幾個核心原因。
03信息密度
HTML 可以承載嘅信息類型，比 Markdown 豐富好多。
表格、CSS 樣式、SVG 插圖、代碼高亮、互動組件、工作流程圖、空間佈局、嵌入圖片，一個 HTML 檔案就可以裝曬。
Thariq 原話係：
“ 幾乎唔存在 Claude 讀得明但 HTML 表達唔到嘅信息。
而 Markdown 呢？
想展示個顏色嗰陣，只能用 Unicode 字符去「估算」。Thariq 貼咗一張 Claude Code 喺終端度試圖展示色板嘅截圖：
點講呢……精神可嘉、諗法好好、效果感人。
04睇唔鬱嘅方案
隨住 Claude 可以處理嘅任務越嚟越複雜，佢寫嘅方案同規格文件都越嚟越長。
Thariq 坦言：
“ 超過 100 行嘅 Markdown 檔案，我基本上唔會認真睇完。更加唔好講叫團隊入面其他人去睇。
呢個同我前面講嘅情況，簡直一模一樣。
HTML 嘅好處係，Claude 可以用 tab 頁、導航連結、摺疊面板呢啲方式嚟組織內容，讀者唔需要由頭碌到尾，而係好似瀏覽一個網頁咁，按需要跳轉。
甚至可以做埋響應式，手機睇都冇問題。
05分享門檻
Markdown 檔案其實有啲唔方便，因為大部分瀏覽器唔會原生渲染 Markdown，你成日要將佢當成附件 send 出去，或者貼去飛書 / Notion 呢啲原生支援 markdown 嘅在線文件度。
但 HTML 呢？上傳去 S3 之後俾個連結，或者本地區域網絡開個 192.168.1.xxx:8080/xxx.html 就得。
(注意：唔可以係 localhost:8080/xxx.html)
同事打開就睇到，唔需要任何額外工具。
Thariq 表示：
06“ 如果你嘅方案係 HTML 格式嘅，人哋真係會去睇嘅機會，比 Markdown 高好多。
雙向互動
呢一點，好實用。
上圖展示嘅係一個按鈕懸浮動畫嘅調參界面。左邊係 HTML 生成嘅可互動面板：duration、scale、shadow blur、spring easing，全部係可以拉嘅滑塊。
調好參數之後，㩒「Copy as prompt」，參數就俾複製成一段 prompt，直接貼返去 Claude Code，佢就會將呢啲值套用到真實嘅代碼組件度。
喺瀏覽器度調，調好貼返俾 AI。
咁樣嘅互動方式，顯然，Markdown 係做唔到嘅（如果你話 Markdown 裏面都可以插入 html 嘅脱褲子放屁做法，咁呢句當我冇講過……）。
0720 個示例
光講理論可能仲有啲抽象，Thariq 特意做咗一個示例站點，放咗 20 個完整嘅 HTML 檔案，涵蓋咗 9 大類使用場景。
地址喺呢度：https://thariqs.github.io/html-effectiveness/
每個檔案都係獨立嘅，唔需要安裝任何嘢，瀏覽器打開就體驗到。
我揀咗幾個，一齊睇下。
08方案探索
呢個係一個 debounced search 嘅三種實現方案對比。
A 方案最簡單但唔支援取消，B 方案零依賴但代碼更多，C 方案用咗 library 但多咗 12kb 體積。
三個方案並排擺埋一齊，優缺點好一目瞭然，底下仲有個「choose」按鈕。
而如果用 Markdown 做同樣嘅嘢，你要將三段代碼順序擺出嚟，然後個腦自己去做對比。
分別在於，HTML 係畀你「睇」到差別，Markdown 係畀你「諗」出差別。
09代碼審查
呢個例子係一個 PR 嘅 code review 界面。
diff 渲染出嚟之後，右邊帶咗註釋氣泡：紅色係 blocking（一定要改），灰色係 nit（建議改），綠色係 nice（寫得好）。
Thariq 提到，佢而家每個 PR 都會叫 Claude 生成一個咁樣嘅 HTML 檔案，附喺 PR 描述度。
10“ 呢個效果，往往比 GitHub 預設嘅 diff 界面仲好用。
設計系統
呢個係從代碼倉庫入面提取出嚟嘅設計 Token：顏色、字體、間距、按鈕樣式，全部渲染成可視化嘅色塊同組件。
喺 Markdown 裏面，你只可以寫 #D97757 然後想像下佢嘅顏色……而喺 HTML 裏面，你會直接見到個顏色係點樣。
研究報告
呢份係關於 rate limiting 嘅技術文檔。
上方係流程圖（request → bucket → decision → 429/pass），中間係關鍵代碼片段，底部係 Gotchas 列表。
信息來源標住「Synthesized from codebase · Slack · git log · web」。
即係話，Claude Code 從代碼庫、Slack 訊息、Git 提交記錄、網頁等多個渠道彙總信息，最後生成咗呢一頁。
流程圖加代碼加註意事項，佈局清晰，信息密度高。
12自定義編輯器
呢個的確令我覺得有啲意思。
上圖係一個 feature flag 嘅編輯器。左邊係開關列表，按分類分組。留意 streaming.partial_json 嗰一項，佢被紅框標咗出嚟，因為佢依賴嘅 streaming.delta_events 目前係關閉狀態。
右邊係剪貼簿預覽：淨係導出你改過嘅 key，生成一段 diff，直接可以貼返去 Claude Code 叫佢更新配置同文件。
Thariq 將呢類場景稱為「一次性編輯器」：
“ 叫 Claude 幫你做一個專門用於呢一次任務嘅 HTML 編輯器。調完參數，導出結果，用完就掉。
呢個思路仲可以用喺好多地方：工單排序、數據集標註、prompt 調優、cron 表達式編輯……只要你覺得「用純文字描述太麻煩」嘅場景，都可以叫 Claude 臨時搭個可視化工具。
13HTML 嘅代價
當然，Thariq 都冇迴避 HTML 嘅問題。
生成速度上，HTML 比 Markdown 慢 2-4 倍。版本控制上，HTML 嘅 diff 噪音大、唔好審查。
有網友調侃：
“ 你話唔鍾意讀長 Markdown 檔案，結果寫咗一篇好長嘅 Markdown 帖子。
(呢篇長文正係用 Markdown 寫嘅)
Thariq 回咗個：💀……
仲有人質疑，呢個係咪你官方想呃用戶多用 token 呢？
Thariq 嘅回應係：Opus 4.7 已經有 100 萬 token 嘅上下文窗口，HTML 多用嗰啲 token，喺呢個量級底下幾乎可以忽略不計。
以我嚟睇，呢度嘅關鍵係：你寫咗一份冇人睇嘅 Markdown，同一份大家真係會睇嘅 HTML，邊個更浪費？
14人，係視覺動物
講返轉頭，呢個其實唔關 Markdown 事，係由人嘅「硬件」條件（或者叫限制）決定嘅。
根據認知科學嘅研究，人類獲取外部信息嘅 83% 靠視覺，11% 靠聽覺，兩者加埋佔咗 94%。大腦皮層中，約 30% 嘅區域專門用嚟處理視覺信息，而聽覺只佔 3%。
人，本質上係視覺動物。
而 Markdown 呢？佢係一維嘅、線性嘅。
雖然可以有二維表格，但總體上你仲係要一行行咁讀落去。當你嘅眼光需要由頭掃到尾，一口氣睇完一份幾百行嘅技術方案時，效率低唔在講，壓力都唔細。
而 HTML 可以做到嘅嘢豐富好多：二維甚至三維嘅空間佈局，色彩編碼，可摺疊嘅層級結構，可互動嘅組件。信息可以按人眼嘅自然掃視習慣嚟組織，而唔只係線性排列。
人睇 Markdown 好似讀一本冇插圖嘅小說，睇 HTML 好似行一個精心設計嘅展覽。
呢度武斷講句，AI PPT、AI PDF 最終都會消失。以我嚟睇，PPT 同 PDF 明顯都唔會係 AI 時代信息傳遞的「原生語言」，佢哋最多，都係攞嚟做個導出格式就算。
15for AI 定 for 人
呢就帶出一個框架。
AI 同 AI 之間，Markdown (暫時) 仲係更好嘅選擇。
我哋而家所有嘅 Skill、Agent 配置，包括 Claude 嘅 Artifacts，都以 Markdown 作為通用標準。佢係更高濃度嘅信息壓縮，刪走咗 HTML 嘅各種標籤、樣式、腳本呢啲「視覺噪音」，對 token 更友好，AI 解析同生成都更有效率。
畀 AI 輸入嘅時候，Markdown 都更合適。同樣嘅信息，Markdown 用更少嘅字符就表達清楚。
但一旦信息要面向人，Markdown 就開始顯出佢嘅侷限性。
細心嘅朋友可能會發現，我最近喺公眾號文章入面都加咗啲可以鬱、可以互動嘅 SVG 插圖，例如你正在讀嘅呢篇文章就有。相比純文字，佢多咗一層視覺互動，我想會帶嚟唔同嘅閲讀體驗。
喺文字之外，用更豐富嘅視覺同互動嚟溝通，微信 svg 嘅坑實在太多，我五一期間執咗好耐……之後穩定啲我可能會開源出嚟（如果有人需要）。
16HTML 之外
關於 Markdown 同 HTML 嘅討論，以我嚟睇本質嘅問題係：AI 到人嘅信息帶寬。
信息喺 AI 同人之間嘅流動，無非就係兩個：輸入同輸出。
人嘅信息輸出端，我之前間中都有提到，例如：我做咗一個 AI 時代嘅效率神器，已開源
而 Markdown 到 HTML 嘅升級，解決嘅係人嘅輸入端，點樣令 AI 交付嘅結果更適合人嘅視覺系統去消化。
但呢一步，以我嚟睇其實仲未夠。
或者輸出端仲可以繼續向前行幾步，可能係可互動嘅視頻，AI 唔只係生成一個靜態頁面畀你自己睇，而係帶住語音，好似一個同事咁同你講方案、行碼、解釋數據，甚至可以隨時打斷同提問。當然，仲有好多可能嘅方案。
輸入端都同樣有改進空間。而家人畀 AI 嘅輸入主要仲係文字，但人同人之間最自然嘅溝通方式唔係鍵盤而係當面溝通，淨係以說話為例都遠唔止語音轉文字咁簡單，語氣、停頓、強調，呢啲都攜帶住大量嘅意圖信息。喺呢點上，我好睇好 OpenAI，佢哋喺多模態同互動上有更多嘅嘗試同積累。
Thariq 喺佢嘅文章結尾寫道：
“ 我用 HTML 嘅真正原因，係我覺得自己同 Claude 之間嘅關係更緊密咗。我本來擔心，因為我已經唔再認真讀啲方案，就只能放任 Claude 自己決定。但而家，我反而覺得自己比以前更加 in the loop。
當 AI 嘅能力越嚟越強，人同 AI 之間嘅信息帶寬，就成為瓶頸。
對人嘅信息輸入而言，如果話 Markdown 係一條水管，咁 HTML 可以睇作一條河。
我喺度諗，點樣先係一片海？
◇ ◆ ◇
相關連結：
• Thariq 原文：https://x.com/trq212/status/2052809885763747935
• HTML 示例站：https://thariqs.github.io/html-effectiveness/
• Thariq 嘅 X 主頁：https://x.com/trq212
有沒有發現，Markdown 文檔，正在變得越來越長？
我最近做了些調整：當有了一個新的想法或一件新的事情要做，如果不是我讓 AI 直接就能幹完的、複雜度較高的，我會給 AI 連續口噴 10 分鐘數千字，然後讓它幫我把想法完善。
完善的過程，我會和多個 AI 進行深入的討論，會交替使用 Claude Code 和 Codex，並最終給出一個文檔。
這個文檔可能會有三五百行，甚至 1000 多行。
我的習慣上，我更傾向於讓 AI 一次性解決一個很大、很完整的功能，或者一堆小需求小 bug 的大集合（比如“請完成如下所有任務“——大約有 20 個這樣）。
在這裏，我已經不太喜歡小步快跑了，而是一次性讓 AI 完成較大的任務。原因在於，AI 已經具備一次性完成複雜任務的水平了。而我則需要減少與 AI 溝通的頻率，減少我在其中 loop 的次數。
這雖然很好理解，但我還是舉個例子。
假如你要去菜市場買菜，你顯然是不會先買一棵白菜回家，然後再去買一個西紅柿回家，然後再買一次辣椒回家；你會一次性在菜市場買好，然後全部帶回家，這樣可以大大減少你在路上的時間。
但如果你買好到家後發現漏了個什麼沒買，你會罵自己一句 SB，然後再跑一趟……
而在 AI coding 的過程中，這“路上的時間”也就是 AI 說：“我幹完了，你來看看。”後你得一次又一次對這些小任務進行的多次檢查驗收。
所以在準備好這個很長的 Markdown 文檔之後，偷懶的我一般會開一個分支，然後交給團隊裏的某位同學去完成。這裏我不是直接自己完成，是因為在 AI 完成之後，我需要去驗收，然後發佈到生產，還要增加相關的數據統計，並持續地進行數據分析和效果追蹤。
雖然我是省事了，但是看這麼一個大文檔，確實還是很有壓力的。
我發現接手的人要麼就不會一行一行看，要麼會認真且很頭疼地看。更多時候，我發現他們會直接扔給 AI 進行討論分析然後開幹。
但我其實，更希望接手的人能有一些不同的意見和觀點，在方案環節就進行 review 提出大的質疑和建議，而不是完成之後再 review 出我初始方案中的問題，讓問題更能左移而非右移。
這裏我們會習慣性地選擇 Markdown，原因在於它確實輕量、通用、夠用，且 AI 和 AI 之間傳遞信息也足夠順暢。
但看一份詳細的 Markdown 文檔，實在是太不容易了。
幾百行、上千行，一個大項目的技術方案，終於寫好了，但問題也來了：你/其他人真的會從頭到尾讀完嗎？
雖然我在給 AI 的指令帶上的最多的，就是“精煉”這個詞了，我會經常說“用精煉的文字給出，不要無用的廢話”。
對應的就是，現在用 AI 寫本書真的越來越容易了（不要覺得寫書的人多牛逼了……我就拒絕了好多出版社的寫書邀約），如何在和人進行信息傳遞時，使用精煉的語言、更少的 token 來表達同樣的內容，反而是 AI 時代更為重要的一項技能了。
但即使如此，我和 AI 最後產出的文檔，還是會長到自己都看不過來，甚至不小心裏面還會藏着一些前後矛盾的地方。
我一直在琢磨怎麼改進這件事。
然後昨天，我看到 Claude Code 的工程師 Thariq Shihipar 發了篇文章，講的也正是這件事情。
01關於 Thariq Shihipar
Thariq Shihipar，Anthropic 的 Claude Code 團隊成員。
他的履歷可以說是非常豐富：MIT Media Lab 碩士畢業，YC W20 的創業者，創辦過一家拿了 1700 萬美元融資的遊戲公司，賣掉過一個 SaaS 產品，做過非營利組織。
大概一年多前，Thariq 加入了 Anthropic，據他自己說的是：因為「AI 精神病」發作，覺得 Claude Code 就是軟件開發的未來，於是放下一切 all in 了進來。
他在 Claude Code 團隊裏有一個你一定會知道的貢獻：設計了「ask user question」工具，也就是讓 Claude 在 Plan 模式下可以反過來向用戶提問、澄清需求的那個功能。
他在 X 上發了一篇長文，標題叫：
Using Claude Code: The Unreasonable Effectiveness of HTML
即：HTML 不講道理的好用。
Thariq 在推文中說道：
“ HTML is the new markdown. I've stopped writing markdown files for almost everything and switched to using Claude Code to generate HTML for me.
HTML 是新的 Markdown。我已經幾乎不寫 Markdown 文件了，全部換成讓 Claude Code 給我生成 HTML。
這篇文章很快在開發者社區裏引發了大量討論，我們一起來看一看。
02為什麼是 HTML
Thariq 的核心論點，可以用一張圖來概括：
左邊是一個 240 行的 Markdown 文件，底部寫着「還有 214 行」。
右邊是同樣的內容，用 HTML 呈現：有 tab 切換、有數據圖表、有關鍵指標高亮。同樣的信息，一個是讓你滾動閲讀的文檔，一個是讓你掃一眼就能抓住重點的頁面。
他在文章中列了幾個核心理由。
03信息密度
HTML 能承載的信息類型，比 Markdown 豐富太多了。
表格、CSS 樣式、SVG 插圖、代碼高亮、交互組件、工作流程圖、空間佈局、嵌入圖片，一個 HTML 文件就能全裝下。
Thariq 的原話是：
“ 幾乎不存在 Claude 能讀懂但 HTML 表達不了的信息。
而 Markdown 呢？
想要展示個顏色時，只能用 Unicode 字符去「估算」。Thariq 貼了一張 Claude Code 在終端裏試圖展示色板的截圖：
怎麼說呢……精神可嘉、想法很好、效果感人。
04讀不動的方案
隨着 Claude 能處理的任務越來越複雜，它寫的方案和規格文檔也越來越長。
Thariq 坦言：
“ 超過 100 行的 Markdown 文件，我基本不會認真讀完。更別提讓團隊裏其他人去讀了。
這和我前面說的情況，簡直是一模一樣。
HTML 的好處在於，Claude 可以用 tab 頁、導航連結、摺疊面板這些方式來組織內容，讀者不需要從頭滾到尾，而是像瀏覽一個網頁一樣，按需跳轉。
甚至還能做成響應式的，手機上看也沒問題。
05分享門檻
Markdown 文件其實挺有些不方便，因為大部分瀏覽器不會原生渲染 Markdown，你往往得把它當成附件發送出去，或者貼到飛書 / notion 這樣原生支持 markdown 的在線文檔裏。
但 HTML 呢？上傳到 S3 後發個連結，或者本地局域網開個 192.168.1.xxx:8080/xxx.html 就行。
（注意：不能是 localhost:8080/xxx.html）
同事打開就能看，不需要任何額外工具。
Thariq 表示：
06“ 如果你的方案是 HTML 格式的，別人真的會去看的概率，比 Markdown 高得多。
雙向互動
這一點，非常實用。
上圖展示的是一個按鈕懸浮動畫的調參界面。左邊是 HTML 生成的可交互面板：duration、scale、shadow blur、spring easing，全都是可以拖動的滑塊。
調好參數之後，點「Copy as prompt」，參數就被複製成一段 prompt，直接粘貼回 Claude Code，它就會把這些值應用到真實的代碼組件裏。
在瀏覽器裏調，調好了粘回給 AI。
這樣的交互方式，顯然，Markdown 是做不到的（你要是說 Markdown 裏也可以插入 html 的脱褲子放屁式做法，那這話當我沒說……）。
0720 個示例
光說理論可能還有點抽象，Thariq 特意做了一個示例站點，放了 20 個完整的 HTML 文件，覆蓋了 9 大類使用場景。
地址在這裏：https://thariqs.github.io/html-effectiveness/
每個文件都是獨立的，不需要安裝任何東西，瀏覽器打開就能體驗。
我挑了幾個，一起來看下。
08方案探索
這是一個 debounced search 的三種實現方案對比。
A 方案最簡單但不支持取消，B 方案零依賴但代碼更多，C 方案用了庫但多了 12kb 體積。
三個方案並排擺在一起，優缺點非常的一目瞭然，底下還有個「choose」按鈕。
而如果用 Markdown 來做同樣的事情，你得把三段代碼順序擺出來，然後腦子裏自己去做對比。
差別在於，HTML 是讓你「看」到差異，Markdown 是讓你「想」出差異。
09代碼審查
這個例子是一個 PR 的 code review 界面。
diff 渲染出來之後，右側帶了註釋氣泡：紅色是 blocking（必須改），灰色是 nit（建議改），綠色是 nice（寫得好）。
Thariq 提到，他現在每個 PR 都會讓 Claude 生成一個這樣的 HTML 文件，附在 PR 描述裏。
10“ 這個效果，往往比 GitHub 默認的 diff 界面還好用。
設計系統
這是從代碼倉庫裏提取出來的設計 Token：顏色、字體、間距、按鈕樣式，全部渲染成可視化的色塊和組件。
在 Markdown 裏，你只能寫 #D97757 然後想象一下它的顏色……而在 HTML 裏，你會直接看到那個顏色是什麼樣的。
研究報告
這是一份關於 rate limiting 的技術文檔。
上方是流程圖（request → bucket → decision → 429/pass），中間是關鍵代碼片段，底部是 Gotchas 列表。
信息來源標註着「Synthesized from codebase · Slack · git log · web」。
也就是說，Claude Code 從代碼庫、Slack 消息、Git 提交記錄、網頁等多個渠道彙總信息，最後生成了這一頁。
流程圖加代碼加註意事項，佈局清晰，信息密度高。
12自定義編輯器
這個確實讓我覺得有點意思。
上圖是一個 feature flag 的編輯器。左邊是開關列表，按分類分組。注意看 streaming.partial_json 那一項，它被紅框標出來了，因為它依賴的 streaming.delta_events 目前是關閉狀態。
右邊是剪貼板預覽：只導出你改過的 key，生成一段 diff，直接可以粘貼回 Claude Code 讓它去更新配置和文檔。
Thariq 把這類場景稱為「一次性編輯器」：
“ 讓 Claude 給你做一個專門用於這一次任務的 HTML 編輯器。調完參數，導出結果，用完即扔。
這個思路還能用在很多地方：工單排序、數據集標註、prompt 調優、cron 表達式編輯……只要你覺得「用純文本描述太費勁」的場景，都可以讓 Claude 臨時搭個可視化工具。
13HTML 的代價
當然，Thariq 也沒有迴避 HTML 的問題。
生成速度上，HTML 比 Markdown 慢 2-4 倍。版本控制上，HTML 的 diff 噪聲大、不好審查。
有網友調侃：
“ 你說不喜歡讀長 Markdown 文件，結果寫了一篇很長的 Markdown 帖子。
（這篇長文正是用 Markdown 寫的）
Thariq 回了個：💀……
還有人質疑，這是不是你官方想要騙用戶多燒 token 呢？
Thariq 的回應是：Opus 4.7 已經有 100 萬 token 的上下文窗口了，HTML 多用的那點 token，在這個量級下幾乎可以忽略不計。
在我看來，這裏的關鍵在於：你寫了一份沒人看的 Markdown，和一份大家真的會看的 HTML，哪個更浪費？
14人，是視覺動物
話說回來，這其實不怪 Markdown，是由人的「硬件」條件（或者叫侷限）決定的。
根據認知科學的研究，人類獲取外部信息的 83% 靠視覺，11% 靠聽覺，兩者加起來佔了 94%。大腦皮層中，約 30% 的區域專門用來處理視覺信息，而聽覺只佔 3%。
人，本質上是視覺動物。
而 Markdown 呢？它是一維的、線性的。
雖然可以有二維表格，但總體上你還是得一行一行往下讀。當你的目光需要從頭掃到尾，一口氣看完一份幾百行的技術方案時，效率低不說，壓力也不小。
而 HTML 能做到的事情要豐富得多：二維甚至三維的空間佈局，色彩編碼，可摺疊的層級結構，可交互的組件。信息可以按照人眼的自然掃視習慣來組織，而不只是線性排列。
人看 Markdown 像讀一本沒有插圖的小說，看 HTML 像逛一個精心設計的展覽。
這裏武斷提一句，AI PPT、AI PDF 也終會消亡。在我看來，PPT 和 PDF 顯然也不會是 AI 時代信息傳遞的「原生語言」，它們最多，也就當個導出格式就好了。
15for AI 還是 for 人
這就引出了一個框架。
AI 和 AI 之間，Markdown (暫時）還是更好的選擇。
我們現在所有的 Skill、Agent 配置，包括 Claude 的 Artifacts，都以 Markdown 作為通用標準。它是更高濃度的信息壓縮，去掉了 HTML 的各種標籤、樣式、腳本這些「視覺噪聲」，對 token 更友好，AI 解析和生成起來也更高效。
給 AI 輸入的時候，Markdown 也更合適。同樣的信息，Markdown 用更少的字符就能表達清楚。
但一旦信息要面對人，Markdown 就開始顯出它的侷限性了。
細心的朋友可能會發現，我最近也在公眾號文章中加了一些可以運動、可以交互的 SVG 插圖，比如你正在讀的這篇文章裏就有。相比於純文字，它多了一層視覺交互，我想會帶來不一樣的閲讀體驗。
在文字之外，用更豐富的視覺和交互來溝通，微信 svg 的坑實在是太多了，我五一期間打磨了好久……後面穩定一些了我可能會開源出來（如果有人需要）。
16HTML 之外
關於 Markdown 和 HTML 的討論，在我看來本質的問題是：AI 到人的信息帶寬。
信息在 AI 和人之間的流動，無非就是兩個：輸入和輸出。
人的信息輸出端，我之前也偶爾有提到，比如：我做了一個 AI 時代的效率神器，已開源
而 Markdown 到 HTML 的升級，解決的是人的輸入端，如何讓 AI 交付的結果更適合人的視覺系統去消化。
但這一步，在我看來其實還不太夠。
或許輸出端還可以繼續往前走幾步，也許是可交互的視頻，AI 不只是生成一個靜態頁面讓你自己看，而是帶着語音，像一個同事一樣給你講方案、走讀代碼、解釋數據，甚至可以隨時打斷和提問。當然，還有很多的可能方案。
輸入端也同樣有改進空間。現在人給 AI 的輸入主要還是文字，但人和人之間最自然的溝通方式不是鍵盤而是當面溝通，僅以說話為例也遠不只是語音轉文字那麼簡單，語氣、停頓、強調，這些都攜帶着大量的意圖信息。在這點上，我非常看好 OpenAI，他們在多模態和交互上有着更多的嘗試和積累。
Thariq 在他的文章結尾寫道：
“ 我用 HTML 的真正原因，是我覺得自己和 Claude 之間的關係更緊密了。我本來擔心，因為我已經不再認真讀那些方案，就只能放任 Claude 自己做決定。但現在，我反而覺得自己比以前更 in the loop 了。
當 AI 的能力越來越強，人和 AI 之間的信息帶寬，就成了瓶頸。
對人的信息輸入而言，如果說 Markdown 是一根水管，那 HTML 可以看作是一條河。
我在想，什麼樣才是一片海？
◇ ◆ ◇
相關連結：
• Thariq 原文：https://x.com/trq212/status/2052809885763747935
• HTML 示例站：https://thariqs.github.io/html-effectiveness/
• Thariq 的 X 主頁：https://x.com/trq212