夯爆了！这个开源神器把任意书籍转成 Skill，轻松打造专业的随身顾问

阅读全文

⭐⭐⭐ Spring Boot 项目实战	⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》	《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》	《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》	《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》	《Java 面试题 + Java 学习指南》

摘要: 原创出处 http://www.iocoder.cn/Fight/book-to-skill-advisor/ 「芋道源码」欢迎转载，保留摘要，谢谢！

🙂🙂🙂关注微信公众号：【芋道源码】有福利：

RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表

RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址

您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。

新的源码解析文章实时收到通知。每周更新一篇左右。

认真的源码交流微信群。

我硬盘里躺着大概四五十本技术书 PDF，买的时候雄心壮志，三个月后连第七章讲什么都说不上来，挺浪费的。

有个开源项目想把这件事接过去，叫 book-to-skill。它干的事说出来很简单，把技术书 PDF 丢进去，吐出来一个结构化的 Agent Skill，写代码的时候直接问它。仓库现在三万两千多 Star。

book-to-skill 仓库首页，Star 32.6k

项目的能力总览

它到底解决什么问题

它不是一个 PDF 阅读器，也不是笔记工具。准确说它是一个编译管线，把一本书或者一堆文档吃进去，吐出来一个完整的 Skill。

生成的东西放在 ~/.claude/skills/<slug>/ 下面。关键在于它不只是全文摘录，而是把书重新拆了一遍，核心框架、章节索引、术语表、模式库、速查表各归各位。

拆解出来的功能面

这套结构的精妙之处在按需加载。章节文件你不问就不读，不占 token。只有你敲 /book-slug ch05 的时候，它才去读那一个文件。

对比一下常规操作就更清楚了。把一本 400 页的 PDF 直接扔进上下文窗口，20 万 token 一次性烧完，而且每一个问题、每一轮对话都要重新烧一遍。book-to-skill 只在编译那一次烧，之后每次查询只加载核心那份，大概 4000 token。

基于 Spring Boot + MyBatis Plus + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能

项目地址：https://github.com/YunaiV/ruoyi-vue-pro

视频教程：https://doc.iocoder.cn/video/

格式和提取器，它自己会挑

支持的格式基本覆盖了常见文档，PDF、EPUB、DOCX、TXT、Markdown、reStructuredText、AsciiDoc、HTML、RTF、MOBI、AZW、AZW3 都在。纯文本格式不需要额外依赖。

技术书与纯文本走两条提取路径

我觉得这里做得最聪明的一点是它不傻跑。处理 PDF 之前它会先问一句，这本书是技术书还是纯文本，然后按答案选提取器。

技术书有代码、表格、公式，走 Docling 这条线，速度大约是每页 1.5 秒，但 markdown 表格和代码块能完整保住。纯文本走 pdftotext，基本是秒出。pdftotext 没装就自动退到 pypdf，再不行用 pdfminer.six。

有人在一台 Mac 上拿一本 103 页的技术书做过基准测试，结果是这样。pdftotext 用了 0.1 秒、2.7 万 token，但表格和代码块都是 0，结构化内容全丢了。Docling 用了 164 秒、2.8 万 token，多花 1.2%，表格和代码块分别保住了 48 个和 36 个。

所以选哪个取决于书长什么样。这个先问再跑的设计，比那些一条路走到底的工具聪明。

基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能

项目地址：https://github.com/YunaiV/yudao-cloud

视频教程：https://doc.iocoder.cn/video/

它给的是框架，不是摘要

它不会给你总结「这本书讲了分布式系统的设计原则」这种话。它提取的是作者花几年时间搭起来的框架，命名的模式、精确的表述、反模式清单。

作者定了七条质量原则，挑三条最说明问题的。密度优先于完整，一份 1000 token 的摘要比一份 10000 token 的摘录强。实践者口吻，输出是「用 X 当 Y」，不是「本书解释了 X」。永远不复制原文，始终合成、总结、从源头提取信号。

