为什么拆书比读书更重要：book-to-skill 背后的知识哲学

为什么拆书比读书更重要：book-to-skill 背后的知识哲学

by 一只阿木木

这篇文章会冒犯一些人。

因为它要说的核心观点，和我们从小被教导的"好好读书"是矛盾的。

但我相信，读完之后你会理解： 我不是在否定读书，我是在重新定义"读书的终点在哪里"。

一个程序员朋友的灵魂一问

两年前，我和一个做后端的朋友吃饭，聊起各自最近在读什么书。

我说我在读《系统思考》，正在做读书笔记，读了差不多一半了。

他问我："你读完之后，这本书会变成什么？"

我愣了一下。

"变成什么？"我重复了一遍这个问题，"就……读完了，有些收获，做了笔记……"

他说："我是说，这本书里的方法，你以后能用到吗？三年后，你在做某个项目，你会想起来翻这本书吗？你能快速找到你需要的那个框架吗？"

我没有回答。

因为我知道答案是：大概率不能。

不是因为书不好，不是因为我没认真读，而是因为我读书的方式，从来没有认真想过这个问题：

读完一本书之后，它应该以什么形态继续存在？

这个问题，我后来想了很久。

一本书，从你拿起它，到你放下它，经历了什么？

text

你买了它
你读了它
你可能做了笔记
你把它放回书架
然后……

然后什么？

然后它就在那里。书架上。静止的。等你想起来的时候去翻找。

而你想起来的概率，随着时间指数级衰减。

读完第一天：记得 70% 读完一周后：记得 40% 读完一个月后：记得 20% 读完一年后：记得能用到的，大概 5%

这 5%，是你真正拥有的。

剩下的 95%，你付了时间，付了注意力，但什么都没留下。

我们一直搞错了一件事

在继续之前，我想先厘清一个根本性的概念混淆。

我们把两件完全不同的事，一直用同一个词描述：

"学到了"。

当我们说"我从这本书里学到了很多"，这句话可能是两种完全不同的意思：

意思 A： 我读的时候，有一种恍然大悟的感觉。某些概念让我有共鸣，某些观点刷新了我的认知，读完感觉很有收获。

意思 B： 这本书里的某个框架、某种思维方式，已经真实地改变了我处理某类问题的方式，并且我可以在未来持续调用和应用它。

我们通常说的"学到了"，是意思 A。

但我们真正需要的，是意思 B。

意思 A 是一种体验。

你在阅读过程中经历了一次认知刺激，你的神经元被激活了，你感受到了思维扩展的愉悦感。

这是真实的，这有价值，但它本质上是消费性的——就像看了一部很好的电影，你有触动，但触动会随时间消散。

意思 B 是一种能力改变。

书里的方法论已经被你内化，成为你认知工具箱的一部分，成为你在面对特定问题时会自然调用的框架。

这才是读书真正的目的。

问题是：意思 A 很容易实现，意思 B 极其困难。

因为从"读懂了一个概念"到"真正能用这个概念"，中间有一道巨大的鸿沟。

跨越这道鸿沟，需要的不是把书再读一遍，而是改变知识的存在方式。

知识的两种存在方式

让我用一个我作为程序员最熟悉的比喻来解释。

在软件开发里，有一个概念叫库（Library）。

一个函数库，是把某种能力封装起来，让它可以被任何程序按需调用的东西。

你不需要每次使用它的时候，重新实现一遍底层逻辑。你只需要 import，然后调用。

现在我问你一个问题：

你读过的书，是以哪种方式存在的？

是以文档的方式存在——静止地躺在书架上，等你主动去翻找，翻找之前需要先记得它的存在？

还是以函数库的方式存在——被封装成一个随时可调用的能力模块，在你需要它的时候，它自动出现？

绝大多数人读书，知识以文档的方式存在。

读完，记了些笔记，放回书架。知识被归档了，但没有被激活。

text

知识的文档形态：
书 → 读 → 笔记 → 归档 → 偶尔翻找 → 大部分永久沉睡

book-to-skill 要做的，是让知识以函数库的方式存在。

读完，拆解，封装成 Skill，写入系统。知识不只是被记录，而是被集成进了你的工作流。

text

知识的函数库形态：
书 → 拆解 → Skill → 集成进系统 → 按需自动调用 → 持续产生价值

这两种存在方式，不是同一件事的两个版本，而是两种完全不同的知识哲学。

