一个 Vault，两套逻辑：PARA × LLM-Wiki 融合架构的设计推演

本文是「AI 生活操作系统」系列的第二篇。

上一篇文章的结论是：你需要的不是更好的知识库，而是一个能容纳知识库的生活操作系统。

但这个结论很容易被误读为"再搭一个系统"——在 LLM-Wiki 旁边放一个 PARA，两套系统共存，互不干扰。

这是错的。

两套独立系统共存，是上一篇我们已经否定的"分库方案"的变体。它的失败方式是一样的：信息在系统边界处流失，维护成本加倍，AI 无法建立跨系统的上下文。

我们需要的是融合，不是并置。

融合意味着：PARA 和 LLM-Wiki 在同一个 Vault 中，遵循同一套 Schema，由同一个 AI Agent 管理。它们是一个系统的两个层次，不是两个独立的系统。

这篇文章要回答的问题是：这个融合架构应该长什么样？每一层的边界如何划定？两层之间如何通信？以及——为什么要这样设计，而不是另一种方式？

我会展示设计决策的推演过程，而不是直接给出答案。因为只有理解了"为什么"，你才能在自己的情况下灵活调整"怎么做"。

一、在画第一个文件夹之前：四个设计原则

架构设计有一个常见的错误：急于画结构图。目录树是架构的结果，不是起点。在画任何结构之前，需要先确立原则——这些原则将约束所有后续的决策，确保最终的系统是一致的，而不是东拼西凑的。

原则一：逻辑分层，物理共存

PARA 和 LLM-Wiki 是两套逻辑系统，但它们必须物理上住在同一个 Vault。

"逻辑分层"意味着：两套系统有清晰的职责边界，不互相侵入。PARA 不会去干涉 Wiki 内部的编译逻辑，Wiki 不会去影响 PARA 的项目状态管理。

"物理共存"意味着：它们共享同一个文件系统，可以通过 wikilink 互相引用，被同一个 AI Agent 统一调度。

这个原则来自一个类比：操作系统的"用户空间"和"内核空间"。两者共享同一块物理硬件，但在逻辑上是隔离的——用户程序不能直接操作内核，内核通过定义好的系统调用接口与用户空间通信。这种设计让系统既稳定（边界清晰，不会意外互相破坏），又高效（共享资源，不需要重复维护）。

实践含义：目录结构是逻辑边界的物理映射。每个目录的存在都有理由，每条边界的划定都有依据。不能因为"感觉应该放这里"而随意组织。

原则二：单一入口，AI 分拣

所有信息从同一个 Inbox 进入，不要求你在信息到来的那一刻就做出分类决策。

分类是认知负担。每次捕获信息时同时思考"这条信息属于哪个维度、应该放哪里、用什么格式记录"，会制造足够的摩擦，让你逐渐放弃捕获习惯。

更重要的是，分类决策在信息刚到来时往往是困难的。你看到一篇论文，你说不清楚它现在对你是"知识素材"还是"项目参考"——这取决于你接下来的行动，而此刻你还不知道自己会怎么行动。

单一入口解决的不只是便利性问题，而是认知时序问题：先捕获，后分类。捕获的摩擦要接近于零，分类可以稍后发生，由 AI 代劳。

实践含义：Inbox 是整个系统的唯一入口。它的设计必须是零摩擦的——手机上可以快速投入，桌面端一个快捷键触发，不需要填写任何元数据。分拣规则必须是可编程的，写在 Schema 里，由 AI 执行。

原则三：双向链接是唯一的跨层通信协议

PARA 和 Wiki 之间不通过目录嵌套通信，而是通过 [[wikilink]]。

为什么不用目录嵌套？因为嵌套意味着从属，而 PARA 和 Wiki 的关系不是简单的从属关系，而是相互引用的关系。

一个 Project 页面引用了 Wiki 里的概念，同时 Wiki 里的概念页记录了这个概念被哪些项目使用。这是双向的关系，无法用单向的目录包含来表达。