翻译成人话就是，它产出的东西像你认真读过这本书之后自己做的笔记，而不是把书拆碎重新排列。

输入不限于一本书

名字叫 book-to-skill，但输入可以是任何结构化文字。

把整个 docs/ 文件夹揉成一个 skill，写代码时直接问，架构决策记录、运维手册、新人指南就从「偶尔翻翻」的文件夹变成了随时能调用的东西。品牌手册也能转，视觉规范、文案语调、组件原则变成一个团队共享的 skill。论文集群加上自己的笔记合并成一个 skill，新论文来了还能往里加。RFC、API 合约、合规文档这些反复引用又永远记不住的东西，同样适合。

判断标准很简单，只要你反复打开同一个文档、每次都想着要是记住就好了，它就适合做成 skill。

增量更新的合并逻辑

生成出来的 skill 不是死的。买了新版 PDF、读了新论文、写了新笔记，都能直接并进去，最后一条命令是这么写的。

/book-to-skill ~/articles/new-paper.pdf ~/.claude/skills/project-knowledge

指向已有的 skill 目录，它会识别出来，把新内容合并进去。这样一来 skill 就成了一个随时间增长的知识库，而不是一次性快照。

一次编译，之后按需读

这条管线总共十步，简化成四个阶段看就清楚了。

提取阶段，你敲 /book-to-skill your-book.pdf，它先问你技术书还是纯文本，然后选提取器。不同格式对应不同工具，EPUB 用 ebooklib，DOCX 用 python-docx。

分析阶段，模型读提取出来的文本，识别书名、作者、章节结构和核心主题。章节标题是标准格式的话就自动分段，不是标准格式也能处理，只是章节索引需要手动指定。

生成阶段是核心。它对每一章做深度分析，生成 800 到 1200 token 的章节摘要，技术书还会附上代码示例和参考表格，同时生成术语表、模式库和速查表。

交付阶段把整个 skill 写进你 Agent 的 skills 目录。Claude Code 是 ~/.claude/skills/<slug>/，Copilot CLI 是 ~/.copilot/skills/<slug>/，另外还有支持同一套开放标准的 Amp、Hermes Agent 和 OpenClaw。

整个架构图

四个阶段的流水线

有人拿几本真实的书跑过一遍，用的模型是 Claude Sonnet 4.5。244 页的 Think Python 处理出 11.9 万 token、识别到 19 个章节，花了 0.88 美元。371 页的 Working Backwards 是 17.5 万 token、10 个章节、0.96 美元。501 页的 Pro Git 是 22.9 万 token、1.23 美元，章节自动检测失败但转换成功。Moby-Dick 的 EPUB 是 30.1 万 token、1.42 美元，章节检测同样需要手动处理。

一本技术书的转换成本大概五到十块钱，一次性的，之后每次调用只花极少的 token。

跟灌 PDF 和 RAG 比，差在哪

作者在 FAQ 里正面回答过这个问题，逻辑我直接引一遍。

跟直接灌 PDF 比。一本 400 页的 PDF 扔进上下文约 20 万 token，每个问题、每一轮对话都要重复处理这 20 万。book-to-skill 编译一次花五块左右，之后每次查询只加载 5000 左右，一本 500 页的 Pro Git 算下来 token 占用差 51 倍。

还有一个更隐蔽的问题。模型在接近满的上下文里检索具体事实时会丢精度，这个现象叫 lost in the middle。1000 个 token 的精炼章节和 20 万个 token 的原始文本，哪个答得更准，不用测试也能猜个大概。

RAG 与编译式 Skill 的差别

跟 RAG 比。RAG 是在查询那一刻工作的，切块、嵌入、找相似向量、塞进 prompt，它擅长的是「找到提到 X 的那一段」。book-to-skill 是在编译那一刻工作的，一次深度分析提取出作者的框架、命名、使用条件和反模式，它回答的是「这个作者搭的十二个框架分别是什么，什么时候用哪个」。

