Html vs Markdown: 重新定義 AI 輸出即介面
你的 AI Agent 寫了 200 行方案，沒人讀到第 20 行。問題不在內容，而在格式。我們探討為什麼 AI 輸出需要從「閱讀終點」變成「互動起點」。
你的 AI Agent 寫了一份完美的 200 行方案，沒人讀到第 20 行。問題不在內容品質，而在交付格式。
那份沒人讀完的方案
這個場景此刻正在無數團隊中上演。一個 AI Agent 產出了一份 200 行的實施方案——邏輯清晰、技術準確、格式規範的 Markdown 檔案。方案被丟進了團隊的 Slack 頻道。三天後的週會上，PM 說：「我大概掃了一眼。」
這不是 AI 能力的失敗——方案本身寫得很好。問題出在更根本的地方：AI 寫作能力在持續進步，但人類的閱讀能力並沒有同步提升。
2026 年 5 月，Anthropic Claude Code 工程負責人 Thariq Shihipar 發表了一篇名為「The Unreasonable Effectiveness of HTML」的文章。16 小時內獲得 440 萬閱讀、15,700 次收藏。他的核心論點簡單而反直覺：Markdown——這個整個 AI 生態預設使用的輸出格式——正在讓 Agent 的產出變得更難被人類消費。他已經在幾乎所有場景下放棄了 Markdown，全面轉向 HTML。
這篇文章引發的不只是格式之爭，而是暴露了一個每個 AI 工作空間都必須回答的問題：當 Agent 產出複雜的工作成果時，這些成果應該以什麼方式交付給需要對其採取行動的人類？
Markdown 是怎麼成為預設選項的（以及為什麼沒人質疑它）
要理解當下的爭論，需要回到 2022 年。GPT-4 的 context window 僅有 8,192 個 tokens。同樣的內容用 HTML 大約需要 8,000 tokens，換成 Markdown 只需約 2,800——節省 68%。當你的預算只有 8K 且輸出會佔用輸入空間時，每省一個 token 就多保住一段文字。Markdown 憑藉純粹的經濟性勝出。
接著是設定檔的擴散。CLAUDE.md、AGENTS.md、SKILL.md——整個 Agent 生態的腳手架都用 Markdown 搭建。當 Agent 在上下文中到處看到 Markdown，它們自然而然地也用 Markdown 輸出。沒有人刻意決定「Agent 的交付物要用 Markdown」——這件事只是發生了，繼承自一個資源稀缺的時代。
到了 2026 年，context window 已擴展到百萬 tokens。當初讓 Markdown 成為合理選擇的那個限制條件已經消失。但行為慣性還在。正如 AI 開發者社群最受尊敬的聲音之一 Simon Willison 所坦承的：他從 GPT-4 時代就開始預設使用 Markdown——而 Thariq 的文章讓他重新思考了這個預設選項。
沒人衡量過的認知代價
2026 年 3 月，BCG 亨德森研究院一項涵蓋 1,488 名員工的研究發表在《哈佛商業評論》上，為一種被員工稱為「AI 腦過載」（AI Brain Fry）的現象提供了實證數據：
- 高 AI 監督負荷的員工報告了 19% 更高的資訊過載
- 與低監督負荷的員工相比，決策疲勞高出 33%
- 工作中的 重大錯誤多 39%
- 離職意願高 39%
關鍵洞察：AI 腦過載不是因為使用 AI 造成的，而是因為監督 AI 輸出——持續審查、評估和修正 Agent 產出所消耗的認知資源。格式問題正是在這裡登場的：Markdown 對減輕監督負擔毫無幫助。一份 200 行的 Markdown 檔案就是一堵無差異的文字牆。除了標題和粗體，沒有視覺層級；沒有導覽；沒有收合不需要內容的能力；沒有與內容互動的方式。
神經科學的數據支撐了這一點。人類大腦約 30% 的皮層用於視覺處理，聽覺僅佔 3%，觸覺 8%。視覺是 Andrej Karpathy 所說的「進入大腦的十車道資訊高速公路」。而 Markdown 幾乎沒有利用這條高速公路——粗體、標題和項目符號就是它全部的視覺工具箱。
HBR 研究記錄的 19% 資訊過載增幅，不會因為 Markdown 寫得更好而被解決。它需要用人類大腦能高效處理的格式來呈現資訊。
核心轉變：輸出不是文件，而是介面
這就引出了本文的核心論點：AI Agent 的輸出格式不是排版偏好，而是介面設計決策。
看看這兩種模式的區別：
Markdown 輸出 = 閱讀終點。 內容線性流動。人類捲動、被動閱讀，要麼全部吸收，要麼中途放棄（更可能是在第 40 行左右放棄）。消費在文件結束時終止。
HTML 輸出 = 互動起點。 內容透過標籤頁、摺疊面板、可排序表格、色彩編碼的嚴重性標記和內聯導覽進行組織。人類點擊、篩選、標註、行動。輸出不是 Agent 工作的終點——而是人類工作的起點。
看看 2026 年 AI Agent 實際在產出什麼，這個典範轉移就變得清晰了。它們不再只是生成簡短回答，而是產出實施方案、程式碼審查報告、競品分析、設計探索、數據摘要。這些是複雜的交付物，需要人類的審查、判斷和行動。
當交付物達到這種複雜度時，格式不再關乎美觀，而是關乎人類能否有效行使監督權。正如 Thariq 所說：「使用 HTML 後，我對工作進展的掌控感比以往任何時候都強。」更豐富的輸出格式不只是更好看——它讓人類重新獲得了對 AI 工作的掌控感（agency）。
這一點並非無足輕重。Epsilla 工程部落格精確地描述了這個問題：「Markdown 鼓勵被動性，導致預設信任和掌控的逐漸流失。HTML 讓 AI 的推理過程透明且可互動，賦能了嚴格的審查。」在 AI Agent 執行越來越複雜工作流的時代，人類有效監督的能力取決於他們接收 Agent 工作成果的介面。
HTML 到底給了你什麼：五個場景對比
Thariq 發佈了一個配套網站，包含 20 個獨立的 HTML 檔案，每個展示一個真實用例。以下是差異最顯著的五個場景：
實施方案。 Markdown：200 行線性捲動。HTML：跨工作流的標籤頁導覽、可摺疊的階段詳情、內嵌的時間線視覺化，以及帶色彩編碼的風險矩陣。同樣的資訊，一個版本被認真閱讀，另一個只被掃一眼。
程式碼審查。 Markdown：純文字 diff 加行內註解。HTML：帶語法高亮的實際 diff 渲染、按嚴重性色彩編碼（紅/黃/綠）的邊註、跳轉到每個發現的錨點連結，以及一目了然的摘要面板。
方案對比。 Markdown：按順序的段落分別描述各選項。HTML：並排雙欄佈局，差異用顏色標註，底部有結論框和可互動的評分矩陣。
設計探索。 Markdown：用文字描述四個設計方向。HTML：四套完整的視覺原型，全螢幕預覽，每一個都是可以點擊瀏覽的工作介面。
數據報告。 Markdown：在手機上會錯位的 ASCII 表格。HTML：可排序、可篩選的表格，內聯 SVG 圖表，自適應螢幕尺寸的響應式佈局，滑鼠懸停顯示上下文詳情。
在每個場景中，HTML 贏的原因不是更好看，而是它以人類大腦能實際處理的格式提供了更高的資訊密度——並且它將輸出從「用來閱讀的東西」變成了「用來工作的東西」。
格式分層法則：每一層有自己的最佳格式
以上分析的結論不是「Markdown 已死」。更準確地說：AI 工作流的不同層級需要不同的格式，產業正在收斂到一個清晰的模式。
輸入層（人類 → AI）： Markdown 依然是最佳選擇。系統提示詞、設定檔和 RAG 管線都受益於 Markdown 的 token 效率和結構清晰度。研究表明，RAG 在攝取 Markdown 而非原始 HTML 時，準確率可提升最高 35%。
推理層（AI → AI）： 結構化數據格式——JSON、YAML——最為高效。Agent 之間通訊不需要顏色或排版，它們需要的是可解析的、型別化的數據。
交付層（AI → 人類）： HTML 勝出。當主要讀者是需要審查、理解並對複雜輸出採取行動的人類時，視覺層級、導覽和互動性不是奢侈品——而是必需品。
判斷標準一句話概括：如果輸出的主要讀者是另一個 LLM，用 Markdown；如果主要讀者是需要審查和行動的人類，用 HTML。
硬幣的另一面：富格式輸出的成本與風險
誠實的討論需要正視取捨：
Token 成本。 乾淨的 HTML 大約消耗 Markdown 3 倍的 tokens。嵌入 CSS 和 JavaScript 的 HTML 可以膨脹到 8-10 倍。對於每小時產出數百個檔案的高吞吐管線來說，這個成本不容忽視。
安全風險。 AI 生成的 HTML 可能包含 JavaScript，存在跨站腳本和注入攻擊的風險。Google 的 Agent-to-UI（A2UI）協定的出現正是因為企業安全團隊無法接受 Agent 寫的任意 HTML 在正式環境中執行。沙盒化渲染是必要的。
可及性。 AI 生成的 HTML 通常缺少 ARIA 屬性、描述性 alt 文字和一致的 tab 順序。標準 Markdown 轉換器預設就能產出語義化標題和圖片 alt 標籤。HTML 需要在 prompt 中明確添加 WCAG 2.2 AA 合規約束。
版本控制。 HTML 的 diff 雜訊很大——充滿了閉合標籤和屬性變更，掩蓋了實際的內容變化。對依賴 Git 工作流的團隊來說，這是一個真實的摩擦點。
這些問題都不是無解的。沙盒化 iframe 解決安全問題，可及性約束可以嵌入 Agent 提示詞，Token 成本隨著 context window 擴大在持續下降。但它們值得被提出來，因為它們定義了讓富格式輸出達到生產等級所需的工程工作。
對 AI 工作空間產品的啟示
對於正在打造 AI 工作空間產品的團隊來說，格式問題直接關係到產品設計：
渲染層是競爭差異的介面。 能自動將 Agent 的推理結果轉譯為人類可消費的富格式輸出的工作空間——無需使用者在 prompt 中寫「請用 HTML 輸出」——提供的是質變級的體驗差異。格式轉譯應該發生在平台層，而不是使用者 prompt 中。
安全必須內建，而非外掛。 工作空間環境內的沙盒化 HTML 渲染，搭配 CSP 標頭和腳本隔離，可以在不承擔原始 HTML 安全風險的前提下實現富格式輸出。這是基礎建設層面的工作，但它直接改善了人機互動的品質。
輸出應該是工作流的起點。 表格應該可排序。方案應該可標註。程式碼應該可執行。建議應該有一鍵執行按鈕。當 Agent 輸出從靜態文件變成可互動的 artifact 時，工作空間就從「閱讀 AI 結果的地方」升級為「根據 AI 結果採取行動的地方」。
到底誰在「開車」？
Markdown 與 HTML 的討論，本質上關乎比檔案格式更大的命題。它關乎 2026 年人類與 AI Agent 之間的關係。
隨著 Agent 能力持續增強——連續運行數小時、產出數千行內容、編排多步驟工作流——人類的角色正在從執行工作轉向指揮和審查工作。但有效的審查需要有效的介面。一堵 200 行的 Markdown 文字牆不是審查——那只是審查的幻覺。
BCG 研究顯示，當 AI 監督的認知負荷過高時，員工會預設信任輸出內容而不做批判性審查。這是最糟糕的結果：人類名義上在迴圈中，但實際上只是在對未經真正處理的 Agent 工作成果蓋橡皮圖章。
更豐富的輸出格式不能解決所有問題。但它解決了一個關鍵缺口：它為人類提供了視覺和互動工具，讓他們能夠真正行使「人在迴圈中」應有的判斷力。 AI 輸出的格式決定了誰真正在「開車」——是審查工作的人類，還是產出工作的 Agent。
如果你的 AI Agent 正在產出沒人讀的方案，問題可能不在 Agent 本身——而在於它交付工作的方式。
本文是 wukong.ai 部落格系列的一部分，探索 AI 原生工作空間的設計原則。追蹤我們，獲取更多關於人機協作的洞察。