用 wikilink 作为通信协议还有一个重要的架构优势：松耦合。两套系统可以独立演化——你可以重组 PARA 的目录结构，而不破坏 Wiki 内部的链接网络；你可以扩展 Wiki 的内容，而不影响 PARA 的任务管理逻辑。只有 wikilink 保持稳定，两个系统就能持续互联。

实践含义：任何跨越 PARA 和 Wiki 边界的关联，都通过 wikilink 建立，而不是通过目录结构暗示。两套系统在目录层面是平行的兄弟关系，在内容层面通过链接形成网状连接。

原则四：AI 必须持有完整的系统地图

这个原则是整个架构能够运转的前提，也是最容易被忽视的一条。

如果你只给 AI 看 Wiki 的结构，它能很好地编译知识页，但它不知道这个知识应不应该触发一个新任务。如果你只给 AI 看当前打开的 Project 笔记，它能帮你整理任务，但它不知道 Wiki 里有没有相关的背景知识。

AI 需要理解整个 Vault 的架构，才能做出跨层的正确决策。

这意味着需要一个统一的 Schema 文件——不是配置文件，而是写给 AI 看的"系统说明书"。它描述整个 Vault 的逻辑结构，每个层次的职责，每种信息的归属规则，以及 AI 在各种情况下应该怎么行动。

这个文件是第三篇文章的核心主角，此处先建立概念：它的存在是整个架构成立的基础条件，不是可选的附件。

二、PARA 层：管理生活全域信息

原则确立之后，我们开始设计具体的架构。先从外层开始：PARA。

为什么选 PARA

首先回答一个合理的质疑：为什么是 PARA，而不是其他框架？

GTD（Getting Things Done）是强大的任务管理系统，但它只覆盖了行动维度。知识、参考资料、生活领域的持续维护——GTD 没有为这些设计位置。用 GTD 作为外层，你仍然需要为其他维度另找方案。

Zettelkasten 是为知识维度设计的，和 LLM-Wiki 的角色重叠。把 Zettelkasten 作为外层，相当于用一个知识系统包裹另一个知识系统，非知识维度的信息依然无处安放。

Johnny Decimal 是编号索引系统，擅长让信息"有地方放"，但它本质上是一个分类方案，缺乏对信息可操作性的感知——它不区分"你现在在做的"和"你以后可能用到的"。

PARA 的独特之处在于它的核心组织原则：以可操作性梯度，而非主题，组织信息。

Projects（立即推进）> Areas（持续维护）> Resources（备用参考）> Archives（不再活跃）

这个梯度解决了知识管理中一个根本性的问题：同样的信息，对你当前生活的意义不同，应该在不同的位置。一篇关于健身的文章，你准备下周开始实践时它是 Project 资料，你只是感兴趣但没有计划行动时它是 Resource，你实践结束后它进入 Archives。信息本身没有变，但它对你的可操作性改变了，位置随之改变。

这种设计的实用价值是：你永远知道现在应该把注意力放在哪里——打开 Projects，这里是你今天应该推进的事情。

Projects：必须同时满足两个条件

Projects 层存放的是有明确终点和时间边界的承诺。

判断一个事项是否属于 Project，需要同时满足两个条件：

条件一：有明确的完成状态。"完成"必须可以被客观判断。不是"我觉得差不多了"，而是"这个具体的产出物存在了"或"这个具体的事件发生了"。

条件二：有时间边界。不一定是精确的 deadline，但要有"预期完成时间"的概念。无限期推进的事项不是 Project，是 Area。

举几个例子来校准边界：

Project 页面的核心元素：

• 成功标准（"完成"的定义，必须写清楚）
• 预期完成时间
• 当前状态（active / waiting / someday）
• 关联的 Area（这个项目服务于哪个生活领域）
• 关联的 Wiki 内容（与这个项目相关的知识背景）
• 任务列表

最后一个元素——关联的 Wiki 内容——是 PARA 和 Wiki 之间最重要的接口之一。当你启动一个新 Project 时，AI 应该自动在 Wiki 中检索相关概念，将关联的知识背景链接到 Project 页面。这意味着你不是从零开始推进每个项目，而是站在已有知识积累的基础上开始。

