高级 Obsidian 设置：构建个人智能操作系统

用 AI 赚钱，关键不在于"笔记数量"

首先，让我们冷静地讨论一下。

没有任何研究显示，年收入 1 亿日元与 Obsidian 配置之间存在因果关系。也没有"只有富人知道的秘密插件"。

我所说的"1 亿日元玩家"，并非指那些储存了大量知识的人。

而是指那些能够将获取的信息，以极高的速度转化为以下内容的人：

决策
谈判
招聘
投资判断
产品设计
内容
销售材料
组织系统
可复用的智力资产

普通的 Obsidian 用户思考的是"该保存什么"。

强大的用户首先思考的是"未来在什么情况下，用什么问题，我会检索这条信息？"

更强大的用户会追踪这些检索到的知识最终转化成了什么决策或输出。

换句话说，你真正应该设计的并非"第二大脑"。

而是一个能够复合决策和智力产出的个人智能操作系统。

Obsidian 将笔记保存为本地 Markdown 文件。一个 Vault 就是一个文件夹，从外部编辑器或脚本所做的更改会反映在 Obsidian 中。设置和插件信息被分离到 .obsidian 文件夹中。这意味着 Obsidian 不仅仅是一个应用，而是一个可以被 Git、CLI、Claude 和 Codex 处理的"知识仓库"。

在本文中，我们将 Obsidian 上的元素视为如下：

Obsidian 元素	在知识系统中的含义
Markdown	源代码
Properties	类型系统
Templates	构造函数
Links	依赖关系
MOC	人工编辑的索引
Bases	数据库视图
Canvas	临时思考空间
Skills	可重复执行的业务流程
CLI	外部 Agent 的 API
Git	历史、差异、恢复
Weekly Review	测试与重构

一旦你达到这个视角，你使用 Obsidian 的方式就会完全改变。

第 1 章：研究海外案例——制胜策略是"搜索"，而非"整理"

1. 从 7 位研究者的 Vault 中学到的

有一项 2025 年发表的案例研究，调查了巴西某研究所七位计算机科学研究者使用 Obsidian 的情况。

这项研究最重要的收获，并非参与者如何创建笔记。

而是发现：他们未来打算如何检索笔记，强烈影响了他们创建和整理笔记的方式。 参与者出于不同的目的，使用了搜索栏、标签列表、文本中的标签以及内部链接。有些用户还将创建的笔记放入收件箱，每周处理一次。

研究者得出的设计建议可以归纳为以下三点：

不要一开始就要求完美的分类，准备一个最小化的初始结构。
允许在使用过程中改变结构。
从一开始就将创建/整理方法与未来的搜索方法联系起来。

换句话说，重要的不是"创建正确的文件夹"。

而是决定你未来的自己将如何搜索，并按照该搜索路径进行记录。

仅此一点就表明，大多数常见的 Obsidian 教程都是反过来的。

许多教程让你先决定文件夹、标签、插件和外观。

然而，实际上你应该首先决定的问题是：

三个月后，当我需要这条信息时，我会在为什么事情而烦恼？

2. Nicole van der Hoeven——让笔记成为职业学习工具

Nicole van der Hoeven 是一名开发者倡导者和性能工程师，她表示持续记录工作中的笔记不仅对学习速度有积极影响，也对她在科技行业的职业生涯产生了正面作用。

关键在于她并非"创建了一个漂亮的知识数据库"。

而是她记录了工作中的学习，并将其复用于公开分享、讲解和演示。

她将学习笔记不仅仅用于个人记录，而是流向：

演讲
文章
视频
文档
教学材料
下一份工作

这种"从输入到输出的转换"创造了知识的经济价值。

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

软件工程师 Bruno Paz 将代码片段、会议记录、项目规格、研究甚至生活知识都汇总到 Obsidian 中。

然而，比把所有东西都放进 Obsidian 更重要的是他的设计理念。

他强调 Markdown 的可移植性和通过 Git 进行历史管理，并采取将插件数量保持在最低限度的策略。插件让 Obsidian 变得便捷，但内容本身不应过度依赖特定插件。

他还使用模板标准化 type 等 Frontmatter，将相关笔记的 Wikilink 放入 topics，并通过 Bases 或 Dataview 列出它们。

这里的结论很明确：

当出问题时，仅用 Markdown 就能恢复，比功能强大更重要。

4. Ian O'Byrne——信息从"消费 → 策展 → 创建"流动

Ian O'Byrne 在教育和研究中使用 Obsidian，他将 Vault 大致按以下流程组织：

