编译式阅读：一个 AI 时代的深度学习方法

编译式阅读：一个 AI 时代的深度学习方法

一只阿木木 · AI 深读工程师

这不是一篇文章，这是一本小书。 它是我用两年时间，编译了 20 本书之后， 从自己身上提炼出来的方法论。

献给每一个读了很多书，却总感觉什么都没有留下的人。

写在最前面

我想先问你三个问题。

第一个问题：

你上个月读完的最后一本书，现在能讲出几个核心框架？

不是大概说说，而是能具体到："这个框架有 X 步，第一步是……第二步是……"

如果你能讲出来，你很厉害。

如果你只记得一两句金句，或者只有"好像讲了什么很有用的东西"的模糊感觉，你和我一样——曾经一样。

第二个问题：

你上个月读完的那本书，有没有改变过你的一个真实决策，或者一个真实习惯？

不是"让你觉得很有道理"，而是真的改变过一件具体的事。

如果有，你是少数人。

如果没有，也别太自责——这不是你的问题，这是方法的问题。

第三个问题：

你现在的读书方式，和三年前有什么本质不同吗？

不是"读的书更多了"，而是方法本身。

如果几乎没有区别——

那么这本小书，是我写给你的。

第一章：问题的根源

1.1 为什么读了很多书，还是什么都没有？

让我先说一个让大多数读书爱好者不舒服的真相：

大多数人的阅读，本质上是一种信息消费行为，而不是知识建设行为。

这两者的区别在于：

text

信息消费：
书 → 你的大脑 → （遗忘）
知识建设：
书 → 你的系统 → 可被调用的能力

信息消费会让你觉得充实，但没有留下什么。

就像你吃了一顿很好的饭，感觉很满足，但三天后你的身体不会因为那顿饭变得更强壮。

而知识建设是另一回事。

它是系统性地把外部知识转化为内部能力的过程。

这个过程，需要一套工程化的方法。

这套方法，就是「编译式阅读」。

1.2 传统读书方法，在哪里失效了？

我不是要否定读书这件事，我是要指出方法的局限。

传统读书方法——无论是思维导图、康奈尔笔记、SQ3R，还是各种摘录高亮——它们都在优化同一个环节：

从书到笔记。

但知识工作的完整链路，是这样的：

text

书 → 理解 → 结构化 → 存储 → 检索 → 触发 → 行动 → 反馈 → 迭代

传统方法只覆盖了：

text

书 → 理解 → 存储（结束）

从存储到行动，中间有一条没有人帮你搭建的桥。

这就是为什么：

• 你做了笔记，但从来不看
• 你划了高亮，但合上书就忘
• 你写了读后感，但写的时候就知道以后也不会再翻

不是你不努力，是方法没有覆盖完整链路。

1.3 AI 时代，读书方法需要升级

2025 年之后，有一件事发生了：

AI 工具的成熟，让「把书编译成可执行工具」这件事，第一次真正可行。

以前，就算你想把一本书转化成一套决策框架，你也很难做到——因为：

• 提取框架需要大量时间
• 把框架命令化需要工程能力
• 跨书关联需要几乎不可能的记忆广度

但现在，这些问题都有了工具解法：

• Book-to-Skill：把书自动提炼成结构化 Skill
• Claudian：在 Obsidian 里直接和 Skill 交互
• Claude-Obsidian：自动发现跨书关联，维护知识图谱

这不是"用 AI 写读书笔记"。

这是一种真正意义上的方法升级：

从「读书」到「编译书」。

第二章：什么是编译式阅读？

2.1 从一个编程比喻开始

如果你写过代码，你知道：

源码放在那里不编译，等于没有程序。

一份 Java 文件、一份 Python 脚本，在运行之前什么都不是。它需要被编译、链接、部署，才能在真实环境中运行，才能真正产生价值。

读书也是一样。

一本书的内容，对你来说只是「源码」。

如果你只是阅读、理解、记笔记，你只是在「读懂源码」。

但如果你不编译，这份源码就只是存档，不会运行，不会产生价值。

编译式阅读，就是把「读懂源码」变成「编译成可执行文件」的过程。

编译的产物不是笔记，而是 Skill——可以在真实场景中随时调用的能力包。

2.2 一个精确的定义

编译式阅读的定义：

用系统化的工具链，把一本书的框架、模型和原则，转化为可在真实场景中执行的 AI 技能（Skill），并通过持续使用和跨书连接，让这些技能在你的知识系统中自组织、复利增长的阅读方法。

