HTML 是新的 Markdown

資料來源#

• A Field Guide to Fable: Finding Your Unknowns
• Codex from 0 to 10M Users: Building ChatGPT Work - Akshay Nathan, OpenAI
• How I AI: Thariq Shihipar on Replacing Markdown with HTML for AI-Powered Development
• The new rules of context engineering for Claude 5 models

摘要#

Thariq Shihipar 在 Code with Claude（2026 年 5 月）向 Claire Vo 提出的論點是：「HTML 是新的 Markdown。」 Markdown 一直是人類與 LLM 互動的通用語言——簡單、有結構，雙方都看得懂。但隨著模型能力愈強、專案愈複雜，數千行的 Markdown 計畫會讓人類難以招架。我們看著看著就恍神、不再閱讀、不再參與，合作品質也隨之崩解。解方是改用更豐富的溝通媒介：視覺化、可捲動、可互動的 HTML 成品，讓人類從被動審閱者重新成為積極的協作者。

關鍵觀察是：限制因素不是模型，而是人類的注意力。

「問題不在於模型難以處理 Markdown——它們擅長得不得了——而在於 HTML 讓身處迴路中的我們這些人，更容易將正在進行的工作視覺化、與之互動，並持續掌握進度。」

它解決的失效模式#

Thariq 親口坦承了問題所在：面對長達數千行的計畫，「他會直接叫 Claude 修改計畫，而不是自己閱讀。」人類不再閱讀的計畫，也就不再由人類掌舵——原本藉由規劃建立的對齊便消失了。目標於是變成「做出一份你真的想讀的計畫」。

這是人類注意力上的對應問題，就像模型的 Context Window Smart Zone：模型無論宣稱的視窗有多大，超過約 100K tokens 後就會退化；人類審閱者也會在資訊量超過某個程度後，無論 Markdown 多完整都開始退化。HTML 把 tokens 用在提升易讀性（模型圖、結構、色彩、互動），而不是堆疊原始文字，因此擴大了人類有效的 smart zone。

HTML 帶來什麼#

當 Claude 被要求「用 HTML 檔案腦力激盪一些點子」時，回傳的不是清單，而是一個視覺化、可捲動的頁面——裡面有八個示範點子，各自附上模型圖、說明和風險評估。完整計畫的提示詞如下：

create a HTML file as a plan that helps me visualize what the implementation plan is.
Include excerpts, mockups, code, whatever is needed to give me like maximum context

產生的是單檔網站：有腳本式的介紹、檔案結構圖、程式碼片段，以及視覺情緒板。這是一份你可以閱讀、探索，並且分享給隊友的文件——隊友參與其中的可能性，遠高於面對一大份 Markdown 檔案。這個成品不只連結人類與 AI，也跨越工程團隊與公司的其他部門。

提示詞技巧：限制加上空間#

計畫提示詞裡有兩個細節是刻意安排的：

• 他把「excerpts」拼錯了，但完全不影響結果——模型能應付表層雜訊。
• **「任何能提供最多脈絡的內容都可以」**讓模型有發揮空間。這套理念是：提供足夠的限制，讓模型產出你要的東西，同時也留一點餘地，讓模型帶來驚喜。正如 Thariq 所說，「我總是得跟 Claude 說：『嘿，Claude，這裡我相信你。』」

這是把 The Bitter Lesson 應用到提示詞上的一個小型、可反覆實踐的例子——不要把結構規定得太細，讓擴大的能力自行補足；這也呼應了 Compute Allocator 的角色：人類設定方向，其他部分交給模型。

它化解的 harness 張力#

乍看之下，這似乎與 wiki 持續討論的 Harness Shrinkage as Models Improve 論點相矛盾（Cat Wu／Boris Cherny：每次推出新版本，鷹架都會縮小），也與 Interaction Models 相牴觸（Thinking Machines Lab：harness 會融入模型）。Thariq 卻提出相反說法——他只有約 1% 的 tokens 用於交付成果；99% 都花在鷹架上。

解法是：這是兩種不同的 harness。

• 逐漸縮小的 harness 面向模型——提示詞、指令、驗證機制，都是為了讓模型依預期行事。模型愈進步，這一層就愈精簡。
• 持續擴大的 harness 面向人類——各種成品（HTML 計畫、micro-apps、design systems），目的是讓人類保持對齊、投入，並有能力做出決策。模型愈進步，這一層反而會擴大，因為關鍵限制從「模型能不能做到」轉變為「人類能不能持續參與，並妥善分配運算資源」。

The Bitter Lesson 消解的是面向模型的結構；它不會消解面向人類的結構，因為後者的全部目的就是讓人類理解。HTML 成品正是位於這條界線的另一側。這種媒介意味著什麼角色，請見 Compute Allocator。

成品的用途（2026 年 7 月更新）#