消费：文章、书籍、论文、播客等输入
策展：提炼关键点，关联它们，创建 MOC
创建：博客、新闻通讯、教学材料等输出
元：关于 Vault 本身的操作信息

重要的不是文件夹名称。

而是信息从输入，经过意义构建，最终流向输出的结构。 他解释说，过程比平台更重要，并且 Vault 会随着需求而演变。

总结这些海外案例，优秀的 Vault 具有五个共同点：

检索优先——从未来搜索反向推导
输出导向——流向可交付成果，而非仅仅存储
本地优先——以 Markdown 为事实来源
最小化模式——不要过度复杂化输入字段
进化性——在使用中改变结构

第 2 章：定义"1 亿日元 Vault"的六个指标

笔记数量、链接数量和图表的美丽程度并非关键性能指标。

我会用以下六个指标来衡量 Vault 的性能：

1. 捕获延迟

从产生想法到保存的时间。

目标是在 30 秒内。那种在输入时强迫你思考标签、相关笔记和保存位置的结构是弱的。

2. 检索时间

到达必要信息所需的时间。

一般信息目标在 30 秒内，重要决策记录在 60 秒内。

3. 上下文重建成本

查看旧笔记时恢复其内容所需的时间。

只有会议标题的笔记是弱的。能够保留"背景"、"决策"、"理由"、"前提"和"下一步行动"的笔记是强的。

4. 决策可追溯性

对于重要判断，你以后能够追踪以下内容的百分比：

为什么做出该决定
拒绝了什么
存在哪些前提
什么条件会触发反转

5. 输出转化率

存储的源笔记或常青笔记中被复用于文章、提案、产品、决策、会议或销售活动的百分比。

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

有完成条件的活动。"提高销售额"是一个领域或目标，但"在 2026 年 9 月前修订企业计划定价"是一个项目。项目必须始终有一个 next_action。

30_Areas

持续负责的领域。管理、销售、招聘、财务、健康、家庭、学习等。即使项目完成，领域仍然存在。

40_Notes

长期复用的知识。将你能用自己的话解释的内容放在这里，而不仅仅是摘录。无需严格遵循"一条笔记一个概念"。在中文中，主语和前提容易被省略，所以过度碎片化会破坏上下文。标准是：

1 条笔记 = 你未来希望作为一个单元复用的内容

50_Sources

外部信息的记录。书籍、论文、文章、视频、会议材料、研究数据等。将"对方说了什么"与"我如何解读"分开。

60_Entities

实体，如人、公司、产品、客户、竞争对手和技术。即使同一个人或公司出现在多个项目中，也只需保留一条实体笔记。

70_Outputs

文章、规划文档、提案、视频脚本、演示文稿、销售材料、产品规格等。将输出放在独立的顶层文件夹中至关重要。 只面向存储的 Vault 会成为知识的坟墓。

90_System

运行 Vault 本身的机制，如模板、模式、Bases、AI 规则和技能。通过构建它，你能够解释自己的操作流程。

应该是一个 Vault 吗？

原则上，是的。Obsidian 中的内部链接在 Vault 内解析；拆分 Vault 会断开知识之间的关系。在上述研究中，将 Vault 分成三个的参与者报告了搜索混乱。

然而，以下信息应物理分离：

合同禁止外部 AI 输入的信息。
医疗、个人身份证号码、凭证。
高度敏感的人力资源信息。
受监管的数据。
根据组织政策不能传递给外部模型的信息。

可以将其视为分离"个人 Vault"和"受监管 Vault"。

第 4 章：不要混淆文件夹、属性、链接和标签的角色

Obsidian 系统崩溃的最大原因，是同时使用文件夹、标签、属性和链接来表达相同的分类。固定它们的角色如下：

文件夹用于"生命周期"

收件箱、项目、来源、输出、归档等。它们表示笔记当前处于流程的哪个阶段。

属性用于"机器处理的类型和状态"

type、status、created、project、revisit 等。Obsidian 属性保存为 YAML，可以具有文本、列表、数字、复选框、日期、日期时间和标签等类型。

链接用于"语义关系"

[[定价策略]]、[[ABC 公司]]、[[决策的可逆性]]等。将主题设为笔记而非标签，可以让该主题本身包含解释、反证、参考材料和 MOC。

标签用于"临时的交叉状态"

将标签限制为 #review、#waiting、#question、#contradiction、#publish 等。

像"市场营销"或"AI"这样的概念，应尽可能使用链接。将标签用作概念词典会导致标签泛滥（例如 #AI、#ArtificialIntelligence、#GenerativeAI）。相反，要在概念笔记中使用别名。

