只有天才與高收入者才知道的 Obsidian 建構技巧

用 AI 賺錢，關鍵不在「筆記數量」

首先，讓我們冷靜地討論一下。

從來沒有任何研究指出，年收入 1 億日圓與 Obsidian 的設定方式之間存在因果關係。也沒有「只有有錢人才知道的秘密插件」。

我所說的「年收入 1 億日圓玩家」，並不是指那些儲存了大量知識的人。

而是指那些能夠將他們獲得的資訊，轉化為以下事物，並且速度極快的人：

• 決策
• 談判
• 招聘
• 投資判斷
• 產品設計
• 內容
• 銷售資料
• 組織系統
• 可重複使用的智慧資產

一般的 Obsidian 使用者想著「要儲存什麼」。

強大的使用者首先思考的是：「未來在什麼情況下，會用什麼問題來檢索這筆資訊？」

更強大的使用者則會追蹤：那些被檢索的知識，最終轉化成了什麼決策或產出。

換句話說，你真正該設計的，不是一個「第二大腦」。

而是一個能讓決策與智慧生產產生複利效應的個人智慧作業系統。

Obsidian 將筆記儲存為本機的 Markdown 檔案。一個 Vault 只是一個資料夾，從外部編輯器或腳本所做的修改會反映在 Obsidian 中。設定與插件資訊則獨立存放在 .obsidian 資料夾中。這意味著 Obsidian 不僅是一個應用程式，更是一個可以透過 Git、CLI、Claude 和 Codex 來操作的「知識倉儲」。

在本文中，我們將 Obsidian 中的元素視為以下對應：

一旦你達到這個視角，你使用 Obsidian 的方式就會徹底改變。

第 1 章：研究海外案例——致勝策略是「搜尋」，而非「整理」

1. 從 7 位研究者的 Vault 中學到的事

2025 年發表了一項個案研究，調查巴西某研究機構中七位電腦科學研究者的 Obsidian 使用方式。

這項研究最重要的發現，並非參與者如何建立筆記。

而是發現他們未來打算如何檢索這些筆記，強烈地影響了他們建立與整理筆記的方式。 參與者針對不同目的，使用了搜尋列、標籤清單、內文中的標籤以及內部連結。有些使用者還會將建立的筆記放入收件匣，並每週處理一次。

研究者提出的設計建議，可以歸納為以下三點：

1. 不要一開始就要求完美的分類，先準備最小的初始結構。
2. 允許在使用過程中改變結構。
3. 從一開始就將建立/整理方法與未來的搜尋方法連結起來。

換句話說，重點不在於「建立正確的資料夾」。

而是在於決定你未來的自己將如何搜尋，並依照那個搜尋路徑來記錄。

光是這一點，就顯示出大多數常見的 Obsidian 課程都是本末倒置的。

許多課程會先讓你決定資料夾、標籤、插件和外觀。

然而，實際上你應該先決定的問題是這個：

三個月後，當我需要這筆資訊時，我可能會在什麼情況下感到困擾？

2. Nicole van der Hoeven——讓筆記成為職涯學習工具

擔任 Developer Advocate 與 Performance Engineer 的 Nicole van der Hoeven 指出，持續在工作上做筆記，不僅對學習速度有正面影響，也對她在科技業的職涯產生了正面影響。

關鍵不在於她「建立了一個美麗的知識資料庫」。

而是在於她記錄工作中的學習，並將其重複用於公開分享、解說和簡報。

她將學習筆記從個人記錄，進一步轉化為：

• 簡報
• 文章
• 影片
• 文件
• 教材
• 下一份工作

這種「從輸入到輸出的轉換」，創造了知識的經濟價值。

3. Bruno Paz——本機、Markdown、最小化插件

軟體工程師 Bruno Paz 將程式碼片段、會議記錄、專案規格、研究資料乃至生活知識，全部整合到 Obsidian 中。

然而，比將所有東西放進 Obsidian 更重要的，是他的設計哲學。

他強調 Markdown 的可攜性與 Git 的歷史管理，並採取將插件數量維持在最低限度的策略。插件讓 Obsidian 變得更方便，但內容本身不應過度依賴特定插件。

