打開任何一個 GitHub 倉庫，你第一眼看到的不是程式碼，而是 README.md。這個檔案通常用 Markdown 撰寫，也是專案裡被閱讀次數最多的文件。徵才啟事、學術論文和法律合約很少以 Markdown 存在，但網路上大量的技術寫作都離不開它。要理解原因，得回到一種在渲染前就被設計成可閱讀的格式。
Markdown 從何而來
2004 年，科技作家 John Gruber 在 Aaron Swartz 的協助下發表了 Markdown 語法規格。Gruber 的目標很實際：他想要一種以純文字書寫、看起來舒服，之後又能轉成 HTML 的網路寫作方式。當時的網頁由標籤驅動。寫一篇部落格文章，意味著要把每個段落、清單和連結都包進尖括號裡。Gruber 認為，對大多數人出版的這類散文來說，這些噪音並不必要。
最後誕生了一小組約定：
- 標題使用
#符號。 - 清單使用
-或*。 - 連結使用
[text](url)。 - 強調使用
*text*或_text_。 - 程式碼使用反引號。
這些約定借用自電子郵件慣例、Usenet，以及寫作者本來就熟悉的純文字習慣。Markdown 沒有發明太多東西，只是把它們寫成規則。
Gruber 也釋出了參考實作 Markdown.pl，這是一支把語法轉成 HTML 的 Perl 腳本。可讀的來源格式加上確定的輸出格式，讓它很容易推廣。寫作者得到一個可以在任何文字編輯器裡修改的檔案；發布者得到乾淨的 HTML，可以用 CSS 來設定樣式。
Markdown 不是 HTML
這聽起來很明顯，但技術上的區別很重要。HTML 是一種結構化文件格式，它描述元素、屬性、巢狀結構與行為。瀏覽器不在乎原始碼對人類來說長什麼樣子；它在意的是能從標記建構出的 DOM。
Markdown 是一種寫作慣例。它沒有 DOM，沒有事件處理器，沒有表單，也沒有使用者透過 frontmatter 自行加上以外的 metadata 架構。它比較像速記，而不像標記語言。把 Markdown 丟進解析器（parser），輸出通常是 HTML，但 Markdown 本身只關心寫作者手動輸入的部分：標題、段落、強調、清單、連結、圖片和程式碼。
這項差異決定了兩種格式各自適合的位置：
| 任務 | Markdown | HTML |
|---|---|---|
| 撰寫初稿 | 快速，在任何編輯器都易讀 | 冗長，會打斷思路 |
| 版本控制 diff | 乾淨，可看到句子層級的變動 | 因標籤而雜亂 |
| 精確排版 | 設計上較弱 | 強大 |
| 互動性 | 沒有 | 原生支援 |
| 樣式 | 交給渲染器決定 | 行內或 CSS |
HTML 是最終頁面；Markdown 是手稿。
為什麼它傳播得這麼快
三股力量把 Markdown 從小眾的 Perl 腳本推成技術寫作的預設語言。
版本控制。 Git 成為標準後，開發者開始把文件和程式碼放在一起管理。純文字勝出，因為 diff 看得懂。HTML 和 Word 文件會讓小改動在 diff 裡變成無法閱讀的亂碼；Markdown 則保持清晰。
GitHub。 2009 年，GitHub 開始在倉庫頁面上渲染 README.md。突然之間，每個專案都需要一份 Markdown 檔案。Stack Overflow 也在問答中採用 Markdown。開發者學會這套語法，因為他們每天使用的平台都要求它。
靜態網站產生器。 Jekyll、Hugo、Gatsby，以及後來的 Next.js 等工具，把 Markdown 檔案變成完整的網站。寫作者不需要 CMS 就能發布。來源檔案放在 Git 倉庫裡，由建置步驟產生 HTML。這個現在被稱為 docs-as-code 的工作流程，讓 Markdown 成為現代網路很大一部分內容的輸入格式。
筆記應用給了最後一推。Obsidian、Notion、Bear、Logseq 和 iA Writer 都支援 Markdown 或它的近親。這個格式走出開發者工具，成為整理個人知識的方式。
Markdown 會取代 docx 和 PDF 嗎？
不會。這個問題之所以出現，是因為 Markdown 感覺乾淨，而其他格式感覺沉重，但它們解決的問題不同。
.docx 檔案是一個壓縮的 XML 套件，專為豐富編輯而設計：追蹤修訂、註解、樣式、目錄、郵件合併與嵌入媒體。它是合約、報告與手稿的格式，適合需要非技術使用者反覆來回編輯的文件。
PDF 是固定版面的電子紙格式。它能在不同裝置上保留字型、間距與分頁。這正是發票、履歷或學術論文最終版本所需要的：無論在哪裡看起來都一樣。
Markdown 則是交換格式。它適合起草、版本控制與發布到網頁，卻不擅長頁面排版、精確字型與印刷級輸出。務實的工作流程是：用 Markdown 寫作，當文件需要離開文字編輯器時，再轉成 docx 或 PDF。
這也是瀏覽器端轉換器派上用場的地方。當 Markdown 草稿需要變成可分享的 PDF 時，我們的 Markdown 轉 PDF 轉換器 會在本機完成轉換。如果你手邊是 PDF，想要可編輯的 Markdown，PDF 轉 Markdown 轉換器 會直接萃取結構，無需上傳檔案。
Markdown 的長處與破綻
優點
- 可讀的來源。 Markdown 檔案幾乎和渲染後的頁面一樣乾淨。你可以在終端機、電子郵件客戶端或手機筆記應用裡閱讀它。
- 可攜。 它是純文字。沒有專有廠商、沒有授權、沒有會損毀的二進位格式。
- 對 diff 友善。 Git 能準確顯示哪個句子改了，寫作者與審閱者立刻受益。
- 工具豐富。 每種程式語言都有解析器，每個主要平台都有編輯器。
- 原生網路。 它編譯成 HTML，也就是網頁真正的輸出格式。
局限
- 規格模糊。 Gruber 的原始規格對邊緣案例沒有定義。不同的解析器對同一份輸入會產生不同的 HTML。這就是 CommonMark 存在的原因，但不是每個工具都採用它。
- 無法控制版面。 若不降級到 HTML 或 CSS，你無法定位圖片、設定頁邊界或定義印刷樣式。
- 風格混亂。 GitHub Flavored Markdown、Pandoc Markdown、MultiMarkdown、Obsidian Markdown 和 MDX 都加入了彼此不相容的擴充。為某個工具寫的檔案，在另一個工具上可能會渲染錯誤。
- 表格與註腳是事後追加。 它們由擴充支援，而非核心語法，而且行為各異。
老實說，Markdown 擅長的是寫作中 90% 的部分：段落、清單、連結和程式碼。剩下的 10% 則被推給 HTML 或專門格式。
Markdown 與 AI 時代
如果你用過大型語言模型（large language model，LLM），你一定看過 Markdown。大多數對話介面預設會把 LLM 輸出渲染成 Markdown。這背後有實務上的原因。
首先，Markdown 很精簡。token 很貴，而一種用 # 取代 <h1></h1> 的格式能節省空間。第二，Markdown 結構簡單。標題、清單和程式碼區塊對模型來說容易產生，對解析器來說也容易驗證。第三，訓練資料裡充滿 Markdown。GitHub、Stack Overflow、Reddit 和文件網站都用它，所以模型能可靠地學會這套語法。
除了對話輸出，Markdown 也成為 AI 知識系統的儲存格式。Retrieval-Augmented Generation（RAG）管線經常把文件切分成 Markdown 或純文字，因為結構可預期。向量資料庫、筆記工具和編碼助理都把長期脈絡存成 Markdown 檔案，因為人類看得懂，機器也解析得了。
風險在於風格不一致。某個模型輸出 GitHub 風格的表格，另一個模型卻用 HTML 表達同一張表格。混合多種風格的知識庫在工具間移動時可能會壞掉。唯一的解法是採用 CommonMark 或文件化的風格，讓 AI 產生的 Markdown 保持可攜。
Markdown 的未來與演進
Markdown 不會變成更豐富的格式。每一次想把它變得更豐富——表格、註腳、定義清單、屬性——都會把它拉離當初讓它流行的簡潔。真正的演化朝兩個方向進行。
標準化。 2014 年開始的 CommonMark 定義了嚴格的解析規格。越來越多工具實作它，降低了一份檔案從某個解析器移到另一個解析器時的意外。
嵌入。 MDX 讓作者把 React 元件匯入 Markdown 裡。Jupyter notebook 把 Markdown 儲存格和可執行程式碼混合在一起。靜態網站產生器把 Markdown 當成結構化內容的資料來源。在每一種情境中，Markdown 本身保持小巧，周圍的工具負責提供能力。
可能的未來大同小異：Markdown 作為通用的純文字草稿格式，再由轉換器把它變成 HTML、PDF、docx、投影片，或任何目標所需的格式。
各平台的閱讀與編輯工具
使用 Markdown 不需要專屬應用。任何文字編輯器都可以。不過，有些工具能讓體驗明顯更好。
Windows
- VS Code 搭配 Markdown 擴充：開發者的預設選擇。支援預覽、linting 與 Markdown-it 渲染。
- Typora：極簡的所見即所得（WYSIWYG）編輯器，需要時才顯示語法。
- MarkText：Typora 的開源替代品，提供乾淨的分割檢視。
- Notepad++：適合快速編輯，可透過外掛取得 Markdown 語法突顯。
macOS
- iA Writer：專注於無干擾寫作與語法控制。
- Bear：使用類 Markdown 語法的筆記應用，用於個人知識管理。
- Ulysses：受長文寫作者歡迎，適合發布到網路。
- Marked 2：不是編輯器，而是強大的即時預覽渲染器，適合在其他地方編輯的檔案。
Linux
- Ghostwriter：無干擾的 Markdown 編輯器，支援即時預覽。
- Apostrophe：乾淨的 GTK 編輯器，專為散文設計。
- ReText：簡單的編輯器，可匯出成多種格式。
- Vim / Neovim / Emacs：對已經生活在終端機裡的寫作者來說無可匹敵。
跨平台
- Obsidian：本地優先的知識庫，支援連結、圖表與外掛。
- Logseq：大綱工具，把所有內容存成 Markdown 或 Org 檔案。
- Joplin：開源筆記應用，支援端到端加密與 Markdown。
各程式語言的 Markdown 函式庫
如果你正在開發需要解析或渲染 Markdown 的軟體，很少需要自己寫解析器。生態系已經很成熟。
| 語言 | 函式庫 | 說明 |
|---|---|---|
| Python | markdown、mistletoe、markdown-it-py | markdown 是經典；markdown-it-py 是符合 CommonMark 的移植 |
| JavaScript / TypeScript | marked、markdown-it、remark / unified | remark 是 unified 生態系的一部分，用於基於 AST 的處理 |
| Go | goldmark、blackfriday | goldmark 符合 CommonMark 且可擴充 |
| Rust | pulldown-cmark、comrak | 快速、安全、以 CommonMark 為重心 |
| Ruby | redcarpet、kramdown | redcarpet 是 GitHub 風格；kramdown 是 Jekyll 預設 |
| Java | commonmark-java、flexmark-java | flexmark 支援許多 Pandoc 風格擴充 |
| C# | Markdig | 高度可擴充，被 Statiq 等靜態網站產生器使用 |
這些函式庫大多都能處理好核心語法。差異主要出現在擴充、效能，以及對 CommonMark 的遵循程度上。選擇時應根據你需要支援的風格，而不只是根據使用的語言。
結論
Markdown 勝出不是因為它強大，而是因為它不擋路。寫作者可以開啟任何文字編輯器，打完一份文件，直接送進版本控制，完全不用考慮檔案格式。這個取捨是故意的：Markdown 犧牲排版精確度，換取可攜性與可讀性。
這個取捨讓它支撐起 README、文件、靜態網站、筆記應用，以及現在的 AI 輸出。也是為什麼它會繼續與 docx 和 PDF 共存。每種格式都有各自的工作。Markdown 的工作就是作為純文字的起點。當你需要把這個起點搬進更豐富的格式時，轉換器通常就是下一步。