所以两者是互补的。几十本书、浅层搜索，用 RAG。一两本书、要深度应用，用 skill。

作者还做了一个叫 Discovery Loop Tax 的基准测试，专门量回答一个具体问题要烧掉多少 token，比较三种做法，直接灌 PDF、让 Agent 自己去翻 PDF、以及用 book-to-skill。

Discovery Loop Tax 的对比数据

三本书的结果很一致。book-to-skill 比直接灌 PDF 省 24 到 51 倍 token，比让 Agent 自己翻书省 2.4 到 15.6 倍。章节越大，优势越明显。

装和用，几条命令的事

安装不需要 pip，也不需要 npm，直接 clone 就行。用 Claude Code 的话是这样。

git clone https://github.com/virgiliojr94/book-to-skill.git ~/.claude/skills/book-to-skill

也可以更省事，直接在 Claude Code 会话里敲这一句。

Install book-to-skill: https://raw.githubusercontent.com/virgiliojr94/book-to-skill/master/SKILL.md

GitHub Copilot CLI 换一个目录，装完记得刷新一次。

git clone https://github.com/virgiliojr94/book-to-skill.git ~/.copilot/skills/book-to-skill
# 然后在 copilot 会话里
/skills reload
/skills info book-to-skill

其他宿主只换路径，命令一样。

# Amp 与跨 Agent 宿主
git clone https://github.com/virgiliojr94/book-to-skill.git ~/.agents/skills/book-to-skill
# Hermes Agent
git clone https://github.com/virgiliojr94/book-to-skill.git "${HERMES_HOME:-$HOME/.hermes}/skills/book-to-skill"
# OpenClaw
git clone https://github.com/virgiliojr94/book-to-skill.git "${OPENCLAW_STATE_DIR:-$HOME/.openclaw}/skills/book-to-skill"

依赖方面它不强制装任何东西。跑之前可以用一条命令看当前环境里哪些提取器已经装好、哪些需要补。

python3 scripts/extract.py --check

纯文本格式零依赖。PDF 需要 pdftotext 或者 docling，EPUB 需要 ebooklib，缺什么它会直接告诉你装哪个，不用自己去猜。

使用更简单，一条命令处理一本书，slug 默认从文件名生成。

# 处理一本书，slug 自动从文件名生成
/book-to-skill ~/Downloads/designing-data-intensive-applications.pdf
# 指定 slug
/book-to-skill ~/books/clean-code.epub clean-code

处理完之后，按需求不同有三种问法。

/designing-data-intensive-apps            # 加载核心心智模型
/designing-data-intensive-apps replication   # 查具体主题
/designing-data-intensive-apps ch05       # 深入第五章

Copilot CLI 用户注意，创建完 skill 之后要跑一次 /skills reload 刷新。Claude Code 和 Amp 下次启动会自动识别。

这里有几个实际限制要讲清楚。章节自动检测依赖标准格式，比如 Chapter N 或者第N章，如果你的书用罗马数字或者纯标题分段，自动检测会失败。书照样能处理，但章节索引需要你自己手动指定。刚才那几本书里，Pro Git 和 Moby-Dick 就是这种情况，都转换成功了，只是要多做一步。

最后说我的判断

它解决的其实是一个老问题，技术知识读了用不上。

不搞花活，也不卖概念，就是把一本书编译成一个 Agent Skill，然后你写代码的时候随时能问。跟 RAG 相比它换了一个思路，把成本从「每次查询都要付」挪到了「编译时付一次」。

用下来一个礼拜，把一本技术书和两份使用手册都转成了 skill。每次在 Claude Code 里敲 /ddia ch05 的时候，确实觉得它补上了「读书」和「用书」之间那个缺口。

当然，它也不是什么都能接。书的章节结构太乱就要手动指定，转换本身要花几块钱，而且 skill 的产出质量最终还是取决于书本身值不值得读。有这方面需求的话，可以拿一本自己真正在读的书试一次。

项目地址是 https://github.com/virgiliojr94/book-to-skill