Areas：你的人生责任清单

Areas 层存放的是需要持续维护标准的生活面向。

每个人的 Area 清单是个人化的，但有一些几乎普遍存在的领域：职业发展、健康、财务、家庭关系、个人成长、创作、居住环境。

Area 与 Project 的核心区别是：Area 没有终点，但有"健康/不健康"的状态。"维持身体健康"没有完成时刻，但你能感知到它目前的状态——你最近三个月有规律运动吗？你的睡眠质量怎么样？

因此，每个 Area 页面的核心内容不是任务列表，而是：

• 标准描述：这个领域"理想状态"是什么样的？（用来判断健康/不健康）
• 当前状态评估：最近的实际情况如何？（每月更新）
• 定期任务：不属于任何 Project 但需要持续做的事
• 关联项目：目前服务于这个 Area 的 Projects
• 资源指针：指向 Resources 和 Wiki 中相关内容的链接

Area 是 PARA 系统中最容易被忽视、也最重要的一层。很多人把 PARA 理解为项目管理工具，用 Projects 管理一切，Area 沦为摆设。但 Area 才是你对自己生活的系统性承诺——它强迫你定期回问自己：我真正在意的那些生活面向，我真的在维护它们吗？

Resources：普通资源与知识资源的分叉点

Resources 层是这个架构中最关键的设计决策所在。

表面上，Resources 是"感兴趣但暂时不需要行动的材料"的存放地。但在我们的架构中，Resources 内部存在一个重要的分叉：

text

3-Resources/
├── 普通资源/          ← 菜谱、旅行攻略、工具推荐、参考链接
│   ├── 生活/
│   ├── 工具/
│   └── 娱乐/
│
└── → Wiki/            ← 专业知识资源（指向根目录下的 Wiki/）

普通资源不需要 AI 编译，不需要交叉引用网络，不需要持续维护。它们只需要被分类存放，在你需要时能找到。一个收藏的菜谱、一份旅行攻略、一个工具推荐——它们的价值是参考性的，不是知识性的。

专业知识资源则不同。它们是可以被编译为概念的，可以与其他知识建立实质性关联，值得 AI 持续维护的内容。这类内容进入 Wiki 子系统。

为什么 Wiki 不是顶层目录，而是 Resources 层的延伸？

这是一个刻意的架构决策，背后有两个理由：

第一，从逻辑上说，Wiki 里的内容本质上是"知识型的参考资源"——它们是 Resources 的一个特殊子集，只是深度更深、组织方式更精密。把 Wiki 定位为 Resources 的内核，比把它定位为与 PARA 并列的独立系统，在逻辑上更自洽。

第二，从实用上说，这种定位明确了 Wiki 的边界：Wiki 只处理"资源性"的知识，不处理"行动性"的信息。如果一条知识与某个正在进行的 Project 强烈相关，它的上下文在 Projects 层；当项目结束、知识沉淀为通用资产后，它才从 Projects 流向 Wiki。

物理上，Wiki/ 作为独立目录存放在 Vault 根目录而非嵌套在 3-Resources/ 内部——因为 Wiki 有复杂的内部结构，深层嵌套会增加路径复杂度。但逻辑上，Wiki 属于 Resources 层的知识子系统。这种"物理独立、逻辑从属"的设计是刻意的权衡。

Archives：认知卸载的仪式

Archives 是所有"不再活跃"内容的归宿：完成的 Projects、不再关注的 Areas、过时的资源。

归档不是删除。删除会引发焦虑——万一以后还用得到？归档是把不再需要占用注意力的内容移出视野，同时保留它的可检索性。

Archives 还有一个重要的功能：知识沉淀的触发点。

每当一个 Project 被归档，这是一个信号——这段时间内你积累的经验、学到的东西、形成的判断，有一部分具有通用价值，应该从项目语境中提取出来，沉淀为 Wiki 中的永久知识资产。

/archive 命令（第三篇会详细设计）应该自动触发这个提取过程：Project 进入 Archives，同时 AI 扫描 Project 笔记，将通用知识编译进 Wiki。这个流程确保了知识不会随着项目的关闭而消失，而是以更高质量的形态持续存在。

