把一本书，编译成一个永不遗忘的 AI 队友

把一本书，编译成一个永不遗忘的 AI 队友

——模块二：COMPILE 完整实践手册

「翻译是把一种语言转换成另一种语言。 编译是把人类可读的代码转换成机器可执行的指令。 这两件事看起来相似，但产物的命运截然不同—— 翻译的结果，是给人读的；编译的结果，是给机器跑的。」

一、一个类比

我第一次真正理解「编译」这件事，不是在读书的时候，是在调试一个生产环境的Bug。

那是凌晨两点，一个内存溢出的问题把整个服务搞挂了。我翻出三年前一位离职同事写的文档——密密麻麻的，两万字，用Word写的，配了二十几张截图。每一张截图都模糊到看不清字。文档描述了这个服务的所有设计决策，但我花了四十分钟，找不到任何和内存管理相关的内容。

后来我用关键词搜遍了整个文档，终于在第七千三百个字的某个括号里，找到了一句话：「注意：该模块在高并发时有内存泄漏风险，见附录C。」

附录C是一个「待补充」。

那位同事知道所有的答案。他把答案写进了文档。但他写的方式，让答案在真正需要它的时刻，完全无法被调用。

这就是「存储」和「可调用」的差距。

三年后，当我第一次看到 book-to-skill 的设计理念时，我立刻想到了那个凌晨两点的夜晚。它要解决的问题，和那份失效的文档完全一样：不是「知识在不在」，而是「知识能不能在你需要它的那一刻，被精确地交到你手上」。

这个问题，才是模块二真正要回答的核心。

二、编译的本质：不是压缩，是重铸

很多人第一次听到 book-to-skill 时，会有一个直觉反应：「哦，就是让AI帮我总结书嘛。」

这个理解差了一个数量级。

让我用冶金做比喻。

你挖出一块铁矿石，它含有铁，但你不能直接用它造桥。你需要先把矿石放进高炉，在1500摄氏度的高温下冶炼，把铁从矿石里提炼出来，排除杂质，再根据你的需要，加入不同比例的碳，制成不同用途的钢材——弹簧钢、工具钢、不锈钢，各有各的配方，各有各的用途。

「总结」是把一块矿石压扁——体积小了，但还是矿石，还是不能直接用。

「编译」是把矿石放进高炉——出来的不再是矿石，是钢材，是真正可以被工程使用的材料。

book-to-skill 的提取逻辑基于三个核心原则，每一条都值得深究：

原则一：密度胜于完整。

一个1000 token 的章节摘要，胜过一个10000 token 的原文摘录。不是因为短的一定比长的好，而是因为在 AI 调用的场景下，密度决定了信噪比。一个10000 token 的原文摘录，包含了大量的举例、过渡句、修辞，这些内容在阅读时有价值，在查询时是噪音。AI 需要在噪音中寻找信号，准确率下降，响应时间上升。一个1000 token 的高密度摘要，是纯信号，AI 可以直接调用。

原则二：提取结构，而非摘录内容。

这是最容易被误解的原则。「摘录内容」是把书里的金句抄下来，「提取结构」是把书的骨架拆出来。同一本书，这两种操作产生的文件完全不同。摘录内容的文件是散文，你读着有感觉，AI 难以索引；提取结构的文件是框架，你读着有点枯燥，AI 调用极其精准。

原则三：实践者口吻，而非观察者口吻。

「本书解释了专注力的重要性」—— 观察者口吻。 「当你需要进入深度工作状态时，先执行20分钟的启动仪式：关闭所有通知，写下本次工作的唯一目标，设置物理边界」—— 实践者口吻。

前者告诉你书讲了什么，后者告诉你你该做什么。Skill 的全部价值，在于把后者从书中提炼出来。

三、什么样的书，值得被编译？

在你拿起第一本书开始编译之前，有一个问题需要先想清楚：不是所有书都适合被编译。

这不是工具的缺陷，这是信息结构的本质差异。