他也透過模板來標準化 Frontmatter（例如 type），將 Wikilink 放在 topics 中，並使用 Bases 或 Dataview 來列出它們。

這裡的結論很明確：

當出問題時，能夠僅靠 Markdown 還原，比功能強大更重要。

4. Ian O’Byrne——讓資訊流動：「消費 → 策展 → 創作」

在教育與研究領域使用 Obsidian 的 Ian O’Byrne，將其 Vault 大致結構化為以下流程：

• 消費：文章、書籍、論文、Podcast 等輸入
• 策展：提煉關鍵點、建立關聯、建立 MOC
• 創作：部落格、電子報、教材等輸出
• 後設：Vault 本身的操作資訊

重要的不是資料夾名稱。

而是資訊從輸入，經過意義建構，再到輸出的結構。 他說明，流程比平台更重要，而且 Vault 會隨著需求演進。

總結這些海外案例，優秀的 Vault 有五個共通點：

1. 檢索優先——從未來的搜尋反向思考
2. 輸出為中心——導向可交付成果，而非僅僅儲存
3. 本機優先——以 Markdown 為事實來源
4. 最小化 schema——不要讓輸入欄位過於複雜
5. 演化式——在使用過程中改變結構

第 2 章：定義「年收入 1 億日圓 Vault」的六個指標

筆記數量、連結數量、Graph 的美觀程度，都不是關鍵績效指標。

我會用以下六個指標來衡量 Vault 的效能：

1. 捕捉延遲

從產生想法到儲存之間的時間。

目標是 30 秒內。一個在輸入時強迫你思考標籤、相關筆記和儲存位置的結構，是脆弱的。

2. 檢索時間

找到必要資訊所需的時間。

一般資訊目標在 30 秒內，重要決策記錄則在 60 秒內。

3. 脈絡重建成本

看著舊筆記時，還原當時故事背景所需的時間。

只有會議標題的筆記是脆弱的。能夠保留「背景」、「決策」、「理由」、「前提」和「下一步行動」的筆記才是強大的。

4. 決策可追溯性

對於重要判斷，你日後能夠追蹤以下項目的比例：

• 為什麼做出這個決定
• 否決了什麼
• 存在哪些前提
• 什麼條件會觸發逆轉

5. 輸出轉換率

儲存的 Source Notes 或 Evergreen Notes 中，被重複用於文章、提案、產品、決策、會議或銷售活動的比例。

6. Agent 可執行性

Claude 或 Codex 能夠在不誤解 Vault 規則的情況下，進行搜尋、提案和驗證的時間比例。

總結來說，知識系統的 ROI 可以這樣思考：

知識 ROI = (重複使用的知識 + 改善的決策 + 避免的失敗) / 花在記錄、整理和維護上的時間

即使筆記數量增加，如果沒有被重複使用，那麼成長的只有分母。

第 3 章：適合日文使用者的 Vault 結構

如果我要從頭建立，我會使用以下頂層結構：

MyVault/

├── 00_Inbox/

│ ├── AI/

│ └── Clippings/

├── 10_Daily/

│ └── 2026/

├── 20_Projects/

├── 30_Areas/

├── 40_Notes/

│ └── MOCs/

├── 50_Sources/

├── 60_Entities/

│ ├── People/

│ ├── Companies/

│ └── Products/

├── 70_Outputs/

│ ├── Drafts/

│ └── Published/

├── 80_Assets/

├── 90_System/

│ ├── Templates/

│ ├── Bases/

│ ├── Schemas/

│ ├── AgentSkills/

│ └── AI/

├── 99_Archive/

├── scripts/

├── .claude/

├── .agents/

├── .codex/

├── CLAUDE.md

└── AGENTS.md

00_Inbox

未分類的輸入。不要在這裡整理。通常不需要標籤。這裡只是一個「先存起來」的地方。

10_Daily

按時間順序的工作記錄。留下那些不值得建立獨立筆記的備忘錄、對話、領悟和進度。

20_Projects

有完成條件的活動。「增加銷售額」是 Areas 或目標，但「在 2026 年 9 月之前修訂企業方案定價」則是 Project。Project 必須始終有 next_action。

30_Areas

持續的責任領域。管理、銷售、招聘、財務、健康、家庭、學習等。即使 Project 完成，Areas 仍然存在。