最初的訪談說明了媒介；兩個月後，Thariq 的 field guide 則點出這種媒介的用途。「我之前寫過如何用 HTML 搭配 Claude——幾乎在所有這些情況下，HTML 成品都是視覺化與呈現內容的最佳方式。」這裡的「內容」指的是未知之處：檢查盲點、提出一組差異極大的設計方向供人回饋、依照最可能修改的項目排序的實作計畫，以及在底部附上測驗的合併後說明文件。HTML 是媒介；揭露你從未寫下的內容才是目的。

以下一項技巧把後文的限制加空間做法，進一步化為一條適用於計畫結構的規則：依照修改可能性排序，而不是依照執行順序排序。「先列出我最可能調整的決策：資料模型變更、新的型別介面，以及任何面向使用者的部分。機械式重構放在最底下，那部分我信任你處理。」人類有限的注意力，就能先投注在現在修改成本低、之後修改成本高的決策上。

Thariq 在 context-engineering 貼文（2026 年 7 月）中，完成了這項論點的最後一段：「簡單規格 → 豐富參照」如今成為 Claude 5 模型官方「過去→現在」規則之一。Markdown 計畫檔——也就是 plan mode「高度依賴」的那種成品——被列為過去；現在則是 HTML 成品，以及更廣泛的參照形式：作為規格的詳細測試套件、用來移植的另一個程式碼庫函式，以及交給新啟動 verifier agents 的評分規準。起初只是單一工程師對工作流程的偏好，如今被重新表述為廠商的 context-engineering 指引，並總結為一般規則：「設計的 HTML 模型圖，通常會比設計描述或螢幕截圖帶來更好的結果。」

獨立得出的相同結論：OpenAI Sites（2026 年 7 月）#

直到現在，這項論點一直來自單一實務工作者——一位 Anthropic 工程師提出，再由同一人兩度完善。OpenAI 的 Sites（2026 年 7 月 ChatGPT Work 發布的一部分）是第一個來自 Anthropic 以外、得出相同結論的案例。Akshay Nathan 在 podcast 中看著一個龐大的研究儀表板，未受提示就幾乎用 Thariq 的原話說出了這個前提（Codex from 0 to 10M Users: Building ChatGPT Work - Akshay Nathan, OpenAI，practitioner-opinion）：

「我覺得 Markdown 就是不太適合人閱讀，對吧？不如直接寫個 HTML 網站。」

這個佐證比引言更有力，因為它帶來的是一項使用情況主張，而不只是工作流程偏好。Nathan 表示，在 OpenAI 內部，團隊週期性工作的代表性成品正從簡報和試算表轉移到 Sites：某個企業財務團隊每月的報告「過去都放在簡報和試算表裡，現在則都放在 Sites……Sites 是他們跨團隊協作的媒介。」他的理由在於彈性的上限，而非格式本身：「PowerPoint 和 Excel 的彈性無限，但總有一天會碰到界線——可能是你身為使用者不知道如何使用某個功能，也可能是產品本身不支援。但網站可以讓你做任何事。」OpenAI 自己的模型設定滑桿「幾乎完全是在 Site 裡開發的。」（practitioner-opinion 來源中的 vendor-claim 等級軼聞——沒有測量數據。）

這項新證據帶來兩點超越單純佐證的發現：

• 這種媒介不限於計畫。 Thariq 的案例全是工程成品（計畫、腦力激盪、盲點檢查、說明文件）。Nathan 的案例則是知識工作成品——財務報告、研究儀表板、設計審查原型——而且並未參考 Thariq 的工作。這項主張離開孕育它的工程情境後，依然成立。
• 同一句話也佐證了膨脹上限。 swyx 談到自己產生的研究網站時說：「內容也散得很開。你看這東西有多長，數字多得不得了。真的讓人難以招架，所以我得從這裡開始刪減。」Nathan 也同意這些成品「又長又囉嗦，可以拆開……我相信還有可以改進的地方。」這正是 面向人類的 harness（HTML 成品）會不會碰上自己的膨脹上限？的結論：在另一家廠商的場合現場觀察到，HTML 只是移動了人類注意力的上限，並沒有消除它。

三種工作流程#

1. 以互動式 HTML 進行腦力激盪與規劃（本頁）——讓人想讀的視覺化計畫。
2. Disposable Micro-Apps——一次性自訂介面，用來編輯計畫的部分內容，回應「HTML 不能編輯」的疑慮。
3. Living Design System——以 design_system.html 作為可攜、同時能讓人與機器讀取的真實資訊來源。

三者都以人類為核心；沒有一種是要把開發者自動化取代掉。

延伸閱讀#

