如何组织一个机器可读的知识库：Obsidian + Markdown 的实践

个人知识库很容易长成”剪藏垃圾场”：看到好文章就收藏，几个月后想找某个经验，翻半天找不到。

我踩过这个坑之后，把知识库重构成一套机器可读的规范——不只是给人看的，也是喂得动 AI 的。

这库是干什么的：先划边界#

要	不要
项目决策、Bug 根因、可复用经验	无筛选的剪藏垃圾场
人机都能检索的结构化 Markdown	只给插件看的英文双轨分类
入口清晰：首页 → 目录 → 页面	只靠侧边栏滚目录

底层方法：借 ACE 意图（知识 / 行动 / 时间）+ MOC 导航 + 受控页面类型。不采用全库硬切 PARA、无约束卡片狂拆。

新建一页前，先走决策树#

最防止”垃圾场”的是新建门槛。每次要记东西，先过一遍决策树：

这是不是一次可复用的经验？是 → 经验
是不是故障闭环？是 → bug
挂在现有项目页的变更日志够不够？够 → 不新建
外部文章 → 只建来源索引，概念能不拆就不拆

第 3 条最关键：能挂在现有页面就绝不新建。页面数量爆炸是知识库烂掉的开始。

写正文的规范#

1. frontmatter 填全：type / title / created / updated，业务页补状态和所属领域。

2. 链接只用裸链接：[[页面名]] 而不是 [[目录/页面]]。裸链接按名字解析，文件移动不断链。

3. 结论先看：高价值的经验页，开头先给一句话结论，别让人翻到底才知道这页讲什么。

4. 用醒目块区分关键信息：症状 / 根因 / 修复 / 教训 / 风险，用不同的强调块区分，一眼扫到重点。

MOC：只做索引，不写长文#

MOC（Map of Content）是知识库的导航层，只放链接，不写正文。

1
MOC-Agent与Harness
2
MOC-部署与网关
3
MOC-前端设计
4
...
5

6
新增一页 → 在对应 MOC 下加一行
7
  - [[页面名]] — 一句话

首页 → MOC → 页面，三级入口。新知识库成员（人或 AI）进来，5 秒知道有什么、在哪。

为什么”机器可读”很重要#

这套规范最大的受益者其实是 AI 助手。给 AI 配一个知识库 MCP 接口后：

它按 type 字段知道一页是经验还是 bug
它按裸链接能顺着 [[关联]] 跳转相关页
它按 MOC 能找到”这个领域有哪些内容”
它读经验页时先看到结论，不用全文读完

规范即接口。你给知识库定的结构，就是 AI 检索它的接口定义。

两条禁忌#

不为单篇剪藏自动生成十几个概念页——那是垃圾场膨胀的自动版
不写路径链接（[[dir/page]]）——文件一移动全断

看到”不自动生成概念页”，你可能会问：那什么时候才该建概念页？

这里的关键不是”建不建”，而是”门槛设在哪”。LLM Wiki 和 Obsidian 自动生成概念页的逻辑，本质是把门槛降到了”出现一次就建”——每个专有名词一页，为的是给关系图谱提供节点。这在”领域百科”型知识库（系统收集一个领域的术语）里是对的，术语就是知识骨架；但你的库如果是”项目记忆库”（记经验、记决策、记 bug），概念就是配角，无脑拆页只会让图谱被空壳节点淹没。

图谱的节点不一定是概念页——项目页、经验页、bug 页互相 [[关联]]，本身就是图谱。MOC 是手动策展的导航层，图谱是自动的关联层，两者互补。你要的是”节点和边够多”，不是”每个名词都有一页”。

那什么时候把一个名词”升格”成独立概念页？三条门槛，满足其一才建：

判断维度	问自己	门槛
复用度	这个概念会被几个页面引用？	≥2 个才建；只在单篇剪藏出现 → 留在原文
权威性	这个词的语义需要统一定义吗？	多处说法会不一致才建页”定锚”
丢失风险	不建这页，它会丢吗？	散落各处检索不到才建；不会 → 不建

三条都答”否” → 不建，让它留在记录页里。

自动生成和克制升格，差的只是这道门槛设在哪。门可以低，不能为零。

结论#

知识库组织规范的本质是三件事：

建前有门槛（决策树），写时有模板（受控类型），检索有入口（MOC）。

个人知识库不需要复杂工具，一套克制的规范 + Markdown + Git 版本控制就够了。克制，是知识库最稀缺的品质。

音乐

音乐