HTML是AI代理想要的格式

2026年5月8日，在Anthropic負責Claude Code的工程師Thariq Shihipar，於個人網站發布了一組由代理生成的20個HTML成品，涵蓋9類知識工作。他的論點很直接：當答案承載空間結構、互動，或視覺證據時，HTML勝過Markdown。¹²

HTML比Markdown更適合作為代理輸出，因為空間結構、互動與視覺證據能承載散文會壓平的資訊。代理輸出的格式，就是人類檢查的控制介面，而不是包在外面的容器。

這篇文章發布6天後，5月14日的一篇arXiv論文指出，代理搜尋品質取決於執行環境，而不是檢索器。³同樣的模式再次出現：格式與執行環境是基底，不是外包裝。只有在周邊介面能把模型輸出轉成可供人驗證的東西之後，元件本身才真正有意義。

太長不看

Thariq Shihipar推出了一個配套網站，展示20個HTML範例，橫跨程式碼審查、設計系統、原型製作、探索、圖表、研究、報告與編輯器介面。¹核心主張是：Markdown會把原本以空間方式抵達的資訊線性化。差異比較、呼叫圖、並排對照與互動式原型，都帶有散文會壓平的意義。8Ktoken的GPT-4發布年代，讓Markdown成為節省token的預設選項；但目前Claude的脈絡視窗文件已列出200Ktoken與1Mtoken模型，許多成品規模下的取捨已經改變。⁴⁵對FastAPI加HTMX這類伺服器端渲染、無建置的網頁技術棧而言，這篇文章補上了代理端的理由：HTML是模型想產生的格式，也是瀏覽器早已能渲染的格式。繞經Markdown只會多一道翻譯步驟，兩端都損失保真度。⁶

重點整理

給代理建構者： - 當答案是比較、差異、流程圖，或可導覽結構時，不要再預設用Markdown輸出。請要求HTML，讓代理直接承諾一個空間版面。¹ - 把模型輸出格式視為工具介面的一部分。單一渲染成品，比一段不斷捲過去的對話紀錄更容易檢查。⁷

給介面設計師： - HTML就是您的設計系統本來就會交付的媒介。繞經Markdown會先引入一次失真的轉譯，渲染時又再轉譯一次。¹ - 代理產生什麼，控制介面就是什麼。若人類看不到代理所看到的東西，這個介面就是壞的。⁷

給採用伺服器端渲染、無建置技術棧的團隊： - 選擇HTML而不是建置管線，如今也有了代理端的驗證：模型想產生的格式，和瀏覽器早已能渲染的格式，是同一個。⁶ - 伺服器端渲染網站會移除兩層轉譯：一次在建置步驟，一次在代理輸出步驟。兩者相乘，效果會累積。

Thariq實際主張了什麼

Shihipar在Anthropic負責Claude Code；這篇文章發布於他的個人網站，而不是Anthropic官方部落格。²配套展示頁包含20個自成一體、由代理生成的HTML檔案，分成9類工作。這些場景裡，HTML在結構上勝過Markdown。¹

他的核心主張如下：

對任何建構網頁基礎設施的人而言，第二點最關鍵。若設計系統交付HTML，代理就應該產生HTML。其他格式都會導入一次有損的來回轉換。

20個範例本身就是論證

Shihipar展示頁上的分類，涵蓋了多數人如今會交給程式碼代理的工作：¹

• 程式碼審查：帶有嚴重度標記的行內註解差異；高亮呼叫路徑的模組地圖。
• 探索：並排比較的程式碼方案；以便選擇而非循序閱讀的視覺設計選項。
• 設計：可運作的設計系統頁面；能實際渲染各種變體的元件變體表。
• 原型製作：具備真實緩動曲線的動畫沙箱；會回應點擊的互動流程。
• 圖表：行內SVG圖形；附註解的流程圖；方塊與箭頭架構草圖。
• 研究：可收合區段；搭配即時示範的互動式概念解說。
• 報告：經過格式化的時間軸與圖表，結構本身就承載意義。
• 編輯器：把匯出功能嵌入成品內的自訂介面。

每一個都是模型一次生成的HTML頁面。共同模式是：答案本身具有空間性或互動性，而渲染後的成品保留了Markdown回覆只能用文字描述的東西。

為什麼預設曾經是Markdown

Markdown成為代理輸出的預設，有兩個理由；但這兩個理由現在都不再成立。

第一，GPT-3.5與GPT-4世代在聊天輸出慣例定型時，脈絡視窗大多落在4K到8K範圍。⁴Markdown的精簡確實形成限制條件：花在<div class="...">上的token，就不能拿來分析。如今Claude的脈絡視窗文件列出許多模型具備200Ktoken脈絡，Opus 4.1與Sonnet 4.6則具備1Mtoken脈絡。⁵對許多檢查型成品而言，token效率這個理由已經弱化。