周期笔记：PARA 的时间维度

PARA 是一个静态的空间组织系统，它回答的是"信息应该放在哪里"，但它没有时间感——它不知道什么事情应该在今天发生，本周有什么重要节点，这个月的整体进展如何。

周期笔记（Daily / Weekly / Monthly / Quarterly）补充了这个缺失的时间维度。

设计上有一个重要决策：周期笔记不归属于 PARA 四层中的任何一个，而是独立的 Periodic/ 目录。

原因是：周期笔记横跨 PARA 的所有层——Daily Note 里有今天的 Project 任务，也有 Area 的状态检查，也有新进入 Inbox 的内容，也有 Wiki 的更新摘要。把它放进任何一个 PARA 层都是错的，因为它服务于整个系统，而不是某个特定层次。

周期笔记在这个架构中的功能是：你感知系统整体状态的唯一界面。

你不需要分别打开 Projects、Areas 和 Wiki 来了解系统状态。Daily Note 是你今天的操作界面，它聚合了来自所有层次的相关信息，由 AI 自动生成和更新。Weekly Note 是系统的心跳检测，每周一次，让你从上帝视角评估整个系统的健康状况。

三、Wiki 层：管理深度专业知识

现在进入内核设计。

LLM-Wiki 子系统在这个架构中有一个精确的定位：它是 PARA Resources 层的知识内核，专门处理"可以独立于你的个人上下文存在的专业知识"。

这个定位划定了 Wiki 的边界，这条边界极其重要：跨越它就意味着信噪比的下降。

什么内容应该进入 Wiki

判断标准是一个问题：这条知识是否"独立于你的个人上下文"？

如果一条知识的价值不依赖于你当前的项目、你当前的想法、你当前的处境——它描述的是一个客观存在的事实、原理、或领域共识——它就应该进入 Wiki。

如果一条内容包含了你的主观判断、你的项目上下文、你对某件事的个人看法——它应该留在 PARA。

几个例子来校准这条边界：

灰色地带的处理方式：个人观点可以作为 Wiki 页面的附注区块存在，但必须明确标记为主观内容，与客观知识部分视觉上区分开来。Wiki 的客观性是它价值的基础——一旦主客观混淆，AI 在查询时就无法判断哪些是可引用的知识，哪些是你的个人倾向。

Wiki 的内部结构

Wiki/ 目录的内部结构是这套架构中最需要精心设计的部分，因为它直接决定了 AI 编译质量和后续查询效率。

text

Wiki/
├── _schema.md          ← Wiki 操作规范（给 AI 看的说明书）
├── _index.md           ← Wiki 主索引（由 AI 自动维护）
├── raw/                ← 原始素材区
│   ├── articles/       ← 文章、博客、网页内容
│   ├── papers/         ← 学术论文、研究报告
│   ├── transcripts/    ← 播客、视频、会议转录
│   └── notes/          ← 手写笔记、会话摘要
├── topics/             ← 概念页区（扁平结构）
└── people/             ← 人物页区

每个区域的设计逻辑如下。

raw/：只进不出的素材池

raw/ 是原始素材的存放区域，一旦进入就不再移动，也不由人类直接浏览。它的唯一用途是作为 AI 编译的输入来源。

按素材类型分子目录，是因为不同类型的素材需要不同的 ingest 策略：一篇学术论文的处理方式（摘要、方法论、结论、引用）与一段播客转录的处理方式（观点提取、论据梳理、嘉宾立场）是不同的。通过目录区分类型，AI 可以在编译时选择适合的处理策略。

topics/：扁平的概念图谱

这是 Wiki 的核心区域，也是最需要解释的一个设计决策：为什么是扁平结构，不建子目录？

直觉上，建子目录似乎更有序：机器学习/、自然语言处理/、计算机视觉/……每个领域有自己的空间。

但这个直觉是错的，原因在于知识的本质。

