夜雨聆风我的电脑里有很多 PDF。
有些是买过的技术书，有些是收藏的论文、产品手册和行业报告。下载时总觉得以后一定会认真读，真正遇到问题时，却往往只记得“那本书里好像讲过”，至于在哪一章、作者为什么这么判断，早就想不起来了。
把 PDF 直接交给 AI，似乎可以解决这个问题。
但用过几次就会发现：换会话或换 Agent 时，往往还要重新上传或重新指定资料；书很长时，即使能放进上下文，也会占据大量空间；想问一个具体问题，模型还可能先消耗不少 Token 重建目录和结构。资料没有真正进入日常工作流，下一次使用时，许多整理工作又要重复。
最近 GitHub 上有一个项目突然火了，名字叫 book-to-skill。
它在 2026 年 5 月才创建，截至 8 月 6 日已经获得约 1.69 万个 Star。它想做的事情非常直接：
把一本书、一个文档目录，或者一组资料，转换成 AI Agent 可以按需调用的 Skill。
不是再生成一份几千字的“全书摘要”，而是让这本书以后真正参与工作。
它生成的不是摘要，而是一套知识结构
普通的 PDF 摘要通常只有一个文件。
前几章讲得很详细，越往后越简略；作者原本层层推进的论证，被压缩成几个看起来都正确、实际很难使用的结论。下次遇到具体问题，AI 仍然不知道该回到哪一章寻找依据。
book-to-skill 会先提取文档结构，再生成一套完整的 Skill：
your-book-skill/
├── SKILL.md
├── chapters/
│ ├── ch01-core-concepts.md
│ ├── ch02-practical-patterns.md
│ └── ...
├── glossary.md
├── patterns.md
└── cheatsheet.md
其中，SKILL.md 保存全书最重要的框架、使用方式和章节索引；chapters 按章节保存核心观点、方法、反例和关联内容；另外还有术语表、模式清单与速查表。
最大的区别在于：这些文件不会每次全部进入上下文。
当你问到“复制为什么会带来一致性问题”时，Agent 可以先通过索引定位相关章节，再加载对应内容；当你只需要一个概念定义时，也不必重新阅读整本书。
这更像是给 AI 做了一套经过整理的专业书架，而不是每次提问都把一箱书倒在它面前。
和“直接把 PDF 发给 AI”有什么不同？
第一，整理成本只需要支付一次。
传统做法中，每次换会话、换 Agent，模型都可能重新扫描目录、检索章节、理解结构。book-to-skill 把这部分工作提前完成，以后主要读取与问题相关的文件。
项目官方使用真实书籍做过测试：在其测试方式下，按需加载 Skill 回答一个目标问题时，进入上下文的内容约为 5,000 个 Token；相比把整本书直接放进上下文，少约 24 到 51 倍。这个数字不是对所有模型和所有书籍的普遍保证，也不代表总成本一定下降相同比例，但它说明了一件事：先把资料结构化，再按需读取，通常比反复吞全文更节省上下文。
第二，它保存的不只是知识点，还有使用知识的路径。
生成结果可以包含作者提出的框架、决策规则、反例、常见误区、代码示例和章节之间的关联。Agent 不只是搜索到一句相似的话，还能知道这条结论属于什么场景、与哪些章节相互制约。
第三，它可以继续更新。
你可以把新论文、新版本文档或自己的笔记合并进已有 Skill，而不是每次重新制作一套知识库。这对经常变化的产品文档、团队规范和研究资料尤其有用。
安装并不复杂，但有一个地方很容易搞错
book-to-skill 有两种安装方式，它们不是一回事。
如果你希望在 Agent 里使用 /book-to-skill 命令，需要把完整仓库安装到宿主的 Skills 目录。以 Claude Code 为例：
git clone https://github.com/virgiliojr94/book-to-skill.git \
~/.claude/skills/book-to-skill
然后在新的会话中运行：
/book-to-skill ~/Documents/my-book.pdf
GitHub Copilot CLI 和 Amp 等兼容 Agent Skills 规范的宿主，也可以使用各自的 Skills 目录。当前官方文档明确给出了 Claude Code、GitHub Copilot CLI 和 Amp 的安装方式。
另一种方式是：
pip install "book-to-skill[pdf,epub,docx]"
这只会安装独立的文本提取工具，适合脚本处理 PDF、EPUB 和 DOCX；它不会自动注册 /book-to-skill Skill。很多人看到 pip install 成功，就以为已经能在 Agent 中调用，问题就出在这里。
按照项目的 Agent Skill 流程，转换时会先让你选择技术型或文本型资料，再提取文本、分析文档结构、估算生成所需的 Token，并询问你希望应用作者的框架、借助其思维模型思考，还是快速查阅特定章节。完整 Skill 生成后，还应按照项目的 Step 9.5 运行一次建议性安全扫描，检查可疑指令和不可见字符。
这一步很重要。原始文档可能带有隐藏文本或提示词注入；生成结果又会被 Agent 调用，因此除了检查内容是否完整，也应该审查生成 Skill 的安全提示。
哪些资料最值得转换？
我认为它最适合下面四类内容：
经常查询的技术书和公开规范； 自己积累的课程笔记、研究材料和方法论； 团队内部的产品文档、运行手册和架构决策； 需要持续补充的新论文、行业资料与项目文档。
反过来，如果一份 PDF 只需要读一次，或者你只想知道它讲了什么，普通摘要就足够了。没有必要为了十页资料专门生成一套 Skill。
它也有几个不能忽略的限制
首先，本地提取不等于全程离线。
文档解析和文件整理可以在本机进行，但生成章节总结和回答问题的是宿主 Agent 使用的模型。如果你连接的是云端模型，相关文本仍可能发送给模型服务商，必须遵守对应的数据条款。机密资料不能因为“工具是开源的”就放心上传。
其次，它不能消灭幻觉。
结构化资料能让 Agent 更容易找到依据、减少只凭模型记忆作答的情况，但总结过程本身仍可能遗漏或理解错误。重要结论仍然要回到原文核对，尤其是法律、医疗、财务和安全相关内容。
第三，复杂文档需要额外的解析工具。
普通文本型 PDF 可以使用 pdftotext、pypdf 等工具；包含大量代码、表格和公式的技术书，更适合使用 Docling。MOBI、AZW 等格式则需要 Calibre。一本书越长，首次生成耗费的时间和模型 Token 也越多。
最后，还有版权边界。
你可以处理自己合法拥有的书籍和资料，用于个人学习，但不应该把受版权保护的整本书转换后公开分发。项目只提供转换工具，不提供任何书籍内容；怎么使用以及是否有权分享，责任仍然在使用者自己。
真正有价值的，不是让 AI “读过”，而是让知识留下来
过去我们谈 AI 阅读，关注的是它一次能塞进多少上下文。
但上下文再长，也不等于知识真正进入了工作流。今天上传、今天提问、明天重新开始，这种使用方式更像临时借阅，而不是积累。
book-to-skill 最吸引我的地方，是它改变了资料的存在方式：一本躺在硬盘里的书，可以变成 Agent 随时调用的框架、规则和检查清单；一组散落的项目文档，可以变成团队共同使用的经验；新资料到来后，还可以继续合并，而不是推倒重来。
它当然不能替你读书，更不能保证每个答案都正确。
但如果 AI Agent 已经开始参与你的学习和工作，那么，与其不断给它喂重复的资料，不如先把真正重要的知识，变成一项可以长期复用的能力。
如果让你先选一份资料转换成 Skill，你会选择哪一本书？