在個人知識管理（PKM）的領域，使用者長期以來被迫在兩個典範之間做出選擇：以 Notion 為代表的雲端結構化資料庫，和以 Obsidian 為代表的本地化、網絡化純文本筆記。前者提供了強大的資料組織能力，但犧牲了資料所有權和長期可用性；後者確保了使用者對資料的絕對控制，但在處理結構化資訊時，往往需要依賴第三方外掛和相對複雜的查詢語法。這個兩難的局面，隨著 Obsidian 核心功能 Bases 的推出，終於迎來了破局的可能。
作為一個長期的 Obsidian 使用者，我深度依賴 Dataview 外掛來為我的筆記庫建立儀表板和索引。Dataview 功能強大，但其學習曲線不容忽視，且其查詢結果本質上是動態生成、無法直接編輯的「視圖」。Bases 的出現，旨在從根本上解決這個問題。它並非一個外掛，而是 Obsidian 的原生功能，這意味著更底層的整合、更優異的性能和更一致的使用者體驗。我花費了數週時間在 Insider 版本中對其進行深度測試，試圖回答一個核心問題：Bases 是否真的能將結構化資料庫的強大功能，無縫整合進 Obsidian 本地優先的哲學中？
Bases 的核心機制，是將筆記的元數據——即「屬性」（Properties）——提升為第一公民。它掃描指定資料夾下的所有筆記，讀取其 YAML Frontmatter 中的屬性，並將其轉換為一個功能完整的資料庫表格。這個過程完全在本地發生，速度極快。在我包含數千個檔案的庫中，建立和篩選一個包含數百篇筆記的 Base，其響應幾乎是瞬時的，這與基於雲端的 Notion 在處理大型資料庫時偶爾出現的延遲，形成了鮮明對比。
與 Dataview 最大的不同在於，Bases 提供的表格是「可寫」的。使用者可以直接在表格單元格中修改一篇筆記的屬性，變更會立刻寫回對應的 `.md` 檔案中。這個看似微小的改動，卻是工作流程上的一次巨大飛躍。例如，在管理一個專案的任務列表時，我可以直接在 Base 視圖中，將多個任務的狀態從「進行中」改為「已完成」，而無需逐一打開這些筆記檔案。這種原地編輯（in-place editing）的能力，極大地降低了維護結構化資料的摩擦力，使其體驗無限接近於 Notion，同時保留了所有資料都在本地的安心感。
另一個值得稱道的設計是其「視圖」（Views）系統。在同一個 Base 中，我可以建立多個擁有不同篩選和排序規則的視圖。例如，在我的讀書筆記庫中，我可以有一個「所有書籍」的總覽視圖，一個「待讀清單」的看板視圖（Kanban-style card view），和一個「年度精選」的畫廊視圖。這些視圖共用同一份底層資料（我的筆記檔案），但提供了多維度的觀察視角。這種設計顯然是借鑒了 Notion 的成功經驗，但在 Obsidian 的本地化框架下實現，顯得更為輕快和可靠。
當然，Bases 目前並非完美。相較於發展多年的 Dataview，其查詢能力還相對基礎。它目前無法進行複雜的數據聚合（如 `SUM` 或 `AVERAGE`），也缺乏 Dataview 強大的 `FLATTEN` 和 `GROUP BY` 功能，這對於需要進行深度數據分析的進階使用者來說，可能構成限制。Obsidian 官方已經表示，更強大的查詢和聚合功能正在開發路線圖上，但在此之前，Dataview 在處理複雜查詢場景時，依然保有其不可替代的優勢。
此外，Bases 的成功與否，高度依賴使用者是否養成了為筆記添加結構化屬性的習慣。對於習慣了自由書寫、不加任何元數據的使用者來說，Bases 的價值將大打折扣。它在某種程度上，要求使用者在寫作時，就對資訊的未來用途有一定的預判和規劃。這既可以被視為一種約束，也可以被看作是一種引導使用者進行更清晰思考的「有益的摩擦」。
總結來說，Obsidian Bases 是對個人知識管理領域一次意義重大的「融合創新」。它成功地將結構化資料庫的核心優勢——易於操作的視圖、篩選和排序——植入了 Obsidian 本地優先、純文本的生態系統中。它或許在初期還無法完全取代 Dataview 的所有高階功能，但它極大地降低了在 Obsidian 中進行結構化管理的門檻，並提供了一種遠比 Dataview 更為流暢和直觀的工作流程。
對於那些一直在 Notion 的便利性和 Obsidian 的自主性之間猶豫不決的使用者，Bases 提供了一個極具說服力的答案。它證明了我們無需為了強大的功能而犧牲資料的所有權。這是一個更符合長期主義的、更可持續的個人知識管理範式。Bases 並非終點，但它為我們指明了一個清晰的方向：一個真正由使用者掌控、兼具自由與秩序的「第二大腦」，是完全可能實現的。