使用 Obsidian 管理个人知识库已有一段时间，期间经历过多次目录重构。本文记录我当前的笔记库设计思路，希望对正在搭建或优化 Obsidian 库的朋友有所启发。
设计原则
在设计笔记库结构时，我遵循以下原则：
- 覆盖面广：能够容纳工作、学习、生活等各方面的内容
- 易于扩展：预留足够的扩展空间，新增内容时无需大幅调整现有结构
- 扁平顶层：充分利用顶层目录空间，避免过深的层级嵌套
- 冷热分离：高频访问的内容放在醒目位置，低频内容放在次要位置
- 按量拆分：当某个子类内容量增长到一定规模时，可独立为单独分类
- 例如：人工智能相关内容较多，从计算机知识库中独立出来；LeetCode 题解数量庞大，单独成库
- 这是一个动态演进的过程，因此设计之初就要为未来扩展预留空间
- 层次分明：目录、标签、文档属性各司其职，通过模板确保规范统一
- 稳定优先：目录结构一旦确定，尽量保持稳定，减少频繁变动带来的维护成本
- 流程与分类并重：既要支持信息处理流程（收集 → 处理 → 整理 → 存储 → 回顾），也要做好内容的分类存储
目录命名规范
采用 数字 + 字母 的命名方式来控制目录排序，而非依赖插件。这样做的好处是：在任何环境下（Obsidian、VS Code、文件管理器）都能保持一致的显示顺序。
命名规则：
- 数字表示大类（0-9）
- 字母表示子类（A-Z）
为什么不用纯数字？因为数字只有 0-9 共 10 个，而字母 A 在 ASCII 排序中位于数字之后（0 < 1 < ... < 9 < A < B），混用会导致排序混乱。统一使用字母作为子类标识更清晰。
字母分段策略：
以知识库（1x）为例：
1A~1G：核心高频子类，预留1H~1N供未来扩展1O~1S：次要子类，可向后扩展1Y~1Z：特殊用途，从后向前分配（如1Y LeetCode、1Z 术语库）
顶层目录结构
├── _obscripts/ # 脚本目录（Dataview、Templater 脚本）
│
├── 0A 收集/ # 临时收集，待处理内容
├── 0B 灵感/ # 灵感记录、想法
├── 0C 项目/ # 进行中的项目
├── 0D 时记/ # 日记、周记等时间记录
├── 0E 会议/ # 会议记录
├── 0F 任务/ # 任务清单
│
├── 1A 工具资源库/ # 工具、软件、资源
├── 1B 解决方案库/ # 问题解决方案、经验总结
├── 1C 计算机知识库/ # 计算机基础知识
├── 1D 人工智能知识库/ # AI、机器学习相关
├── 1E 专业知识库/ # 专业领域知识
├── 1F 数据结构与算法/ # 数据结构与算法
├── 1G 游戏开发/ # 游戏开发相关
├── 1O 趋势与行业洞察/ # 行业动态、趋势分析
├── 1P 软技能与方法论/ # 软技能、学习方法
├── 1Q 语言学习库/ # 外语学习
├── 1R 人文社科库/ # 人文、社科、历史等
├── 1S 艺术设计库/ # 艺术、设计相关
├── 1Y LeetCode/ # LeetCode 题解（量大，独立分类）
├── 1Z 术语库/ # 术语、词汇表
│
├── 2A 生活管理/ # 日常生活事务
├── 2B 职业发展/ # 职业规划、工作相关
├── 2C 健康管理/ # 健康、运动、饮食
├── 2D 个人财务/ # 财务管理、投资
├── 2E 法律事务/ # 法律相关
├── 2F 人脉网络/ # 人际关系、联系人
├── 2G 游戏娱乐/ # 游戏、娱乐
├── 2H 书籍阅读/ # 读书笔记
├── 2I 影剧音乐/ # 影视、音乐
├── 2J 兴趣爱好/ # 其他兴趣爱好
│
├── 9A 归档区/ # 归档内容
└── 9Z 系统区/ # 模板、示例文件
分区说明：
| 分区 | 编号范围 | 定位 | 特点 |
|---|---|---|---|
| 临时区 | 0A ~ 0F | 信息处理流程 | 高频访问，流动性强 |
| 知识库 | 1A ~ 1Z | 知识沉淀与积累 | 长期积累，相对稳定 |
| 个人区 | 2A ~ 2J | 个人生活管理 | 私人事务，按需访问 |
| 系统区 | 9A ~ 9Z | 系统支撑功能 | 低频访问，支撑运作 |
链接策略
Obsidian 的核心优势在于双向链接，合理的链接策略能让笔记之间形成有机的知识网络。
- MOC（Map of Content）：为每个大类建立索引页，作为该领域的入口和导航中心
- 双向链接原则：
- 概念首次出现时创建链接
- 相关笔记之间建立关联
- 避免过度链接——不是每个词都需要变成链接
- 别名规范：在 frontmatter 中设置
aliases，统一中英文名称、缩写等，方便搜索和链接引用
标签体系
标签与目录承担不同的组织职责：
- 目录：管理笔记的物理位置，回答”在哪”的问题
- 标签：描述笔记的属性和特征，回答”是什么”的问题
标签设计建议：
- 使用嵌套标签表示层级关系，如
#tech/python、#status/draft - 常用标签分类：
- 状态标签：
#status/draft、#status/active、#status/archived - 类型标签：
#type/note、#type/project、#type/resource - 主题标签：根据内容领域自定义
- 状态标签：
tags 与 topics 的区别：
有些笔记系统会同时使用 tags 和 topics 两个字段，它们的定位有所不同：
| 维度 | tags | topics |
|---|---|---|
| 粒度 | 细粒度，可以很具体 | 粗粒度，通常是大的主题领域 |
| 数量 | 一篇笔记可以有很多 | 通常只有 1-3 个 |
| 层级 | 可嵌套（如 tech/python） | 一般扁平 |
| 用途 | 多维度标记属性、状态、特征 | 标识内容所属的核心领域 |
| 稳定性 | 相对灵活，可随时添加 | 相对稳定，代表笔记的归属 |
举个例子，一篇”Python 异步爬虫实战”的笔记：
topics: [编程, 爬虫] # 它属于什么领域
tags: [tech/python, tech/async, type/tutorial] # 它有哪些属性简单来说：topics 回答”这篇笔记讲什么大方向”，tags 回答”这篇笔记有哪些特征”。
对于大多数个人笔记库，只用 tags 配合嵌套结构就足够了。如果你的博客需要按主题分类展示文章，再考虑引入 topics 字段。
文件命名规范
- 文件名：使用有意义的标题，避免无意义的编号或日期前缀
- 中英文混排：中英文之间可加空格，提高可读性
- 特殊字符：避免使用
\ / : * ? " < > |等文件系统保留字符 - 日期格式：统一使用
YYYY-MM-DD格式 - 附件管理：图片等附件存放在统一目录，或使用同级
assets子目录
元数据规范
通过 frontmatter 为笔记添加结构化元数据，便于检索和自动化处理。
常用字段：
created: YYYY-MM-DD HH:mm # 创建时间
updated: YYYY-MM-DD HH:mm # 更新时间
publish: true/false # 是否发布
tags: [] # 标签
aliases: [] # 别名
status: draft/active/archived # 笔记状态最佳实践：
- 通过模板自动填充
created、updated等字段 - 为不同目录绑定对应模板，确保元数据格式统一
归档策略
并非所有内容都需要常驻主目录。对于以下情况，建议移至归档区：
- 项目已完成或终止
- 内容已过时，但仍有参考价值
- 长期未更新且不再活跃
归档原则：
- 统一归档至
9A 归档区 - 保留原有标签和链接，确保归档后仍可通过搜索找到
定期维护
笔记库需要定期维护，避免逐渐变成”数字垃圾场”。
- 孤立笔记清理：定期检查无链接的笔记，决定是补充链接还是归档删除
- 内容回顾周期：
- 每周：回顾本周新建笔记，补充遗漏的链接
- 每月：回顾重点领域，整理和完善内容
- 每季度：审视目录结构，评估是否需要调整
同步与备份
数据安全是知识管理的底线。
- 同步方案：选择可靠的同步工具，如 Git、Syncthing、iCloud 等
- 冲突处理：多设备使用时及时处理同步冲突，避免内容丢失
- 备份策略：定期备份整个库；若使用 Git，可定期清理历史以控制仓库体积
以上就是我的 Obsidian 笔记库设计方案。这套结构经过多次迭代，目前运行良好。当然，每个人的需求不同，最好的设计是适合自己的设计。希望本文能为你提供一些参考和启发。