當火箭君之前提到 AnyType 和 Tana 時，後台就有小夥伴希望我介紹 Capacities。最近，講到 LogSeq 時， 又有小夥伴提及介紹 Capacities 這款 App。我覺得， 的確是應該介紹一下 Capacities，這是一款特色鮮明，有「靈魂」的筆記產品，也深受某一類用戶青睞。

考慮到，我主力工作流在 Obsidian 以及 LogSeq（LogSeq 近期可能會有變化，下次專門撰文介紹）。所以我覺得自己很難深入介紹 Capacities， 但是我腦海裡幾乎第一時間閃過一個海外 PKM （個人知識管理）社區的作者， 我覺的她最適合介紹 Capacities。

這位 PKM 社區作者 是 Beth， 我 follow 了很久， 她早期在讀書，同時發表一些 PKM 觀點，她也喜歡 LogSeq / Capacities / Notion。去年她放棄了碩士，最近（幾個月前）正式為 Capacities 工作。

雖說現在她和 Capacities 有利益關係，但是她的很多觀點在加入 Capacities 就已經形成， 包括長期筆記的習慣。

今天我想介紹的是一篇她近期的文章。既介紹了一些筆記的觀點，又介紹了 Capacities 這款 App。

原文位址：https://medium.com/@pkmbeth/how-i-spend-nearly-no-time-organising-my-notes-d5dc6c40fd28 作者：Beth McClelland (aka. PKM Beth)

以下正文，火箭君翻譯並略作編輯。

正文

整理筆記 是 PKM 的主要問題之一。大家創建了這麼多出色的筆記，但如何才能再次找到它們呢？筆記越多，這個問題就越重要。

在我以前使用的每一個筆記系統中，我都為此掙扎了很長時間。大學時，我曾使用 Word 和 OneDrive 但沒能整理好筆記，後來也沒能堅持使用 Roam Research / Obsidian / Logseq。我知道我討厭「資料夾」結構，但 Logseq 和 Roam 過度自由的節點結構也讓我受不了。我覺得很沮喪。

但是，當我在 2022年11月轉用 Capacities 時，我發現了一些有趣而的地方。我就一直使用它，一段時間后，到現在我已經為 Capacities 工作 （火箭君注：2024年上半年），並使用該應用程式處理大量事務。與Kaushik (火箭君注：The App Advocate 的博主) 的交流中，我意識到，我幾乎根本沒有考慮過整理這個問題。

然後我看到 Ev （火箭君注：另一個 PKM 博主, evielync） 的推文，她提到Tana 的超級標籤在她的生活日誌系統中提供了自動組織功能。這讓我想到，如果想不費力折騰「整理筆記」，關鍵可能就是使用「基於物件」的筆記應用。這也是我今天想詳細談談的問題。

我將使用 Capacities 作為示例，因為我使用的就是它，但 Capacities 並不是唯一一款「基於物件」的筆記軟體。其中一些內容在某些方面也適用於 Tana 和 Anytype，當然每個應用程式在處理問題的方式上都不盡相同。我還沒有廣泛測試過 Tana 和 AnyType 這兩款應用。

我（Beth）想在這裡明確指出，我也受雇於 Capacities 公司，但此文是我在自己的空閒時間寫的，而且沒有報酬。

什麼是「基於物件」（object-based）？

首先，我說的 「物件」指的就是一種（抽象意義上的）筆記。一個有標題、書寫位置的東西，在 Capacities中，「物件」還有一些「屬性」。在 Capacities 中，所有 物件（= 筆記）都有一個「類型」（Type）。這是什麼類型的筆記？事件、人物、會議、專案？如果你沒有特定的類型，可以直接創建一個 「空白頁面」。

我喜歡「類型」，因為可以輕鬆地為我的筆記賦予一個身份，而 Capacities 之前的系統都不允許我這樣做。這是因為這種身份不僅僅是把筆記放在特定資料夾位置或給它加上 #people 標籤，而是對筆記類型採取更多的自定義方法。（火箭君注：這是後面所有理念的出發點）

就拿人來說吧。如果我在我的歷史筆記空間（火箭君注：Beth 研究歷史， 英國王朝和歷代君主之類 ……）里開始記錄一個人，我想知道關於其他人的同樣的事情，這樣我就可以進行比較。他們是什麼時候出生的，他們的家庭成員是誰，他們統治了多少年？在我使用的任何其他系統中，我都必須記住創建這些資訊。但我沒有這樣做。這導致了很多長期的摩擦，我在這裡已經說過了。（火箭君注：想想最近筆記工具裡面流行的「範本」功能）

但現在，我只需新建一個「人」的物件，就能創建我想要的身份。這是因為我已經將我的人員物件類型配置為可以捕獲這些資訊的「屬性」（火箭君注：也可以理解為：元資訊，範本的固定欄位 ……），而且我已經配置了特定的頁面佈局，甚至是連結筆記時的預設檢視（下圖）。

事實上，在 Capacities 中，每次創建筆記時，我們必須選擇它的類型。是一個會議、一個人，還是只是一個簡單的頁面？然後，會根據你的設置自動載入特定的「屬性」。

這又能怎樣幫助我們？

我的大腦顯然喜歡基於對象的記錄方法。對我來說，用類型來思考比完全自由地控制各種筆記更有意義。我自己的各種試驗證明瞭這一點。

例如，如果我想 「我記下了一個……提到 ….」，我必須定義名詞才能知道搜索詞。這些名詞與我的物件類型名稱相對應。

以下是我目前設置的一些名詞：

