把技术书变成 AI 助手随身携带的知识库:这个开源工具做到了

花几百块买一本技术书，认真读了一遍，三个月后想查里面某个细节——你记得有，但想不起来在哪一章。于是你要么翻 PDF 翻半天，要么问聊天机器人，结果它要么胡编，要么说没读过这本书。

这个痛点太常见了，以至于很多人默认「书读完就算了」。但有一个新开源项目，打算把书变成你的 AI 助手随身携带的知识库，而且是按需加载、不会胡编的那种。它叫 book-to-skill，意思简单直接：把书变成「技能」。

book-to-skill GitHub 首页

买书 — 读书 — 忘书，中间断了一环

先聊聊为什么会有这个需求。

一个人认真读一本技术书，投入的是几十个小时。但技术书的信息密度太高，大脑几乎不可能全部记住。真正能被长期使用的，往往只有你反复用到的那 20%。剩下的 80%——那些你当时觉得有用、但当下没用到的地方——会慢慢沉底，直到某天你真的需要时，却连它在哪都翻不出来。

更现实的是，很多人看书本就不是为了「背下来」，而是为了「以后查得到」。可问题在于：查的过程太痛了。

假设你把一本书读完了，想找一个概念或一个做法，常见的几种路径各有各的坑：

• 直接搜 PDF。 你得到的是「第 132 页」「第 178 页」这样的页码列表。你得一页页翻，还不一定翻得到答案。
• 让 AI 助手聊聊这本书。 如果助手没被喂过这本书的内容，它要么根据训练记忆胡编，要么诚实地说「我没有这本书的内容」。前者更危险——你很难分辨它哪句是真的。
• 读书时记笔记。 这是最「正确」却也最难以坚持的做法。多数人的笔记最后变成一份几百行的文档，跟书脱节，自己都不想再打开。

book-to-skill 把这三条路的缺点一次性绕开：它把书本身变成 AI 助手能直接引用的结构化知识，按需加载，基于真实内容回答。 装好之后，你输入一个指令，助手就去读对应的章节，用书里的真东西回答你。

它生成的东西长什么样

跑一遍 book-to-skill 你的书.pdf，它会自动在 AI 助手的技能目录里生成一整套文件：

注意最后一个设计，也是它跟「把书交给 AI」最本质的区别：章节文件是按需加载的。 它们不会一次性全塞进上下文档住 AI 的注意力，而是等你问到相关主题时，才把那一章加载进来。

为什么它不会胡编：按需读取，不是压缩记忆

这是所有「让 AI 用书」的方案里最关键的问题——幻觉。book-to-skill 的解法值得单独拿出来讲。

最偷懒的做法，是把整本书打包成一个大 Prompt 塞给模型。问题很明显：书那么厚，塞进去又贵又慢，上下文直接爆掉，模型反而抓不住重点。

另一种常见做法，是让模型「总结一下这本书」，把它压缩成一个几千字的摘要。摘要确实省 token，但代价是信息被极度稀释——很多细节被删掉了，你问到一个没被写进摘要的细节，它依然不知道。

book-to-skill 走的是第三条路：不压缩细节，而是保持结构、按需读取。

它把书拆成「骨架 + 肌肉」两层。骨架是 SKILL.md，只放核心心智模型和章节索引，让 AI 知道「这本书大概讲了什么、哪一章讲什么主题」。肌肉是每个章节独立的小文件，正文内容都在这层。当 AI 需要回答某个具体问题时，SKILL.md 帮它定位到正确的章节文件，它再去读那一章，用真正的原文作答。

这种「先索引、再取用」的设计，本质上跟人脑检索很像——你不是把整本书背下来，而是知道去哪一章找，用到才翻。好处是双重的：

• 回答基于真实内容，不是模型凭记忆硬编，幻觉被大大压制。
• 按需加载，不会让无关章节长期占着上下文。

官方给了一个很有说服力的量化数据：回答一个问题，book-to-skill 比把整本书直接塞进上下文，省 24 到 51 倍的 token。 这个数字是在真实书籍上测出来的。省 token 意味着更便宜、更快，也意味着你可以放心给 AI 用很厚的书而不怕烧钱。

它是怎么工作的：确定性提取 + 规范驱动生成

从实现上讲，这个项目分两半：

前半是确定性提取器（Python）。 它先把各种格式的文档转成干净文本和元数据。支持的格式很全：PDF、EPUB、DOCX、Markdown、HTML、RTF、MOBI 都能吃。这一步是确定性的——它不做语义理解，就是把文档里的文字和结构准确抽出来，所以结果稳定、可复现，不依赖模型发挥。