想象一下两种不同的建筑图纸。第一种是施工图——精确标注了每一根梁的位置、每一堵墙的厚度、每一根管道的走向。这种图纸可以被「编译」——你把它输入建筑软件，软件知道怎么解析它，可以自动检测冲突、计算承重、生成材料清单。

第二种是水彩效果图——画得很美，充满情感，展示了建筑落成后的诗意光影。你没有办法把这张图「编译」，因为它的价值不在于结构，而在于意境。

对应到书，就是这样的分类：

高度可编译的书（施工图类型）：

有命名框架（「5个为什么」「SCQA结构」「飞轮效应」）；有可操作的步骤序列；有明确的原则清单或反模式列表；章节之间有递进的逻辑结构；书中重复出现特定的分析框架。

典型代表：《深度工作》《原子习惯》《系统思考》《麦肯锡方法》《金字塔原理》

低可编译性的书（水彩画类型）：

以故事和情感为主要载体；没有可以抽象复用的框架；知识和叙事高度绑定，拆开就失去意义；属于文学、回忆录、叙事性非虚构类型。

典型代表：《活着》《乔布斯传》《人类简史》（这本其实有框架，但框架嵌在叙事里）

可编译性自检清单（编译前必做）：

Markdown

## 📋 Compilability Checklist
- [ ] 这本书有没有「命名框架」？
      （某个被作者特别命名的方法/模型/概念）
- [ ] 能不能用编号步骤描述书的核心方法？
- [ ] 书中有没有「要做/不要做」的明确清单？
- [ ] 章节之间有没有递进的逻辑？
      （不是「第一章讲A，第二章讲B」，
       而是「理解A才能理解B」）
- [ ] 有没有可以在现实场景中直接应用的原则？
→ 勾选 4-5 项：高度可编译，全力投入
→ 勾选 2-3 项：可编译，但需手动补充结构
→ 勾选 0-1 项：不建议编译，换一种处理方式

有一个简单的判断标准：把书名替换成一个函数名，这个函数有没有可描述的输入输出？

deepWork(situation) → 返回「在这个情境下如何进入深度工作状态」，有意义。 lifeOfPiStory(situation) → 返回什么？说不清楚。

如果你能写出这个函数的签名，这本书就是可编译的。

四、第一次编译：像外科手术一样精确

选好了书，现在开始真正的操作。

我把第一次编译的全流程分成六个步骤，每一步都有需要特别注意的细节。

Step 1：安装 book-to-skill

在 Claude Code 会话中执行：

Bash

mkdir -p ~/.claude/skills/book-to-skill/scripts
curl -o ~/.claude/skills/book-to-skill/SKILL.md \
  https://raw.githubusercontent.com/virgiliojr94/book-to-skill/master/SKILL.md
curl -o ~/.claude/skills/book-to-skill/scripts/extract.py \
  https://raw.githubusercontent.com/virgiliojr94/book-to-skill/master/scripts/extract.py

验证安装：

Bash

ls ~/.claude/skills/book-to-skill/
# 应该看到：SKILL.md  scripts/

Step 2：准备你的书

book-to-skill 接受多种输入格式。

最常见的场景：单本PDF

Bash

/book-to-skill ~/Downloads/深度工作.pdf

整个文件夹（适合系列书或相关资料集群）：

Bash

/book-to-skill ~/reading-materials/productivity/

多文件合并编译（把相关的书和你自己的笔记一起编译）：

Bash

/book-to-skill 深度工作.pdf 我的阅读笔记.md 相关论文.pdf

最后一种方式特别强大，后面会详细讲。

Step 3：执行编译，理解它在做什么

运行编译命令之后，Claude 会执行一系列操作：

第一阶段：结构识别 AI 扫描全书，识别章节结构、命名框架、重复出现的模式、原则清单。这是「解构」的过程，就像外科医生拿到一张CT片，先识别所有的器官位置。

第二阶段：框架提取 把识别出的命名框架、步骤序列、原则清单，按照实践者口吻重写。注意：是「重写」不是「摘录」——每一个框架都被翻译成「在X场景下，执行Y步骤」的格式。