• Outsource Your Thinking, Not Your Understanding——HTML 成品能讓人類理解代理程式做了什麼
• Design by Selection——來自設計領域的獨立結論：Nate Parrott 在尋找產出可用設計的方法時，也得出了相同的新觀點（「HTML 也是豐富的互動式視覺媒介——簡報、影片檔或 PDF 能做的事，網頁也都能做到」），並以此打造了 Claude Design。兩位 Anthropic 實務工作者，一位談計畫、一位談視覺，兩人都沒有引用對方
• Thariq Shihipar——論點的作者
• Claire Vo——訪談者；也有平行的元件視覺化實作
• Claude Code——這些 HTML 成品工作流程所使用的產品，示範內容來自 Claude Code 團隊內部
• Compute Allocator——這種媒介所服務的角色：由人類做決策，99% 的 tokens 花在像這樣的鷹架上
• Disposable Micro-Apps——HTML 計畫可編輯性的解方
• Living Design System——同樣以 HTML 為先的做法，應用於設計領域
• Harness Shrinkage as Models Improve——面向模型的 harness 逐漸縮小，面向人類的 harness 不斷擴大；兩者的關鍵差異
• Interaction Models——回應「如何改善人類與 AI 的合作」的另一種做法：讓即時介面融入模型；本文則讓非同步成品更豐富。兩種機制，相同目標：讓人類持續參與
• The Bitter Lesson——「留一點空間讓模型帶來驚喜」是提示詞層面的形式；但面向人類的易讀性不會因此移入模型
• Context Window Smart Zone——HTML 擴大人類有效的 smart zone，就像清理脈絡能恢復模型的狀態
• Design Concept Grilling——腦力激盪 → 讓 Claude 訪談你 → 規劃，這就是 grilling 的流程；HTML 計畫則是更豐富的最終成品
• AI Native Product Cadence——Cat Wu 讓 PRD 變得更精簡；Thariq 則讓它們更豐富——兩種不同的做法，試圖在高速工作中讓人類保持對齊
• Software 3.0——以 HTML 為先的計畫和 Disposable Micro-Apps 都是原生的 Software 3.0：依提示詞為每項任務建立介面，就像 MenuGen 風格的「幾乎不存在的 app」
• Prototype Over PRD——第三種讓人類在高速工作中保持對齊的做法：Thariq 讓計畫更豐富，Cat Wu 讓它更精簡，Dan Carey 則以原型取代它
• Shared Harness, Differentiated Surfaces——OpenAI 的 Sites 所在的位置：共用 harness 基礎元件會依使用介面調整易讀性，讓面向人類的 harness 成為依受眾而異的部分
• Unknowns as the Agentic Bottleneck——HTML 成品的用途：每場腦力激盪、訪談、計畫和說明，都是在未知變得昂貴之前將其揭露的工具

尚待解答的問題#

• 這項做法能普遍適用於專家工作者以外的人嗎？還是得像 Thariq 一樣熟悉 Claude，才值得付出額外成本？

已解答的問題#

• 面向人類的 harness 會不斷擴大嗎？還是會遇到自身的膨脹上限（一份繁複到難以閱讀的 HTML 計畫，就像它取代的 Markdown）？已解答：面向人類的 harness（HTML 成品）會不會碰上自己的膨脹上限？——會；HTML 提高並重新塑造了人類注意力的上限，卻無法消除它；膨脹只是從文件長度轉移到成品散亂／橡皮圖章式審核。
• HTML 比 Markdown 更難做差異比較與版本管理——當成品是單檔網站時，計畫歷史和審查該如何處理？已解答：HTML 成品的生命週期：計畫歷史存放的位置，以及何時從一次性變為持久——成品是編譯後的檢視畫面，不是紀錄：對內容層做版本管理（回寫往返和從程式碼擷取的模式已經做到這點），依需求重新產生呈現方式，並讓審查聚焦在決策，而非差異（依修改可能性排列計畫的技巧，會把可審查的變更放在最上方）。呈現歷史會刻意捨棄——重新產生的成本很低，不值得做版本管理；而一旦呈現方式成為關鍵依據，就代表它已發展成需要真正履行版本管理責任的持久工具。尚待補足之處（已列於上方）：目前沒有來源記錄團隊規模下多人共同審查 HTML 計畫的做法。

衍生文章#

• 面向人類的 harness（HTML 成品）會不會碰上自己的膨脹上限？——探討這種面向人類的 harness 是否會遇到自身的膨脹上限（會；上限會移動、重新塑形，但不會消失）
• HTML 成品的生命週期：計畫歷史存放的位置，以及何時從一次性變為持久——版本管理的解答：HTML 計畫是編譯後的檢視畫面；內容層承載歷史，審查聚焦在決策，而非差異

資料來源#

• How I AI: Thariq Shihipar on Replacing Markdown with HTML for AI-Powered Development
• A Field Guide to Fable: Finding Your Unknowns——Thariq Shihipar，2026-07-04（practitioner-opinion）：以 HTML 作為引出未知的預設媒介；計畫依修改可能性排序
• The new rules of context engineering for Claude 5 models——Thariq Shihipar，2026-07-25（practitioner-opinion）：「簡單規格 → 豐富參照」作為官方指引；HTML 模型圖勝過文字描述或螢幕截圖；以測試套件作為規格，並為 verifier agents 提供評分規準
• Codex from 0 to 10M Users: Building ChatGPT Work - Akshay Nathan, OpenAI——Latent Space，2026-07-28（practitioner-opinion）：來自 Anthropic 以外的相同結論——OpenAI Sites、「Markdown 就是不太適合人閱讀」、企業財務團隊從簡報與試算表轉用 Sites，以及現場佐證成品散亂的上限