Obsidian知识库的目录与维护方式
早期使用Markdown加同步盘管理个人文档，最看重的是纯文本、可以随时更换编辑器，也不会被某个云笔记服务锁住。后来编辑器换成Obsidian，同步方式和目录也调整了几轮，但这个出发点一直没变。
现在这套知识库仍然只是一组本地Markdown文件。Obsidian负责编辑、搜索、双链和Base视图，同步工具负责多设备传输，Git负责留下可回退的版本。三者各做一件事，比把所有希望都压在某个插件上稳定得多。
目录按内容处境划分
目前根目录保持为七个入口：
1 | 00.Inbox/ 临时收集和待整理内容 |
编号只是为了让顺序稳定，真正有用的是每个目录回答的问题不同。
项目中的会议记录、环境差异和处理过程会留在20.Projects，因为离开项目上下文后很容易被误解。经过复盘、能够跨项目复用的内容，才整理到10.Notes。已经结束的资料移入50.Archive，但默认不大规模重写，保留当时的背景比追求整齐更重要。
00.Inbox也不是永久仓库。临时内容先放进去没有问题，但有价值的部分最终要么进入长期笔记，要么回到项目，要么明确删除。否则它只会变成另一个名字更好听的下载目录。
索引页比无限细分目录更好用
技术笔记按大主题保留一层目录，每个主题增加一个很短的索引页。例如一个索引通常只有这些内容：
1 | --- |
索引页承担人工导航，能写清楚一组笔记为什么放在一起；Obsidian的Base则负责按属性动态筛选。两者不是替代关系：Base适合看“所有进行中的项目”，索引更适合进入某个主题时看到经过选择的入口。
这也避免了一个老问题：为了表达所有关系，不断增加目录层级。一篇笔记可能同时与网络、容器和安全有关，文件只能放在一个位置，但索引和双链可以从多个主题指向它。
front-matter只保留会用到的字段
Obsidian的Properties最终仍然存成文件顶部的YAML。当前常用字段是：
1 |
|
不同目录只增加确实需要的字段：项目资料使用project，领域资料使用area，长期笔记和资源使用topic。status也只保留少量固定值，例如draft、active、stable、reference和archived。
历史文件没有一次性补满属性。属性只有在搜索、Base过滤或维护规则中真正使用时才有价值；为了“看起来结构化”增加十几个长期为空的字段，只会让写笔记变慢。
链接先解决导航，不追求一张完美的图
重要主题会建立索引，相关笔记之间再补少量带说明的链接。相比在每篇文章末尾堆一串标题，直接说明关系更有用：
1 | ## 相关笔记 |
反向链接和关系图可以帮助发现遗漏，但不会自动产生知识结构。两个文件互相链接，只说明它们有关；链接旁边为什么相关，才是以后重新找到它时最有用的信息。
移动或重命名文件时，由Obsidian自动更新内部链接。批量调整目录仍然会单独提交一次Git，这样外部Markdown链接、脚本引用或同步冲突出问题时还能看清改了什么。
附件没有只用一种规则
通用建议通常是把所有附件集中到一个目录，但实际使用后发现这不适合所有情况。现在图片优先放在笔记同目录的assets/子目录，移动整组笔记时正文和截图可以一起带走：
1 | 某篇笔记.md |
PDF放进99.Assets/pdfs/，其他跨主题使用的文件放进99.Assets/files/。旧笔记中的历史附件不批量迁移，因为一次移动几百个文件带来的断链风险，通常大于目录变整齐的收益。
Obsidian支持把新附件放到当前文件旁的子目录，可以在“设置→文件与链接→新附件的默认位置”中配置。无论采用哪种规则，最好在大量粘贴截图之前确定下来。
同步不是版本历史
这套知识库日常通过同步工具在设备之间传输，Git只做版本保险。同步可以让几台设备看到同一份最新文件，也会很快传播误删和错误覆盖；Git则用来查看差异、恢复文件和确认一次整理到底改了哪些内容。
日常顺序是先等同步完成，再开始编辑；一组相关整理完成后提交一次Git。多台设备同时修改同一文件时，先处理同步冲突，不在冲突未解决时继续批量提交。
.obsidian也不需要全收或全丢。插件列表、主题、快捷键等可复现配置可以纳入版本管理，workspace.json和移动端工作区这类界面状态则忽略。大附件是否进入Git要单独考虑，不能因为Markdown文件很小，就假设整个知识库永远适合普通Git仓库。
给自动化工具留一份维护约定
知识库开始由脚本或AI辅助整理以后，根目录增加了AGENTS.md。它不负责介绍知识内容，只约束维护动作：
- 不随意删除、移动或合并原始笔记。
- 大规模调整前先说明范围，小步修改并保留Git差异。
- 敏感笔记只整理结构，不主动摘要到更公开的位置。
- 重复内容先建立索引和关联，再决定是否合并。
- 不强行为所有文件补标签和front-matter。
这份约定比一段临时提示词更可靠。工具换了以后，新工具仍然可以先读同一个文件，了解哪些内容允许修改、哪些操作必须停下来确认。
没有采用的做法
Daily Note没有作为所有内容的最终归宿，也没有安装大量插件来替代目录和文件名。当前真正离不开的仍然是文件浏览、全局搜索、快速切换、Properties、反向链接和Bases等基础能力。
模板也保持很少。新文件只带日期、类型和状态，正文结构按内容决定。部署记录、故障排查、项目过程和资料摘录本来就不应该长成同一个样子。
知识库规模变大以后，稳定来自几个很普通的习惯：文件仍然可以脱离Obsidian阅读，目录变化可回退，索引有人维护，敏感内容不会因为自动整理跑到错误的位置。其他功能都可以等确实遇到问题时再增加。