第三阶段：密度压缩 把每个章节的内容压缩到800-1200 tokens。这一步会丢失很多举例和叙事，但保留所有可执行的结构。

第四阶段：生成文件系统

编译完成后，在 ~/.claude/skills/<book-slug>/ 下会生成：

text

~/.claude/skills/deep-work/
├── SKILL.md          # 核心框架，~4000 tokens，始终加载
├── ch-01.md          # 第一章，~1000 tokens，按需加载
├── ch-02.md
├── ...
└── ch-N.md

Token 分配的工程逻辑

SKILL.md 消耗约4000 tokens，始终在上下文中。每个章节文件约1000 tokens，只在你询问相关内容时加载。假设你编译了15本书，同时运行：15 × 4000 = 60000 tokens 的核心知识库，始终在 AI 的工作记忆中。这是 Claude 3.5 Sonnet 200K 上下文窗口的30%，完全可以承受。

Step 4：理解 SKILL.md 的内部结构

编译完成后，打开 SKILL.md 看一眼。你会看到这样的结构：

Markdown

---
skill: deep-work
version: 1.0
author: Cal Newport
compiled: 2026-06-12
---
## Core Philosophy
（一到两段，核心思想的最高密度版本）
## Primary Frameworks
### Framework 1: Deep Work vs Shallow Work
（定义 + 判断标准 + 应用条件）
### Framework 2: The 4 Disciplines of Execution
（步骤序列 + 每步的具体操作）
## Topic Index
- 专注力训练 → ch-03
- 时间分块法 → ch-04
- 深度工作习惯 → ch-05
- 数字极简主义 → ch-06
## Anti-Patterns
（书中明确指出的「不要做什么」）
## Key Metrics
（书中提到的可量化指标）

Topic Index 是整个系统的路由器。

当你向 Skill 提问时，AI 先读取 SKILL.md，通过 Topic Index 判断你的问题属于哪个章节，然后按需加载对应的章节文件。这就是为什么查询速度快、准确率高——AI 不是在全文搜索，而是在使用你的书的「目录系统」精确导航。

Step 5：调用语法全解

编译完成后，调用方式如下：

Bash

# 加载核心框架（只读 SKILL.md）
/deep-work
# 按主题查询（路由到对应章节）
/deep-work 如何设计深度工作习惯
# 直接指定章节
/deep-work ch-05
# 在 Claudian 中引用（自动获取 vault 上下文）
@deep-work 结合我正在写的这篇文章，给出具体建议

Step 6：建立 Skill 调用习惯的三个场景

编译完了不用，等于白编。以下三个场景，是把 Skill 从「文件」变成「习惯」的关键入口：

场景一：工作前的框架检索 早上开始某项工作之前，先问 Skill：「今天我要做 [具体任务]，这本书对此有什么建议？」

场景二：遇到问题时的框架调用 工作中卡住了，先问 Skill：「我遇到了 [具体问题]，书中有没有相关的分析框架？」

场景三：输出前的一致性检查 写完一篇文章或完成一个项目后，问 Skill：「我的这个结论和书中的框架是否一致？有没有遗漏的角度？」

五、编译质量审查：大多数人跳过的关键步骤

编译完成，不是终点，是起点。

我第一次编译《系统思考》的时候，满心期待地测试，结果第一个问题就暴露了问题：我问「反馈回路的种类」，AI 给了我一个流畅的答案，听起来完全正确，但我翻书对照，发现有两种反馈回路的定义被混淆了。

AI 在用它的训练数据填补了 Skill 文件的空白。这正是 book-to-skill 设计时最想避免的问题——当 Skill 密度不够时，AI 会用自己的「常识」填补，而这些常识可能和书中的精确表述有偏差。

这就是编译质量审查的意义。

四维质量检验框架：

维度一：框架完整性检查

操作：打开书籍目录，和 SKILL.md 里的 Primary Frameworks 逐条对照。

判断标准：书中所有被命名的框架，是否都在 SKILL.md 里出现了？

特别注意：有些框架藏在不起眼的地方——比如某个章节末尾的一个列表，或者某个脚注里定义的术语。这些「隐性框架」最容易被编译器遗漏，也往往是书中最有价值的内容。