这个定义里，有几个关键词：

系统化的工具链：

不是随意用几个工具，而是有完整流程：Book-to-Skill → Claudian → Claude-Obsidian。

框架、模型和原则：

编译式阅读不适合所有书。它适合有明确可命名框架的书。小说、散文、回忆录不适合编译。

真实场景：

Skill 必须在真实场景中跑通，而不是停留在文档里。

自组织、复利增长：

单本书是工具，多本书是系统。系统会随着编译数量的增长，自发产生越来越多的跨书洞察。

2.3 编译 vs 拆书 vs 摘录：三种方法的本质差异

第三章：编译式阅读的四个阶段

这是方法论的核心。

编译式阅读分为四个阶段，我用编译原理里的概念来命名它们：

text

预处理（Preprocess）
编译（Compile）
链接（Link）
运行（Run）

第一阶段：预处理

目标： 把一本书从线性文本转化为结构化知识包。

核心工具： Book-to-Skill

时间投入： 30-60 分钟（主要自动完成）

预处理的三个关键任务

任务 1：框架提取

方法论类书籍的价值，不在于它的文字，而在于它的框架。

框架是什么？框架是作者对某类问题的结构化解法。

它通常有三个特征：

• 有名字（比如「五步流程」「系统1/系统2」「杠杆四类型」）
• 有结构（不是一句话，而是一套可以执行的步骤）
• 有边界（有它适用的场景，也有它不适用的场景）

好的框架提取，不是"作者说了什么"，而是"这个框架用来解决什么问题，怎么用"。

任务 2：术语锚定

每本好书都有自己的术语体系。

错误的做法是：用你已有的词汇去理解作者的新词汇。

正确的做法是：先接受作者的定义，再理解它的含义。

比如，达利欧说"极度透明"，这个词的含义非常具体，不等于"说话直接"。
卢曼说"永久笔记"，这个词的含义非常严格，不等于"做了就不删"。

术语锚定，是预处理最容易被忽略、也最关键的环节。

任务 3：反模式识别

每本好书，都不只是告诉你"该做什么"，还会告诉你"不该做什么"。

这些反模式，往往是最有价值的内容。

因为反模式是作者见过最多失败案例后，总结出来的警告。

预处理阶段的选书标准

可以编译的书（强烈推荐）：

• 有 ≥ 3 个命名框架
• 有可操作的步骤或流程
• 有明确的使用场景描述
• 有作者的真实案例

谨慎编译的书（需要额外加工）：

• 框架隐含在叙事里，需要主动提炼
• 作者更关注"道理"而非"方法"
• 概念密集，但执行性弱

不适合编译的书：

• 小说、散文、诗歌
• 纯叙事回忆录
• 只有观点没有框架的书

编译适配性评分（工具）

在开始编译之前，先用这个四维评分做预检：

text

📐 框架密度（1-5分）
   书中可命名框架的数量和质量
🔧 可执行度（1-5分）
   框架能否被转化为可操作命令
🔗 可链接度（1-5分）
   这本书能否和你已有的书产生关联
🎯 个人适配度（1-5分）
   你在真实生活中能否跑通这些框架
综合评分 ≥ 16 → 强烈推荐编译
综合评分 12-15 → 可以编译，需要额外加工
综合评分 < 12 → 暂缓编译

第二阶段：编译

目标： 把预处理结果，通过深度交互，转化为"你的"Skill。

核心工具： Claudian

时间投入： 每本书 3-5 小时，分散在 5-7 天

为什么叫"编译"而不叫"学习"？

学习，往往是被动的——别人告诉你什么，你接受什么。

编译，是主动的——你把外部框架放进自己的生活场景里跑一遍，看输出是什么。

这个区别非常重要。

同一本《原则》，达利欧的原则是他的。
你不是在"学习达利欧的原则"，你是在"用达利欧的框架编译你自己的原则"。

编译阶段的四个必做动作

动作 1：追问

每个框架，都要追问它的边界：

text

这个框架在什么情况下会失效？
作者的假设前提是什么？
如果有一个反例，最强的反例是什么？

一个经得起追问的框架，才值得被编译进你的系统。

动作 2：场景化

每个框架，都必须找到至少一个你自己的使用场景：

text

我上次什么时候遇到过这类问题？
这个框架如果放在那次情况里，会产生什么？
下次我遇到类似情况，具体怎么用这个框架？

