系列上一篇讲了知识库批量操作怎么不翻车。今天聊一个更根本的问题——笔记拆解。
知识库里的文章越攒越多。明明保存了很多好文章，用的时候还是一大坨。找也找不到，引用也没法引用。
问题出在笔记的粒度上。
保存一篇 5000 字的深度文章，是一个大块头。但想用的可能只是里面提到的某个方法论、一个数据、一个案例。整篇文章扔进知识库，等于把一整头牛塞进冰箱。想吃牛排的时候，得先把整头牛拖出来化冻。
更好的做法是：把牛拆成牛排、牛腩、牛腱子，各归各位，用的时候直接拿。
这篇就说怎么拆。
一篇文章拆成几个原子笔记
拆解的原则很简单：一个原子笔记只讲一件事。
听起来不难。实际操作中，很多人拆着拆着就偏了——要么拆得太碎，一段话拆一条；要么拆得太粗，还是整篇文章的逻辑。参考标准：一篇 3000 字的文章，拆成 3 到 5 条笔记比较合理。
拆什么？三个维度：
事实类——文章里的硬数据、统计数据、引用原文。比如「2025 年中国企业 AI 采用率 65%」，这就是一条事实笔记。标注来源，以后写文章可以直接引用。
概念类——文章提出的观点、方法论、分析框架。比如「飞轮效应」的机制描述，或者某个产品增长的归因分析。
案例类——文章里提到的具体例子、故事、实验。比如「某 SaaS 公司通过调整定价策略实现月活翻倍」，这就是一个案例笔记。
一篇文章，从这三个维度扫一遍，基本能拆干净。
拆的时候遵循源头可追溯
每条拆出来的笔记，必须回答一个问题：这条信息从哪里来的？
做法是在每条拆出来的笔记底部固定一行：
来源：[[2025-07-15_公众号名_原标题]]
用 Obsidian 的 wikilink 直接链接到原文。以后写东西引用这条笔记，点一下链接就能回到原文看上下文。不这么干的话，拆个半年，笔记池里全是孤岛，根本记不得哪句是哪来的。
拆完不要删原文
这一点很多人反着做——拆完觉得原文占地方，删了，只留拆出来的小卡片。
千万别。
原文是完整逻辑链，拆出来的卡片是碎片。想理解一个观点的全貌，需要回到原文看上下文。而且拆的过程难免漏东西——半年后翻到原文，可能会发现当时没注意但后来很有价值的段落。
做法是原文完整保留，在原文的 frontmatter 或开头加一行：
拆解日期：2026-07-15 拆出笔记：[[笔记A]]、[[笔记B]]、[[笔记C]]
这样原文和拆出来的笔记之间是双向连接的，哪边都能找到另一边。
拆出来的笔记怎么放
每个原子笔记放一个文件，文件数会爆炸。这是对的，但不用怕。
做法分两层：
一层是主题文件夹，按大主题建目录，比如「营销」「产品」「技术」。
另一层是MOC（Map of Content），每个文件夹下放一个索引笔记，把相关原子笔记的链接汇总在一起。
原子笔记本身是独立的 .md 文件，通过 MOC 把它们串起来，同类的内容随时能扫到全貌。
拆解频率——不要每天拆
最容易踩的坑：每读完一篇文章就拆。拆完发现时间没了，拆出来的笔记也没人看。
节奏是每周集中拆一次，每次 30 到 40 分钟。平时读到好文章，先打标签「待拆解」，周末统一处理。
30 分钟能拆大概 3 到 5 篇。拆出来的笔记当天就整理到对应的文件夹和 MOC 里。不需要追求一次拆完所有库存，那是给自己找不痛快。
拆解的终局
拆到一定程度，写文章的时候不用再从头查资料了。
比如想写一篇「如何搭建知识库」的文章，在 Obsidian 里搜「知识库」「笔记管理」「信息整理」这几个标签，所有拆出来的相关笔记全弹出来。只需要把已有的笔记片段串联起来，加上自己的观点，一篇文章就出来了。
拆解的终极目的不是把笔记拆碎，而是让笔记变成乐高积木。需要什么形状，就拿什么形状拼。
系列前几篇讲了知识库的架构、采集、标签、维护。今天这篇讲的是知识使用前的一步：把信息拆成可复用的知识单元。下次遇到一篇好文章，试试先拆再存。一个月后再来看就知道值不值了。