如果发现遗漏：手动编辑 SKILL.md，补充缺失的框架。

维度二：路由准确性测试

操作：准备3个分属不同章节的问题，依次提问，观察 AI 是否调用了正确的章节文件。

判断标准：每次查询的答案，应该包含该章节特有的框架名称或步骤序列，而不是泛化的常识性回答。

检测方法：在问题里故意包含一个只在某个章节出现的术语，看 AI 是否能定位到正确的章节并给出精确的答案。

如果路由错误：检查 Topic Index，修正关键词映射。

维度三：反幻觉验证（最重要）

这是三个维度里最关键的一个，也是最容易忽略的一个。

AI 的语言能力极强，这既是它的优势，也是它的危险。即使 Skill 文件里没有相关内容，AI 也能给出一个听起来完全合理的回答——它在用自己的训练数据「补全」你的问题。

操作：找书中一个非常具体的细节——一个精确的数字、一个特定的步骤序号、一个作者自创的术语——向 Skill 提问。

判断标准：AI 的回答必须和书中的原文精确匹配，包括数字、术语、步骤序号。

如果出现偏差：说明该部分的章节文件提取密度不够，AI 在用训练数据补全。解决方案：重新编译该章节，提高密度，减少歧义词汇。

维度四：密度评估

操作：检查每个章节文件的大小。

判断标准：理想的章节文件在800-1200 tokens之间。

过长（超过2000 tokens）意味着什么？ 提取粒度不够细，文件里包含了太多叙述性内容。AI 在这个文件里工作，需要过滤大量噪音，准确率下降。解决方案：重新编译，提高压缩比。

过短（低于500 tokens）意味着什么？ 提取过度，关键细节可能被丢失。AI 的回答会变得过于概括，缺乏操作性。解决方案：手动补充章节文件里的关键框架细节。

六、高阶编译：不只是书

理解了基本编译之后，有一个认知需要升级：book-to-skill 的名字里有「book」，但它真正处理的，是任何有结构的知识。

这个理解的转变，会彻底改变你的知识管理方式。

想想看：一本书是什么？它是把知识组织成线性文本的一种格式，仅此而已。如果你有另一种知识来源，同样具有可提取的结构，同样值得被反复调用，那它就同样可以被编译。

五种值得编译的知识类型：

类型一：研究论文集群

场景：你在研究某个主题，积累了十几篇相关论文，加上你自己的阅读笔记。

做法：

Bash

/book-to-skill \
  论文1.pdf \
  论文2.pdf \
  论文3.pdf \
  我的阅读笔记.md

产物：一个综合了多个来源的统一 Skill，AI 能跨文献回答你的问题，自动综合不同作者的观点，标注分歧点。

价值：一次编译，永久可用。下次做相关研究，不需要重新梳理文献，直接向 Skill 提问。

类型二：项目文档集群

场景：你有一个进行了两年的项目，积累了架构决策记录、设计文档、故障复盘、会议纪要。

做法：

Bash

/book-to-skill ~/projects/project-alpha/docs/

产物：一个「项目知识 Skill」，能回答「当时为什么做了这个决定」「这个模块有没有历史上的已知问题」「上一次类似问题是怎么解决的」。

价值：项目知识不再只存在于老员工的脑袋里，而是变成了可调用的组织记忆。

类型三：自己的历史内容

场景：你是一个知识创作者，过去三年写了200篇文章。

做法：

Bash

/book-to-skill ~/writing/articles/

产物：一个「自我知识 Skill」，能回答「我过去写过哪些和AI知识管理相关的内容」「我的核心观点在不同时期是否有演变」「我还没有系统写过的主题是什么」。

价值：你的历史输出，成为未来输出的原料库。创作不再是每次从零开始，而是从已有观点的基础上延伸。

类型四：技术文档

场景：你每天使用一个复杂的工具，官方文档有1000页。

做法：

Bash

/book-to-skill ~/tools/obsidian-docs/

