很多人用 Obsidian，都有一个阶段：
刚开始很兴奋，疯狂记笔记； 过了一段时间，开始迷茫——
笔记是有了，但找不到、用不上、也不想再看。
我之前的 Obsidian Vault，就是典型的这种状态：
- 有内容，但没有系统
- 有分类，但没有路径
- 有积累，但没有复习机制
表面看起来很“整齐”，实际上完全不可用。
后来我做了一件事： 👉 把整个知识库交给 Codex，重新设计了一遍结构
这次重构，我不是在整理文件夹，而是在解决一个更核心的问题：
知识如何被放进去、如何被找到、如何被复习、如何长期维护？
这篇文章，我把整个过程完整拆给你。
一、我先解决的不是“美观”，而是信息结构
我一开始最容易犯的错，就是把 Obsidian 当成“高级文件夹”来用。
也就是说，我会先想：
- 这篇文章该放哪个目录？
- 这个主题是不是要单独建一个文件夹？
- 这个文件名要不要加编号？
但真正需要先想的问题其实是：
- 我以后会从哪里进入这批内容？
- 这些内容是按主题查，还是按顺序学？
- 哪些东西是长期领域，哪些只是一次性的专题？
- 新文章进来时，是否有稳定的归档规则？
当这几个问题没有先想清楚时，目录再工整，知识库也还是会越用越乱。
所以我后来给自己定了一个原则：
目录不是为了“看起来整齐”，而是为了降低我未来复习、归类和继续扩展的成本。
二、我最后采用的 Vault 结构
我最后没有用很重的 PARA，也没有做特别复杂的双链体系，而是用了一个更适合长期写文章、持续沉淀的方法。
我的顶层固定为：
00-总览
10-收件箱
20-领域
30-资源库
90-归档
99-模板
这 6 层的职责我定义得很明确。
1. 00-总览
这里是我整个 Vault 的控制台，不放正式内容，只放入口。
我把以下页面放在这里：
知识地图复习面板最近更新文章录入流程
它们分别解决 4 个问题：
- 我从哪里进入整个知识库
- 我现在应该复习什么
- 最近刚整理过什么
- 新文章以后怎么稳定录入
也就是说，00-总览 解决的是“如何使用知识库”，不是“知识本身是什么”。
2. 10-收件箱
这里专门放还没整理完成的内容。
我后来明确规定：
- Daily Notes 只负责捕捉
- 真正准备沉淀的内容，统一进
10-收件箱 - 只要进入正式知识库，就必须补完整元数据
这样我就不会再把半成品、正式文章、临时想法混在一起。
3. 20-领域
这里放的是“长期关注主题”的入口页，不直接放正文。
比如我现在的领域页包括：
AI进化论基础设施与运维企业信息化知识管理与工作流
后来我还专门调整过一个关键策略：
领域必须是长期主题，不是工具名，不是单一项目名。
所以像 NetBox 这种内容，我最后没有让它继续当顶层领域，而是归并到了 基础设施与运维 下，作为一个系列来管理。
这个动作对我帮助很大，因为它让我不再用“软件名”当知识库顶层分类，而是用“长期认知主题”来做分类。
4. 30-资源库
这是正式沉淀的主体。
我最终规定：
- 独立文章进
10-专题 - 需要顺序学习的内容进
20-系列 - 每个领域都配一个
00-MOC
也就是说，一个领域至少有这三层：
30-资源库/<领域>/
00-MOC/
10-专题/
20-系列/
如果内容量更大，我再在领域里继续加模块层。比如我现在在 基础设施与运维 下面又拆成了：
10-基础设施
20-网络
30-运维
40-云计算
这一步很关键。因为真正让知识库变得可扩展的，不是顶层分类多，而是“进入某个领域后还能继续分层”。
5. 90-归档
所有过时、被替代、暂时不用的内容都进这里。
我不再用“删掉文件”的方式保持整洁，而是用：
status: archived- 移动到
90-归档
这样历史还在，但默认不会出现在知识地图和复习面板里。
6. 99-模板
我最后只保留了 4 个模板：
- 文章模板
- 系列文章模板
- 知识地图模板
- 收件箱整理模板
模板的作用不是为了“写得更快”，而是为了确保新内容一进库就符合规则。
三、我怎么设计“领域、专题、系列”这三层关系
这是我这次重构里最重要的设计之一。
我后来把它理解成 3 种不同的问题：
1. 领域
领域回答的是：
这批内容长期属于哪条认知主线？
例如：
- AI 工具和 agent 实践，属于
AI进化论 - NetBox、LibreNMS、Nginx 部署，属于
基础设施与运维 - Obsidian、知识管理、工作流设计，属于
知识管理与工作流
2. 专题
专题回答的是：
这是不是一篇独立可读的文章？
如果答案是“是”，我就放到 10-专题。
3. 系列
系列回答的是：
这批内容是不是按顺序学习更有价值？
如果答案也是“是”，我就把它放进 20-系列，并给每一篇加顺序号。
后来我给自己定了一个特别实用的判断标准：
- 能单篇读懂的，进专题
- 必须按顺序看才更有价值的，进系列
这条规则让“要不要编号”这件事变得特别简单。
四、我最后确定的命名规则
如果标题和文件名不统一，知识库很快就会出现第二层混乱。
所以我后来只保留了两套命名规则。
1. 独立文章
文件名保持自然标题，不强制编号。
例如：
我用 Obsidian + Codex 重构知识库：从杂乱笔记到可复习、可扩展的知识系统.md
2. 系列文章
文件名必须带顺序号：
01-标题.md
02-标题.md
03-标题.md
这样做好处很直接：
- 文件浏览器中天然有顺序
- Dataview 按
order排序时也一致 - 我后面补文章时，不会出现“系列页顺序”和文件夹顺序不一致
比如我现在的 NetBox实战，就是按这条规则整理的。
五、我怎么设计链接体系
我没有追求复杂的双链密度，而是先做“最低必要链接网络”。
我最后固定了 3 条规则：
1. 每篇文章至少回链到知识地图
我给每篇正式文章都加这一行：
> 所属知识地图：[[某领域-知识地图]]
这样无论我从搜索、最近更新，还是文件列表点进文章，都能一键回到上层索引页。
2. 系列文章必须回链到系列页
系列文章我统一再加一行：
> 系列导航：[[某系列名]]
这样我读系列里的任意一篇时，都不会丢失上下文。
3. 领域页负责“长期入口”，MOC 负责“资源索引”
我给每个主题都保留两个入口：
20-领域/<主题>.md30-资源库/<主题>/00-MOC/<主题>-知识地图.md
两者职责不同：
- 领域页是长期入口
- MOC 是资源索引页
这一步让我不再把“导航页”和“内容索引页”混成一张。
六、我怎么设计标签，避免标签系统失控
我以前用标签最容易踩的坑，就是想到什么打什么。
最后的结果就是：
- 标签越来越多
- 同义标签并存
- 搜索时想不起来自己当初用过什么词
后来我把标签压缩成 4 个前缀系统：
tags:
- 领域/知识管理与工作流
- 模块/基础设施
- 主题/Obsidian
- 系统/知识地图
我现在基本只用这 4 类：
领域/模块/主题/系统/
我不再用标签去替代目录，而是让标签只承担“补充检索维度”的作用。
比如：
- 领域靠目录确定
- 模块靠目录或 frontmatter 辅助
- 主题靠标签增强搜索
- 系统页用
系统/区分
这样标签就不会反客为主。
七、我最后只装了一个社区插件：Dataview
这是我这次重构里最克制、但也最有效的一步。
我没有装一堆“看起来很强”的自动化插件，而是只保留：
- 原生 Templates
- 原生 Properties
- 原生 Search
- 原生 Bookmarks
- 原生 Daily Notes
- 1 个社区插件：Dataview
为什么只留 Dataview？
因为我真正需要自动化生成的，其实只有 3 类页面：
- 主题文章清单
- 待复习清单
- 最近更新清单
而 Dataview 足够解决这 3 个问题。
例如我的领域页和知识地图页里，会直接用 Dataview 拉：
- 某个目录下的文章
- 某个系列下的文章
- 某个领域下最近更新的内容
这样我不需要手工维护一堆文章列表，也不会因为文件移动而让索引页失效。
八、我怎么用 frontmatter 让文章自动进入系统
我后来意识到，知识库是否稳定，不取决于目录，而取决于“每篇文章有没有统一元数据”。
我最后固定了这些字段：
title:
domain:
type:
status:
series:
order:
created:
updated:
next_review:
tags:
这套字段解决的是 5 个问题：
- 这篇文章属于哪个领域
- 它是专题、系列还是系统页
- 它现在是活跃内容还是归档内容
- 它需不需要按顺序排
- 它什么时候应该再次复习
也就是说，我后来不是在“管理文件”，而是在“管理带元数据的知识对象”。
九、我现在如何日常使用 Obsidian 管理知识库
当结构搭好以后，我的日常动作就变得很简单。
1. 新内容先进入收件箱
如果只是灵感、草稿、片段，我先放 10-收件箱。
2. 准备沉淀时再决定 3 件事
我只判断这 3 个问题：
- 它属于哪个领域？
- 它是专题还是系列？
- 它需不需要复习节奏？
3. 录入正式文章时补齐元数据
我现在不会再“先写完再整理”，而是先按模板把结构搭好，再往里填内容。
4. 回顾时不靠记忆，只靠入口页
我主要从这几个入口回看：
- [[知识地图]]
- [[复习面板]]
- [[最近更新]]
- 各领域页
- 各系列页
这样我不会再从文件浏览器里盲翻。
十、Codex 在这个过程中到底帮我做了什么
如果只是让我自己一点点重构，我当然也能做，但成本会很高。
Codex 真正帮我解决的，不是“代替我点鼠标”，而是把原本很琐碎、很容易拖延的整理工作，变成了一套可以持续协作的流程。
我主要让 Codex 做了 6 类事：
1. 设计知识库结构
我先把问题说清楚，Codex 帮我把 Vault 重构成一套可扩展结构，而不是只改眼前几个文件夹。
2. 批量迁移文章
我可以直接把本地 Markdown 文件路径发给它，让它判断：
- 放哪个领域
- 是否属于系列
- 是否需要新建模块或新领域
3. 统一标题风格
很多原始文章标题更像临时稿名、公众号标题或者操作手册名。
Codex 会帮我把它们统一成更适合知识库长期保存的标题风格，比如：
- 保留关键检索词
- 去掉过强的口语化噪音
- 让系列标题结构一致
4. 统一 frontmatter
这一步特别值钱，因为手工补 20 篇文章的元数据真的很消耗意志力。
5. 维护知识地图和系列页
Codex 可以顺手补好：
- 知识地图回链
- 系列导航
- MOC 页面
- 领域页
6. 持续优化目录策略
最重要的一点是：
我不是一次性把知识库整理完，而是让 Codex 参与后续的长期维护。
比如我后来就继续让它：
- 把
NetBox从独立领域降级为系列 - 把
基础设施与运维按模块继续拆分 - 把新文章自动并入已有系列
这说明 Codex 不是“整理一次”，而是“持续维护结构”。
十一、如果你也想复现，我建议你按这个顺序来
如果你现在的 Obsidian 也比较乱，我建议直接照这个顺序走。
第一步：先定顶层结构
先把顶层固定成：
00-总览
10-收件箱
20-领域
30-资源库
90-归档
99-模板
第二步：先建领域页和知识地图，不急着搬所有内容
先把入口搭好，再搬内容，不要反过来。
第三步：先决定“专题还是系列”
不要一上来就给所有文章编号。
只有顺序学习有意义的内容，才做成系列。
第四步：统一 frontmatter
哪怕先只补 5 个字段，也比完全没有强。
第五步：只装最必要的插件
如果你现在还没有明确需求，我建议先像我一样，只装 Dataview。
第六步：把“整理新文章”变成固定工作流
这一步最容易被忽略，但它决定了知识库能不能长期稳定。
十二、我现在对“知识库管理”的理解
这次重构之后，我对知识库这件事有一个很明确的判断：
好的知识库不是“存了很多内容”，而是“未来的我能稳定找到、理解、复习和继续扩展这些内容”。
所以真正重要的不是炫技，而是这些基础设计：
- 入口要明确
- 结构要可扩展
- 命名要统一
- 元数据要稳定
- 插件要克制
- 日常维护要有流程
而 Codex/Claude 的价值，则在于把这些原本容易半途而废的整理动作，变成一个可以持续协作、持续优化的过程。
结语
如果你的 Obsidian 现在也已经开始变乱，不要急着折腾一堆插件，也不要先去补几百个双链。
先把“结构、入口、元数据、工作流”这四件事搭起来，知识库才会真正开始变得可用。
如果你对 Obsidian、知识管理、NetBox、AIOps、自动化运维或者 Codex 协同工作流感兴趣，欢迎关注我的公众号 数字卢语。
我会继续把这些从混乱到可复用、从概念到落地的真实实践，持续写下去。