第 5 章：最小化属性模式

不要一开始就试图填满 20 个项目。将模式分为三个阶段：

捕获阶段

仅包含必要内容：
``yaml
type: inbox
created: 2026-07-24
status: inbox
``

提升阶段

当笔记具有长期存储价值时添加：
``yaml
type: note
created: 2026-07-24
status: active
topics:
- "[[定价策略]]"
- "[[B2B SaaS]]"
source_notes:
- "[[SRC 竞争对手定价研究 2026-07]]"
confidence: medium
sensitivity: internal
``

操作阶段

添加项目或决策所需的项目：
``yaml
type: project
created: 2026-07-24
status: active
owner: me
area: "[[管理]]"
due: 2026-09-30
next_action: 比较 5 家竞争对手的年度计划
``

第 6 章：中文文件名规则

没有必要强制将中文正文或标题改为英文。但是，用于机器处理的属性名称和文件夹名称应保持 ASCII。我使用以下命名约定：

项目：PJT 企业定价重新设计
决策：DEC 2026-07-24 将年度计划设为标准提案
常青笔记：价格由实施失败风险而非功能数量决定

将常青笔记标题设为"断言"而非"类别名称"。断言式标题有助于你仅通过搜索结果就能回忆起内容。

第 7 章：实际要包含的模板

每日笔记

包含一个"摩擦日志"。记录"我搜索了但没找到的内容"，可以让你根据实际的搜索失败来改进 Vault。从失败的搜索中进化结构，而非根据审美偏好。

项目笔记

项目笔记不是任务的仓库。它是项目指挥中心，任何人在 30 秒内就能理解当前状态。

决策笔记

在高利润工作中，决策质量比信息更重要。因此，决策笔记是最有价值的笔记类型。最重要的字段是反转触发器。优秀的决策者能够在决策时就写下在什么条件下他们会改变主意。

第 8 章：MOC 是"编辑过的思维模型"，而非链接列表

一个好的 MOC（内容地图）包含编辑者的判断。它是一个编辑过的认知模型，压缩了你当前对整个领域的理解，而不仅仅是相关笔记的列表。

第 9 章：使用 Bases 创建"管理仪表板"

Obsidian Bases 是一个核心功能，允许你像数据库一样显示、筛选和排序笔记属性。使用它创建一个"活跃项目 Bases"或"决策审查 Bases"，以恢复那些被搁置的判断。

第 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。它允许你从终端操作桌面版：搜索、读取、创建、更新属性以及检查任务。这使得 Claude 和 Codex 能够使用 Obsidian 自身的解析逻辑进行操作，而不仅仅是直接编辑 Markdown。

第 12 章：AI 原生 Vault 的正确结构

让 AI 自由编辑所有笔记并非"AI 利用"。这就像把公司所有文件交给一个未经审查的实习生。正确的分工是：

人类： 目标、价值判断、最终批准、MOC 编辑。
Obsidian： 事实来源、关系、历史、视图。
Claude： 提炼意义、比较、反驳、起草。
Codex： 结构变更、脚本、验证、差异审查。
Git： 恢复、审计、实验隔离。
验证器： 检测模式违规和链接异常。

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

Claude Code 读取 CLAUDE.md 作为持续指令。Codex 搜索 AGENTS.md。在这些文件中放置"Vault 操作契约"，以定义语言（中文正文、ASCII 属性）、安全规则（默认 dry-run）和模式规则。

第 14 章：通过 Claude 将 Obsidian 任务转化为技能

对于执行超过三次或需要标准化质量的任务，定义"Agent 技能"。例如，obsidian-distill 技能可以将原始会议笔记转换为决策、任务和常青笔记。一个好的技能是一个可重复执行的工作标准，具有明确的输入、程序、禁止事项和完成条件。

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

模式 1：会议笔记提炼（Claude 提取决策/任务）。
模式 2：每周管理回顾（Claude 总结本周进展和停滞的项目）。
模式 3：模式漂移审计（Codex 检测属性不一致）。
模式 4：决策前提审计（Claude 检查过去决策背后的假设是否仍然成立）。

这种用法超越了"用 AI 总结笔记"。你将 AI 用作一个智力控制器，用于审计你的过去判断。

第 18 章：包含一个 Vault 验证器

如果 AI 正在编辑你的 Vault，不要满足于"看起来没问题"。通过脚本（例如 vault_check.py）实现最小静态测试，以验证允许的类型、状态和必需属性。