产物：一个「工具知识 Skill」，能在你使用工具时实时回答「这个功能怎么用」「有没有更好的实现方式」「这个参数的边界条件是什么」。

价值：比搜索文档快十倍，而且能结合你的具体场景给出定制化的建议。

类型五：学习笔记 + 原始材料的融合编译

这是最强大的一种用法，也是最容易被忽视的。

场景：你读了一本书，同时有自己的阅读笔记、相关文章、实践记录。

做法：

Bash

/book-to-skill \
  原书.pdf \
  我的读书笔记.md \
  相关文章1.md \
  我的实践记录.md

产物：不只是书的 Skill，而是「书 + 你的理解 + 相关来源」的融合 Skill。

当你向这个 Skill 提问时，AI 能同时调用书的原始框架、你的个人诠释、相关补充材料，给出一个专属于你的知识视角。

这是任何人都抄不走的东西——因为你的阅读笔记和实践记录，没有人能复制。

七、四层提问法：让 Skill 产生真正的价值

编译是建库，提问是用库。

我观察过很多人使用 book-to-skill 的方式，发现一个共同的模式：他们问的问题，都停留在「检索」层面——「这本书讲了什么」「第三章的主要内容是什么」。

这就像花了大力气建了一个世界级的图书馆，然后只用来查字典。

真正的价值，在于提问的深度。我把提问分成四个层次，每个层次产生的价值，是上一个层次的三到五倍。

Level 1：检索式提问（Retrieval）

本质：确认信息存在，建立基础认知。

适用时机：刚完成编译，验证质量；遗忘了某个框架的具体内容；需要确认书中的精确表述。

示例：

text

/deep-work ch-04
"这一章的核心框架是什么？有哪些命名概念？"

产出：框架清单，词汇表。

注意：这一层不是终点，是起点。如果你的大多数提问停留在这里，说明你在用调用工具做存储工具的工作。

Level 2：应用式提问（Application）

本质：把框架应用到你的真实场景，产生个性化方案。

关键技巧：在问题里加入具体的约束条件——你的职业、你的时间限制、你的具体问题。约束条件越具体，答案越有价值。

示例：

text

/deep-work
"我是一个每天要接待5个以上客户的知识创作者，
 有效的深度工作时间不超过2小时，
 如何用书中的时间阻断法设计一个适合我的每日结构？"

对比：

text

问法A（弱）：「如何用时间阻断法？」
→ AI 复述书中内容，和你的场景无关。
问法B（强）：「我有 2 小时深度工作时间 + 5 个客户要接待，
              如何应用时间阻断法？」
→ AI 基于书中框架 + 你的约束，
  生成一个可以直接执行的个性化方案。

产出：可直接执行的个性化行动方案。

Level 3：挑战式提问（Challenge）

本质：与作者对话，形成独立判断。这是产生原创内容的关键层次。

适用时机：你发现书中的观点和你的经验有矛盾；你所在的场景是书中没有覆盖的特殊情况；你想找到作者观点的边界条件。

示例：

text

/deep-work
"作者说社交媒体对深度工作有根本性的伤害，建议完全戒断。
 但我的IP定位是'公开记录我的系统搭建过程'——
 我必须持续在社交媒体上输出，否则就失去了IP建设的意义。
 这个矛盾如何解决？书中有没有给创作者的例外处理逻辑？"

为什么这种提问最有价值？

因为你的挑战和 AI 的回答，共同构成了一个「阿木木版的深度工作框架」——它不是书的摘要，不是书的翻译，而是你经过独立思考之后，对书中观点的延伸和修正。

这是只有你才能写出来的内容，是你 IP 的护城河。

产出：你自己的观点，原创内容素材。

Level 4：跨 Skill 叠加提问（Cross-Skill Stack）

本质：激活多本书的知识碰撞，产生跨领域洞察。这是整个系统最高价值的使用方式。

三种叠加模式：

对比式（找差异）：

text

@deep-work @atomic-habits
"两本书对'降低启动阻力'的理解有何根本差异？
 深度工作强调仪式感和高门槛，
 原子习惯强调让行为足够容易——
 如何在设计知识阅读系统时协调这两个看似矛盾的原则？"

