Design pattern 23 篇、infra 系列 18 篇、前後端零散筆記不計其數。寫到某個時刻你會發現：文章越多，找東西越難。知識庫開始像一個巨大的垃圾桶——什麼都丟進去，什麼都撈不出來。
先講結論
公開和私人內容必須分開管理。我用 Obsidian 做私人知識網（收納所有東西），Quartz 做公開部落格（只發精選）。兩者用不同的分類策略，因為它們服務不同的讀者——前者是我自己，後者是你。
Obsidian：PARA 方法 + 編號前綴
Obsidian Vault 用 Tiago Forte 的 PARA 方法：
_roadmap/
├── 1. Projects # 有期限的專案（如「完成 infra 系列」）
├── 2. Areas/ # 持續維護的領域（核心知識庫）
│ └── 1_CS/
│ ├── 0_common/ # 通用 CS：API, MVC, design-patterns
│ ├── 11_b2e/ # 後端
│ ├── 21_f2e/ # 前端
│ ├── 31_devOps/ # 基礎設施
│ ├── 9_git/ # Git
│ └── 91_constructor/ # 23 篇設計模式
├── 3. Resources # 純參考資料（書摘、外部文章）
└── 4. Archives # 冷藏區
你可能注意到了那些怪異的數字前綴。11_ 是 1_ 的延伸、21_ 是 2_ 的延伸——這是刻意的。好處是排序穩定（不靠字母）、分群直覺（看 21_f2e 就知道跟 2_ 系列有關）、而且中間留了足夠的數字空間可以插入新資料夾，不用重新編號。
是的，我就是那種會為了資料夾排序焦慮的人。
Quartz：刻意的扁平
部落格完全不同——故意保持扁平，每個主題一個資料夾：
content/
├── design-pattern/ # 23 篇設計模式
├── infra/ # 18 篇基礎建設
├── frontend/ # 前端
├── backend/ # 後端
├── git/ # Git
├── tools/ # 開發工具
└── ...
為什麼不用跟 Obsidian 一樣的深層結構？因為你（讀者）不需要理解我的 PARA 架構。/design-pattern/01-singleton-pattern 比 /areas/cs/constructor/01-singleton-pattern 好記太多了。URL 簡潔、維護簡單、搬資料夾不會連結全壞。
兩邊怎麼對應？
| Obsidian | Quartz | 內容 |
|---|---|---|
91_constructor/ | design-pattern/ | 設計模式 |
31_devOps/ | infra/ + devOps/ | 基礎建設 |
21_f2e/ | frontend/ | 前端 |
11_b2e/ | backend/ | 後端 |
| (私人筆記) | (不發布) | 草稿、備忘 |
重點：不是所有 Obsidian 內容都會發布。很多東西只是我自己的碎碎念和半成品。
同步流程
寫作直接在 Quartz 的 content/ 目錄進行（要符合 front matter 格式），寫完同步一份回 Obsidian 做 wikilink 串聯。Obsidian 可以額外寫不公開的補充筆記，用 [[wikilink]] 連回已發布文章。
核心原則：Quartz 是發布源，Obsidian 是知識網路。
理想狀態是加入第三層——用 Notion 做原始收集（會議筆記、需求規格、外部剪貼），值得深入的搬到 Obsidian 精煉，整理好的才發到 Quartz。三個工具各有專長，硬要用一個做所有事反而更慢。
走過的彎路
在現在這套系統之前，我經歷了幾個階段：
散亂時期：筆記散落桌面、Downloads、隨意命名的 txt。找東西靠搜尋和運氣——運氣的比重還比較大。
全部丟 Notion 時期：技術筆記、規格文件、個人日記全塞進去。頁面越多載入越慢，Markdown 支援又不夠原生，寫程式碼筆記很卡。
導入 PARA：效果立竿見影。每個東西都有明確歸屬，不再有「這筆記到底該放哪」的存在焦慮。
回頭看，最關鍵的領悟是：分類系統要符合自己的思維方式。別人的方法再好，不適合你就是不適合。我試過很多「最佳實踐」，最後留下來的都是經過自己使用習慣打磨過的版本。
知識管理最大的敵人不是工具不夠好，是你懶得整理。工具只是藉口。