为什么我们一直停留在"文档形态"

如果函数库形态明显更好，为什么大多数人还是在用文档形态处理知识？

我认为有三个原因：

原因一：我们把"做笔记"误解成了"入库"

从小到大，我们被教导"读书要做笔记"。

于是大多数人读书的时候：画波浪线，折页角，在空白处写批注，或者在笔记本上摘抄重要段落。

这些动作让我们感觉在"处理知识"，感觉在"入库"。

但事实上，做笔记只是在创造另一种形态的文档。

你把书里的文字，移动到了你的笔记本里，或者 Obsidian 里。知识的位置变了，但它的存在形态没有变——它依然是静止的，依然需要你主动去找它，依然不能被调用。

我在某种程度上，花了好几年时间，非常勤奋地做着一件本质上没有价值的事：把知识从一个地方搬到另一个地方，然后称之为"学习"。

原因二：没有工具能让"入库"这件事变得可行

在 AI 出现之前，把知识真正"封装成可调用模块"，是一件极其昂贵的事。

你需要：深度理解一本书的全部内容，把它的框架结构化，写成清晰的"操作手册"，再反复训练自己使用这个框架……

这个过程，对一本普通的书，可能需要几十个小时。

对于绝大多数人，成本太高，所以这件事从来没有大规模发生。

我们退而求其次，用"做笔记"代替"真正入库"，然后安慰自己说：至少我留下了什么。

book-to-skill 第一次让"知识真正入库"变得有可行性。

不是因为它代替了你的思考，而是因为它把这件事的成本，从几十小时压缩到了几分钟。

原因三：我们没有意识到"不可调用"的代价有多大

我们很少计算这件事的真实代价。

你读了一本书，花了 10 个小时。

然后你记住了 20%，用到了 5%。

这意味着，你为了这 5% 的有效知识，支付了 10 小时的时间成本。

按这个利用率，你读 100 本书，真正沉淀下来的，可能相当于认认真真内化了 5 本书的内容。

另外那 95 本书的时间，哪里去了？

被遗忘消耗了。

而你对这件事的感知是：我读了 100 本书，我是一个爱读书的人。

但你对知识系统的真实贡献，是 5 本书。

我不是在说读书没有价值。我是在说，我们一直在用一种极其低效的方式对待知识，并且因为大家都这样，所以我们从来没有质疑过它。

拆书，到底在做什么

理解了上面的问题，再来看 book-to-skill 的本质，就很清晰了。

拆书，不是"做一份更好的读书笔记"。

拆书，是在做一次知识的编译。

在编程世界里，你写的代码，在真正能被机器执行之前，需要经过一道工序：编译。

编译，是把人类可读的源代码，转化为机器可直接执行的形式。

未编译的代码，你能读懂，但机器不能直接用。编译之后，机器才能调用它。

一本书，是人类可读的知识。

你读它，能理解它，能在读的时候受到启发。但你的 AI 系统，无法直接"调用"这本书的框架来帮你工作。

book-to-skill 做的事，就是把书编译成 AI 可以执行的形式。

text

书（人类可读）
  ↓ 编译（book-to-skill）
Skill 文件（机器可执行）
  ↓ 加载
AI 系统（可按需调用这本书的框架）

编译之后，这本书不再只是你的阅读材料，它成了你系统的一个能力模块。

你的 AI 助手，可以随时调用这个模块，用这本书的框架来分析问题、生成建议、评估方案——就像调用一个函数一样。

这就是我说的：拆书比读书更重要。

不是说读书不重要，而是说：读书是输入，拆书是编译。没有编译这一步，输入永远不能变成可用的能力。

被编译的知识，有什么不同

让我具体说说，一个知识被"编译"之后，它的属性发生了哪些变化。

变化一：从被动等待，到主动参与

未编译的知识（书里的知识）：你去找它。

你需要记得这本书的存在，记得它讲了什么，然后主动去翻找，重新激活相关内容，才能使用它。

这个过程依赖你的记忆，而记忆是不可靠的。

编译后的知识（Skill）：它来找你。

当你在 Obsidian 里讨论某个问题，当你在项目里遇到某种情境，你的 AI 系统可以主动识别：这个场景和哪个 Skill 相关，然后调用它，把那本书的框架带进当前的对话。

知识的调用模式，从"拉取（Pull）"变成了"推送（Push）"。

变化二：从孤立存在，到网络节点

未编译的知识：每本书是孤立的。