第二，終端機渲染器與聊天視窗能輕鬆顯示Markdown，而HTML需要網頁檢視或瀏覽器分頁。這種介面便利性讓Markdown在token理由消退後，仍然維持阻力最小的路徑。

Shihipar這篇文章之所以有分量，是因為作者在Anthropic負責Claude Code。那20個範例是具體成品，不是抽象主張。²Simon Willison同日的報導也重現了同一模式：Linux安全漏洞解說被渲染成互動式HTML頁面，而不是Markdown文章。⁸

HTML保留了Markdown丟掉的什麼

這個論點由4個特性支撐：

每一個特性，都對應到一類代理任務；一旦輸出被壓平成散文，任務就會變難。差異比較是空間比較，流程圖是圖，設計系統審查是視覺判斷。強迫這些內容通過Markdown，等於要求讀者自行重建渲染器本來可以直接呈現的東西。

與執行環境的關聯

代理搜尋品質取決於執行環境，而不是檢索器。那篇文章主張，檢索方法的重要性低於包住它的代理框架：提示形狀、工具介面、對話紀錄格式、結果交付、重試行為。³

HTML的論點把同一個框架延伸到輸出。模型能用任何格式產生正確答案；但您要求的格式，是執行環境契約的一部分。不同格式會產生不同的可驗證介面：

• Markdown交付：使用者從上讀到下，自行判斷重點，並在腦中重建結構。
• HTML交付：模型承諾一個結構，渲染器讓結構可掃視，使用者檢查，而不只是閱讀。

同樣的資料，不同的控制介面。代理式設計就是控制介面設計。代理輸出的格式，是這個介面的一部分，而不是外層包裝。⁷

這對無建置技術棧意味著什麼

本站的FastAPI加HTMX指南主張用伺服器端渲染HTML，取代JavaScript建置管線。⁶Shihipar的文章補上了代理端的理由：

• 模型想產生HTML。
• 瀏覽器想渲染HTML。
• 在兩者之間插入Markdown或JSX，會增加兩道有損轉譯。

無建置的伺服器端渲染網站，移除了建置時轉譯。代理直接產生HTML，則移除了輸出時轉譯。兩者疊加後的收益是：同一種格式能從模型一路經過路由到瀏覽器，不必經過中間形式。

這並不是說React或Markdown到處都錯。重點是：轉譯步驟的成本，如今已經從兩端都看得見；能避開兩端成本的技術棧，也會按比例變得更簡單。

格式重要。執行環境重要。兩者都是基底。

代理搜尋論文與HTML文章相隔8天發布，卻提出同樣形狀的論點：¹³

• 檢索器是元件。執行環境是基底。
• 模型是元件。輸出格式是基底。

元件思維不斷提供局部升級：更換檢索器、加入記憶、替換模型、微調提示。基底思維則改變使用者看到的介面，也改變代理產生的介面。本週這兩個發現，都把工作推向後者。

實務上的做法是：當代理答案承載空間資訊時，請要求HTML。當代理在框架中執行時，先檢測框架，再檢測模型。這兩件事會相互加成。任何一件單獨來看，都不是萬靈丹。

FAQ

這篇文章是Anthropic發布的嗎？

不是。Thariq Shihipar將它發布在個人網站：thariqs.github.io/html-effectiveness/。¹他在Anthropic負責Claude Code，因此權威訊號很強；但這篇文章不是Anthropic的官方發布。²

這個論點適用於每一種代理任務嗎？

不適用。這篇文章明確針對空間結構、互動或視覺證據承載意義的工作。對簡短事實答案或受限於終端機的輸出而言，Markdown仍然是很好的預設選項。¹

token成本怎麼辦？

Markdown的成本優勢，原本就綁定在小型脈絡視窗時代。Claude目前的脈絡視窗文件列出200Ktoken與1Mtoken模型；對文章展示的那些成品規模而言，這已經改變了HTML冗長度的取捨。⁵

這會破壞Claude Code既有的Markdown預設嗎？

不會。這個論點談的是您要求模型按需產生、用於檢查的輸出，不是對話紀錄或終端機輸出。您仍然可以在單一提示中要求HTML，並取得一個自成一體的成品。¹

這和代理搜尋執行環境論文有什麼關係？

兩個論點都指向模型周邊的基底，而不是模型本身。搜尋品質取決於代理框架；輸出品質取決於格式。元件不可或缺；但基底讓元件變得可靠。³

FastAPI加HTMX團隊該怎麼做？

把HTML視為您所交付任何AI功能的一級輸出目標。同一種格式能從模型經過路由一路到瀏覽器，而無建置技術棧本來就已經為這條路徑最佳化。⁶

參考資料