Word、HTML、JSON 全輸了：AI 時代最重要的格式 Markdown 是 22 年前發明的
2004 年，一個部落客和一個 17 歲的天才一起做了一個純文字格式。
部落客叫 John Gruber，2002 年他做了一個在當時看起來完全不理性的決定：把自己的線上事業全部押在兩個東西上，蘋果和部落格。Anil Dash（Movable Type 的早期團隊成員，也是 Gruber 的朋友）後來回憶說，2002 年的蘋果才剛從瀕死邊緣走回來，幾乎沒有人在固定報導蘋果，更不用說「只寫蘋果」。當時連「科技新聞」這個領域都還不太存在，寫部落格的人也寥寥無幾。
第一台支援 Windows 的 iPod 剛推出，iPhone 還要再等五年。但 Gruber 就是把所有籌碼押在了 Daring Fireball 上，一個專寫蘋果的個人部落格。從那之後，蘋果的股價漲了大約 120,000%，而 Gruber 成了蘋果圈最有影響力的獨立評論者，某種程度上定義了後來整個科技媒體的樣貌。Dash 形容他是「一個脾氣暴躁但心地善良的傢伙，此刻大概正在重看庫柏力克（Stanley Kubrick）的電影，同時為一支完全站不住腳的運動隊加油」。
天才叫 Aaron Swartz，1986 年出生在芝加哥郊區的 Highland Park。他 14 歲參與制定了 RSS 1.0 規格，後來共同創辦了 Reddit，參與建構了 Creative Commons 的技術架構。2004 年幫 Gruber 測試 Markdown 的時候，他才 17 歲。Dash 說 Aaron 最厲害的地方是他可以「非常煩人」，這讓他成為測試軟體的頂級人選。
他們兩個做的東西叫 Markdown，設計目標只有一個：讓人用純文字寫東西，寫出來的原始檔不需要任何渲染就能直接閱讀，同時又能轉換成結構化的 HTML。Gruber 的原話是：「如果未渲染的原始碼看起來不對，那語法就是錯的。」
22 年後的今天，幾乎所有 AI 系統都在用 Markdown。ChatGPT 的輸出是 Markdown，Claude 的輸出是 Markdown，GitHub Copilot 讀的文件是 Markdown，Claude Code 的 CLAUDE.md 和所有 Skills 都是 Markdown，連 Ghost 部落格的編輯器底層都是把 Markdown 包在 Lexical JSON 裡面。
Word 有豐富的格式，HTML 有完整的結構，LaTeX 有精確的排版，JSON 有嚴格的資料規範。但 AI 時代選中的，是 2004 年兩個人花幾個月做出來的、最簡單的那個格式。
一個設計師和一個少年駭客
Markdown 的語法幾乎不需要學，# 是標題，** 是粗體，- 是列表，> 是引用，空一行是換段。就這樣。
這種極簡來自 Gruber 身為 UI 設計師的直覺。他觀察到一個現象：人們在寫純文字 email 的時候，早就自然地用星號表示強調、用大於符號表示引用、用空行分段。這些不是誰規定的，是大家在沒有格式工具的環境下自然發展出來的慣例。Markdown 做的事情，就是把這些非正式慣例整理成一套可以可靠轉換成 HTML 的語法。
Aaron Swartz 在這個過程中的角色，是 Markdown 的「唯一 beta 測試者」。Gruber 後來在 Podcast 上描述他們的合作關係：「真的就只有我和 Aaron，我是創造者，Aaron 是我的試聲板，我的繆斯。」Swartz 在發布前反覆測試語法、提供回饋，還寫了一個把 HTML 轉回 Markdown 的工具 html2text。值得一提的是，Swartz 在 2002 年就做過一個叫 atx 的格式，用 # 符號的數量來表示標題層級，這個設計直接影響了 Markdown 的標題語法。
Swartz 的人生軌跡後來走向了更大的舞台，也走向了更大的衝突。他在 2010 年到 2011 年間，從 MIT 的網路大量下載了 JSTOR 付費論文資料庫的學術文章，主張學術知識應該自由流通。這件事讓他面臨聯邦重罪起訴，最高可判 35 年。2013 年 1 月 11 日，Aaron Swartz 在紐約的公寓裡自殺，年僅 26 歲。他的「游擊隊開放取用宣言」（Guerilla Open Access Manifesto）至今仍然是網路自由運動的核心文件之一。
Markdown 在 2004 年發布的時候，圈子很小，主要是部落客和技術寫作者在用。真正讓它爆發的，是 2008 年 GitHub 的出現。
GitHub 讓 Markdown 變成開發者的母語
GitHub 從第一天就把 Markdown 當作預設的文件格式。每個開源專案的首頁都是 README.md，每個 Pull Request 的描述是 Markdown，每個 Issue 的內容是 Markdown，Wiki 是 Markdown。GitHub 還發展出自己的擴充版本 GitHub Flavored Markdown（GFM），加了表格、任務清單、程式碼區塊語法高亮等功能。
這個決定的連鎖效應非常深遠，全世界的開發者開始用 Markdown 寫文件，用 Markdown 寫技術部落格（Jekyll、Hugo、Gatsby 這些靜態網站生成器全部以 Markdown 為核心），用 Markdown 寫內部文件（Notion、Obsidian、HackMD），用 Markdown 寫 API 文件。到了 2020 年代初期，Markdown 已經是軟體產業的通用文件語言。
Stack Overflow 的問答也是 Markdown。Reddit 的貼文也是 Markdown。技術文件平台 Read the Docs、GitBook、Docusaurus，全部是 Markdown。
這些平台上累積了人類有史以來最大量的高品質結構化文字。然後，大型語言模型來了。
AI 為什麼選中 Markdown
大型語言模型的訓練資料有很大一部分來自 GitHub、Stack Overflow 和技術文件。這意味著 LLM 從出生開始就泡在 Markdown 裡面，它們對 Markdown 的語法模式有原生的熟悉度。當你問 ChatGPT 一個問題，它回覆的時候自動用 ## 分段、用 - 列點、用 ** 強調，這不是工程師硬編進去的規則，是模型從訓練資料裡學到的：「人類在解釋複雜事情的時候，就是這樣組織文字的。」
但訓練資料只是原因之一，Markdown 在 AI 系統中勝出還有三個結構性的理由。
第一個是詞元（token）效率，AI 模型處理文字的基本單位是詞元，詞元數量直接決定了成本和速度。OpenAI 社群的測試顯示，同樣的資訊用 Markdown 表達比用 JSON 省大約 15% 的詞元。和 HTML 比，差距更大。每一個 <div>、<p>、</p> 都是在浪費詞元，而 Markdown 用一個 # 或一個空行就傳達了同樣的結構資訊。當你的模型有上下文視窗限制（即使是 100 萬詞元的模型也有），每一個省下的詞元都意味著可以塞進更多實際內容。
第二個是語義結構，Markdown 的 # 標題明確定義了資訊的層級關係，| 表格讓模型可以做欄位推理，- 列表讓並列資訊一目了然。Webex 開發者團隊的研究顯示，在 RAG（檢索增強生成）的場景中，用 Markdown 格式的文件比用 HTML 或純文字的檢索準確度高 20% 到 35%。因為 Markdown 的結構標記既輕量又有語義，模型可以快速理解一段文字在整篇文件中的位置和角色。
第三個是人機共讀，這其實是 Gruber 2004 年的設計哲學在 AI 時代的完美體現。一個 Markdown 檔案，人類打開看得懂，AI 讀進去也能正確解析結構。不需要任何中間轉換層。HTML 人類讀起來痛苦，JSON 人類讀起來更痛苦，Word 的 .docx 格式 AI 根本讀不了（那是壓縮的 XML）。Markdown 是唯一一個在人類可讀性和機器可解析性之間取得完美平衡的格式。
Claude Code 的整個系統就是建在 Markdown 上面
如果你用過 Claude Code（Anthropic 的 AI 程式開發工具），你會發現它的整個指令和擴充系統都是 Markdown。
專案根目錄的 CLAUDE.md 是 AI 在每次對話開始時讀取的核心指令檔，用 Markdown 寫。Skills 資料夾裡每一個 skill 都是一個 .md 檔（或一個包含 .md 檔的資料夾），用 YAML frontmatter 定義觸發條件，用 Markdown 寫內容。AI 的記憶系統（auto memory）也是 Markdown 檔案。
Anthropic 的工程師 Thariq Shihipar 最近寫了一篇文章解釋他們內部如何使用 Skills，裡面有一句話很關鍵：「關於 Skills 最常見的誤解是它們『只是 Markdown 檔案』，但 Skills 最有趣的地方在於，它們是可以包含腳本、資源檔、資料的資料夾，AI 可以探索和操作這些內容。」
換句話說，Markdown 在 Claude Code 裡的角色不只是文件格式，它是 AI 代理的指令語言。CLAUDE.md 定義了 AI 的行為規則，Skills 定義了 AI 的能力邊界，Memory 定義了 AI 的長期記憶。這些全部用 Markdown 寫，因為 Markdown 是 AI 最能理解的格式。
OpenAI 的 ChatGPT 也一樣，它的系統提示（system prompt）雖然是純文字，但裡面大量使用 Markdown 語法來組織指令。Custom GPTs 的指令也是 Markdown。Anthropic 的 Model Context Protocol（MCP）用 Markdown 描述工具。
整個 AI 代理生態系，從指令到輸出到記憶到工具描述，底層都是 Markdown。
為什麼其他格式輸了
Word（.docx）第一個出局，因為它是二進位壓縮格式，AI 沒有辦法直接讀取，必須經過解壓和解析。而且 Word 檔裡充滿了格式標記（字型、顏色、間距），這些對 AI 來說全部是噪音。
HTML 有結構但太囉嗦，一個簡單的標題在 HTML 裡是 <h2>標題</h2>，在 Markdown 裡是 ## 標題。多出來的 tag 全部是浪費詞元的冗餘字元，而且 HTML 允許太多彈性（同一個視覺效果可以用十種不同的 tag 組合達成），這讓 AI 的解析變得不可靠。
JSON 在 API 場景中仍然很強，因為它有嚴格的資料結構。但 JSON 的問題是人類讀起來很痛苦，而且詞元消耗高。在需要人類和 AI 都能讀寫的場景（像是 CLAUDE.md、Skills、文件），Markdown 完全勝出。
LaTeX 太複雜了，學習曲線陡峭，語法對 AI 來說也沒有特別的優勢。它在學術排版領域仍然無可取代，但在 AI 的日常使用場景中幾乎不會出現。
最後贏的是 Markdown，因為它恰好在四個維度上都取得了夠好的平衡：人類可讀、機器可解析、結構夠用、詞元夠省。不是每個維度都最好，但綜合分數最高。
Gruber 的設計哲學預見了 AI 的需求
回頭看 Gruber 2004 年寫的那句話：「如果未渲染的原始碼看起來不對，那語法就是錯的。」
這句話在當時是一個關於人類閱讀體驗的設計原則，但放到 2026 年的 AI 語境裡，它精準地描述了為什麼 Markdown 成為 AI 的原生語言：因為 Markdown 的原始碼本身就是有意義的，不需要渲染、不需要轉換、不需要解析器，直接讀就能理解結構。對人類如此，對 AI 也如此。
有趣的是，Gruber 本人至今沒有公開談過 Markdown 在 AI 時代的角色。他的 Daring Fireball 和 Podcast「The Talk Show」持續活躍，但主題始終聚焦在 Apple 生態系。他對 AI 的態度主要體現在 2025 年一篇措辭嚴厲的文章裡，標題是「Something Is Rotten in the State of Cupertino」，批評 Apple Intelligence 的推出是徹底的失敗。換句話說，他關注的 AI 議題是蘋果做得多爛，而非 Markdown 在 AI 生態系中扮演多重要的角色。2026 年 1 月 Anil Dash 寫了長文「How Markdown Took Over the World」，描述 Markdown 如何成為「從最尖端的 AI 系統到大學生隨手寫的程式碼」的通用格式語言，但 Gruber 對這個 AI 敘事沒有發表任何評論。
這種沉默本身可能就是一種態度，Gruber 對 Markdown 的立場一直很一致：他在 2004 年做了這個東西，發布了規格，然後就放手了。他沒有成立基金會，沒有推標準化，甚至在 CommonMark（社群主導的標準化嘗試）出現時也沒有介入。Markdown 的成功靠的從來就不是有人在推動，純粹是因為它夠簡單、夠好用、夠容易記。Anil Dash 的結論是：「Markdown 成功的原因就是這三件事，夠好、好用、好記。」
Aaron Swartz 在 2013 年過世的時候，AI 還沒有成為主流話題。他大概不會想到，自己在 17 歲時幫忙測試的那個純文字格式，會在 20 年後成為所有 AI 系統的基礎語言。但如果你回頭看他一生的工作，從 14 歲參與 RSS 到 Creative Commons 到 Markdown 到游擊隊開放取用宣言，有一條很清楚的線：讓資訊以最開放、最簡單的方式流通。
Markdown 做到了，而且做得比任何人預期的都好。
相關資料：
John Gruber：Daring Fireball - Markdown
https://daringfireball.net/projects/markdown/
Anil Dash：How Markdown Took Over the World（2026）
https://www.anildash.com/2026/01/09/how-markdown-took-over-the-world/
OpenAI 社群討論：Markdown is 15% More Token Efficient Than JSON
https://community.openai.com/t/markdown-is-15-more-token-efficient-than-json/841742
Thariq Shihipar：Lessons from Building Claude Code - How We Use Skills
https://x.com/trq212/status/2033949937936085378
Webex Developers Blog：Boosting AI Performance with LLM-Friendly Content in Markdown
https://developer.webex.com/blog/boosting-ai-performance-the-power-of-llm-friendly-content-in-markdown