找不到场景，就暂时不要强行编译。等你真正遇到场景再回来。

动作 3：质疑

不要无条件接受作者的观点。

即使是非常值得尊重的作者，也有他视角的局限性：

text

这本书的受众是谁？
作者的个人经历如何影响了他的建议？
有没有研究或反例和这个观点相悖？

这不是为了否定作者，而是为了知道这个框架适用的边界在哪里。

动作 4：个人化改写

这是编译阶段的最终产物。

你要把原书的框架，改写成"你自己的命令"：

text

原版：纳瓦尔的杠杆分析框架
个人化改写：/naval-amumu leverage [项目]
→ 针对我的后端工程师 + 内容创作者双重身份，
  专门为"如何判断一个副业项目是否值得投入"而优化

个人化意味着：这个命令放在别人那里可能跑不通，但放在你这里一定跑得通。

编译阶段的踩坑警告

陷阱 1：把 AI 总结当成编译

让 AI 帮你总结一本书，不是编译。

编译是你和 AI 一起，把框架放在你的真实场景里反复跑。

总结是别人的，编译产物是你的。

陷阱 2：只用书里的场景，不用自己的场景

书里的场景是作者的，不是你的。

编译的意义在于：把框架跑在你的身上，看输出了什么。

陷阱 3：编译阶段就想输出内容

编译是深度消化的过程，不是内容产出的过程。

在编译阶段，先只问"我理解了吗"和"我能用吗"，不要想"我怎么写文章"。

第三阶段：链接

目标： 让新编译的 Skill，和已有知识图谱自动连接，产生跨书洞察。

核心工具： Claude-Obsidian

时间投入： 每天 5-10 分钟审查

为什么链接比编译更重要？

一本书的价值是线性的：一个 Skill，解决一类问题。

但书与书之间的连接，价值是指数的：两个 Skill 结合，往往能解决任何一本书单独无法解决的问题。

更重要的是：跨书连接揭示的，是比单本书更深层的规律。

比如：

text

《纳瓦尔宝典》说：复利是财富的核心机制。
《原则》说：痛苦 + 反思 = 进步（经验复利）。
《卡片笔记写作法》说：知识的价值在连接，不在存储（知识复利）。
三本书交叉后，涌现出一个更深的洞察：
复利不是时间的自然结果，
而是「经验被结构化保存和反复调用」的结果。
如果你只读一本书，你得不到这个洞察。

这就是链接阶段的魔法。

链接阶段的三种关联类型

类型 1：共振（Resonance）

两本书用不同语言，说了同一件事。

这说明你发现了一个跨领域的通用规律。

示例：

text

系统之美的"调节回路" ≈ DDIA 的"最终一致性收敛机制"
→ 底层规律：通过负反馈机制消除偏差，趋向平衡
→ 这个规律在生态系统、分布式系统、组织管理中都成立

类型 2：补全（Completion）

一本书有框架没有方法，另一本书有方法正好补上。

示例：

text

卡片笔记法：有「积累」方法，没有「输出」方法
金字塔原理：有「输出」方法，没有「积累」方法
→ 两者补全 = 完整知识工作管道

类型 3：冲突（Conflict）

两本书的建议在某个场景下互相矛盾。

这是最有价值的关联类型，因为它迫使你找到两者各自的适用边界。

示例：

text

深度工作：碎片时间要消灭，保持专注
卡片笔记法：碎片时间是捕捉灵感的最佳窗口
→ 冲突解析：它们管辖的是不同时间粒度，分属不同工作模式

Claude-Obsidian 的角色

Claude-Obsidian 在链接阶段承担的是"自动园丁"的角色。

它每天后台运行，做三件事：

text

1. 扫描所有新增笔记和 Skill
2. 用语义理解发现潜在关联（而不只是关键词匹配）
3. 在笔记中插入双向链接，生成每日发现报告

但它不能替代你的判断。

每天花 5-10 分钟审查它的发现：

• 有意义的关联：深化并写成连接笔记
• 误报的噪音：删除，避免图谱污染

知识图谱的三个成熟阶段

阶段 1：孤立期（1-3 本书）

图谱里都是孤立的节点。这个阶段要耐心积累，不要急于交叉编译。

阶段 2：聚合期（4-8 本书）

某些话题开始出现节点群。这时可以开始做双书交叉编译，但不要强行。