在我的筆記中，很少有我既想寫人又想寫別的東西的例子。因為太少了，所以當問題出現時，我就直接忽略了，而且我也想不起來這些情況的具體細節，這可能告訴我，無論如何，這都不是什麼重要的問題。

此外，這裏還有一點很有用。無論出於什麼原因，如果初始物件類型不再適合你的筆記，只需更改即可！沒有什麼是一成不變的，就像資料夾一樣，但我想很多人會發現，賦予筆記更完整的身份（而不僅僅是它在資料夾中的位置）在實踐中非常有用。

老實說，這解決了我遇到的大部分組織問題。我清楚地記得，我只是想在 Obsidian/Logseq 中查看我所有的人物筆記，但如果不逐一查看就無法實現，因為我沒有將每個人物筆記定義為人物筆記。因此，沒有「元數據」可以查詢，沒有搜索詞可以查找，我只能煞費苦心地查看每份筆記，然後添加 type::person。（火箭君注：Obsidian 的範本和元資訊編輯， 可以實現類似效果）

但是，基於 “能力 “物件的方法卻讓這一切變得更加簡單。通過點擊左側欄中的連結，我可以查看我的所有人員物件，我還可以對這些選擇進行過濾和排序，查詢這些筆記，創建靜態集合等等。（火箭君注：這是 Capacities 從產品一開始就和 Obsidian 不同的地方）

這在我使用 Capacities 的第一天「物件」的機制就起了作用，而且從那以後一直保持著良好的擴展性。

如果物件類型不能解決所有問題呢？

我們可以讓筆記方便地連接起來。網狀筆記的應用程式（有很多）最適合實現這一點。如果你有連結和物件類型，就有很多方法回到你的筆記。這是因為將筆記與它的內容聯繫起來，會增加你重新發現該筆記的「覆蓋面積」。

這不是要記住一個特定的文件路徑，而是要創建多個路徑，説明你找到要找的註釋（或塊）。下面是 👇️ 的一個例子

因此，對我來說，我認為同時「基於物件」和「網路筆記」的應用才是完美的解決方案。我的實現方法就是採用 Capacities。

最後，我覺得「搜索」可以治癒一切。如果有我急需的東西漏網，而我又不記得物件類型或其關聯，那麼搜索總是可以解決這類問題。Capacities 有標題、內容、屬性，也許很快也會有基於人工智慧的語義搜索 👀。

不過，有一個小竅門是我從多年討厭資料夾的經歷中學到的。如果你搜索某樣東西時無法立即找到它，但後來又莫名其妙地找到了，那就重新命名它。我的一些檔名長得令人作嘔，但這是為了涵蓋我可能會用到的搜索條件。這個小竅門很簡單，但允許自己這樣做其實很有説明！

那麼「資料夾」呢？

各位可能已經注意到，我沒有提到「資料夾」。這是因為 Capacities 它沒有資料夾。

如果我們知道可以通過「物件類型」（例如：人）、「搜索」和「連結」（包括標籤）再次發現筆記，那麼再考慮其它組織方法和功能就不重要了。

在 Capacities 中，我們不用先構建一種組織層級的結構（就是資料夾體系）。這一點改變了遊戲的規則。

相應的，我們只需考慮 「將來我想在哪裡看到這個筆記」，就可以通過連結、收藏或查詢讓它出現在所有這些地方。我經常使用這些方法，因為我喜歡按照某些屬性對內容進行分組查詢。

例如，在我目前的研究專案中，無需逐個查閱每個人的資料，就能找到所有英國君主的資料集是非常有用的（火箭君注：在另一篇文章里，Beth 介紹了用工具展現英國王朝的時間線，也很有意思，還有一篇文章里……，算了下次再說）。為此，我剛剛創建了一個「資料集」（Collection）。

我還可以通過查詢創建自動收藏。這些查詢會收集符合我設置的規則的內容。

因此，如果我想查看中世紀晚期所有在世的人，我可以為此創建一個查詢。當我在人物筆記中填寫相關屬性時，他們要麼符合這些規則並出現在查詢中，要麼不符合。如果我忘記填寫屬性，我就會有一個處理頁面來收集遊離資訊。我可以處理該頁面，然後更新我的查詢。

但至少在 Capacities 中，這些集合和查詢只是有類型的物件系統之上的一層，這些物件可以連接到任何東西。App 關注的是內容在哪裡出現，而不是內容放在哪裡。從這個意義上說，我們從來沒有「組織筆記」，我們只是在問自己，想在哪裡看到哪些內容，並為實現這一目標創造條件（包括查詢和範本）。

寫在最後

火箭君注：

Beth 在 Capacities 上的這套方法更像是簡化後期分類的過程，把這個過程提前到了創建時，這是一種索引技術，通過前置分類和多種預設方式建立索引，這樣做使得後期的批量建立索引變得更容易，甚至不再需要後期創建索引。

但我們也要意識到，這種操作的局限性（至少火箭君沒有採用），不是所有人在筆記開始前就能想清楚一些分類和範本屬性問題的，因此這個輸入成本還是挺高的，但的確簡化了後期組織。

Capacities 很優秀， 簡直是為 J 人貼心準備的工具，就是桌面上抽屜里的東西歸類分明的那類小夥伴。而我個人的習慣是（包括筆記）先讓東西野蠻生長，到一定程度（無法忍受時）再來歸類， 和本文的前置分類，恰好相反🤣 …… 但我還是覺得各位一定要找到自己合適的工具，如果Capacities 恰好能滿足自己的需求，那就是最好的了。