知识不是树状的，是网状的。Transformer 架构既属于深度学习，也属于自然语言处理，也属于计算机视觉，也属于强化学习。如果你建了子目录，这个概念页应该放在哪里？无论放在哪里，它和其他领域的关联在目录层面就消失了。

扁平结构让所有概念处于同一层级，它们之间的关联完全通过 wikilink 表达——这才是网状知识的正确组织方式。通过 wikilink，你可以追踪从任意概念出发的关联路径，看到知识之间意想不到的连接。

用子目录作为分类，是在用树状思维处理网状知识，结果是把知识图谱人为切割成孤立的领域孤岛。

people/：人物档案

领域内的重要人物、关键合作者、值得追踪的研究者。人物页的结构类似概念页，但关注点是这个人的研究方向、核心贡献、主要观点，以及与 Wiki 中其他概念和人物的关联。

_schema.md：Wiki 的宪法

这个文件是 Wiki 子系统能够持续高质量运转的关键。它不是给人看的文档，是给 AI 看的操作手册——定义概念页的标准格式、命名规范、如何处理已有类似页面、什么情况下新建与合并、主观内容如何标记。

第三篇文章会详细讨论如何写好 _schema.md。此处先确立它的地位：它是 Wiki 质量的控制器，没有它，AI 每次编译的输出格式都会有偏差，Wiki 的一致性会随时间衰退。

_index.md：人类浏览 Wiki 的入口

由 AI 自动维护的目录页，按主题领域分组列出所有概念页，提供每个页面的一行描述。你通过这个页面浏览 Wiki 全貌，而不是直接在 topics/ 目录里滚动文件列表。

四、两层之间的接口设计

PARA 层和 Wiki 层的设计都清楚了。现在到了整个架构中最精妙、也最容易出错的部分：两层之间如何通信？

共有四个接口，每个都有精确的触发条件和信息流方向。

接口一：Inbox → 分拣 → 两层

这是系统的入口接口，所有信息通过它进入系统并被路由到正确的位置。

分拣决策树：

text

新信息进入 Inbox
│
├── 有明确的可执行行动？
│   ├── YES → 有时间约束或明确产出？
│   │         ├── YES → 1-Projects/（创建或更新 Project 笔记）
│   │         └── NO  → 2-Areas/（更新相关 Area 的定期任务）
│   └── NO  → 继续↓
│
├── 是专业知识素材（客观、可独立存在）？
│   ├── YES → Wiki/raw/（触发 wiki-ingest）
│   └── NO  → 继续↓
│
├── 是普通参考信息（工具、菜谱、攻略）？
│   ├── YES → 3-Resources/普通资源/（按类型归档）
│   └── NO  → 继续↓
│
├── 是碎片想法或个人感想？
│   ├── YES → 合并进当日 Daily Note 的「快速捕获」区块
│   └── NO  → 继续↓
│
└── 是过时信息或无价值内容？
    └── YES → 直接删除

有一种常见的边界情况需要特别处理：一条信息同时包含任务和知识。

例如，你的会议记录里既有"下周三前完成竞品分析"（任务），也有对手产品架构的技术细节（知识）。这条信息不应该整体进入任何一个位置，而应该被拆分：任务部分提取出来进入 Projects，技术知识部分进入 Wiki/raw/，会议记录的原始文件本身归入对应的 Project 笔记中存档。

分拣不是简单的路由，有时需要先拆分，再分别路由。这个拆分逻辑需要在 CLAUDE.md 中明确定义，否则 AI 会倾向于把整条信息路由到它认为最合适的单一位置，造成信息流失。

接口二：PARA → Wiki（知识沉淀）

方向：PARA 层的知识性内容 → Wiki

触发场景：

1. 项目归档时：Project 完成，其中产生了通用知识，自动触发提取
2. 手动触发时：你在推进项目过程中意识到某段内容具有通用价值，手动运行 /extract-to-wiki

这个接口的核心设计挑战是：如何区分"通用知识"和"项目特定信息"？

• 通用知识：脱离项目上下文仍然成立，可以被引用，对其他项目也有参考价值
• 项目特定信息：只在这个项目的上下文中有意义，对其他场景价值有限