你读了《卡片笔记写作法》，又读了《金字塔原理》，又读了《系统思考》。

这三本书，各自以笔记的形式存在于你的知识库里。它们之间有联系，但那个联系，存在于你脑子里，不存在于系统里。

你的脑子一旦忘记，联系就断了。

编译后的知识：每个 Skill 是网络中的一个节点。

当你把这三本书都拆成 Skill，你的 AI 系统可以同时调用三个框架，发现它们之间的交叉点，生成跨书的洞见——这是单本书阅读无法实现的知识组合。

《卡片笔记写作法》讲的是如何建立知识连接，《金字塔原理》讲的是如何结构化表达，《系统思考》讲的是如何看见系统中的反馈回路。

把这三个 Skill 同时激活，你在做内容规划的时候，AI 可以同时调用三本书的框架，给出一个比任何单本书都更完整的分析视角。

知识的价值，从加法变成了乘法。

变化三：从时间衰减，到时间增值

未编译的知识：价值随时间衰减。

读完第一天，价值最高。然后指数级下降，直到你基本忘光。

编译后的知识：价值随时间增值。

今天拆了一本书，加入了系统。明天拆了另一本书，系统里多了一个节点，同时这两本书之间建立了连接，价值不是 1+1，而是更高。

下个月又拆了五本，系统里有了七本书的框架，它们互相连接，产生交叉洞见，价值是 7 的某个乘数。

这是知识复利的真实含义：每一次积累，都在放大之前所有积累的价值。

变化四：从私人体验，到可组合资产

未编译的知识，是私人体验。

你读了一本书，有了某种感悟和收获，但这种感悟是你脑子里的状态，无法被移植，无法被复用，无法参与其他任务。

编译后的知识，是可组合的资产。

一个 Skill 文件，可以被：

• 导入到任何项目的 CLAUDE.md 里
• 和其他 Skill 组合使用
• 被团队成员共享（如果需要）
• 在你建造的任何 AI 系统里调用

它不再只属于"你读了这本书的那段时间"，它属于你这个系统的整个生命周期。

一个让我想了很久的比喻

程序员这个职业，有一个很有意思的习惯：

当你解决了一个复杂的问题，你不会就此打住。

你会把解决方案抽象成函数，封装进工具库，这样下次遇到类似问题，不需要重新解决，直接调用。

这个习惯的名字叫：抽象（Abstraction）。

软件工程进化的整个历史，在某种程度上，就是一部抽象层次不断提高的历史：

text

机器码
  ↓ 抽象
汇编语言
  ↓ 抽象
C 语言
  ↓ 抽象
面向对象语言
  ↓ 抽象
高级框架和库
  ↓ 抽象
……

每一层抽象，都让"站在巨人肩膀上"这件事变得更容易。

你今天写一段 Python，调用了几十年来无数程序员封装的智慧成果，你不需要重新发明轮子，你在抽象层面上工作。

读书，本质上也是站在巨人肩膀上的事。

一本书，是一个人花了多少年的思考、实践、失败、总结，提炼出来的智慧结晶。

你花几个小时读完它，理论上可以获得作者花几十年才得到的洞见。

但如果你读完就忘，这本书对你的真实价值，接近于零。

你站上了巨人的肩膀，但你没有在那里建立任何东西，然后你就滑了下来。

拆书，是在巨人的肩膀上搭一个脚手架。

让你能在那个高度上稳定地站立，稳定地工作，而不是短暂地攀上去然后掉落。

但读书本身，还有价值吗

写到这里，我必须正面回答一个可能让人困惑的问题：

如果拆书比读书更重要，那读书这件事本身，还有价值吗？

有的。而且是不可替代的价值。

我做过一个实验：

把一本我没读过的书，直接用 book-to-skill 拆解，然后开始调用它的 Skill。

结果很有意思：

Skill 文件生成得很完整，框架看起来很清晰，但每次我调用它，总感觉有哪里不对——AI 给的建议是对的，但我不知道该不该信，也不知道在什么情况下这个框架会失效。

后来我把那本书读了一遍，再去用同一个 Skill。

完全不同的感受。

Skill 的每个框架，背后现在有了血肉。

我知道作者为什么提出这个框架，我知道它解决了什么具体的问题，我知道它的前提假设是什么，我知道哪些地方作者自己也承认是有局限的。

这些东西，Skill 文件里没有——不是因为技术不够，而是因为这些东西只在阅读体验中存在。