40_Notes

供長期重複使用的知識。將能夠用自己的話說明的內容放在這裡，而不僅僅是摘錄。不需要嚴格遵守「一則筆記，一個概念」。在日文中，主語和前提容易被省略，過度碎片化會破壞脈絡。標準是：

1 則筆記 = 未來想要以一個單位重複使用的內容

50_Sources

外部資訊的記錄。書籍、論文、文章、影片、會議資料、研究數據等。區分「對方說了什麼」和「我如何解讀」。

60_Entities

人物、公司、產品、客戶、競爭者、技術等實體。即使同一個人物或公司出現在多個 Project 中，也只保留一則 Entity Note。

70_Outputs

文章、企劃書、提案、影片腳本、簡報、銷售資料、產品規格等。將 Outputs 放在獨立的頂層資料夾中至關重要。 一個只以儲存為目標的 Vault，會成為知識的墳墓。

90_System

驅動 Vault 本身的機制，例如模板、Schemas、Bases、AI 規則和 Skills。透過建立這個，你將能夠解釋自己的操作方式。

應該使用一個 Vault 嗎？

原則上，是的。Obsidian 中的內部連結是在一個 Vault 內解析的；分割 Vault 會切斷知識之間的關聯。在上述研究中，將 Vault 分成三個的參與者回報了搜尋上的混亂。

然而，請將以下資訊在物理上分開：

• 合約禁止外部 AI 輸入的資訊。
• 醫療、個人 ID 號碼、憑證。
• 高度敏感的 HR 資訊。
• 受規範的資料。
• 根據組織政策無法傳遞給外部模型的資訊。

可以想像成區分「個人 Vault」和「受規範 Vault」。

第 4 章：不要混淆資料夾、Properties、連結和標籤的角色

Obsidian 系統崩潰的最大原因，是同時使用資料夾、標籤、Properties 和連結來表達相同的分類。請將它們的角色固定如下：

資料夾用於「生命週期」

Inbox、Project、Source、Output、Archive 等。它們表示筆記目前處於流程的哪個階段。

Properties 用於「機器處理的型別與狀態」

type、status、created、project、revisit 等。Obsidian Properties 以 YAML 格式儲存，可以具有 text、list、number、checkbox、date、datetime 和 tags 等型別。

連結用於「語意關係」

[[Pricing Strategy]]、[[ABC Corp]]、[[Reversibility of Decisions]] 等。將主題製成筆記而非標籤，可以讓該主題本身承載解釋、反證、參考資料和 MOC。

標籤用於「暫時性的跨領域狀態」

將標籤限制在 #review、#waiting、#question、#contradiction、#publish 這類事物上。

「Marketing」或「AI」這類概念應盡可能使用連結。將標籤用作概念字典會導致標籤擴散（例如 #AI、#ArtificialIntelligence、#GenerativeAI）。相反地，請在概念筆記中使用 Aliases。

第 5 章：最小化 Property Schema

不要一開始就試圖填滿 20 個項目。將 Schema 分為三個階段：

捕捉階段

只保留必要項目：
``yaml
type: 收件匣
created: 2026-07-24
status: 收件匣
``

提升階段

當它具有長期儲存價值時再加入：
``yaml
type: 筆記
created: 2026-07-24
status: 活躍
topics:
- "[[Pricing Strategy]]"
- "[[B2B SaaS]]"
source_notes:
- "[[SRC Competitor Pricing Research 2026-07]]"
confidence: 中等
sensitivity: 內部
``

操作階段

加入 Project 或 Decision 所需的項目：
``yaml
type: 專案
created: 2026-07-24
status: 活躍
owner: 我
area: "[[管理]]"
due: 2026-09-30
next_action: 比較 5 家競爭對手的年方案
``

第 6 章：日文檔案名稱的規則

不需要強迫將日文內文或標題改為英文。但是，用於機器處理的 Property 名稱和資料夾名稱請保持 ASCII。我使用以下命名慣例：

• Project: PJT Redesign of Corporate Pricing
• Decision: DEC 2026-07-24 Make Annual Plan the Standard Proposal
• Evergreen Note: Price is Determined by Implementation Failure Risk Rather Than Feature Count

