ReadAny：把 RAG 塞進電子書閱讀器的本地優先路線
AI-powered cross-platform e-book reader with semantic search, RAG chat, local vector store, notes, TTS, and WebDAV sync.
秒懂
- 它是什麼？
- ReadAny 用 TypeScript 加上 Tauri 與 Expo 做跨平台閱讀器，把向量檢索、RAG 問答與筆記綁在同一份本地書庫上。它的價值不在功能清單長度，而在於它把 AI 檢索的資料邊界畫在使用者自己的裝置裡。
- 適合誰用？
- 如果你讀的書以 EPUB 為主、願意自己接上 OpenAI 或 Ollama 這類模型端點，而且在意書庫與筆記不出本機，ReadAny 值得先裝桌面版試一輪：從 GitHub Releases 下載 .dmg 或 .msi，或走 brew tap codedogQBY/readany 加 brew install --cask readany。若你需要 DRM 內容、需要成熟的 PDF 學術標註流程，或無法接受 NOASSERTION 這種未定授權狀態，就先不要把它當成主要工具。
- 可以商用嗎？
- 請先確認。這個儲存庫使用的授權不在我們自動分類的範圍內，商用前請閱讀儲存庫中的 LICENSE 檔案。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 5 天前。
- 用什麼語言寫的？
- 主要是 TypeScript（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它想解決的是「讀完就忘」而不是「沒書可讀」
電子書閱讀器這個品類早就飽和了。Calibre 管書庫，KOReader 管排版與跨裝置閱讀，Apple Books 管生態系內的順手。ReadAny 沒有打算在這些維度上競爭，它的 README 開頭直接把問題寫成三個問句：為什麼讀完就忘、為什麼筆記四散、為什麼只能靠關鍵字搜尋。這三個問句對應的是同一件事，讀者累積的內容沒有變成可查詢的資產。
目標使用者輪廓因此相當明確：手上有一批 EPUB 或 PDF、會做畫線與筆記、並且願意花時間設定模型端點的人。它對應的是知識工作者的個人書庫，不是給一般消費者隨開即用的閱讀 App。README 的比較表把 AI Chat、語意搜尋、本地向量庫三欄全部標成 ReadAny 獨有，這個對比方式本身說明了專案的自我定位：檢索能力是主軸，閱讀體驗是載體。
反過來說，如果你的需求只是把書打開、翻頁、調字級，ReadAny 的 AI 設定流程反而是多餘的前置成本。它不試圖當所有人的第一支閱讀器。
混合檢索是核心機制，本地向量庫是它的前提
README 對檢索的描述是「Hybrid vector retrieval + BM25 search」，也就是向量檢索與 BM25 關鍵字檢索並行。這個組合的用意不難推斷：純向量檢索在專有名詞、人名、書中自創術語上經常失準，BM25 正好補上這塊；純關鍵字檢索則抓不到語意相近但用詞不同的段落。兩者並行是 RAG 系統裡常見的做法，ReadAny 把它寫進功能列表，代表這是預設路徑而非外掛。
RAG 問答的上下文來源在 README 裡寫得比多數專案清楚：AI 知道你的閱讀位置、選取的文字與既有的畫線。這是一個具體的設計選擇。多數閱讀器問答只把整本書切塊丟進檢索，回答與你當下讀到哪裡無關；ReadAny 把位置與選取範圍一起餵進 prompt，回答會傾向貼著你正在看的段落。代價是 prompt 組裝邏輯更複雜，而且檢索結果的品質會直接受你的畫線習慣影響，不畫線的使用者拿到的上下文會薄很多。
向量庫放在本地是整個架構的支點。README 反覆強調 local embeddings 與 local vector store，並把「Local vector store, fully offline capable」列為與雲端方案的差異。離線可用的前提是你採用本地嵌入模型，這通常意味著接 Ollama；若改用 OpenAI 或 Claude 的雲端嵌入，書庫內容仍然會離開本機。README 把「Keep knowledge private」與「Use your preferred model」並列，但這兩者在雲端供應商路徑下是有張力的，專案並沒有把這個張力講開。
Tauri 加 Expo 的雙軌前端，以及它帶來的取捨
從 repository 結構與 topics 可以看出前端分成兩條線：桌面端走 Tauri，行動端走 Expo 與 React Native，主語言是 TypeScript，本地資料層用 SQLite。這個組合在 2026 年不算罕見，但它決定了很多使用體驗的邊界。
Tauri 的桌面端打包體積比 Electron 小，這是選擇它的常見理由，但代價是各平台的 WebView 行為差異要自己處理。行動端用 Expo 則意味著 iOS 與 Android 共用一套 React Native 程式碼，README 的 v2.0 更新說明行動版是後來才補上的，且 iOS 目前走 TestFlight 而非 App Store，Android 直接發 .apk。TestFlight 與側載 APK 這兩種發佈方式，對一般使用者來說門檻明顯高於商店安裝，也代表專案現階段沒有走完整的上架流程。
桌面與行動共用同一套書庫格式與同步機制，這讓 WebDAV 同步成為必要的黏著層。README 提到 auto sync 與 conflict resolution，寫的是「Smart merge for concurrent edits」。這是整個專案裡最需要保守看待的一句話：並行編輯的合併策略在筆記類應用裡很容易出錯，而 README 沒有說明合併的粒度是段落、整則筆記還是整份檔案。跨裝置同時畫線與寫筆記的使用者，應該自己驗證合併後有沒有內容遺失。
實際啟動：從安裝到接上模型
安裝路徑 README 寫得很直接。macOS 可以用 Homebrew：先 brew tap codedogQBY/readany，再 brew install --cask readany。其他平台直接到 GitHub Releases 取對應檔案，macOS 是 .dmg（分 Apple Silicon 與 Intel），Windows 是 .msi，Linux 是 .AppImage，Android 是 .apk，iOS 則需要加入 TestFlight。
啟動流程 README 拆成三步：把檔案拖進書庫、雙擊開書、設定 AI。第三步標註為 optional，這個標註是誠實的，不設定模型端點時它仍然是一支可用的閱讀器，只是沒有問答與語意搜尋。
模型端點支援 OpenAI、Claude、Gemini、Ollama、DeepSeek，以及自訂的相容供應商。要讓「本地優先」這個說法成立，你得選 Ollama 這條路，因為其餘四家都是雲端服務。README 沒有提供具體的設定檔鍵名或環境變數，設定是在應用內的 Settings 完成，因此實際的欄位名稱與格式需要以應用版本為準，這篇文章無法從現有材料確認。
TTS 有三種引擎：Edge TTS、Browser TTS 與 DashScope（通義千問）。前兩者不需要額外金鑰，DashScope 需要。翻譯功能支援 AI 翻譯或 DeepL，涵蓋 19 種語言。格式方面支援 EPUB、PDF、MOBI、AZW、AZW3、FB2、FBZ、CBZ、TXT、UMD，其中 TXT 與 UMD 是匯入時轉成 EPUB 再處理，這個轉換步驟會影響原始排版，README 有明講。
Skills 系統是這個專案最不明確的一塊
README 在功能列表裡提到 Skills System：內建 summarizer、concept explainer、character tracker 等技能，並可建立自訂技能。比較表也把它列為與 Calibre、KOReader、Apple Books 的差異點。
問題在於 README 沒有說明技能是怎麼定義的。是一個 prompt 模板？是一段可執行的腳本？能不能存取書庫以外的資料？有沒有權限邊界？這些問題決定了自訂技能的實際能力與風險。如果技能只是預先寫好的 prompt，那它的價值主要在於省下使用者自己打提示詞的功夫；如果技能能執行程式碼或呼叫外部端點，那它就需要一套權限模型，而 README 沒有提到任何相關設計。
在材料不足的情況下，合理的做法是把它當成便利性功能而非擴充平台。想要靠它做自動化流程的人，應該先看 packages 目錄下的實際實作再決定。
什麼情況下它會是錯的工具
第一類是 DRM 內容。README 的格式清單裡沒有任何一項提到 DRM 解除或支援，AZW 與 AZW3 通常與 Amazon 的 DRM 綁在一起，能匯入的多半是無 DRM 的檔案。如果你的書來自 Kindle 商店，這條路大概率走不通。
第二類是重度 PDF 使用者。PDF 被列在支援格式裡，但 PDF 的難點從來不是能不能打開，而是文字層抽取、雙欄排版重排、圖表與註解的定位。README 對 PDF 的處理深度沒有任何描述，而向量檢索的品質高度依賴文字抽取的乾淨程度。學術論文為主的讀者，用 ReadAny 之前應該先拿一篇雙欄論文實測切塊結果。
第三類是不想處理模型設定的使用者。Ollama 本地跑嵌入模型需要一定的機器資源與安裝步驟，雲端供應商則要處理 API 金鑰與計費。README 把 AI 設定標為 optional，但語意搜尋與 RAG 問答正是這個專案的主要賣點，跳過這步等於只用了它的閱讀器外殼。
還有一類要留意的是行動端使用者。iOS 走 TestFlight，代表版本有期限、需要重新加入；Android 走 .apk 側載，需要自行處理更新。把行動裝置當主要閱讀場景的人，要有手動維護的準備。
與 Calibre、KOReader 的實際差異
README 的比較表把 Calibre、KOReader、Apple Books 放在一起對比，這個對比本身有點錯位，因為這三者解決的問題不同。
Calibre 的核心是書庫管理與格式轉換，它是一套桌面工具，強項在批次處理、metadata 編輯、格式轉檔，閱讀介面只是附帶。ReadAny 沒有書庫管理的深度，README 也沒有提到批次 metadata 編輯或轉檔管線。如果你的痛點是幾千本書的整理與格式統一，Calibre 仍然是唯一合理的選擇，ReadAny 補不上這一塊。
KOReader 的定位更接近 ReadAny：跨平台、開源、注重閱讀體驗，支援的裝置範圍甚至更廣，包含 Kindle 等電子紙裝置。它的差異在於 KOReader 走的是純閱讀路線，沒有向量檢索與 RAG 問答，但它在排版引擎、字典整合、以及電子紙裝置的適配上有多年累積。要在電子紙上讀，KOReader 是更成熟的選項。
ReadAny 的差異點因此收斂到一件事：它把檢索與問答當成閱讀流程的一部分，而不是事後在另一個工具裡整理。這個定位是否值得，取決於你是否真的會用問答功能。多數人裝了 AI 閱讀工具之後，實際使用頻率遠低於預期，這是採用前值得誠實面對的問題。
授權狀態與維護成本要先看清楚
最需要先確認的是授權。repository 的 License 欄位顯示 NOASSERTION，這代表 GitHub 無法從檔案內容自動識別出標準授權條款。README 的徽章指向 LICENSE 檔案，但材料中沒有該檔案的內容。這不是小事：NOASSERTION 可能意味著自訂授權、雙授權、或是授權條款有額外限制。要商用、要fork、要打包進內部工具的人，必須自己讀過 LICENSE 全文再決定。本文不對授權內容做任何推測，也不提供法律意見。
維護節奏方面，release 記錄顯示 v1.3.4 在 2026-06-09、v1.3.5 在 2026-07-08、v1.3.6 在 2026-08-16，大約一個月一版，最後推送時間是 2026-09-09。這個節奏對個人專案來說算穩定，但也意味著功能變動頻繁，設定介面與行為可能隨版本調整。
升級成本主要落在兩處。一是資料格式，書庫、畫線、筆記都存在本地 SQLite，跨版本升級若涉及 schema 變更，備份就很重要。二是模型端點設定，供應商 API 變動時需要跟著調整。建議在升級前先複製一份書庫目錄，尤其是已經累積大量筆記之後。
WebDAV 同步還有一個容易被忽略的成本：它是自帶伺服器的方案。README 說支援 WebDAV，但沒有推薦特定服務，也沒有說明認證方式與傳輸加密。你得自己準備 Nextcloud、Synology 或其他 WebDAV 端點，這對非技術使用者是一道實際的門檻。
編輯結論
如果你讀的書以 EPUB 為主、願意自己接上 OpenAI 或 Ollama 這類模型端點，而且在意書庫與筆記不出本機，ReadAny 值得先裝桌面版試一輪：從 GitHub Releases 下載 .dmg 或 .msi，或走 brew tap codedogQBY/readany 加 brew install --cask readany。若你需要 DRM 內容、需要成熟的 PDF 學術標註流程，或無法接受 NOASSERTION 這種未定授權狀態，就先不要把它當成主要工具。動手前先確認三件事：LICENSE 檔案的實際內容、你打算使用的模型供應商是否支援 embeddings、以及 WebDAV 同步在衝突合併後筆記是否完整。
社群筆記