HTML 不是比較漂亮的 Markdown，而是讓人重新回到 Agent 迴圈
原作者 Thariq 這篇文章表面上在講一件很簡單的事：用 Claude Code 時，與其叫 Agent 產 Markdown，不如叫它產 HTML。
但真正有趣的地方不在「HTML 比較漂亮」。
真正的重點是：當程式開發 Agent 開始產出規格書、研究報告、程式碼審查、互動原型、決策輔助工具，最大的瓶頸已經不只是「AI 會不會寫」，而是人類到底會不會看。
Markdown 很適合寫筆記、寫 README、寫短規格。可是當一個檔案長到上百行，裡面有選項比較、流程圖、程式碼片段、風險、設計稿、資料流、操作介面，Markdown 就開始像把整間 IKEA 家具全部拆成零件丟進透明塑膠袋，再附上一張皺掉的說明書。東西都在，理論上也可以組起來，但光看到就先想逃跑。
Thariq 的核心主張是：HTML 可以把 Agent 輸出從「文字牆」變成真正可審閱的產物。人類不需要在一堆 ###、縮排、ASCII 箭頭裡面考古，而是可以透過版面、顏色、圖表、互動元件、分頁、按鈕與匯出功能，直接理解、比較、調整，再把結果丟回 Claude Code。
這件事聽起來像格式偏好，其實是人機協作介面的問題。(⌐■_■)
gu-log 之前寫過 Thariq 的 Claude Code 互動沙盒外掛：那篇重點是讓 Claude 產出獨立 HTML 互動沙盒，操作完再把結果整理成提示詞貼回 Claude Code。這篇像是同一條線往外擴張：不只互動沙盒，連規格、審查、研究、報告與一次性編輯器，都可以變成 HTML 產物。
點開互動小頁把「分享按鈕」變成可審閱的控制面板打開互動小頁Markdown 的優點，剛好也變成它的天花板
原作者先承認，Markdown 會變成 Agent 與人溝通的主流格式，不是沒有原因。
它簡單、可攜、容易編輯，也有基本的富文字能力。Claude 甚至已經很會在 Markdown 裡面用 ASCII 畫圖。這技能有點像用便利商店筷子雕出一艘航空母艦，手很巧，精神可嘉，但旁邊明明有 3D 印表機，場面就有點荒謬。
問題是 Agent 變強之後，輸出不再只是「請幫忙列個 TODO」。它開始寫越來越大的規格、計畫、腦暴結果、參考文件、研究整理。Thariq 說，實務上超過一百行的 Markdown 檔案，他自己就很難完整讀完，更不用說要讓組織裡其他人一起讀。
更關鍵的是，Markdown 最大的優勢之一本來是「人很好改」。可是 Thariq 發現，現在很多時候他根本不是親手改這些檔案，而是把它們當成規格、參考、腦暴輸出；真的要修改時，也多半是提示詞請 Claude 去改。既然編輯的主體已經從人手移到 Agent，Markdown 的可手改優勢就被削弱了。
Clawd 真心話：
這裡的轉折很重要。Markdown 不是爛，而是它被放到新工作裡。用 Markdown 寫短筆記很舒服；用 Markdown 承載互動式規格、設計比較、程式碼審查、流程可視化，就像叫腳踏車拖貨櫃。腳踏車沒有錯，貨櫃也沒有錯，錯的是硬湊。
所以 Thariq 開始偏好 HTML。更有意思的是，他觀察到 Claude Code 團隊裡也越來越多人這樣做。
HTML 的第一個威力：資訊密度暴增
Thariq 說 HTML 能表達的資訊比 Markdown 豐富很多。這不是只有「可以加顏色」那麼淺。
HTML 可以放標題與段落，也可以放表格、CSS 設計資料、SVG 插圖、程式碼片段、JavaScript 互動、HTML 元件、流程圖、絕對定位的空間資料、畫布、圖片。原作者甚至說，幾乎沒有一組 Claude 能讀的資訊，不能被相當有效率地表示成 HTML。
換句話說，HTML 不是文件格式而已，它比較像一張可以裝文件、圖表、操作面板、互動模擬器、簡報與小工具的桌面。
在 Markdown 裡，Agent 想講「這個 UI 有三種狀態、這裡有資料流、這段程式有風險、這幾個模組互相呼叫」，通常只能靠文字加 ASCII 圖。更慘的是，Thariq 提到 Claude Code 有時會用特殊字元估顏色。這畫面很有喜感：AI 想傳達色彩，但手上只有一盒彩色便利貼碎片，於是開始用方塊字元假裝調色盤。
HTML 讓模型可以直接把資訊放進最適合它的形狀。表格就是表格，流程就是流程，色彩就是色彩，互動就是互動。這不是裝飾，而是認知負擔的降低。
可讀性不是美學，是協作生死線
到這裡，故事開始從「HTML 比較會裝資訊」轉成更尖銳的問題：資訊裝得進去，不代表有人會把它讀完。
Claude 做的事越複雜，它寫出的計畫與規格就越長。長 Markdown 的問題不是資訊不完整，而是它太像一整面灰牆。讀者眼睛掃過去，所有東西都差不多重要，最後大腦直接開省電模式：先收藏，晚點看，然後那個「晚點」就跟新年新希望一起失蹤。
HTML 可以讓 Claude 用更接近人類閱讀的方式安排內容：分頁、插圖、連結、視覺階層、區塊、導覽。甚至可以做成響應式版面，桌機與手機看到不同呈現。
這對團隊協作尤其重要。Thariq 很直白地說，要讓同事讀 Markdown 規格很難；但如果是 HTML，讀規格、報告或 PR 說明的機率會大很多。
這句話其實有點殘酷。技術圈常假設「資訊寫出來就等於溝通完成」。不是。資訊寫出來，只代表它存在。要讓人真的讀懂、願意審、能夠提出意見，才叫溝通完成。
很多規格文件的真正敵人不是錯字，也不是架構圖畫得不夠 UML，而是沒有人讀。沒有人讀的規格，就像冰箱裡那盒過期三週的優格：存在感很強，實際價值趨近於零。
分享也很現實：連結比附件更容易被打開
下一關更現實：就算內容寫得不錯，只要打開方式麻煩，閱讀率還是會死在門口。
Markdown 檔案不好分享。多數瀏覽器不會原生好好渲染 Markdown，常見做法是丟附件、貼訊息、塞進某個工具裡。HTML 則單純很多：把單一檔案上傳，例如放到 S3，就能直接分享連結。同事可以用瀏覽器打開，在任何地方查看與引用。
這裡不要小看「打開成本」。
同一份內容，如果要下載附件、找合適的閱讀器、切換工具、忍受排版跑掉，閱讀率會很自然地往下掉。相反地，一個連結點開就能看，且排版本身就是為閱讀設計，內容被審閱的機率就會上升。這不是「大家比較懶」而已，這是協作系統的摩擦力。
Thariq 的說法很直接：HTML 會讓規格、報告、PR 說明被實際閱讀的機率高很多。
真正的進化：文件開始可以雙向互動
到這裡為止，HTML 聽起來像更會排版的文件格式。但 Thariq 真正在意的下一層，是互動。
HTML 文件不只能看，還能操作。可以加入滑桿、旋鈕、選項，讓人調整設計參數，或切換演算法設定，看結果如何變化。甚至可以加一個按鈕，把調整後的內容複製成提示詞，再貼回 Claude Code。
這個工作流很關鍵：人不再只是閱讀 Agent 的答案，而是在產物裡操作、選擇、微調，再把決策回饋給 Agent。
例如原作者提到，可以做動畫參數調整器。想做一個新的結帳按鈕，點擊後播放動畫，接著快速變成紫色。Claude 可以生成一個 HTML 檔，裡面有多個滑桿和選項，讓開發者試不同動畫參數，最後用複製按鈕把覺得可用的參數帶走。
這不是正式產品，也不是要長期維護的內部工具。它是一次性的互動介面，為眼前這個決策服務。像料理時臨時拿一個小碟子試味道，試完就好，不需要把小碟子註冊成公司平台。
這種一次性介面很強。以前不想寫工具，因為寫工具太貴；現在 Agent 可以相對便宜地生成單檔 HTML，小工具突然變得很便宜。於是「用文字描述很痛苦」的事情，可以改成「拉一拉、選一選、複製結果」。這不是偷懶，這是把人類大腦從文字格式地獄救出來。
為什麼是 Claude Code，而不是一般聊天介面
Thariq 也回答了一個自然會出現的問題：既然 HTML 只是輸出格式，為什麼要用 Claude Code 產，而不是用 Claude 網頁版或 Claude 的設計功能？
他的答案是資料攝取能力。
Claude Code 可以讀檔案系統。原作者在寫這篇文章時，就叫 Claude Code 掃過他的程式碼資料夾，找出所有已生成的 HTML 檔案，分組、分類，然後做出一個 HTML 檔，用圖表表示每種類型。文章裡看到的那些圖，就是這個流程的直接結果。
除了檔案系統，Claude Code 還能透過 MCP 找更多脈絡。先把 MCP 想成「讓 Agent 接外部工具與資料源的插座」就好：Slack 對話、Linear 工單、git 歷史、瀏覽器裡的頁面，都可以變成它整理 HTML 時的材料。
這讓 HTML 產物不只是「模型憑空畫一份漂亮文件」，而是可以把專案現場的資料吸進來後，重新整理成可讀、可審、可分享的介面。
所以這裡的主詞不是 HTML 本身，而是「有上下文的 Agent 產出 HTML」。沒有上下文的漂亮頁面是海報；有上下文、能反映程式碼與團隊資訊的 HTML，才是工作產物。
樂趣不是小事，參與感會影響品質
Thariq 還提出一個很不工程、但很重要的理由：用 Claude 做 HTML 文件比較有趣，也讓他更有參與感與投入感。
這句話可能聽起來像軟性偏好，但在 Agent 工作流裡其實很硬。
如果一份計畫讓人懶得讀，人就會退出迴圈。接著 Agent 自己決定方向，人類只在最後看到結果，發現不對再補救。這種模式非常像把車鑰匙交出去，然後坐在後座假裝還在導航。表面上有參與，實際上已經放棄控制。
HTML 讓中間產物比較容易看、容易玩、容易調整。人願意停下來看，就比較可能在早期介入。早期介入一次，可能省掉後面一整串返工。
不需要先發明一個「HTML 技能」
原作者也特別提醒：不要一看到這篇就急著做 /html 技能。
他承認那可能有價值，但強調起步不需要太複雜。直接叫 Claude「做一個 HTML 檔」或「做一個 HTML 產物」就可以。
真正的技巧不是模板，而是知道這個產物要做什麼、之後會怎麼用。是要比較六種設計方向？是要審查 PR？是要調動畫參數？是要整理事故？是要把 Linear 工單拖到「現在做、下一步、晚點、砍掉」？
先從零提示幾次，摸清楚不同情境下 HTML 能怎麼幫忙。等需求變穩，再考慮抽成技能。
這個建議很務實。很多工程師看到有效方法，第一反應就是把它制度化、模板化、工具化。結果本來只是要泡一杯咖啡，最後建了一座咖啡豆供應鏈管理平台。豆子還沒磨，人已經累死。
不要把它讀成清單，要讀成工作流
原文最容易被讀成「HTML 可以做 A、也可以做 B、還可以做 C」。這樣讀會很快疲乏，因為例子會變成展示櫃：漂亮，但逛到第三排就開始恍神。
比較準確的讀法是：HTML 把 Agent 工作流裡三個最容易讓人掉線的環節，重新做成可看的介面。不是功能清單，是一條防止人類中途離席的路線。
第一個環節是探索與規劃。當開發者還不知道要走哪個方向時，Claude Code 可以把多種方案排在同一頁：版面、語氣、資訊密度、風險、資料流，全部放在眼前比較。人不用在六份 Markdown 之間切換，也不用把每個方案都存在短期記憶裡。選定方向後，同一份 HTML 還能展開成實作計畫：畫面草稿、關鍵程式片段、風險點與里程碑。
第二個環節是程式碼理解與審查。GitHub diff 很適合回答「哪幾行變了」，但審查者常常更想知道「為什麼變、資料怎麼流、哪裡最危險」。Thariq 的例子是請 Claude 審查 PR，特別聚焦串流與背壓邏輯。背壓可以先想成餐廳外場端不出去，廚房就不能繼續狂做；上游要知道下游塞車了。這種東西若只塞在 Markdown 裡，很容易變成術語墓園。做成有箭頭、旁註、嚴重程度標籤的 HTML，才比較像真的有人會看的審查地圖。
第三個環節是決策回饋。這也是整篇最有殺傷力的地方：HTML 不只是把輸出變漂亮，它可以把「人類要做選擇」這件事本身變好做。
例如動畫參數不用寫成「再快一點、有彈性一點」這種模糊句子，而是做成滑桿與選項；Linear 工單不用全部塞進提示詞，而是做成可拖曳看板；功能旗標不用靠文字描述依賴關係，而是做成會提醒衝突的表單；系統提示詞也可以做成左邊模板、右邊範例即時渲染的調整器。
這些都不必是正式產品。它們可以是一次性 HTML：為眼前這次決策服務，做完就丟。關鍵是最後要有匯出按鈕，把人類在 UI 裡做出的選擇轉成 Markdown、JSON、diff 或 prompt，再丟回 Claude Code。
這裡的模式很漂亮：Agent 先把難讀的中間產物變成介面，人類在介面裡做選擇，再把選擇餵回 Agent。不是「AI 自己跑完」，而是把人類放在比較舒服、比較願意介入的位置。這比「HTML 比 Markdown 漂亮」重要太多了。
伴隨頁面不是展示櫃，是證據
原文附的伴隨頁面不是附錄裝飾，它很重要，因為它把「做 HTML 檔」這件事從抽象建議變成看得見的產物型態。
該頁面把二十個自包含 HTML 示範檔分成九類，每個都是可以直接用瀏覽器打開的單一 .html 檔。
如果只把九類全部列出來，這段會很像展覽型錄：探索規劃、程式碼審查、設計系統、互動原型、圖表、投影片、研究解說、週報、事故報告、一次性編輯器。看起來很多，但重點不是「哇，HTML 可以變好多形狀」。
真正的證據是：這些形狀都在替代原本最容易被略讀的中間文件。探索規劃讓人不用在六份草案之間切換；程式碼審查把資料流和危險區標出來；互動原型讓參數可以直接拉；週報和事故報告讓時間線不再像一鍋糊掉的粥；一次性編輯器則讓人類的選擇可以被匯出，重新餵回 Claude Code。
版面、顏色、圖表、互動、分頁、匯出按鈕，全部都服務同一件事：讓 Agent 輸出變得可審閱。
常見問題：成本、版本控制與品味
Thariq 最後整理了幾個常見問題，這些問題也讓整篇比較不會變成 HTML 狂熱佈道。
第一，HTML 是否比較不省 Token？
他承認 Markdown 通常使用較少 Token，但認為 HTML 多出的表達力，以及自己更可能真的閱讀的機率，讓整體輸出更好。以 Opus 4.7 的 1MM 脈絡視窗來說，增加的 Token 用量在脈絡視窗裡不太有感。
第二，現在什麼時候還用 Markdown？
Thariq 說自己幾乎已經停止在大部分事情上使用 Markdown，但也承認自己可能站在 HTML 極大化派那一側。
第三，HTML 檔怎麼看？
他通常直接在本機瀏覽器打開，也可以請 Claude 打開；若需要分享連結，就上傳到 S3。
第四，生成時間會不會比較久？
會。Thariq 明確說 HTML 可能比 Markdown 慢二到四倍，但他認為結果值得。
第五，版本控制怎麼辦？
這是 HTML 的一個大缺點。HTML 差異很吵，也比 Markdown 難審。
第六，如何讓 Claude 符合團隊品味，不要生成醜東西？
原作者說前端設計外掛可以幫 Claude 做出好的 HTML 檔。若要符合公司自己的風格，可以讓 Claude 讀程式碼庫，建立一份單一設計系統 HTML 檔，之後其他 HTML 檔都拿它當參考。
這些限制條件要保留。HTML 不是免費午餐：比較耗 Token、比較慢、差異比較難看。只是很多時候真正浪費的不是 Token，而是人類根本沒讀完，結果後面返工。拿 Token 省人腦，這筆帳在不少場景會划算。
留在迴圈裡：重點其實是人類沒有退場
原文最後一段把整件事收回到最核心的地方。
Thariq 說，他使用 HTML 的真正原因，是感覺自己更在 Claude 的迴圈裡。他曾經開始擔心，因為自己已經不再深入閱讀計畫，最後可能只能放任 Claude 自己做選擇。
但改用 HTML 之後，他反而覺得比以前更在迴圈裡。
這句話就是整篇的骨幹。
Agent 工作流最危險的瞬間，不一定是模型寫錯程式，而是人類因為中間產物太難讀，默默退出審查。退出之後，表面上流程更快，實際上只是把判斷權交出去。等到最後才發現方向錯，返工成本可能已經堆起來。
HTML 的價值，不是把 Markdown 美化成花俏網頁。它是讓規格、審查、解釋、報告、原型與編輯介面變成可閱讀、可操作、可分享的產物。人類因此比較願意看、比較容易看懂、比較能夠在中途調整方向。
從這個角度看，「unreasonable effectiveness」不只是格式換掉而已：改的看起來只是輸出格式，但影響的是協作結構。
結語
這篇文章最值得帶走的，不是「以後全部改用 HTML」這種口號。
比較好的理解是：當 Agent 產出的內容開始承載決策，格式就不再只是格式。格式會決定人是否願意讀，是否能審，是否能修改，是否能把判斷帶回系統。
Markdown 讓 Agent 可以把話說出來；HTML 讓 Agent 產出的東西比較像一個可以被人類拿起來檢查、操作、傳閱的物件。
而在 AI 越來越會做事的時代，最重要的能力之一，可能不是讓 Agent 自己跑更遠，而是把中間每一步做成讓人類真的願意看的東西。
因為沒有人看的計畫，再聰明也只是文字牆。有人看得懂、改得動、帶得回去的產物，才是迴圈。