互补式（找合力）：

text

@thinking-fast-and-slow @superforecasting
"系统2思维如何在实际预测场景中被激活？
 两本书在这个问题上能形成一个完整的操作指南吗？"

对抗式（找边界）：

text

@zero-to-one @good-strategy-bad-strategy
"蒂尔强调避免竞争、创造垄断，
 鲁梅尔特强调识别关键竞争杠杆——
 对于一个早期 IP 创作者，这两个框架的适用边界在哪里？"

为什么 Cross-Skill 提问产生的价值远大于单 Skill？

因为知识的价值，不在于单个框架，而在于框架之间的关系。同一个问题，被不同的框架从不同角度照射，产生的理解比任何单一框架深得多。

这就是「Skill Stack」名字的真正含义——不是一个 Skill，而是叠加的一摞 Skill，每一本书都是一层透镜，叠加的透镜越多，你看到的现实越清晰。

产出：跨领域洞察，这是你 IP 中最稀缺、最难被复制的内容。

八、Query Log：让每次提问都成为资产

现在我们来说一件大多数人不做、但做了之后会后悔没早做的事。

每次你向 Skill 提问，AI 给出了一个对你有价值的回答，你的本能反应是什么？

大多数人：截图存下来，或者直接关掉。

这是在让知识再次走向遗忘。

更聪明的方式，是把每一次有价值的提问，记录进 Query Log 系统。

Query Log 的本质

Query Log 是你和书籍之间对话的永久记录。它解决了一个关键问题：你的思考过程比 AI 的回答更有价值，但思考过程是最容易消失的东西。

AI 的回答可以随时重新生成，但你在那个时刻的「反驳」「补充」「疑问」「应用想法」，不会再出现第二次。那是你当时的认知状态与书的框架发生碰撞的瞬间产物，错过了就消失了。

Query Log 的功能，是捕捉这些瞬间。

Query Log 模板

在你的 vault 的 01-BOOKS/ 下，为每本书建立一个 query-log-[book-name].md 文件：

Markdown

---
book: 深度工作
compiled_date: 2026-06-12
total_queries: 0
---
# Query Log · 深度工作
---
## Query #001
**日期**: 2026-06-12
**提问层次**: L2-Application
**触发情境**:
（我当时在做什么？为什么想到问这个问题？）
**我的问题**:
（完整的提问文本，包括所有约束条件）
**AI 回答摘要**:
（3-5句话，不要全文复制，只记核心）
**我的反应**:
（同意？反驳？补充？这是最重要的部分）
**衍生的洞察**:
（这次对话让我想到了什么新的东西？）
**可以输出为**:
- [ ] 推文：_______________
- [ ] Thread：_______________
- [ ] 文章：_______________
---

Query Log 的三个隐藏价值

价值一：内容矿山

30天的 Query Log，是一个内容金矿。你的每一条「我的反应」，都是一个潜在的推文观点。你的每一条「衍生的洞察」，都是一篇文章的核心论点。你不需要每天坐在那里想「今天写什么」——打开 Query Log，随便翻5分钟，素材多到用不完。

价值二：认知地图

三个月之后，回头看你的 Query Log，你会看到一条隐藏的轨迹——你当时在关注什么问题，你的思考方式如何演变，你的盲区在哪里反复出现。这是任何知识管理系统都无法自动提供的东西：你自己的认知成长记录。

价值三：输出质量保证

当你准备写一篇文章或录一个视频，先翻 Query Log，找到相关的对话记录。你的草稿不是从零开始，而是从「我和这本书的真实对话」开始，基于真实思考，而不是对书的二手复述。

Query Log 的使用仪式

每天固定时间，花 10 分钟做以下三件事：

text

Daily Query Ritual（每日提问仪式）
① 向已编译的书提 1-3 个问题（选择当天工作中真实遇到的问题）
② 把有价值的对话记入 Query Log
③ 标记「可输出为」里最有潜力的那一条