讓 Evergreen Note 的標題成為「論點」而非「類別名稱」。論點式的標題能幫助你僅從搜尋結果就回想起內容。

第 7 章：實際應包含的模板

Daily Note

包含「摩擦日誌」。記錄「我搜尋了但找不到的東西」，可以讓你根據實際的搜尋失敗來改善 Vault。從失敗的搜尋中演化結構，而非從美學偏好。

Project Note

Project Note 不是任務的倉庫。它是任何人在 30 秒內就能理解當前狀態的專案指揮中心。

Decision Note

在高利潤的工作中，決策的品質比資訊更重要。因此，Decision Note 是最有價值的筆記類型。最重要的欄位是逆轉觸發條件。一個優秀的決策者，是在做出決策的當下就能寫下在什麼條件下會改變主意的人。

第 8 章：MOC 是「經過編輯的思考模型」，而非連結清單

一個好的 MOC（Map of Content）包含了編輯者的判斷。它是一個經過編輯的認知模型，壓縮了你目前對整個領域的理解方式，而不僅僅是相關筆記的清單。

第 9 章：使用 Bases 建立「管理儀表板」

Obsidian Bases 是一個核心功能，允許你像資料庫一樣顯示、篩選和排序筆記的 Properties。使用它來建立「活躍專案 Base」或「決策檢視 Base」，以恢復那些被擱置的判斷。

第 10 章：分層插件

• 第 0 層（僅核心）： Properties、Templates、Daily Notes、Bases、Search、Canvas 等。
• 第 1 層（出現摩擦時）： QuickAdd、Templater、Tasks。
• 第 2 層（僅在 Bases 不夠用時）： Dataview。

將活躍的社群插件保持在 12 個或更少。記錄每個插件的用途、替代方案和刪除條件。

第 11 章：2026 年的決定性變化——官方 Obsidian CLI

截至 2026 年 7 月，Obsidian 擁有官方 CLI。它允許你從終端機操作桌面版本：搜尋、讀取、建立、更新 Properties 以及檢查任務。這使得 Claude 和 Codex 能夠使用 Obsidian 自身的解析邏輯來操作，而不僅僅是直接編輯 Markdown。

第 12 章：AI 原生 Vault 的正確結構

讓 AI 自由編輯所有筆記並不是「AI 利用」。這就像把所有公司文件交給一個未經審查的實習生。正確的分工是：

• 人類： 目標、價值判斷、最終批准、MOC 編輯。
• Obsidian： 事實來源、關係、歷史、檢視。
• Claude： 提煉意義、比較、反論、草稿。
• Codex： 結構變更、腳本、驗證、差異審查。
• Git： 還原、稽核、實驗隔離。
• Validator： 偵測 Schema 違規與連結異常。

第 13 章：放置 CLAUDE.md 和 AGENTS.md

Claude Code 會讀取 CLAUDE.md 作為持續指令。Codex 會搜尋 AGENTS.md。在這些檔案中放置「Vault 操作契約」，以定義語言（日文散文、ASCII Properties）、安全規則（預設為試運行）和 Schema 規則。

第 14 章：透過 Claude 將 Obsidian 任務轉化為 Skills

針對執行超過三次或需要標準化品質的任務，定義「Agent Skills」。例如，一個 obsidian-distill skill 可以將原始會議記錄轉換為 Decisions、Tasks 和 Evergreen Notes。一個好的 Skill 是具有明確輸入、程序、禁止事項和完成條件的可重複執行工作標準。

第 17 章：Claude、Codex 和 Obsidian CLI 的協作模式

• 模式 1：會議記錄提煉（Claude 提取決策/任務）。
• 模式 2：每週管理檢視（Claude 總結本週進度和停滯的專案）。
• 模式 3：Schema 漂移稽核（Codex 偵測 Property 不一致）。
• 模式 4：決策前提稽核（Claude 檢查過去決策背後的假設是否仍然成立）。

這已經超越了「用 AI 總結筆記」的用法。你將 AI 用作一個審查你過去判斷的智慧控制器。

第 18 章：包含 Vault Validator

如果 AI 正在編輯你的 Vault，不要只滿足於「看起來沒問題」。透過腳本（例如 vault_check.py）實施最低限度的靜態測試，以驗證允許的型別、狀態和必要 Properties。