Capacities 物件式筆記 — 用卡片重新組織你的想法
I have enough authoritative material. Here is the article HTML: ```html Capacities 把筆記的基本單位從「檔案」改成「物件」：一場會議是一個 Meeting 物件，一本書是一個 Book 物件，一個人是一個 Person 物件，每個物件都帶
I have enough authoritative material. Here is the article HTML: ```html Capacities 把筆記的基本單位從「檔案」改成「物件」：一場會議是一個 Meeting 物件，一本書是一個 Book 物件，一個人是一個 Person 物件，每個物件都帶有自己的屬性與雙向連結。這個設計讓你不必先決定「這則筆記要放進哪個資料夾」，而是讓資訊依照它的真實類型自然分類，再透過連結長成一張可被反覆查詢的知識網。對長期累積知識的人來說，這是「整理一次、永久可檢索」與「每次都要重找一遍」的差別。 物件式筆記到底改變了什麼 傳統筆記軟體的核心是「文件」，物件式筆記的核心是「結構化的實體」。在 Evernote、Word 或多數 Markdown 編輯器裡，每一則筆記都是一張白紙，你要靠資料夾、標籤、檔名來事後分類。Capacities 反過來：你先定義內容類型（content type），例如建立一個 Book 物件，給它「作者」「評分」「閱讀狀態」「主題」等屬性；之後每本書都自動帶這些欄位，等於把資料庫的結構化能力放進筆記，卻不必手動建資料庫。 這帶來一個具體後果：同一份資訊只要輸入一次，就能從多個角度被找到。一個 Person 物件會自動聚合所有提到這個人的會議、讀書筆記與待辦；點開它，就看到與這個人相關的一切，不需要事先決定「這個人該歸在客戶資料夾還是專案資料夾」。資訊的歸屬不再是排他的單選題，而是多重連結的網狀關係。 為什麼「卡片」比「資料夾」更接近大腦運作 物件式筆記的思想源頭，是德國社會學家 Niklas Luhmann 的卡片盒（Zettelkasten）方法。Luhmann 用一套手寫卡片系統， 「累積超過 90,000 張索引卡，一生產出約 70 本書與 400 篇學術論文」（來源：Wikipedia） 。他的關鍵做法不是「分類儲存」，而是讓每張卡片透過編號相互指向，形成可以「對話」的網路——他遇到問題時，會循著卡片之間的連結，發現自己原本沒預期到的關聯。 資料夾是樹狀結構，一個檔案只能放在一個位置，這與大腦的聯想方式相反。 Zettelkasten 方法的核心主張 是：知識的價值來自連結密度，而非收納整齊。雙向連結（bi-directional links）正是把 Luhmann 的手寫編號自動化——當你在 A 筆記引用 B，B 也會自動顯示「被 A 引用」，連結成本趨近於零，於是你願意連得更多，網路也長得更密。Capacities 把這套方法做成預設行為，而不是需要外掛才能達成的進階功能。 Capacities 的核心機制 物件類型與屬性 Capacities 允許你自訂任意數量的物件類型，每種類型有獨立的屬性欄位與預設模板。實務上常見的配置是：把「書、文章、播客」設為輸入類物件，「想法、引述、問題」設為原子化的知識卡片，「專案、人、會議」設為脈絡類物件。當你寫一則讀書心得時，把它連到對應的 Book 物件與相關的「想法」卡片，這則心得就同時掛在三張網上，未來從任一入口都能回到它。 雙向連結與每日筆記 每日筆記（Daily Notes）是 Capacities 建議的輸入入口：每天一張卡片，先把當天的想法、摘錄、待辦快速倒進去，再用 @ 連結到對應物件。這個流程降低了「該把這則筆記放哪」的決策成本——先記下來，連結讓它之後自動歸位。隨著時間累積，物件之間的連結會浮現出你原本沒察覺的主題群聚，這正是 Luhmann 所說「與卡片盒對話」的數位版本。 AI 與智慧查詢 Capacities Pro 版本加入 AI 助理、智慧查詢（smart queries）、行事曆整合與任務管理。智慧查詢讓你用條件篩選物件，例如「列出所有評分高於 4 且狀態為已讀的 Book 物件」，等於對你的個人知識庫下 SQL 等級的問題，卻不必寫程式。 Capacities 官方網站 標示產品在 Mac、Windows、Linux、iOS、Android 與網頁版皆可使用，基礎功能免費。 這套方法解決的是哪一種痛點 物件式筆記真正對應的，是「資訊找不回來」這個被低估的成本。 「知識工作者平均花費約 19–20% 的工作週時間在搜尋與彙整資訊」（來源：McKinsey） ，相當於每週近一個工作天耗在「找東西」而非「用東西」。同一份報告也估計， 「更好的知識分享與檢索可使知識工作者生產力提升 20–25%」（來源：McKinsey Global Institute, 2012） 。當你的筆記是結構化物件而非散落文件，檢索成本下降，這部分被浪費的時間就能被收回。 但物件式筆記不是對所有人都划算。它的前期成本明顯：你需要先想清楚自己的物件類型與屬性，這對只想「快速記一句話」的輕量使用者是過度
FAQ
物件式筆記到底改變了什麼
傳統筆記軟體的核心是「文件」，物件式筆記的核心是「結構化的實體」。在 Evernote、Word 或多數 Markdown 編輯器裡，每一則筆記都是一張白紙，你要靠資料夾、標籤、檔名來事後分類。Capacities 反過來：你先定義內容類型（content type），例如建立一個 Book 物件，給它「作者」「評分」「閱讀狀態」「主題」等屬性；之後每本書都自動帶這些欄位，等於把資料庫的結構化能力放進筆記，卻不必手動建資料庫。 這帶來一個具體後果：同一份資訊只要輸入一次，就能從多個角度被找到。一個 Person 物件會自動聚合所有提到這個人的會議、讀書筆記與待辦；點開它，就看到與這個人相關的一切，不需要事先決定「這個人該歸在客戶資料夾還是專案資料夾」。資訊的歸屬不再是排他的單選題，而是多重連結的網狀關係。
為什麼「卡片」比「資料夾」更接近大腦運作
物件式筆記的思想源頭，是德國社會學家 Niklas Luhmann 的卡片盒（Zettelkasten）方法。Luhmann 用一套手寫卡片系統， 「累積超過 90,000 張索引卡，一生產出約 70 本書與 400 篇學術論文」（來源：Wikipedia） 。他的關鍵做法不是「分類儲存」，而是讓每張卡片透過編號相互指向，形成可以「對話」的網路——他遇到問題時，會循著卡片之間的連結，發現自己原本沒預期到的關聯。 資料夾是樹狀結構，一個檔案只能放在一個位置，這與大腦的聯想方式相反。 Zettelkasten 方法的核心主張 是：知識的價值來自連結密度，而非收納整齊。雙向連結（bi-directional links）正是把 Luhmann 的手寫編號自動化——當你在 A 筆記引用 B，B 也會自動顯示「被 A 引用」，連結成本趨近於零，於是你願意連得更多，網路也長得更密。Capacities 把這套方法做成預設行為，而不是需要外掛才能達成的進階功能。
Capacities 的核心機制
物件類型與屬性 Capacities 允許你自訂任意數量的物件類型，每種類型有獨立的屬性欄位與預設模板。實務上常見的配置是：把「書、文章、播客」設為輸入類物件，「想法、引述、問題」設為原子化的知識卡片，「專案、人、會議」設為脈絡類物件。當你寫一則讀書心得時，把它連到對應的 Book 物件與相關的「想法」卡片，這則心得就同時掛在三張網上，未來從任一入口都能回到它。 雙向連結與每日筆記 每日筆記（Daily Notes）是 Capacities 建議的輸入入口：每天一張卡片，先把當天的想法、摘錄、待辦快速倒進去，再用 @ 連結到對應物件。這個流程降低了「該把這則筆記放哪」的決策成本——先記下來，連結讓它之後自動歸位。隨著時間累積，物件之間的連結會浮現出你原本沒察覺的主題群聚，這正是 Luhmann 所說「與卡片盒對話」的數位版本。 AI 與智慧查詢 Capacities Pro 版本加入 AI 助理、智慧查詢（smart queries）、行事曆整合與任務管理。智慧查詢讓你用條件篩選物件，例如「列出所有評分高於 4 且狀態為已讀的 Book 物件」，等於對你的個人知識庫下 SQL 等級的問
這套方法解決的是哪一種痛點
物件式筆記真正對應的，是「資訊找不回來」這個被低估的成本。 「知識工作者平均花費約 19–20% 的工作週時間在搜尋與彙整資訊」（來源：McKinsey） ，相當於每週近一個工作天耗在「找東西」而非「用東西」。同一份報告也估計， 「更好的知識分享與檢索可使知識工作者生產力提升 20–25%」（來源：McKinsey Global Institute, 2012） 。當你的筆記是結構化物件而非散落文件，檢索成本下降，這部分被浪費的時間就能被收回。 但物件式筆記不是對所有人都划算。它的前期成本明顯：你需要先想清楚自己的物件類型與屬性，這對只想「快速記一句話」的輕量使用者是過度設計。如果你的需求是純粹的待辦清單、臨時備忘，或團隊即時協作文件，Capacities 的結構反而是負擔。它真正發揮價值的場景，是長期、跨年度、需要反覆回看與交叉引用的個人知識累積——研究者、寫作者、持續學習特定領域的專業工作者。
相關工具書
由 FeiYueh 親自審稿驗證 · 最後更新於 2026-07-15. Independently maintained — not AI-generated boilerplate.
← Back to Blog