注意：不需要每天都有惊天大洞察。有时候一个 L1 的检索问题，触发了一个意外的思路，这同样值得记录。Query Log 的价值不在于每条都精彩，而在于持续积累之后的复利效应。

九、编译 30 天：你的系统会长成什么样？

我想用数字描述一下，如果你认真执行模块二，30天后你会拥有什么。

假设你每周编译一本书，提问30次，完成30条 Query Log：

第30天的时候，你不只是有了一个知识系统，你还有了一个内容系统——Query Log 里的40多条记录，足以支撑两个月的稳定输出，而且每一条都有来自书中框架的支撑，不是空发议论。

十、如何选择

同样是读《深度工作》，两种方式：

方式A（传统方式）： 读完，划了60处高亮，写了一篇1200字的读书笔记，存进 Obsidian。三个月后，需要和别人讨论「知识工作者如何设计工作结构」，你翻出读书笔记，发现那1200字是对书的复述，没有一句话能直接回答这个具体问题。重新翻书，一小时后，找到了一些相关内容，但不确定是否完整。

方式B（Skill Stack 方式）： 读完，编译成 Skill，做了15条 Query Log，其中三条 L3 挑战式提问产生了你自己的独特观点。三个月后，同样的问题，你向 Skill 提问：「知识创作者如何在需要持续输出的同时，维持深度工作的能力？」AI 在3秒内，基于书中的精确框架，结合你之前的 Query Log 里的个人诠释，给出一个既有书中理论支撑、又有你个人观点的完整回答。

这不是效率的提升，这是一种完全不同的知识工作方式。

区别在哪里？

方式A保存了关于知识的记录。 方式B建立了知识的调用接口。

一个是博物馆，一个是API。

你现在知道，你要建的是哪一个。

附录：模块二完整操作清单

Markdown

## 模块二 · 完整操作清单
### 一、编译准备
- [ ] 完成「可编译性自检清单」：选出 3 本适合编译的书
- [ ] 按优先级排序：最熟悉的书排第一（用于验证质量）
- [ ] 准备好书籍文件（PDF/EPUB）
### 二、book-to-skill 安装与配置
- [ ] 执行安装命令，验证 SKILL.md 和 extract.py 存在
- [ ] 在 Claude Code 会话中运行 /book-to-skill --help 确认可用
### 三、第一次编译
- [ ] 编译第1本书（最熟悉的）
- [ ] 打开 ~/.claude/skills/<slug>/ 查看生成的文件结构
- [ ] 完成四维质量审查：框架完整性 + 路由准确性 + 反幻觉验证 + 密度评估
- [ ] 根据审查结果，修正 SKILL.md 或章节文件
### 四、四层提问练习
- [ ] 对第1本书完成 L1 提问（3个）
- [ ] 对第1本书完成 L2 提问（3个，包含具体约束条件）
- [ ] 对第1本书完成 L3 提问（1-2个，挑战书中观点）
- [ ] 编译第2本书后，完成第一次 L4 跨 Skill 提问
### 五、Query Log 系统建立
- [ ] 在 01-BOOKS/ 下为每本书建立 query-log 文件
- [ ] 使用模板完成前 10 条 Query Log 记录
- [ ] 标记所有「可输出为」选项
- [ ] 从 Query Log 中提取 3 条内容素材，发布出去
### 六、高阶编译（Week 3-4）
- [ ] 尝试编译一个「非书籍」来源（项目文档 / 文章合集）
- [ ] 完成一次「书 + 个人笔记」的融合编译
- [ ] 完成一次三本书的跨 Skill 叠加提问
### 七、Build in Public
- [ ] 发布第一个 Skill 的截图 + 「我为什么选这本书编译」
- [ ] 发布一次质量审查的踩坑记录
- [ ] 发布「30天编译计划」宣言

「知识的墓地里埋满了读过但没有用过的书。每一本书在你翻最后一页的那一刻，都面临同一个命运的选择：被存起来，慢慢遗忘；或者被编译进来，永远可用。

你现在手里有工具了。选择权，在你。」

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

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

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

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

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

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