例如，你做完了一个"系统性学习 Rust"的 Project：

提取后的状态：Project 进入 Archives，Wiki 新增若干概念页，两者之间建立双向 wikilink——Archives 里的 Project 页面链接到它贡献的 Wiki 页面，Wiki 页面底部记录"来源项目"。知识被沉淀了，项目上下文也被保留了。

接口三：Wiki → PARA（知识激活行动）

方向：Wiki 中的知识 → 触发 PARA 层的行动

这个接口是最"软"的一个，不是由命令触发，而是由你的主动意识触发。

场景：你在浏览 Wiki，读到某个概念页，这个知识点触发了一个想法——"我应该基于这个做点什么"。

操作方式：在 Wiki 页面中直接写下这个行动想法，标记 #to-inbox，下次 /triage 时 AI 会将它提取出来，在 Projects 或 Areas 中创建对应的行动条目，然后清理 Wiki 页面中的标记。

为什么不直接在 Wiki 页面里建立到 Project 的链接？

因为 Wiki 应该保持它的客观性。Wiki 页面记录的是知识本身，不应该被你当前的项目计划所污染。今天你打算基于这个知识做 A 项目，但六个月后这个知识对你来说的意义可能是 B 项目。知识的客观内容不应该随着你的行动意图改变。

把行动意图标记为 #to-inbox，让它流回 Inbox 再被分拣处理——这个迂回路径保护了 Wiki 的纯净性，同时确保行动意图不会流失。

接口四：周期笔记 ↔ 两层（时间维度的桥梁）

周期笔记是一个双向接口：它从两个层次聚合信息供你浏览，也向两个层次写回新的状态更新。

聚合方向（两层 → 周期笔记）：

Daily Note 由 /today 命令自动生成：

• 来自 Projects 的今日任务（active 状态的 Project 中 due today 的任务）
• 来自 Areas 的定期任务（每日/每周例行事项）
• 来自 Wiki 的昨日更新摘要（昨天新增或更新了哪些概念页）
• 当日 Inbox 内容（待 triage）

Weekly Note 由 /weekly-review 命令自动生成：

• 本周 Projects 进展（完成了什么，停滞了什么，需要什么决策）
• Areas 健康状态（哪个 Area 本周有异常，需要关注）
• Wiki 本周积累（新增了多少概念页，知识库在哪些方向扩展了）

写回方向（周期笔记 → 两层）：

在 Weekly Review 过程中，你可能做出一些决定：

• "这个 Project 应该归档了"→ 触发 /archive
• "这个想法值得发展成新 Project"→ 通过 Inbox 流入 Projects
• "这个 Area 的标准需要更新"→ 直接编辑 Area 页面

周期笔记是你和系统之间的主交互界面。你不需要直接操作 Projects、Areas 或 Wiki，一切通过周期笔记发生，系统在后台维护自身的状态。

五、完整目录树

现在可以把所有设计决策综合为一张完整的目录树。这不只是文件结构，每个节点的存在都有上述设计原则的支撑：

text

