Obsidian 在短短幾年間累積數百萬用戶、Notion 成為企業標配、GitHub 的 README 幾乎全用 Markdown 撰寫——這場「純文字復興」並非偶然。在 Word、Google Docs 稱霸多年之後，為什麼越來越多人回頭選擇看起來「更原始」的純文字格式？答案藏在格式設計本身的哲學裡。
1. 格式戰爭：.docx vs 純文字
在 Microsoft Word 普及之前，工程師和學者長期使用純文字寫作。Word 的出現帶來了所見即所得（WYSIWYG）的便利，但也帶來了幾個長期問題：
- 格式鎖定：.docx 是封閉的二進位格式，脫離 Word 或 Google Docs 就難以正常開啟或編輯
- 格式腐敗：版本差異、字體缺失、樣式錯亂是跨平台分享的常見噩夢
- 版本控制困難：Git 等版本控制工具對二進位格式束手無策，無法有效追蹤「誰改了什麼」
- 搜尋與索引限制：二進位格式讓全文搜尋更複雜，備份也需要更多空間
純文字完全不存在這些問題。它是通用格式——任何文字編輯器都能開啟，任何作業系統都能搜尋，任何版本控制系統都能追蹤每一個字元的變化。
2. Markdown：純文字與格式化之間的完美平衡
純文字的問題在於：它缺少排版語義。你可以寫 # 標題 但閱讀時只是一行文字，不會自動顯示為視覺上的大標題。
2004 年，John Gruber 和 Aaron Swartz 設計了 Markdown，目標是「讓純文字盡可能接近最終排版的樣子」。關鍵設計決策是：即使不渲染，Markdown 原始碼本身也應該是可讀的。
# 一級標題 看起來就像標題。**粗體** 看起來就像被強調的文字。- 清單項目 看起來就像清單。這種「視覺一致性」讓 Markdown 在純文字狀態下就具有良好的可讀性，不需要依賴渲染工具。
3. Markdown 在哪裡被使用？
Markdown 的應用範圍遠比多數人想像的廣：
- GitHub / GitLab：所有 README、Issue、Pull Request、Wiki 都支援 Markdown
- 技術文件：Docusaurus、MkDocs、Sphinx 等文件框架以 Markdown 為核心
- 部落格平台：Hugo、Jekyll、Hexo 等靜態網站生成器使用 Markdown 寫文章
- 筆記工具：Obsidian、Logseq、Joplin、Bear 等以 Markdown 儲存筆記
- 協作平台：Notion、Confluence、Slack、Discord 都支援 Markdown 語法
- 學術寫作：Pandoc 可將 Markdown 轉換為 LaTeX、PDF、DOCX，越來越多研究者採用
4. 為什麼工程師特別愛用 Markdown？
對工程師來說，Markdown 解決了一個核心問題：文件應該和程式碼放在一起，接受同樣的版本控制。
當專案的說明文件是 Markdown，就可以：
- 用
git diff看出文件的每一次修改，清楚知道誰改了哪一行 - 在 Pull Request 中審查文件變更，就像審查程式碼一樣
- 在 CI/CD 流程中自動驗證文件格式或連結有效性
- 讓文件隨程式碼一起演進，不出現「文件跟不上程式碼」的情況
Markdown 之所以適合版本控制，根本原因是純文字格式讓「比對兩個版本的差異」變得有意義。Word 文件的差異比對不僅難以閱讀，有時甚至需要專用工具才能運作。純文字的差異比對（diff）是標準化的，任何工具都能處理。
5. Obsidian 為什麼爆紅？從工具功能看純文字的優勢
Obsidian 於 2020 年推出，兩年內累積超過百萬用戶。它的核心設計決策是：所有筆記都儲存為本地 Markdown 檔案，而非雲端資料庫。
這個設計帶來了幾個關鍵優勢：
| 特性 | 傳統雲端筆記（Evernote 等） | Obsidian（本地 Markdown） |
|---|---|---|
| 資料擁有權 | 資料在廠商伺服器 | 資料在自己電腦 |
| 離線使用 | 需要網路同步 | 完全離線運作 |
| 匯出彈性 | 通常需要付費匯出 | 直接存取 .md 檔 |
| 搜尋速度 | 依賴伺服器 | 本地全文搜尋，瞬間回應 |
| 廠商鎖定 | 高（換工具需大量轉換） | 低（任何編輯器都能開啟） |
Obsidian 的爆紅某種程度上是對「廠商鎖定」的反彈——用戶意識到，將多年的筆記鎖在某個服務的專有格式裡，是一種隱性風險。
6. 純文字的長期性：二十年後還能讀嗎？
這是許多人從未考慮過的問題：你今天寫的筆記，二十年後還能讀到嗎？
1990 年代的 .doc 檔案，現在要用現代 Word 開啟往往需要「相容模式」，格式可能已經走樣。而 1990 年代的純文字檔案，今天用任何文字編輯器都能完美開啟——因為純文字格式本身沒有版本、沒有依賴。
對於需要長期保存的知識（日記、研究筆記、個人知識庫），純文字是目前最能經得起時間考驗的數位格式。
7. Markdown 的限制
Markdown 並非萬能，有些場景仍不適合：
- 複雜排版：多欄位、精確的圖文混排、頁首頁尾設計仍需要 Word 或 InDesign
- 協作編輯：同時多人編輯同一份文件，Google Docs 的即時協作體驗仍優於大多數 Markdown 工具
- 非技術使用者：對不熟悉語法的人來說，
**粗體**不如工具列按鈕直覺 - 表格複雜度：Markdown 表格語法相對受限，無法合併儲存格或設定複雜公式
工具沒有對錯，只有適不適合。Markdown 最適合的場景是：需要版本控制、長期保存、跨平台分享，或與程式碼共存的文字內容。
8. 字數與長度：Markdown 寫作的一個隱藏挑戰
用 Markdown 寫作時，有一個容易被忽略的問題：字數統計可能因渲染狀態而有差異。
原始 Markdown 包含語法符號（#、**、[] 等），這些符號在渲染後會消失，但在純文字狀態下會被計入字數。如果你需要精確的字數（如稿費計算、SEO 文章長度要求），要特別注意是計算「原始 Markdown 字數」還是「渲染後純文字字數」。
9. 小結
純文字和 Markdown 的復興，反映了人們對數位內容的重新思考：
- 資料擁有權：你的筆記應該是你的，不應該被鎖在某個服務裡
- 長期可讀性：純文字是最能經得起時間考驗的數位格式
- 版本控制友善：程式碼和文件理應使用同樣的工作流程
- 跨平台通用性：Markdown 幾乎在所有現代寫作和開發工具中都被支援
如果你還沒嘗試過用 Markdown 寫筆記或文件，可以從一個簡單的 README 或日記開始——你很可能會發現，移除了多餘的格式干擾之後，思路反而變得更清晰。