后半是生成器（由你的 AI 助手执行）。 它遵循 SKILL.md 里的规范，把提取出的文本整理成结构化的技能包：提取框架、决策规则、反模式，按章节拆分成独立文件。这一半用到了模型的理解力，但它是「照着规范干活」，不是自由发挥。

「确定性提取 + 规范驱动生成」的组合，让整个过程既稳定又灵活。提取环节不靠模型，保证不会抽错；生成环节靠模型，但被规范约束住，保证输出结构一致。

如果你只是想做预处理、不消耗模型，它还提供了 analyze-only（只分析）、generate-from-analysis（基于分析生成）等拆分模式，方便你分步把关。

支持的编程助手生态

一个好设计能不能用起来，很大程度上取决于能接进哪些工具。book-to-skill 遵循的是开放的标准——Agent Skills。这意味着只要支持这个标准的编程助手，都能直接读它生成的 SKILL.md。

官方明确列出的兼容环境包括：

• Claude Code —— 技能装进 ~/.claude/skills/
• GitHub Copilot CLI —— 装进 ~/.copilot/skills/
• Amp / 跨 Agent 环境 —— 装进 ~/.agents/skills/

也就是说，你在一个环境里把书转成技能包，换一个兼容助手，技能包能跟着走。这也是「开放标准」相比「厂商私有格式」的好处——你沉淀下来的知识资产不绑死在某一款工具上。

怎么上手用

推荐用「AI 技能」方式安装：

bash
pip install -e .
book-to-skill install

装完它会自动把技能文件复制到上面说的那几个目录。转换一本书，一行命令：

bash
book-to-skill path\to\book.pdf
book-to-skill "path\to\docs\*.epub" my-skill-slug

常用命令：

bash
book-to-skill help      # 查看帮助
book-to-skill list      # 列出已生成的技能
book-to-skill readme    # 生成使用说明
book-to-skill ui        # 打开图形界面
book-to-skill --check   # 检查环境依赖

一个小提示：这个库的提取器会按格式依次尝试可用的工具，取第一个能用的。纯文本、Markdown、reStructuredText、AsciiDoc 这些不需要额外依赖；PDF/EPUB 这类可能需要额外的解析库，装之前可以用 book-to-skill --check 先看看环境齐不齐。第一次跑还可能会自动弹出 GUI（如果带了 UI 包），之后保持安静。

「书」只是名字，输入远不止书

最后这层可能是它真正值钱的地方——它叫 book，但输入可以是任何结构化的文档。

• 内部文档 —— ADR（架构决策记录）、runbook（操作手册）、新人上手指南。团队积累的运维知识、决策记录，过去都是「要查就翻 wiki」，现在可以变成 AI 随时能引用的技能。
• 品牌与设计系统 —— 语音规范、组件原则。给做品牌内容的 AI 配上一套「该怎么说、不该怎么说」的规范。
• 研究资料 —— 论文 + 笔记，新资料落地时持续更新，让 AI 能引用到最新结论。
• 规范与标准 —— RFC、API 契约、合规文档。这些往往是频繁要查、又绝对不能编错的硬资料。

作者的判断标准很实用：如果你会频繁重新打开一份文档，好到希望自己背下来，那它就是候选。 换句话说，它把「文档」升级成了「AI 能随时引用的人才」——你不需要重读，AI 替你记住并帮你取用。

适合谁用，不适合谁用

适合：

• 经常要在技术书、内部文档、规范里查资料，又用编程助手的开发者。
• 用 Claude Code、GitHub Copilot CLI、Amp 的人——它直接装进这几个生态，配置一次长期受益。
• 想把「读过的书」沉淀成资产，而不是读完就忘的人。

不适合：

• 只想找个 PDF 阅读器的人——它不干这个，它是给 AI 助手做知识包的。
• 完全不用 Agent / 编程助手的人——没有助手，技能包无从加载。
• 期待它把书「一字不差背下来」的人——它保的是结构和关键内容，重在可检索、可引用，不是逐字复制。

一点诚实的提醒

这个项目还很年轻，1k 左右的 star，属于早期实用工具。它解决的问题很真实——「读过的书怎么变成 AI 能用的知识」——「按需加载章节 + 省几十倍 token」这个设计思路在技术上也站得住脚。但它能发挥多大价值，取决于两件事：一是你日常是否真的重度使用编程助手，二是你愿不愿意花一次功夫，把常用的书和文档转成技能包。它属于典型的「一次配置、长期受益」型工具——前期投入一点，后面每次查资料都能省回来。对重度 AI 使用者来说，这值得放进待办清单。

🚀 项目信息

• 项目名：book-to-skill
• 语言：Python
• 协议：MIT
• Star：约 1.0k（截至 2026-08-14）
• 定位：把技术书/文档转成 AI 助手按需加载的技能包

GitHub 地址： github.com/Leutenegger/book-to-skill