别再把整本 PDF 塞给 AI:这个开源项目,把书变成了可调用的 Skill

一本几百页的技术书，你可能认真读过，做过标记，甚至还写了摘要。

但三个月后真正遇到问题时，往往只记得“书里好像讲过”，却不记得在哪一章，更不知道如何把那段知识立刻用到当前工作中。

开源项目 book-to-skill 想解决的，正是这个问题。

它不是又一个“PDF 摘要器”，而是把一本技术书、一组文档，甚至一整个资料目录，转换成能被 AI 智能体按需读取的结构化 Skill。原本躺在硬盘里的“静态知识”，就此变成能在工作流中随时调用的“活能力”。

为什么不直接把整本书丢给 AI？

最简单的做法，是把 PDF 上传到对话窗口，然后提问。但这种方式有三个明显问题。

首先，大量无关内容会占用上下文。你只想问“数据复制应该怎么选”，模型却可能需要先在几百页内容中定位答案。

其次，每次新对话都可能重复搜索、回看目录和重新理解结构。项目把这种额外成本称为“Discovery Loop Tax”，也就是反复发现知识的代价。

最后，简单摘要容易丢掉技术细节。几页笔记看起来更短，却未必保留决策条件、反例、权衡关系和章节上下文。

book-to-skill 的思路是：把结构化成本支付一次，之后每次只读与问题有关的部分。

它生成的不是“一篇摘要”

转换完成后，项目会生成一套可被智能体识别的知识目录。其中包括：

●SKILL.md：放置核心心智模型和章节索引；

●chapters/：把每章编译成独立文件，只在需要时加载；

●glossary.md：整理关键术语及章节引用；

●patterns.md：沉淀技术、算法、模式与反模式；

●cheatsheet.md：把决策规则、权衡关系和快速查询信息集中起来。

这个设计的关键，是“渐进式加载”。智能体平时只需知道这个 Skill 有哪些能力；当你追问某一个主题时，它再打开对应章节。书没有被压成一张信息密度过低的“小纸条”，细节也不必每次全部进入上下文。

根据项目公开的测量，回答一个定向问题时，整本上下文方式需要约 11.9 万到 25.6 万 token，而 book-to-skill 通过核心文件加一个相关章节，约为 5000 token，相当于减少约 24–51 倍。这是项目方法下的测试结果，实际效果仍会受书籍结构和提问方式影响。

三步就能把资料变成 Skill

它的基本使用方式很直接。先将项目克隆到智能体的 Skills 目录：

然后把书籍、文件夹或文件通配符交给它：

生成后，就可以像调用其他 Skill 一样询问：

项目支持 PDF、EPUB、DOCX、TXT、Markdown、HTML、RTF、MOBI 等多种格式，也能把新资料追加、合并到已有 Skill 中。对于普通文字型 PDF，可以使用更快的 pdftotext；对代码、表格和公式较多的技术 PDF，则更适合用 Docling 模式保留结构。

它的真正用途，其实超过“读书”

“book-to-skill”这个名字容易让人以为它只适合技术书。但它的输入本质上可以是任何结构化文本。

例如，团队可以把架构决策记录、运维手册和入职指南合成一个内部知识 Skill；研究人员可以把一组论文、报告和个人笔记合并；开发者可以把 RFC、API 合同和合规规范变成编码时可直接查询的决策层；品牌团队也可以将语气、设计原则和组件规则整理成统一的执行标准。

一个简单的判断标准是：如果某份文档被你反复打开，而你又希望自己早就能“记住它”，它就可能适合被转换成 Skill。

使用前，还要注意三件事

第一，转换质量取决于原始文档和解析方式。如果技术 PDF 中有大量表格与代码，用普通文本模式可能丢失结构。

第二，它是知识组织工具，不是事实正确性的绝对保证。重要技术决策仍应回到原文、版本和实际环境中验证。

第三，要尊重版权。项目本身不附带书籍内容，并建议用户只处理自己合法拥有或有权使用的材料。对受版权保护的书籍，生成的 Skill 更适合作为个人笔记私下使用，不要随意公开分发。

写在最后

AI 时代真正稀缺的，已经不只是“能不能找到知识”，而是“能不能在恰当的时候，以足够低的成本调用正确的知识”。

book-to-skill 最有意思的地方，不是它能够“帮 AI 读书”，而是它试图重新定义文档的形态：文档不再只是等待人类翻阅的文件，而是可以被智能体识别、检索并执行的能力模块。

当一本书真正进入你的工作流，它才不只是“读过”，而是开始被使用。

项目地址： 

https://github.com/virgiliojr94/book-to-skill