阶段 3：涌现期（9 本书以上）

知识图谱开始自组织，产生你没有预期的跨领域洞察。这就是复利开始的时候。

第四阶段：运行

目标： 在真实场景中调用 Skill，验证编译是否成功，并通过反馈持续迭代。

工具： 所有编译好的命令

时间投入： 随时

运行的唯一标准

编译是否成功，唯一的标准是：能不能在真实场景里跑通。

不是你"感觉理解了"，不是 AI "给了一个好看的输出"，而是：

你遇到了一个真实问题，调用了这个 Skill，得到了一个有用的判断或行动方案，这个方案执行后确实有效。

如果做不到，说明编译还没完成。需要回到第二阶段继续深化。

三种运行测试

测试 1：解释测试

text

任务：向一个完全不了解这本书的人，
     用 5 分钟讲清楚核心框架，并举一个你自己的例子。
通过标准：对方听完能用自己的话复述。
失败标准：你说了很多书里的话，但举不出自己的例子。

如果连自己的例子都举不出来，说明你还在"读懂"的层面，没有到"跑通"。

测试 2：场景测试

text

任务：这周用这个命令解决一个真实问题。
通过标准：问题被解决，或者你清楚地知道为什么没有解决。
失败标准：你用了命令，得到了输出，但不知道怎么行动。

如果输出了但无法行动，说明命令的「场景化」程度不够，需要回去重新个人化改写。

测试 3：迭代测试

text

任务：运行之后，更新你的 Skill 或原则。
通过标准：每次运行都带来至少一处更新。
失败标准：你一直在用第一版，从来没有更新过。

Skill 不是静态的，它应该随着你的实践持续进化。

运行失败后怎么办？

运行失败不是问题，逃避失败才是问题。

每次运行失败，都要做一件事：

text

记录失败模式：
- 这次失败是因为框架本身有问题，还是我的场景化不够？
- 如果是框架问题，这本书的这个框架有什么局限？
- 如果是场景化问题，我需要如何调整命令？
- 下次遇到类似情况，我需要补做什么？

这个记录，会成为你个人原则库的原材料。

第四章：编译式阅读的五个原则

这五个原则，是我从两年实践中提炼的核心。

原则 1：密度优于完整性

很多人读书，追求的是"完整性"——把书里所有有价值的内容都记下来。

编译式阅读追求的是"密度"——从书里提炼最核心的框架，以最高密度保存它。

两者的区别：

text

完整性导向：
书有 50 个观点 → 笔记记了 40 个 → 很难检索，很难调用
密度导向：
书有 50 个观点 → 提炼 3-5 个核心框架 → 高度可检索，高度可调用

口诀：1000 token 的高密度摘要，胜过 10000 token 的流水账。

原则 2：实践者口吻

这是 Book-to-Skill 的核心设计原则，也是编译式阅读的重要原则。

所有编译产物，必须用"实践者口吻"表达，而不是"学者口吻"。

text

学者口吻（不好）：
"作者认为，高质量的产出与专注时间和专注强度的乘积成正比。"
实践者口吻（好）：
"当你需要高质量产出时，给自己划定一个 ≥90 分钟的专注块，
 物理隔绝干扰，只做一件事。"

区别在于：前者告诉你"书里说了什么"，后者告诉你"你该怎么做"。

原则 3：跑通才算

这是编译式阅读最核心的验证标准，也是它和所有其他读书方法的本质区别。

读完不算，跑通才算。

"跑通"的定义：

你在一个真实场景中，调用了这个 Skill，得到了有用的判断，并且真的按照这个判断行动了，而且行动之后有反馈，反馈让你更新了 Skill 或原则。

这个完整的闭环，才叫"跑通"。

只完成了其中一部分（只调用，不行动；只行动，不复盘），都不算跑通。

原则 4：失败是数据

这个原则直接来自达利欧的《原则》，但它在编译式阅读里有特殊的意义。

在编译式阅读里，有两种失败都很有价值：

Skill 运行失败：

这说明你的编译不够深，或者场景化不够。回去修正，下次会更好。

编译书籍失败：

有些书就是不适合编译，或者适配度不高。这个失败帮你建立了"什么书值得编译"的判断力。

记录失败，远比忽略失败有价值。

我专门在 Obsidian 里建了一个「编译失败日志」，记录每次失败的书和原因。

这个日志，比我的成功案例更有指导价值。

原则 5：系统复利

