ReadAny：把向量库塞进电子书阅读器之后，它解决了什么、又留下了什么
AI-powered cross-platform e-book reader with semantic search, RAG chat, local vector store, notes, TTS, and WebDAV sync.
秒懂
- 它是什么？
- ReadAny 是一个本地优先的跨平台电子书阅读器，用本地向量库和混合检索把「读书」和「问书」接在一起。判断它的关键不在功能表，而在于你是否愿意为 RAG 链路承担索引与模型配置的代价。
- 适合谁用？
- 适合已经在用 Ollama 或自备 API Key、并且把「读完之后能问、能按语义找回」当成真实需求的人。不适合只想安静翻页的读者，因为本地向量库和嵌入模型这条链路会带来索引时间、存储占用和模型选择问题，而这些问题在纯阅读场景里没有任何回报。
- 能商用吗？
- 请先确认。这个仓库使用的许可证不在我们自动归类的范围内，商用前请阅读仓库里的 LICENSE 文件。
- 还在维护吗？
- 在维护。仓库最近一次提交在 5 天前。
- 用什么语言写的？
- 主要是 TypeScript（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
它针对的不是「读不完」，而是「读完就忘」
README 开头用三个问句点题：为什么读完就忘、笔记为什么散落各处、为什么只能按关键词搜索。这三个问题指向的是同一件事，阅读产生的内容没有被组织成可再次调用的结构。传统阅读器把书当成文件，翻完就结束；ReadAny 把书当成可检索的语料，阅读过程中产生的高亮、笔记和位置信息都进入同一个可查询的集合。
目标用户因此比较明确。一类是需要反复回查的技术书、学术著作读者，他们的问题往往是「我记得某本书里讲过这个概念，但想不起原话」。另一类是把阅读当成知识输入的人，README 把导出格式列为 Markdown、HTML、JSON、Obsidian、Notion 五种，明显是冲着第二大脑类工作流去的。反过来，如果你读书就是从头翻到尾、不做笔记、不回头查，这个项目的核心功能对你基本没有增量。
混合检索才是它的技术重心，向量只是其中一半
README 对检索的描述是「Hybrid vector retrieval + BM25 search」，也就是向量召回和 BM25 关键词召回并行。这个组合值得单独说，因为纯向量检索在书名、人名、专有名词上表现经常不如关键词匹配，而纯关键词又处理不了「那个讲注意力机制但没用这个词的段落」。两路召回并存，等于承认了单一检索方式在书籍语料上都不够用。
RAG 问答的上下文来源也被限定了范围。README 说的是「Ask questions about the current book or selected passages」，并且强调 AI 知道你的位置、选中文本和高亮。这说明检索范围不是整个书库，而是当前书或当前选区。这个设计降低了上下文长度压力，也让回答更容易定位到出处。代价是跨书提问（比如「我读过的三本书里对同一个概念的说法有什么差异」）在文档描述中没有体现。
向量库是本地存储，README 用「Local vector store」和「fully offline capable」来描述隐私属性。技术栈里同时出现 sqlite 和 vector-search 两个 topic，可以推断向量数据落在本地 SQLite 一侧，但仓库说明里没有给出具体的向量索引实现或存储格式，这一点无法从现有材料确认。
桌面端与移动端是两套技术路线，不是同一份构建
从仓库结构和 topic 看，ReadAny 同时使用了 Tauri 和 Expo/React Native。Tauri 面向 macOS、Windows、Linux 桌面，Expo 面向 iOS 和 Android。README 的下载表也印证了这一点：桌面端提供 .dmg、.msi、.AppImage，移动端走 TestFlight 和 .apk。
这意味着两端的运行环境差异不小。桌面端可以依赖系统 WebView 和本地文件系统，移动端要处理沙箱、后台播放和存储配额。README 在 TTS 一节里专门列出「Background Playback」，这是移动端才需要强调的能力。如果你打算同时用两端，需要预期到功能对齐可能有时间差，README 顶部把移动端标注为 v2.0 更新内容，本身就说明移动端是后补上来的。
WebDAV 同步是跨端的连接点，README 提到自动后台同步和「Smart merge for concurrent edits」。并发编辑的合并策略在文档里只有这一句，没有说明冲突判定的粒度是整本书、单条笔记还是字段级，这是采用前值得实测的地方。
跑起来需要几步，以及那几步里藏着的成本
最省事的路径是直接装包。macOS 上 README 给出的命令是：
brew tap codedogQBY/readany brew install --cask readany
Windows 和 Linux 走 Release 页面的 .msi 与 .AppImage。移动端 iOS 通过 TestFlight 加入，Android 下载 .apk。
装完之后 README 的「3 Steps to Get Started」是：导入书籍、双击开始阅读、配置 AI（标注为可选）。这里有个容易被忽略的取舍：AI 配置是可选的，但语义搜索和 RAG 问答都依赖嵌入模型，不配置就等于退回普通阅读器。README 列出的模型提供方包括 OpenAI、Claude、Gemini、Ollama、DeepSeek 和自定义兼容接口，Ollama 这一项是本地推理的入口，也是「本地优先」这个说法能成立的前提。
TTS 侧提供 Edge TTS、Browser TTS、DashScope（通义千问）三种引擎，翻译侧是 AI 翻译或 DeepL，README 称支持 19 种语言。这些能力都需要外部服务或本地模型，纯离线状态下能用到什么程度，文档没有逐项说明。
格式支持是十种，但 TXT 和 UMD 走了转换这条路
README 列出的格式是 EPUB、PDF、MOBI、AZW、AZW3、FB2、FBZ、CBZ、TXT、UMD。其中有一句关键说明：TXT 和 UMD 是先转成 EPUB 再导入的，转换之后才能参与阅读、笔记、搜索和同步。
这个设计有实际后果。转换是一次性的，原始排版信息在转换过程中会丢失，TXT 本来就没有排版可言，但 UMD 作为一类有自身结构的格式，转换后的还原度取决于转换器实现，而仓库说明里没有提供这方面的细节。另外，转换后的 EPUB 成为书库里的实际对象，意味着你看到的不是原文件。
PDF 也在支持列表里，但 README 没有说明 PDF 是否参与语义检索。按常理推断，扫描版 PDF 没有文本层就无法嵌入，文本型 PDF 的切分质量也远不如 EPUB 的章节结构。这是文档留白比较大的一处，如果你的书库以 PDF 为主，建议先用一本代表性文件验证检索效果再决定是否迁移。
Skills System 是它相对独特的地方，也是最不透明的地方
在 README 的对比表里，Skills System 是 ReadAny 相对 Calibre、KOReader、Apple Books 唯一独占的一行。文档列出的内置技能有 summarizer、concept explainer、character tracker，并支持创建自定义技能。
从命名看，这些技能是针对特定阅读任务的预设提示词与检索策略组合。summarizer 处理章节摘要，concept explainer 解释概念，character tracker 追踪人物，最后一项明显是为小说阅读准备的。自定义技能的存在说明作者预期用户会按自己的阅读类型去扩展。
但仓库说明没有给出技能的定义格式、存放位置或调用方式。这意味着自定义技能目前更像是一个需要读源码才能用起来的功能，而不是文档化的扩展点。如果你选型时把可扩展性看得很重，这一块需要先翻代码确认，不能只看功能表上的对勾。
和 Calibre、KOReader 的真实差别在哪
README 的对比表把 Calibre 和 KOReader 列为参照。这个选择本身说明了定位：Calibre 是书库管理和格式转换工具，KOReader 是面向电子墨水设备的阅读器，两者都不做检索增强。
真正的差别在数据流。Calibre 的核心是元数据管理和格式转换，书进来、转格式、推到设备，流程到阅读开始就结束了。ReadAny 把流程延伸到阅读之后，高亮、笔记、位置信息进入本地索引，再通过嵌入模型变成可检索的向量。KOReader 在设备端做了大量阅读体验优化，TTS 在对比表里被标为 Limited，也不涉及任何语义层。
代价也很清楚。Calibre 装完就能用，ReadAny 要先用嵌入模型把书索引一遍。书库越大，首次索引的时间成本和本地存储占用越高，而这两项在 README 里都没有给出量级参考。选 ReadAny 不是选一个更好的阅读器，是选一条更长的工具链。
维护节奏与许可证需要你自己确认的两件事
发布记录显示 v1.3.4 在 2026 年 6 月、v1.3.5 在 7 月、v1.3.6 在 8 月，大致是每月一版的节奏，仓库最近一次推送在 2026 年 9 月，处于活跃状态。这个节奏对个人项目来说算稳定，但也意味着版本之间可能存在需要跟进的变更，尤其是涉及本地向量库结构或同步格式的时候。
许可证是更需要注意的一点。GitHub 侧显示为 NOASSERTION，这表示平台无法自动识别仓库 LICENSE 文件属于哪种标准许可证，而不是说它没有许可证。这个状态常见于自定义许可证或对标准文本做过修改的情况。对打算在公司环境里部署、或者想把代码集成进自己产品的人来说，这一步不能跳过，需要直接打开仓库根目录的 LICENSE 文件阅读条款。这里不构成法律意见，只是指出 NOASSERTION 这个标记本身就在提示你去看原文。
升级成本方面，README 提到 WebDAV 同步和「Smart merge」，如果本地向量库的存储结构在版本间发生变化，重新索引的代价会随书库规模放大。这一点文档没有承诺向后兼容，属于需要自己留意的运维面。
编辑结论
适合已经在用 Ollama 或自备 API Key、并且把「读完之后能问、能按语义找回」当成真实需求的人。不适合只想安静翻页的读者，因为本地向量库和嵌入模型这条链路会带来索引时间、存储占用和模型选择问题，而这些问题在纯阅读场景里没有任何回报。上手前先确认三件事：你的设备能否跑得动本地嵌入模型，你的书库格式是否落在 EPUB、PDF、MOBI、AZW、AZW3、FB2、FBZ、CBZ、TXT、UMD 这十种之内，以及仓库 LICENSE 文件里的实际条款是什么，因为 GitHub 侧显示为 NOASSERTION，这意味着平台无法自动识别许可证类型，采用前必须自己打开该文件确认。
社区笔记