MyLife-Vault/                      ← 单一 Vault，一切发生在这里
│
├── 📥 Inbox/                      ← 唯一入口，零摩擦捕获
│   └── YYYY-MM-DD-HHmm.md        ← 时间戳命名，不需要预先分类
│
├── 📋 1-Projects/                 ← PARA: P，立即推进的承诺
│   ├── _dashboard.md             ← Dataview 项目仪表盘（AI 维护）
│   └── [项目名]/
│       ├── README.md             ← 项目主页（成功标准/状态/关联）
│       ├── tasks.md              ← 任务列表
│       ├── notes/                ← 项目过程笔记
│       └── assets/               ← 项目相关文件
│
├── 🔄 2-Areas/                    ← PARA: A，持续维护的生活面向
│   ├── _dashboard.md             ← Areas 健康状态仪表盘
│   ├── 职业发展/
│   │   ├── README.md             ← 标准描述/当前状态/关联项目
│   │   └── notes/
│   ├── 健康/
│   ├── 财务/
│   ├── 家庭/
│   └── 个人成长/
│
├── 📚 3-Resources/                ← PARA: R，备用参考资源
│   ├── 生活/                     ← 菜谱、旅行、消费等
│   ├── 工具/                     ← 软件、效率工具推荐
│   └── 兴趣/                     ← 娱乐、爱好相关
│
├── 🗃️ 4-Archives/                 ← PARA: A，不再活跃的一切
│   ├── Projects/                 ← 已完成/放弃的项目
│   └── Areas/                    ← 不再关注的生活领域
│
├── 📅 Periodic/                   ← 时间维度，独立于 PARA 四层
│   ├── Daily/
│   │   └── YYYY-MM-DD.md
│   ├── Weekly/
│   │   └── YYYY-WNN.md
│   ├── Monthly/
│   │   └── YYYY-MM.md
│   └── Quarterly/
│       └── YYYY-QN.md
│
├── 🧠 Wiki/                       ← LLM-Wiki 子系统（Resources 的知识内核）
│   ├── _schema.md                ← Wiki 编译规范（给 AI 看的操作手册）
│   ├── _index.md                 ← Wiki 主索引（AI 自动维护）
│   ├── raw/                      ← 原始素材（只进不出，只被 AI 读取）
│   │   ├── articles/
│   │   ├── papers/
│   │   ├── transcripts/
│   │   └── notes/
│   ├── topics/                   ← 概念页（扁平结构，无子目录）
│   │   ├── [概念名].md
│   │   └── ...
│   └── people/                   ← 人物页
│       └── [人名].md
│
└── .agent/                        ← AI Agent 配置（不在 Obsidian 正常视图中显示）
    ├── CLAUDE.md                  ← 主 Schema（整个系统的说明书）
    └── skills/                    ← Slash Command 定义
        ├── triage.md
        ├── today.md
        ├── wiki-ingest.md
        ├── extract-to-wiki.md
        ├── weekly-review.md
        ├── project-kickoff.md
        └── archive.md

几个需要额外解释的设计细节：

为什么 _dashboard.md 用下划线开头？

下划线开头的文件在 Obsidian 的文件列表中会排在最前面，也通过命名约定告诉所有人（包括 AI）"这是系统文件，不是普通笔记"。Dashboard 文件由 Dataview 查询语句驱动，内容自动生成，不需要手动维护。

为什么 .agent/ 目录用点号开头？

这是 Unix 系统中"隐藏目录"的命名惯例。Agent 配置文件不需要出现在你的日常浏览视图中，它是系统的基础设施，不是内容。使用点号开头让它在文件管理器中默认隐藏，减少视觉干扰。

为什么 1-Projects 而不是 Projects？

数字前缀强制 Obsidian 文件列表按 PARA 的可操作性梯度排序：Projects 排最前，Archives 排最后。这不是纯粹的美观考虑——当你打开 Vault 时，最先映入眼帘的是 Inbox 和 Projects，这是今天最需要关注的内容。目录的排列顺序是注意力引导的工具。

六、命名规范与 Frontmatter 标准

架构设计中还有两个容易被忽视但至关重要的细节。

命名规范

Wiki 的命名规范需要单独强调：不用空格，用连字符。原因是 Obsidian 的 wikilink 处理空格的方式在不同系统和不同版本之间有细微差异，可能导致链接失效。连字符是最安全的分隔符。

Frontmatter 标准

Frontmatter 是 AI 读取系统状态的接口。一致的 Frontmatter 让 AI 在任意笔记上都能快速获取关键元数据，而不需要解析整个文档内容。

Project 笔记的 Frontmatter：

YAML

---
type: project
status: active          # active / waiting / someday / archived
area: 职业发展          # 关联的 Area
created: 2026-05-10
target_date: 2026-07-01
success_criteria: "三篇文章全部发布，每篇阅读量超过1000"
wiki_topics:            # 关联的 Wiki 概念页
  - "[[LLM-Wiki]]"
  - "[[PARA方法]]"
---

Wiki 概念页的 Frontmatter：

YAML