这是最后一个原则，也是最强的一个原则。

单本书的 Skill，是工具。

多本书组合的 OS，是系统。

工具的价值是线性的。

系统的价值是复利的：

text

第 1 本书：1 个 Skill，解决 1 类问题
第 5 本书：5 个 Skill，但交叉后能解决 10+ 类问题
第 10 本书：10 个 Skill，但交叉后能解决 30+ 类问题，
           还有你没有预期的新洞察开始涌现

这就是为什么编译式阅读不是一次性方法，而是一个需要长期投入的系统工程。

投入的前三个月，你可能看不到显著的变化。

但过了某个临界点，复利会开始出现，而且会加速。

第五章：工具配置指南

5.1 最小化配置（立刻可以开始）

如果你现在想立刻开始，不需要等所有工具都配置好。

第一步（今天）：

下载 Obsidian，安装 Claudian 插件。

第二步（明天）：

用 Claude（任意版本）手动为一本书生成一份 SKILL.md：

text

提示词模板：
你是一个书籍编译专家。
我要编译《[书名]》。
请按以下格式输出 SKILL.md：
# [书名] Skill
## 核心论点（≤100字）
## 命名框架（每个：定义 + 使用场景 + 示例）
## 可执行命令（格式：/命令 [参数] → 行动描述）
## 术语表（精确定义）
## 反模式（不要做什么）
## 速查表（最重要的 5 个决策点）
书的核心内容：
[粘贴书的核心章节或你的笔记]

第三步（这周）：

在 Obsidian 里，用 Claudian 和这份 SKILL.md 进行至少 3 次对话：

1. 追问边界
2. 场景化测试
3. 个人化改写

第四步（这个月）：

在真实场景里运行至少一个命令，记录结果。

这四步，就是编译式阅读的完整最小循环。

5.2 完整工具配置

当你完成了第一本书的最小循环，可以开始配置完整工具链：

text

层 1：笔记与知识管理
└─ Obsidian（免费）
   必装插件：Claudian / Obsidian Git / Dataview / Templater
层 2：AI 编译引擎
└─ Claude Pro（$20/月）
   + Book-to-Skill（开源）
层 3：知识图谱与自动化
└─ Claude-Obsidian（开源）
层 4：版本管理
└─ GitHub（免费）+ Obsidian Git 插件
   → 给你的 Skill 库做版本控制

5.3 Obsidian Vault 结构建议

text

📁 你的 Vault/
├── 📁 00-Inbox/          ← 所有临时输入
├── 📁 10-Skills/         ← 编译好的 Skill
│   ├── 📁 book-name-skill/
│   │   ├── SKILL.md
│   │   ├── chapter-xx.md
│   │   └── glossary.md
├── 📁 20-Notes/          ← 永久笔记
├── 📁 30-MOC/            ← 主题地图
├── 📁 40-Projects/       ← 进行中的内容项目
├── 📁 50-OS/             ← 你的 AI 人生操作系统
│   ├── os-diagnose.md
│   ├── weekly-review.md
│   └── principles-library.md
└── 📁 60-Daily/          ← 每日笔记

第六章：常见问题与诚实的回答

Q1：编译式阅读适合所有人吗？

诚实的回答：不适合所有人。

它最适合：

• 有明确「读书到行动」需求的人（不只是读书爱好者）
• 愿意在工具配置上投入一定时间的人
• 以知识工作为主要工作方式的人
• 读了很多书但感觉「没有留下什么」而困扰的人

它不适合：

• 读书主要是为了享受和放松的人（这完全没有问题，只是目的不同）
• 排斥 AI 工具的人
• 没有时间和意愿进行系统化学习的人

Q2：一本书要编译多久？

诚实的回答：比你想象的更长，但比你以为的更值得。

text

预处理：30-60 分钟
编译阶段：3-5 小时，分散在 5-7 天
链接阶段：自动（每天 5-10 分钟审查）
运行阶段：持续，随时
总初始投入：约 5-7 小时

这比"快速读完一本书做几页笔记"要长。

但这 5-7 小时的编译投入，会在未来每一次调用这个 Skill 时持续回报。

而"快速读完"的那些书，大多数在两周后已经忘干净了。

Q3：如果我不懂技术，能用这套方法吗？

诚实的回答：能。

技术背景会让你更快上手工具，但方法本身不需要技术背景。

所有的"编程比喻"（编译、运行、链接）只是用来帮助理解，不是真的要你写代码。