所以我的真实观点是这样的：

读书 + 拆书，是一个完整的闭环。缺少任何一步，都是不完整的。

text

读书 = 建立理解（血肉）
拆书 = 封装能力（骨架）
有血肉无骨架 = 你有感悟，但系统无法调用
有骨架无血肉 = 系统能运行，但你不知道该不该信它

读书给你理解的质量，拆书给你调用的能力。

两者缺一不可。

但如果我必须在"只读不拆"和"只拆不读"之间选一个——

我选只拆不读。

因为在 AI 时代，你调用一个 Skill，遇到困惑，你可以问 AI："这个框架的背景是什么？作者的意图是什么？"然后获得相当完整的理解。

但如果你只读不拆，你的理解再深，如果没有可调用的形态，也只能停留在意思 A——一种会消散的阅读体验。

这套哲学，对普通人意味着什么

到这里，我需要说一件事：

这套哲学不只是给程序员的。

我用了很多程序员的比喻——函数库、编译、抽象——但这些只是我熟悉的语言，底层的道理适用于所有人。

你是设计师：你读了十本关于用户体验的书，它们是文档，还是函数库？

你是写作者：你研究了很多写作方法论，它们在你写下一篇文章的时候，会主动参与，还是沉睡在笔记里？

你是管理者：你读了很多关于团队管理的书，三年后你带团队遇到困难，这些书会出现，还是只剩下一些模糊的印象？

每个人都在用时间换知识。

问题只有一个：

你换来的知识，是以文档的形态存在，还是以函数库的形态存在？

文档会衰减。函数库会增值。

这就是我为什么说，拆书比读书更重要。

不是说读书不重要——读书是输入的源头，没有读书就没有什么可以拆解。

而是说：

在读书和知识真正变成你的能力之间，有一步叫"拆书"。大多数人跳过了这一步，然后疑惑为什么读了那么多书，感觉什么都没有变。

这一步，就是从消费者变成建造者的那一步。

这一步，就是知识从体验变成资产的那一步。

这一步，就是你从"读过这本书的人"变成"拥有这本书的能力的人"的那一步。

结尾

两年前，那个朋友问我："你读完之后，这本书会变成什么？"

现在我有答案了。

它会变成我系统里的一个能力模块。

它会在我需要它的时候出现，而不是等我想起它。

它会和我读的其他书建立连接，产生我一个人无法产生的洞见。

它会在三年后我做的某个项目里，默默参与那个项目，我甚至不会特别意识到它的存在——就像你调用一个函数，你不会刻意想起是哪位工程师写了这个函数，你只是用它，然后它帮你解决了问题。

这就是 book-to-skill 背后我真正相信的知识哲学：

知识不是用来被记住的，是用来被调用的。

书不是用来被读完的，是用来被集成的。

学习不是为了感觉更聪明，是为了让系统更有能力。

而我，正在公开建造这个系统。

一本书一本书地拆解，一个 Skill 一个 Skill 地入库，一点一点地，把我读过的每一本真正有价值的书，从书架上的文档，变成系统里的函数库。

这个过程很慢，但有复利。

我相信，十年之后，这个系统里积累的每一个 Skill，都还在为我工作。

而那些只是"读过"但没有拆解的书，大概早就被遗忘了。

两种存在方式，两种命运。

你选哪种？

写完之后的一个补充

写这篇文章，比我想的要难。

难不在于观点——观点我想了很久，很清晰。

难在于一个真实的张力：

我是在鼓励大家"少读书，多拆书"吗？

我不是。

我其实想说的，更接近于这样一种态度：

认真读，然后认真拆。不要在读完之后，假装已经"学会了"。

那种读完的满足感，那种"我又读了一本书"的成就感——我太熟悉了，我曾经以那种满足感为食，好几年。

但满足感，不是能力。

体验，不是资产。

拆书，是从体验到资产的那一步桥梁。

这才是我真正想说的。

我是【一只阿木木】——公开建造我的 AI 第二大脑。

普通人如何用 AI 搭建自己的知识操作系统？

一个程序员出身的知识工作者，公开记录自己如何用 AI 工具搭建个人知识系统、把读过的书和做过的项目变成可复用资产的全过程。

欢迎加入行动营👇获取更多Obsidian + AI数字大脑实践

我相信：在 AI 时代，每个普通人都该拥有一个自动生长的知识系统

欢迎关注【一只阿木木】🌊