---
type: wiki-topic
aliases: [注意力机制, Attention]    # 别名，用于 wikilink 的模糊匹配
domain: 深度学习                    # 所属领域（用于 _index.md 分组）
created: 2026-05-10
last_updated: 2026-05-10
source_files:                       # 编译来源
  - "[[raw/papers/Attention-Is-All-You-Need]]"
related_projects: []                # 关联的 Projects（由 AI 维护）
---

Frontmatter 的设计原则是：只放 AI 需要程序化读取的字段，不要把所有元数据都塞进 Frontmatter。内容性的信息放在正文，结构性的状态信息放在 Frontmatter。

七、这个架构的局限性

任何架构都有适用边界。不诚实地讨论局限性，是对读者不负责任的。

已知局限一：规模上限

当 Wiki/topics/ 的概念页超过数百个时，_index.md 的单文件索引方式会开始失效——文件太长，AI 无法在单次上下文窗口中完整处理。届时需要引入"元索引"机制：按领域创建子索引文件，_index.md 变成指向各领域子索引的目录页。

这不是现在需要担心的问题，但需要预知：当你感觉 Wiki 检索开始变慢或 AI 开始遗漏关联时，这可能就是扩展的信号。

已知局限二：分拣规则的漂移

你对"什么是值得进入 Wiki 的知识"的判断，会随着使用时间不断细化。初期 CLAUDE.md 里写的分拣规则，半年后可能已经不再准确反映你的真实标准。

这不是一次性的配置，而是需要定期回顾和校准的活文档。建议每季度做一次 CLAUDE.md 的"元回顾"：检查过去三个月的分拣结果，看哪些类型的错误在重复出现，针对性地修改规则。

已知局限三：AI 编译质量的不确定性

不同的 LLM、不同的上下文窗口大小、不同质量的原始素材，会产生质量参差不齐的 Wiki 页面。有些概念页可能措辞不准确，有些可能遗漏了重要关联，有些可能把你的主观表述误编入了客观知识区。

这意味着 Wiki 不能完全放任 AI 自动运转而不做人工检查。建议建立一个轻量的质检流程：每次 /wiki-ingest 后，快速扫一遍新增/更新的页面，标记明显的质量问题，在下次编译时让 AI 修正。

开放问题：移动端体验

这套架构在桌面端（配合 Claude Code 或 Cursor）体验流畅，但移动端的 Inbox 快速捕获体验仍然是整个系统的短板。

现有的可行方案：iOS 的快捷指令 + Obsidian URI Scheme，可以实现一键投入 Inbox。但这需要额外配置，不是开箱即用的。移动端的完整 Agent 命令执行目前没有优雅的方案，这是等待生态发展的领域。

写在最后

这篇文章展示了一套架构从设计原则到目录树的完整推演。每个决策——为什么逻辑分层而非物理分离，为什么 Wiki/topics/ 是扁平结构，为什么 Wiki 是 Resources 的内核而非顶层目录，为什么周期笔记独立于 PARA 四层——都有明确的理由。

但目前为止，这个架构还是静态的。它是一张精心设计的图纸，但它还没有动起来。

一套优雅的目录结构，没有持续的维护，两周之内就会退化。Inbox 会积压，Wiki 会停止更新，Projects 会忘记推进，两层之间的接口会逐渐干涸。

让这个架构真正活起来，需要一个 AI Agent 作为系统管理员——持续执行分拣、编译、回顾，让信息在系统中流动起来，让两层之间的接口持续畅通。

Agent 不是这个系统的附件，Agent 是这个系统的引擎。

设计这个引擎，是第三篇文章的主题：《AI 作为系统管理员：用 Agent Schema 激活你的 Obsidian 生活操作系统》。

「AI 生活操作系统」系列文章：

第一篇：当 LLM-Wiki 遇见真实生活——为什么 AI 知识库需要一个"操作系统"

第二篇（本文）：一个 Vault，两套逻辑——PARA × LLM-Wiki 融合架构的设计推演

第三篇：AI 作为系统管理员——用 Agent Schema 激活你的 Obsidian 生活操作系统