如果你完全不懂技术，你可以把：

• "预处理"理解为"提炼精华"
• "编译"理解为"深度消化"
• "链接"理解为"建立关联"
• "运行"理解为"实际应用"

方法是一样的。

Q4：知识图谱会不会越来越乱？

诚实的回答：会，如果你没有维护机制。

Claude-Obsidian 的自动关联，大约有 10-15% 是"误报"——看起来有关联但实际上没有价值的连接。

如果你不每天审查，时间久了确实会有噪音积累。

解决方案很简单：

• 每天花 5 分钟审查当日发现
• 每月花 30 分钟做一次笔记库审计（/zettel audit）
• 删除没有价值的关联，给有价值的关联加批注

噪音是可管理的。

Q5：编译式阅读和 Read-it-Later、ReadWise 这类工具有什么区别？

诚实的回答：目标完全不同。

ReadWise、Readwise Reader 这类工具，优化的是"复习已有高亮"。

它们的假设是：你读了书，划了线，需要一个工具帮你定期复习，加强记忆。

这是好工具，解决了"遗忘"问题。

但编译式阅读解决的是更深层的问题：

不是"你记住了什么"，而是"你能做到什么"。

记忆是手段，行动才是目的。

Q6：我现有的大量读书笔记怎么办？

诚实的回答：不用迁移，但可以"升级"。

你以前的读书笔记，不需要全部转成 Skill。

但你可以用这套方法，把那些你觉得"最有价值但一直没真正用起来"的书，重新编译一遍。

不是从零开始，而是用你已有的笔记作为原材料，快速进入第二阶段（编译）。

这往往比从头编译一本新书更快，因为你已经有了基础理解。

Q7：这套方法有没有可能失效？

诚实的回答：有，在两种情况下。

情况 1：你选了不适合编译的书。

把一本散文编译成 Skill，大概率是失败的。

这不是方法的问题，是选书的问题。

情况 2：你跳过了「运行」阶段。

如果你完成了预处理、编译、链接，但从来不在真实场景里运行，
那你只是建了一个更精美的笔记系统，不是在做编译式阅读。

编译式阅读的价值，在运行阶段才真正体现。

没有运行，编译只是另一种存档。

第七章：第一次编译的 30 分钟快速上手

看到这里，你可能有点跃跃欲试，但不知道怎么开始。

这一章给你一个 30 分钟的快速起步方案。

第一步（5 分钟）：选一本书

推荐：

《The Mom Test》（Rob Fitzpatrick）

理由：

• 篇幅短（200 页）
• 框架非常清晰（3 条规则 + 明确的行为标准）
• 对任何有产品或内容想法的人都适用
• 很多人读过，但很少有人真的用过

如果你已经有想编译的书，用你自己的选择。

第二步（10 分钟）：手动生成一份 SKILL.md

不需要 Book-to-Skill 工具，直接用 Claude：

text

复制这段提示词，替换书名和章节内容：
你是一个书籍编译专家。
请把《The Mom Test》的核心方法编译成 SKILL.md。
格式：
# The Mom Test Skill
## 核心论点（一句话）
## 核心规则（3-5条，每条：规则 + 使用场景 + 示例）
## 可执行命令
/momtest validate [你的商业想法]
/momtest audit [一段对话记录]
## 反模式（绝对不要问的问题类型）
## 速查表（5个最重要的判断标准）

第三步（10 分钟）：第一次交互

拿 SKILL.md 调用 Claudian，和这本书做一次对话：

text

我有一个想法：[描述你的产品/内容想法]
请用 /momtest validate 帮我生成 5 个符合 Mom Test 原则的验证问题。

然后问自己：

• 这些问题和我原本打算问的问题有什么不同？
• 我以前的问题有没有违反 Mom Test 原则？

第四步（5 分钟）：记录第一条「编译笔记」

在 Obsidian 里，建一个新笔记：

text

# 编译日志 - The Mom Test
编译日期：
核心框架：
今天最大的收获：
我会在什么场景用它：
下次追问的问题：

恭喜，你完成了第一次编译的最小循环。

接下来的一周，尝试在一个真实场景里运行 /momtest validate。

记录它有没有帮到你，记录它在哪里不够好。

然后回来更新你的 SKILL.md。

这，就是编译式阅读开始的样子。

第八章：从方法到 IP，从 IP 到系统

