前言
寫了一年多的技術文章後，我開始意識到一個問題：文章越寫越多，但找東西越來越難。
Design pattern 寫了 23 篇、infra 系列寫了 18 篇、前後端零散筆記更是不計其數。當內容量到達一定規模，如果沒有一套系統化的分類策略，知識庫就會變成一個巨大的垃圾桶 — 什麼都丟進去，但什麼都找不到。
這篇文章記錄我目前的知識管理架構：怎麼分類、怎麼編號、怎麼在兩個平台之間同步，以及我理想中的工作流長什麼樣子。
雙平台架構
我目前使用兩個平台來管理技術知識：
| 平台 | 性質 | 分類方式 | 用途 |
|---|---|---|---|
| Obsidian Vault | 私人 | PARA 方法 + 編號前綴 | 個人筆記、草稿、wikilink 導航 |
| Quartz Blog | 公開 | 扁平分類 | 發布文章、公開分享 |
兩者各司其職：Obsidian 負責收納和整理所有東西（包括不會公開的草稿和個人筆記），Quartz 負責對外發布已整理好的文章。
平台一：Obsidian Vault（PARA 方法）
Obsidian Vault 採用 Tiago Forte 的 PARA 方法作為頂層架構：
_roadmap/
├── 1. Projects # 進行中的專案
├── 2. Areas/ # 持續關注的領域
│ ├── 0_Design
│ ├── 1_CS/
│ │ ├── 0_common/ # 通用 CS：API, CRUD, MVC, design-patterns/
│ │ ├── 1_why # 各種「為什麼」的探討
│ │ ├── 11_b2e # 後端（backend）
│ │ ├── 2_officialDocument
│ │ ├── 21_f2e/ # 前端：html, css, js, ts, vue, react, angular
│ │ ├── 3_IDE
│ │ ├── 31_devOps/ # 基礎建設：docker, k8s, gitlab
│ │ ├── 9_git/ # git 指令、CI/CD、release flow
│ │ └── 91_constructor/ # 23 篇設計模式文章
│ ├── 2_DomainKnowHow
│ ├── 3_ProjectManagement
│ └── 9_Others
├── 3. Resources # 參考資料
└── 4. Archives # 已完成 / 不再活躍的內容
PARA 四層的用法
- Projects：有明確目標和期限的專案，例如「完成 infra 系列文章」或「建置 ClawdBot」。
- Areas：沒有期限但持續維護的領域，例如「前端技術」、「DevOps」。這是知識庫的核心。
- Resources：純參考用的資料，例如書摘、外部文章收藏。
- Archives：完成或不再需要的內容，從上面三層搬過來冷藏。
編號慣例
Obsidian 的資料夾名稱使用前綴編號來控制排序和分群：
0_ = 基礎 / 通用（foundational）
1_ = 主要類別
2_ = 次要類別
3_ = 第三類別
9_ = 雜項 / 特殊
子編號：
11_ = 延伸自 1_（例如 1_CS → 11_b2e）
21_ = 延伸自 2_（例如 2_ 系列 → 21_f2e）
31_ = 延伸自 3_（例如 3_IDE → 31_devOps）
91_ = 延伸自 9_（例如 9_git → 91_constructor）
這套編號的好處是：
- 排序穩定：不依賴檔案總管的字母排序，數字前綴確保順序固定。
- 分群直覺：看到
21_f2e就知道它跟2_系列有關，是前端領域。 - 擴展方便：中間有足夠的數字空間可以插入新資料夾，不需要重新編號。
平台二：Quartz Blog（扁平分類）
Quartz Blog 採用完全不同的策略 — 扁平分類，每個主題一個資料夾：
content/
├── aws/ # 雲端服務
├── backend/ # 後端概念
├── blog/ # 部落格 meta 文章
├── design-pattern/ # 23 篇設計模式（完整系列）
├── devOps/ # DevOps 實踐
├── express/ # Express.js
├── frontend/ # 前端概念
├── fundamentals/ # CS 基礎
├── git/ # Git 工作流
├── hexo/ # Hexo 靜態網站
├── infra/ # 18 篇基礎建設（完整系列）
├── jekyll/ # Jekyll 靜態網站
├── mac/ # macOS 技巧
└── tools/ # 開發工具
為什麼公開部落格用扁平分類？
跟 Obsidian 的深層巢狀不同，部落格刻意保持扁平，原因有三：
- URL 簡潔：
/design-pattern/01-singleton-pattern比/areas/cs/constructor/01-singleton-pattern好記得多。 - 讀者導向：訪客不需要理解我的 PARA 架構，直接按主題找文章。
- 維護簡單：不用擔心搬動資料夾時連結全部壞掉。
Obsidian 與 Quartz 的對應關係
兩個平台之間的資料夾有明確的對應關係：
| Obsidian（私人） | Quartz（公開） | 內容 |
|---|---|---|
91_constructor/ | design-pattern/ | 23 篇設計模式 |
31_devOps/ | infra/ + devOps/ | 18 篇 infra 系列 + DevOps |
21_f2e/ | frontend/ | 前端技術 |
11_b2e/ | backend/ | 後端技術 |
9_git/ | git/ | Git 工作流 |
0_common/ | fundamentals/ | CS 通用概念 |
| （無對應） | blog/ | 部落格 meta 文章 |
| （私人筆記） | （不發布） | 草稿、個人備忘 |
重點：不是所有 Obsidian 的內容都會發布到 Quartz。Obsidian 裡有很多個人筆記、未完成的草稿、工作備忘，這些只留在 Vault 裡。
同步策略
目前的同步方式：
- 寫作在 Quartz：文章直接在 Quartz 的 content 目錄寫，因為要符合 front matter 格式和 Quartz 的渲染需求。
- 同步回 Obsidian：寫完的文章同步一份到 Obsidian Vault，方便用 wikilink 串聯和個人導航。
- Obsidian 額外筆記：在 Obsidian 裡可以寫不公開的補充筆記，用
[[wikilink]]連結到已發布的文章。
寫作流程：
Quartz Blog (content/) Obsidian Vault (_roadmap/)
───────────────────── ─────────────────────────
撰寫文章（含 front matter） ──同步──> 個人參考 + wikilink
額外私人筆記（不發布）
這個流程的核心原則是：Quartz 是發布源，Obsidian 是知識網路。
理想工作流
經過多次調整，我認為理想的知識處理流程應該是三階段的：
Notion Obsidian Quartz
────── ──────── ──────
原始收集 整理 & 精煉 發布
- 需求規格 - 加入個人見解 - 公開文章
- 會議筆記 - 建立 wikilink - 系列索引
- 外部資料剪貼 - 分類歸檔 - SEO front matter
各階段的角色
- Notion：快速收集的入口。會議筆記、需求規格、外部文章剪貼，先丟進 Notion。Notion 的表格和資料庫功能適合這類結構化的原始資料。
- Obsidian：精煉和策展。把值得深入的主題從 Notion 搬過來，加入自己的理解、用 wikilink 建立知識之間的連結。這一步把「資料」變成「知識」。
- Quartz：對外發布。把整理好的文章加上 front matter、調整格式，發布成部落格文章。
為什麼不全部用 Obsidian？
曾經考慮過把所有東西都放在 Obsidian 裡，但實際操作後發現：
- Notion 的協作和表格功能，在收集階段比 Obsidian 好用。
- Quartz 的靜態網站輸出，比 Obsidian Publish 更靈活（而且免費）。
- 三個工具各有專長，硬要用一個工具做所有事反而效率更低。
過去的嘗試與教訓
在建立現在這套系統之前，我走過不少彎路：
資料夾散亂時期
最早的筆記散落在各處：桌面、Downloads 資料夾、隨意命名的 txt 檔。找一篇之前寫的筆記要靠搜尋和運氣。
全部丟 Notion 時期
後來試過把所有東西都放在 Notion，包括技術筆記、規格文件、個人日記。結果發現 Notion 的頁面越多，載入越慢，而且它的 Markdown 支援不夠原生，寫程式碼相關的筆記不太順手。
導入 PARA 方法
接觸到 PARA 方法後，把 Obsidian Vault 重新整理了一次。效果立竿見影：每個東西都有明確的歸屬，不再有「這個筆記到底該放哪裡」的困擾。
目前的數據
截至目前，兩個平台的內容規模：
| 系列 | 篇數 | 平台 |
|---|---|---|
| Design Pattern 設計模式 | 23 篇 | Quartz + Obsidian |
| Infra 基礎建設 | 18 篇 | Quartz + Obsidian |
| 其他技術文章 | 持續增加中 | Quartz + Obsidian |
| 私人筆記 / 草稿 | — | 僅 Obsidian |
結語
知識管理不是一次性的工作，而是持續演進的過程。目前這套雙平台 + PARA 分類的架構，對我來說運作得不錯。最關鍵的心得是：
- 公開和私人的內容要分開管理，不要因為怕麻煩就全部混在一起。
- 分類系統要符合自己的思維方式，別人的方法再好，不適合自己就沒用。
- 編號前綴比字母排序可靠，尤其是當資料夾數量超過 10 個的時候。
- 工具各有專長，接受這個事實，用對的工具做對的事。
如果你也在煩惱筆記和文章的組織方式，希望這篇文章能給你一些參考。