book-to-skill:一本书，不应该只被读一次
一只阿木木约 17 分钟Module 4｜book-to-skill
一本书，不应该只被读一次
你花了十小时读完一本书。然后它在书架上待了三个月，再也没被打开过。这一讲，我们来解决这件事。
写在前面
我有一个习惯，大概坚持了两年。
每读完一本书，我会在最后一页写上读完的日期。
然后把它放回书架。
后来有一天，我需要写一篇关于决策框架的东西，我清楚地记得有本书里有一个非常好的模型——但我想不起来那个模型叫什么，在哪一章，具体说了什么。
我翻出那本书，找到那一章，重新读了一遍。
二十分钟。
就为了把我三个月前已经读过的内容，重新装回脑子里。
后来我开始用 AI。
我把 PDF 粘贴给它，让它帮我找那个模型。
有时候能找到，有时候 AI 很自信地描述了一个根本不在那本书里的"框架"。
偶尔它找到了，但给我的是原文摘录，不是一个"可以用于决策"的工具。
这两种方法，解决的都是"检索"问题。
但我真正需要解决的，是调用问题。
不是找到这本书说了什么，而是在我工作的时候，这本书里的思维可以直接参与进来。
book-to-skill，就是为了解决这个差别而存在的。
4.1 先理解问题：你真正损失的是什么
在我们讲工具之前，先说清楚我们在解决什么问题。
因为很多人以为 book-to-skill 是"更好的读书笔记工具"。
不是的。
它要解决的，比"读书笔记"大得多。
一本书的三种命运
命运一：读完忘掉
你读的时候觉得很有启发，合上书，三个月后记得的只有大概印象。
想用的时候，想不起来。
命运二：做了笔记但不用
你做了详细的读书笔记，很认真，很完整。
然后笔记存在某个地方，你打开的频率和那本书一样——几乎为零。
命运三：每次要用都重新读
这是最"勤奋"的方式。
但它有一个隐性成本，很多人没算过。
算一笔账
假设你有十本核心领域的书，每本 300 页。
每本书的 PDF 大约是 200,000 个 token。
你在做一个项目，需要参考三本书。
如果每次都把 PDF 粘贴给 AI，一次对话你就要付 600,000 token 的费用。
而且你不只用一次，你用十次。
6,000,000 token。
按 Claude Sonnet 的价格，大约是几十美元。
每次都是这个成本，永远如此。
book-to-skill 的方式是：提前做一次结构提取，大约每本书 1 美元。
提取完之后，每次调用只加载和你问题相关的部分，大约是 5,000-6,000 token。
是完整 PDF 的 1/40。
但 token 成本，其实是最小的那个损失。
真正的损失是：你每次都在重新读，没有在积累。
每次重新粘贴 PDF，AI 都是第一次接触这本书。
它不知道你上次从这本书里得到了什么，不知道你最看重的是哪个框架，不知道你已经把某个模型用到过三个项目里。
没有积累，没有复合，每次都是零。
book-to-skill 之后，这本书的结构就住在你的系统里了。
你每次调用，AI 带着的是已经为你提炼好的知识工具，不是原始文本。
4.2 什么是 Skill：再深挖一次
Module 1 我们讲过 Skill 和摘要的区别。
这一讲，我要带你看得更具体——
一个 Skill 文件夹里，到底有什么。
Skill 的五个文件
运行完 book-to-skill 之后，你会在 ~/.claude/skills/<slug>/ 里看到这些文件：
text
~/.claude/skills/your-book/
├── SKILL.md ← 核心心智模型（约 4,000 tokens）
├── chapters/
│ ├── ch01-xxx.md ← 按需加载的章节摘要
│ ├── ch02-xxx.md
│ └── ...
├── glossary.md ← 术语索引
├── patterns.md ← 模式与反模式库
└── cheatsheet.md ← 决策速查表
我来逐一解释每个文件是什么，以及它解决什么问题。
SKILL.md——核心心智模型
这是整个 Skill 最重要的文件。
它约 4,000 tokens，每次调用 Skill 时必定加载。
里面是这本书最核心的思维框架——不是内容摘要，是结构化的决策工具。
好的 SKILL.md 读起来像一份"操作手册"，而不是"读后感"。
chapters/*.md——按需加载的章节
这些文件平时不加载。
当你问一个和某章内容相关的问题，AI 会加载那一章的 .md 文件，给你精确的答案。
你问"第三章的核心论点是什么"，它加载 ch03-xxx.md，不加载其他的。
这个懒加载机制，是整个 token 效率的关键。
glossary.md——术语索引
这本书里的专有名词、作者创造的概念，都在这里。
你在工作时遇到一个熟悉又说不清楚的词，问一句，精确定义秒出。
patterns.md——模式与反模式库
书里提到的"这样做有效"和"这样做会出问题"，分两列整理。
这是你在做决策时最直接的参考——我现在的情况，符合哪个有效模式？是否正在踩某个反模式？
cheatsheet.md——决策速查表
最实用的一个文件。
"当你面临 X 类型的问题，调用这个框架"——格式就是这么直接。
为什么不把所有内容都放在一个文件里？
这个问题问得好。
答案是：不同的内容有不同的调用频率和调用场景。
SKILL.md 几乎每次都要加载——它是框架总图。
chapters/ 里的文件只在你深入某个话题时加载——它是放大镜。
cheatsheet.md 在你快速决策时调用——它是速查工具。
把所有内容堆在一个文件里，要么太大（每次都要加载），要么太精简（深入不了）。
分文件，按需加载，是一个工程效率的设计决策，不是随意的文件组织。
4.3 安装 book-to-skill
确认前提条件
book-to-skill 依赖 Claude Code，所以先确认：
Bash
claude --version
# 应该看到版本号，比如 0.2.x
如果报错，说明 Claude Code 没有安装或没有在 PATH 里。回到 Module 2 的 2.2 节检查。
安装
book-to-skill 是一套 Claude Code Skills，存放在全局 Skills 目录：
Bash
# 确保全局 Skills 目录存在
mkdir -p ~/.claude/skills# 克隆 book-to-skill
cd ~/.claude/skills
git clone https://github.com/virgiliojr94/book-to-skill.git book-to-skill
注意路径：~/.claude/skills/，是你用户主目录下的 .claude，不是 Vault 里的 .claude。
这两个位置是不同的：
text
~/.claude/skills/ ← 全局 Skills，所有项目都能调用
~/knowledge/vault/.claude/ ← Vault 级配置，只在这个 Vault 里生效
book-to-skill 生成的每一本书的 Skill，都会存放在 ~/.claude/skills/<slug>/ 里。全局可用，不绑定任何一个 Vault。
验证安装
Bash
cd ~/knowledge/vault
claude
在 Claude Code 里输入：
text
/book-to-skill help
看到 book-to-skill 的使用说明，安装成功。
如果没有响应，检查：
Bash
ls ~/.claude/skills/
# 应该能看到 book-to-skill 文件夹
处理 PDF 的前提
book-to-skill 支持多种格式：PDF、EPUB、DOCX、HTML、Markdown、纯文本、RTF、MOBI/AZW（MOBI 和 AZW 格式需要 Calibre）。
如果你主要用 PDF，大多数情况直接可以处理。
如果 PDF 是扫描版（图片 PDF），需要先用 OCR 工具处理成可选择文本的版本。
一个简单的判断方法：
用 PDF 阅读器打开，能用鼠标选中文字吗？
能选 → 可以直接用。 不能选 → 需要先 OCR。
4.4 第一次运行：从选书开始
选哪本书来做第一次实验
这个选择比你想象的重要。
不要选你最喜欢的书。
要选你最熟悉的书。
原因很简单：
只有你读过、而且读得比较透的书，你才能判断 book-to-skill 提取的质量。
如果你选一本没读过的，你不知道哪些提取是准确的，哪些是有损的。
第一次运行的目标，是校准你对这个工具的认知，不是处理新书。
运行命令
基本格式：
Bash
/book-to-skill <路径> <slug名称>
举个例子：
Bash
cd ~/knowledge/vault
claude# 在 Claude Code 里输入：
/book-to-skill ~/books/designing-data-intensive-applications.pdf ddia
slug 是这本书的简称，用小写字母和连字符，不要空格。
以后调用这本书的 Skill，就用这个 slug：
text
/ddia 第五章的复制策略是什么？
它在运行时会做什么
你看到 Claude Code 开始工作之后，可以观察它的输出。
大致流程是：
text
Step 0：解析文件，识别格式
Step 1：提取原始文本
Step 2：识别文档结构（章节、小节）
Step 3：提取框架和心智模型
Step 4：提取可操作原则
Step 5：提取术语和定义
Step 6：识别模式和反模式
Step 7：生成 SKILL.md
Step 8：生成各章节摘要
Step 9：生成 glossary、patterns、cheatsheet
根据书的长度，整个过程大约需要 5-15 分钟。
在它运行的时候，不要打断。
可以去泡杯茶。
运行完成后，先做一件事
不要立刻问 AI 问题。
先去看生成的文件：
Bash
ls ~/.claude/skills/ddia/
然后打开 SKILL.md，从头到尾读一遍。
带着这个问题读：
如果我是第一次接触这个话题的人，读完这个文件，我能建立这本书的核心思维框架吗？
这是检验 SKILL.md 质量最直接的方式。
4.5 解剖生成结果：逐文件质量审计
这一步很多人跳过。
不要跳过。
你对这个 Skill 的质量有多了解，决定了你之后能有多信任它。
我来教你怎么逐文件做质量审计。
审计 SKILL.md
打开文件，带着以下问题检查：
问题一：框架名称是否正确？
书里有命名的框架，比如"CAP 定理""MVP""飞轮效应"，名称是否准确？
有时 AI 会用描述性语言替代框架名，或者改写了名称。
问题二：核心论点是否准确？
这本书最想说的那一件事，SKILL.md 抓到了吗？
问题三：有没有重要内容缺失？
你认为这本书最精华的部分，在 SKILL.md 里是否存在？
问题四：有没有"拔高"或"降低"
提取的原则是否和书里的原意一致？有没有过度解读，或者把细节当成了核心？
审计 cheatsheet.md
这个文件应该是最可以直接用的。
打开它，看每一条"遇到 X，调用 Y"的描述。
问自己：
如果我在工作中遇到这个场景，拿这条作为决策参考，会有帮助吗？
如果你看完之后感觉"嗯，能用"——质量合格。
如果你看完之后感觉"太抽象了，不知道怎么用"——说明提取不够深入，后面我们会讲怎么处理。
审计 patterns.md
这个文件通常是区分"普通读书笔记"和"可执行 Skill"最明显的地方。
好的 patterns.md 长这样：
Markdown
## 有效模式### 渐进式复杂度引入
在系统设计中，从单机方案开始，验证可行后再引入分布式复杂度。
适用：新系统设计决策
信号：你的团队还在讨论是否需要分布式时
## 反模式
### 过早优化分布式
在单机无法满足需求之前就引入分布式架构。
常见原因：对未来流量的过度预期
代价：复杂度成倍增加，调试困难度指数级上升
不好的 patterns.md 长这样：
Markdown
## 模式
- 数据系统应该可靠
- 数据系统应该可扩展
- 数据系统应该可维护
第二种完全没有操作性，和"书应该有用"这句话一样废。
如果你的 patterns.md 是第二种风格，记下来——这是后面 4.7 节要处理的。
审计 chapters/*.md
抽取两三章，和原书对照：
关键论点是否都在？ 有没有用原书里的例子支撑论点？ 有没有把某章的次要内容当成主要提炼？
记录你的审计结果
打开 inbox/ 里创建一个文件：skill-audit-<书名>.md
Markdown
# Skill 质量审计：<书名>## SKILL.md
- ✅ 准确的部分：
- ⚠️ 有损的部分：
- ❌ 缺失的重要内容：
## cheatsheet.md
- ✅ 可以直接用的条目：
- ⚠️ 太抽象需要改进的：
## patterns.md
- ✅ 有操作性的：
- ❌ 没有操作性的：
## 总体判断
这个 Skill 现在的可信度：[高 / 中 / 低]
原因：
这不是给 AI 看的记录，是你自己对这个 Skill 的"置信度档案"。
以后你调用这个 Skill，会知道哪些部分可以信任，哪些要多核实。
4.6 四种操作模式：根据场景选择
book-to-skill 不只有一种用法。
根据你的情况，有四种不同的操作模式。
模式一：完整转换（默认）
什么时候用：
你有一本书，想把它完整处理成一个可用的 Skill。
怎么运行：
Bash
/book-to-skill ~/books/your-book.pdf your-slug
输出：
完整的 Skill 文件夹，包含 SKILL.md、chapters/、glossary、patterns、cheatsheet。
适合：
你确认这本书值得花时间和成本做完整提取。通常是你已经读过、或者你的核心领域的重要书籍。
模式二：仅分析（analyze）
什么时候用：
你不确定这本书值不值得做完整提取，想先看看能提取出什么。
怎么运行：
Bash
/book-to-skill ~/books/your-book.pdf your-slug analyze
或者在 Claude Code 里说：
text
用 analyze 模式处理这本书，只提取，不生成 Skill 文件
输出：
一份结构化的提取报告——发现了哪些框架、原则、技术——但不生成任何 .md 文件。
适合：
你拿到一本推荐书，不确定是否值得完整处理，先看看质量再决定。
一个我常用的技巧：
先用 analyze 模式，看报告。
如果报告里的内容让你感觉"这个思维我以前没有过"，再做完整转换。
如果报告里的内容你基本都知道，这本书可能不值得花 1 美元生成 Skill。
模式三：从分析生成（from-analysis）
什么时候用：
你已经有了这本书的分析笔记（可能是你自己做的，或者上次 analyze 模式的结果），想基于这些笔记生成 Skill，而不是重新解析书。
怎么运行：
Bash
/book-to-skill my-analysis-notes.md your-slug from-analysis
适合：
你有一本书的详细读书笔记，但原书 PDF 提取质量不好（比如是扫描版）。
用你自己的笔记生成 Skill，通常质量会比直接解析扫描 PDF 更好。
模式四：更新合并（update）
什么时候用：
你有了这本书后续版本、相关文章，或者你自己的补充注释，想把新内容合并进已有的 Skill。
怎么运行：
Bash
/book-to-skill ~/books/new-related-content.pdf existing-slug update
它会做什么：
提取新来源的内容，然后和现有 Skill 比较：
新内容支持现有观点 → 加入相关章节作为支撑 新内容补充了缺失部分 → 添加到对应位置 新内容和现有内容矛盾 → 在 SKILL.md 里标注矛盾，两个版本都保留
适合：
同一个主题，你有多本书或多个来源。
比如你用《设计数据密集型应用》生成了一个 Skill，之后你又读了几篇相关论文——可以用 update 模式把论文的洞见合并进去，而不是创建新的 Skill。
四种模式的选择决策树
text
你有一本新书
↓
这本书你已经了解内容吗？
├── 是 → 直接完整转换
└── 否 → 先用 analyze 模式
↓
analyze 报告有新洞见吗？
├── 有 → 做完整转换
└── 没有 → 不值得转换，
考虑直接 wiki-ingest
作为普通文章处理
4.7 Skill 质量不满意？你能做什么
有时候 book-to-skill 生成的结果，让你觉得不够好。
这很正常。
因为每本书的写法不一样，排版不一样，PDF 质量不一样，提取质量也会有差异。
我来说三种常见的问题，和对应的处理方法。
问题一：框架提取太浅，没有操作性
症状：
SKILL.md 里的原则，读起来像是书的目录，不像可以用来决策的工具。
原因：
书的写法比较概念性，少量实际案例，AI 没有足够的操作性语言可以提取。
处理方法：
不要试图让 AI 重新生成——源头数据就是这样。
更好的做法：
Bash
# 在 Claude Code 里：
请阅读 ~/.claude/skills/your-slug/SKILL.md，
结合你对这本书的理解，
把每一个框架扩展成一个可以用来做决策的"if-then"规则。
格式：如果 [场景]，那么 [应用这个框架时] 应该考虑 [具体操作]。
把结果写入 ~/.claude/skills/your-slug/cheatsheet-enhanced.md
你在 Skill 文件夹里添加了一个手工增强版的 cheatsheet，AI 生成的原版还在，你有了一个更实用的版本。
问题二：某些章节摘要质量差
症状：
大部分章节摘要都不错，但有一两章明显提取得很浅或有错误。
原因：
那几章可能排版比较复杂（大量图表、代码、公式），或者 PDF 那几页质量不好。
处理方法：
针对那几章，用 from-analysis 模式修复：
找到你自己对那几章的笔记，或者重新读一遍，写一份简单的笔记 用你的笔记替换那几章的 .md文件
Bash
# 直接编辑那一章的文件
# 把 AI 生成的内容替换成你自己的笔记
vim ~/.claude/skills/your-slug/chapters/ch05-xxx.md
这个 Skill 是你的，你有权利编辑任何一个文件。
手工修复是完全正当的。
问题三：生成的 Skill 和你的 CLAUDE.md 格式不兼容
症状：
book-to-skill 生成的 Skill 文件的结构，和你 wiki/ 里页面的格式规范不一样。
这是个真实的问题。
book-to-skill 有自己的输出格式，不一定和你在 CLAUDE.md 里定义的 wiki 页面格式一致。
处理方法：
两个方案，选一个：
方案 A：不要把 Skill 文件放进 wiki/
Skill 文件放在 ~/.claude/skills/，这是全局的 Skills 目录，不是你的知识库。
调用 Skill 是"和一个专家对话"，把 Skill 的输出洞见摄入 wiki/ 才是"把知识沉淀进知识库"。
这是最推荐的方式。两者分工明确，不要混在一起。
方案 B：在 CLAUDE.md 里为 Skill 内容添加一个格式规范
Markdown
## Skill 内容摄入规则当从 Skill 中提取洞见进入 wiki/ 时，
将 Skill 的框架内容转换为 wiki/concepts/ 格式，
将 Skill 里的 patterns 内容转换为 wiki/cases/ 格式，
不要直接复制 Skill 文件。
4.8 扩展用法：不只是书
这是很多人没有意识到的用法。
book-to-skill 的设计，从来不只是为书准备的。
任何你反复回来查阅的知识来源，都值得用 book-to-skill 处理。
内部文档
场景：
你加入了一个新团队，有一堆内部文档——架构决策记录（ADR）、系统设计文档、运营手册。
你需要经常查这些，但每次找信息都很慢。
做法：
Bash
/book-to-skill ~/work/docs/ team-docs
把整个文档文件夹处理成一个 Skill。
之后：
text
/team-docs 我们的认证系统是怎么设计的？
/team-docs 部署到生产环境的流程是什么？
秒出，不需要翻 Confluence。
个人知识文档
场景：
你写过一些很长的研究文档、读书笔记、或者方法论总结，放着很少翻。
做法：
Bash
/book-to-skill ~/notes/my-product-methodology.md my-methods
把你自己的方法论处理成 Skill。
这样它就可以被 AI 在你工作时实时调用，不只是存在某个文件夹里。
同一主题的多个来源
场景：
你读了三本关于决策的书，想把它们合并成一个"决策框架 Skill"。
做法：
Bash
# 先处理第一本
/book-to-skill ~/books/decision-book-1.pdf decision-frameworks# 用 update 模式合并第二本
/book-to-skill ~/books/decision-book-2.pdf decision-frameworks update
# 再合并第三本
/book-to-skill ~/books/decision-book-3.pdf decision-frameworks update
三本书的洞见合并成一个 Skill。
调用的时候，AI 从综合视角回答，不是单本书的视角。
研究论文集
场景：
你在研究某个领域，收集了 10-15 篇论文。
做法：
Bash
# 把所有论文放进一个文件夹
mkdir ~/papers/recommendation-systems/
# 把论文 PDF 都放进去# 一次性处理整个文件夹
/book-to-skill ~/papers/recommendation-systems/ recsys-research
所有论文的核心发现，提炼成一个统一的 Skill，并自动标注相互支持和矛盾的观点。
4.9 深度实践：A/B 对比实验
这是本讲最重要的实践环节。
不做这个实验，你不会真正相信 book-to-skill 带来的差别。
准备工作
选一本你熟悉的书，运行 book-to-skill 处理完（如果你在 4.4 节已经做了，直接用那个）。
然后准备一个真实的工作场景——不是"测试"，是你最近真实遇到的问题。
A 组：不用 Skill，直接问
打开 Claude Code，不加载任何 Skill，直接问：
text
我在做 [你的真实场景]，面临 [具体问题]。
你觉得应该怎么思考这个问题？
把回答完整保存下来。
B 组：用 Skill 问
打开新的 Claude Code 会话（不要用刚才的），先加载 Skill：
text
/your-slug
然后用完全相同的问题：
text
我在做 [你的真实场景]，面临 [具体问题]。
根据这本书的框架，应该怎么思考这个问题？
把回答完整保存下来。
对比这三个维度
拿着 A 组和 B 组的回答，逐一比较：
维度一：具体性
哪个回答更具体、更有针对性？
A 组通常是"建议你考虑以下因素……"这种通用框架。
B 组应该是"根据这本书里的 X 原则，你的情况属于 Y 类型，对应的决策路径是……"
维度二：框架的准确性
B 组引用的框架，你能认出来是这本书里的内容吗？
如果你认不出来，可能 Skill 的提取质量有问题，需要回到 4.5 节重新审计。
维度三：可直接使用性
哪个回答你可以拿去直接用，不需要大幅改写或翻译？
记录你的观察
Markdown
## A/B 实验记录：[书名] + [场景]### 场景描述
[你的真实问题是什么]
### A 组（无 Skill）回答的特点
- 优势：
- 局限：
### B 组（有 Skill）回答的特点
- 优势：
- 局限：
### 关键差别
[用一句话描述两者最核心的区别]
### 结论
[这本书的 Skill，值不值得在这类场景下调用？]
把这份记录存入 inbox/。
等你做完 Module 8 的真实项目，回来看——你会发现自己的观察变了。
4.10 何时不需要 book-to-skill
我想在讲结尾说一件不太常见的话——
不是所有内容都值得用 book-to-skill 处理。
不值得的情况
你只读一次的内容。
一篇时事新闻，你读了，了解了，不会再回来查。
用 wiki-ingest 就够了，不需要 book-to-skill。
你不确定是否有价值的书。
先用 analyze 模式看看，再决定。
不要因为"这是本名书"就把它处理成 Skill——名气不等于对你有用。
已经有很好的官方文档的工具或框架。
比如你想把某个框架的官方文档处理成 Skill。
如果那个框架本身就有很好的在线文档，而且你可以实时访问，不需要 book-to-skill。
Skill 的价值在于"把知识变成 AI 可以随时调用的形式"——如果 AI 本来就能很好地回答你关于这个框架的问题，你不需要额外建 Skill。
值得的情况
你会反复查阅的专业书。
你的核心领域里，那几本你"每年都要回来翻一遍"的书——这些值得。
有大量专有术语和框架的书。
AI 对这类书的"自然掌握度"通常不高，Skill 带来的提升最明显。
你想把多个相关来源整合成一个视角的情况。
三本相关的书，处理成一个综合 Skill，比三本书分别存在 wiki 里，调用效率高得多。
一个判断标准
如果三个月后我遇到工作问题，会不会回来查这本书？
会 → 值得 book-to-skill。 不确定 → 先 analyze 模式。 不会 → wiki-ingest 就够了。
模块作业
作业一：完成第一个 Skill + 质量审计（必做）
选一本你读过的书，运行 book-to-skill 完整转换。
按照 4.5 节的方法，逐文件做质量审计，填写审计记录。
写下这个 Skill 的"置信度"：哪些部分你信任，哪些部分要谨慎对待。
作业二：A/B 对比实验（必做）
用一个真实的工作场景，完成 A 组（无 Skill）和 B 组（有 Skill）的对比实验。
把对比结果记录在 inbox/ 里，用 4.9 节的模板。
重要： 用真实问题，不要用"帮我总结这本书"这种测试题。
只有真实问题，才能真正体验到 Skill 带来的差别。
作业三：找一个非书籍的 book-to-skill 用法（选做）
回顾你的工作或学习场景，找出一个"我经常要重复查阅，但每次查都很慢"的知识来源。
把它处理成 Skill，试用一次。
记录：和直接查原来的来源相比，有什么区别？
本讲总结
text
这一讲你做了什么：□ 理解了 book-to-skill 解决的不是"读书笔记"问题
而是"知识调用"问题
□ 安装并验证了 book-to-skill
□ 完成了第一次完整转换
□ 逐文件做了质量审计
□ 完成了 A/B 对比实验
这一讲你应该建立的认知：
Skill ≠ 更好的摘要。
Skill = 让书里的思维成为工作时的同行者。
token 成本是最小的考量。
真正的损失，是每次都在重新读，从来没有在积累。
不是所有书都值得 book-to-skill。
判断标准只有一个：
三个月后遇到问题，你会不会回来查它？
下一讲，我们讲 claude-obsidian——让知识库自我生长。
你在这一讲建立的第一个 Skill，下一讲会真正开始被用起来。
你会第一次体验到：一本书里的框架，在你处理一篇完全不相关的文章时，主动和它建立了连接。
那个时刻，你会理解什么叫"知识复合增长"。
Module 4 完 预计阅读时间：35-40 分钟 动手时间（安装 + 首次运行 + 质量审计 + A/B 实验）：90-120 分钟 认知破点：Skill 不是摘要，是知识调用工具；真正的损失不是 token 成本，是每次重新读、从未积累