这一章，我想从方法论走出来，说一些更个人的东西。

8.1 编译式阅读，如何变成个人 IP

这两年做「编译式阅读」，我越来越相信一件事：

真正有价值的个人 IP，不是一个好听的标签，而是一套系统的持续输出。

「一只阿木木」这个 IP，如果只有「AI 深读工程师」这个定位，它只是一个标签。

真正让它有价值的，是：

• 20 本书的编译记录
• 137 个可执行命令
• 47 篇由知识图谱生长出来的文章
• 34 条从真实失败中提炼的个人原则
• 还有这本你正在读的小书

这些东西叠在一起，才构成了一个别人无法复制的个人 IP 壁垒。

因为：

• 你可以复制我的标签
• 但你无法复制我的两年积累

这就是 Skill Stack 的威力。

8.2 一个给想做内容的人的建议

如果你也想做内容，我只有一条建议：

不要把内容创作当成「表达」，而要当成「系统输出」。

表达是随机的：今天灵感来了，写一篇；明天没有灵感，就不写。

系统输出是可持续的：你的知识图谱里有密度的地方，就是你的下一篇文章。

从「编译」到「内容」，管道是这样的：

text

积累（/zettel capture）
→ 连接（Claude-Obsidian 自动）
→ 涌现（/zettel develop 发现密度）
→ 转换（/pipeline convert 网状变线性）
→ 结构化（/pyramid structure）
→ 深度工作（/deepwork sprint）
→ 发布（文章）
→ 反馈（读者评论、数据）
→ 更新（Skill 和原则迭代）
→ 积累（循环）

这个管道一旦建立，你永远不会再有「不知道写什么」的焦虑。

你只会有「这个话题的笔记还不够密，还需要继续积累」的清醒。

8.3 给工程师读者的一句话

如果你是工程师，而且还不确定编译式阅读是否适合自己，我想说：

你已经在用系统化思维解决代码问题，现在只是把这套思维用在知识问题上。

你写代码时，会做代码审查，会写单元测试，会做性能优化，会有版本控制，会有持续集成。

编译式阅读，只不过是把同样的工程思维，用在了「读书 → 能力」这条生产线上。

• Book-to-Skill = 编译器
• Claudian = IDE
• Claude-Obsidian = CI/CD 系统
• 运行阶段 = 生产环境测试
• 个人原则库 = 系统设计文档

你已经有这套思维了。

只需要把它用对地方。

尾声：写给那个读了很多书却什么都没留下的你

两年前，我整理书架的时候，统计了一件事：

我读过的 200 多本书里，真正改变了我的行为或决策的，不超过 10 本。

那 190 多本书，去哪了？

它们变成了一种模糊的"感觉"——「我读过很多书」的感觉。

但感觉什么都不是。

感觉不会帮你做决策，感觉不会帮你写文章，感觉不会帮你识别认知偏差，感觉不会帮你判断一个技术方案的复杂性权衡。

你需要的不是更多感觉，你需要的是可以调用的能力。

这就是编译式阅读存在的理由。

它不会让你读更多书。

它让你把读过的每一本书，真正变成你的一部分。

开始吧。

选一本书，花 30 分钟，完成第一次编译的最小循环。

不需要完美，不需要工具配齐，不需要读完所有这本小书再行动。

就现在，就这一本书，就这 30 分钟。

读完不算，跑通才算。

这句话，我已经跑给你看了两年。

现在，轮到你了。

一只阿木木 | AI 深读工程师

后端程序员 / 用 Obsidian + Claude 把好书编译成 AI 技能包

编译式阅读法创建者 | 读完不算，跑通才算

附录 A：20 本推荐编译书单

按「编译指数」排序，附上适合编译的理由：

text

第一梯队（编译指数 ≥ 4.8）：
1. 《卡片笔记写作法》
   理由：知识积累的核心方法，与 Obsidian 完美契合
2. 《原则》
   理由：框架极密，五步流程和原则库设计是精华
3. 《思考，快与慢》
   理由：认知偏差框架完整，可直接转化为决策扫描器
4. 《The Mom Test》
   理由：薄，框架清晰，立刻可以验证
5. 《DDIA》
   理由：技术人主场，框架完整，工程判断力必备
第二梯队（编译指数 4.0-4.7）：
6. 《纳瓦尔宝典》
   理由：财富战略框架，跨书连接价值高
7. 《深度工作》
   理由：专注系统的必备基础设施
8. 《金字塔原理》
   理由：表达系统，和卡片笔记互补
9. 《反脆弱》
   理由：风险管理视角，和系统之美有深度交叉
10. 《系统之美》
    理由：系统思维底层原理，跨领域连接极强
11. 《穷查理宝典》
    理由：多元思维模型，可以补强 /kahneman 命令
12. 《重构》
    理由：代码质量框架，直接应用于工程评审
13. 《学会提问》
    理由：批判性思维框架，是 /kahneman 的完美补充
14. 《黑天鹅》
    理由：适合做"警报系统"型 Skill
15. 《凤凰项目》
    理由：DevOps 和约束理论，工程文化视角独特
第三梯队（需要额外加工，适合有经验后再编译）：
16. 《影响力》
17. 《定位》
18. 《长期主义》
19. 《Good Strategy Bad Strategy》
20. 《Inspired》

附录 B：编译式阅读的 6 个常见错误

text

错误 1：把 AI 总结当成编译
解决：编译必须有你的场景化和个人化改写
错误 2：选了不适合编译的书
解决：预检适配性，叙事型书籍不强行编译
错误 3：编译完了但不运行
解决：每本书编译完，立刻设定一个 72 小时的运行任务
错误 4：只积累，不输出
解决：定期用 /zettel develop 检查密度，密度够了就输出
错误 5：追求完美的 Skill，迟迟不用
解决：80 分的 Skill + 真实使用 > 100 分的 Skill + 存档
错误 6：把别人的原则直接当自己的原则
解决：所有框架必须跑在你自己的场景里，产出你自己的版本

附录 C：一次完整编译的检查清单

预处理阶段：

text

☐ 完成编译适配性四维评分（≥16 才编译）
☐ 生成 SKILL.md（包含：框架、命令、术语、反模式）
☐ 人工审查 SKILL.md 质量（是否有误译、是否有原文摘录需要改写）
☐ 放入 Obsidian/10-Skills/ 对应文件夹

编译阶段：

text

☐ 追问框架边界（至少 1 次）
☐ 场景化测试（找到 ≥ 1 个自己的使用场景）
☐ 质疑作者观点（找到 ≥ 1 个可能的局限）
☐ 个人化改写（生成"你的"命令版本）

链接阶段：

text

☐ 查看 Claude-Obsidian 的自动关联
☐ 确认或删除每条关联
☐ 给强关联写 1 条连接笔记
☐ 更新相关 MOC

运行阶段：

text

☐ 设定 72 小时内的运行任务
☐ 完成运行，记录结果
☐ 更新 Skill（如有需要）
☐ 写入个人原则库（如有新原则）
☐ 更新「编译指数」评分（实际跑通后重评）

附录 D：编译式阅读词汇表

text

编译式阅读（Compilation Reading）：
把书里的框架转化为可执行 AI Skill 的系统化阅读方法。
Skill：
一本书的核心框架、命令和逻辑，以结构化文件形式保存，
可以被 AI 在真实场景中调用推理。
SKILL.md：
一本书的编译产物主文件，包含框架、命令、术语表、反模式和速查表。
编译指数：
评估一本书适合编译程度的四维评分（框架密度/可执行度/可链接度/个人适配度）。
运行（Run）：
在真实场景中调用 Skill，验证编译是否成功的行为。
跑通（Run Successfully）：
在真实场景中调用了 Skill，得到了有用判断，并且真实行动，
且行动后有反馈让你迭代了 Skill 或原则。
交叉编译（Cross Compilation）：
把两本或多本书的 Skill 组合使用，产生比单本更强洞察的编译方法。
编译失败（Compilation Failure）：
书籍不适合编译，或 Skill 在真实场景无法产生有用输出的情况。
失败本身有价值，需要记录。
AI 人生操作系统（Personal OS）：
多本书 Skill 组合成的、能辅助思考、决策、创作和复盘的个人知识系统。
读完不算，跑通才算：
编译式阅读的核心口号。强调知识的价值在于行动，而非记忆。

编译式阅读小书 v1.0

一只阿木木 著

2026 年

本书本身，也是编译式阅读的产物——它从 20 本书的 Skill、486 条永久笔记、2840 条知识图谱链接里生长出来。不是写出来的，是编译出来的。

如果这本小书帮到了你，

最好的回报方式是：

去编译你的第一本书。

然后告诉我，你选了什么，跑出了什么。🪵