zotero-AI-Butler：把 Zotero 變成論文精讀管線的插件
【Zotero AI 管家】调用大模型，自动精读论文库里的论文，总结为Zotero笔记。支持主流大模型平台！您只需像往常一样把文献丢进 Zotero， 管家会自动帮您精读论文，将文章揉碎了总结为笔记，让您“十分钟完全了解”这篇论文！
秒懂
- 它是什麼？
- 它把「讀論文」拆成可排隊、可重跑、可換模型的批次任務，用 Markdown 筆記回寫到 Zotero 條目。判斷重點不在功能清單長度，而在你願不願意把 API Key、提示詞與 PDF 處理方式交給一個 AGPL-3.0 的社群插件。
- 適合誰用？
- 如果你已經在用 Zotero 管理文獻，而且願意自己申請 API Key、自己維護提示詞，這個插件值得裝來試；它的價值在批次佇列與多輪精讀，不在單篇摘要。若你不想把 PDF 以 Base64 送到第三方模型、或不接受 AGPL-3.0 的傳染性條款，就別導入。
- 可以商用嗎？
- 可以，但條件嚴格。AGPL-3.0 是網路 copyleft 授權：如果別人透過網路使用你修改過的版本（例如作為託管服務），你必須以同一授權向他們提供原始碼。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 1 天前。
- 用什麼語言寫的？
- 主要是 TypeScript（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它解決的不是「摘要」，而是「一篇一篇貼給聊天視窗」這件事
README 開頭列了三個痛點：文章太多讀不完、讀完就忘、文章太長抓不到重點。第三點市面上的翻譯插件已經處理得不錯，真正沒被處理的是第一點。把 PDF 上傳到網頁版聊天機器人，一次一篇，貼上、等待、複製、回到 Zotero 貼成筆記，這個循環在二十篇之後就會崩潰。
這個插件把循環自動化。它的定位是 Zotero 插件，不是獨立應用，所以文獻庫、目錄結構、條目關聯都沿用 Zotero 既有的資料。README 對目標使用者的描述很直白：照往常把文獻丟進 Zotero，剩下的交給它。適合的人是有穩定 API 額度、文獻量已經累積到某個規模的研究者；不適合的人是把 Zotero 當純書目管理工具、不需要全文分析的人，裝了只是多一個要維護的元件。
生產者與消費者：任務佇列才是這個插件的骨架
README 在說明「任務佇列」頁面時寫得很清楚：所有論文分析都基於生產者與消費者模式進行。這句話比功能列表更能說明它的架構。插件本身不直接呼叫模型，而是先產生任務，再由背景的消費者依序處理，佇列裡可以看到待處理、進行中、已完成與失敗四種狀態。
這個設計帶來兩個實際後果。第一，你可以一次勾選幾十篇論文加入佇列，然後關掉對話框去做別的事，處理速度由「快捷設定」裡的控制項決定，README 說明該設定用來控制每分鐘處理的論文數量，避免 API 呼叫超限。第二，失敗是可見的。任務卡在失敗狀態時，你知道是哪一篇、而不是整批靜默消失。對比之下，把 PDF 貼進聊天視窗的做法沒有狀態，中斷就是中斷。
觸發方式有三種：在條目上按右鍵選「召喚 AI 管家進行分析」；在儀表板的「介面設定」開啟自動掃描新文獻，讓新拖入的 PDF 自動排隊；或在儀表板點「掃描未分析論文」回溯舊文獻。第三種會依你的 Zotero 目錄結構排列結果，可以按目錄全選。自動掃描預設關閉，README 給的理由是最小化對 Zotero 效能的影響，這個取捨是誠實的。
Base64 還是文字提取，這個選項決定了你能用哪些模型
在「快捷設定」的 PDF 處理方式裡有兩個選項。多模態處理會把 PDF 以 Base64 編碼上傳，README 的說法是讓模型直接看到 PDF 原文，對圖片、公式、表格的理解能力更強，甚至純圖 PDF 也能處理。文字提取模式則適用於不支援多模態的模型，README 在 Ollama 那一列註明需使用文字提取或 MinerU 處理 PDF。
這個分岔不是效能微調，而是模型選擇的前提。選了文字提取，就等於放棄掃描版 PDF 與圖表密集的論文；選了 Base64，就等於把整份 PDF 送進模型服務商。隱私聲明提到插件本身不收集、不儲存、不上傳個人資料與 API Key，請求直接從本地送到你配置的服務商。這段話成立的前提是服務商那一端；PDF 內容確實離開了你的機器。
多平台支援橫跨 Google Gemini、OpenAI、Anthropic、OpenAI 相容介面、火山方舟與 Ollama。README 推薦 gemini-3-pro-preview 做總結，理由是 PDF 理解準確。要注意表格裡列的是模型名稱而非穩定版本代號，其中多個帶有 preview 或日期後綴，這類端點被服務商下架時，插件不會替你處理，你得自己改設定。
多輪精讀與提示詞：可控性高，但預設值不是免費的
提示詞模板支援變數替換，README 舉了 {{title}} 與 {{authors}} 這類寫法，編輯時可即時預覽替換結果，也能一鍵恢復系統預設。多輪對話模式下，每一輪的提示詞可自訂，README 列出的輪次主題包括研究背景與問題、研究方法與技術、實驗設計與結果、結論與展望，最後把多輪結果匯總成一篇總結。
這是把「讀薄」與「讀厚」拆成兩條路徑。單次總結產生一篇筆記；多輪精讀則是把同一篇論文分章節反覆送進模型。代價直接反映在 token 消耗上，多輪意味著同一份 PDF 被讀好幾次。若你用的是按量計費的 API，整庫回溯加上多輪模式會是這份清單裡最貴的組合，README 沒有給出任何成本估算，這一點必須自己算。
右鍵選單另有「AI 管家多輪對話重新精讀」，可選多輪拼接或多輪總結，README 明言這會強制覆蓋既有的 AI 筆記。覆蓋沒有版本保留的說明，重跑前最好確認你不需要舊的那份。
一圖總結與思維導圖：依賴外部服務的那一塊
3.0 版本加入「一圖總結」，用 Nano Banana Pro 為每篇論文生成學術海報式圖片；思維導圖則支援縮放、匯出 PNG 與 OPML 大綱。OPML 匯出這點比圖片實用，大綱可以搬進其他工具繼續編輯。
這兩個功能的可靠性取決於模型端而非插件端。README 沒有說明一圖總結在模型拒絕生成或回傳格式不符時如何處理，也沒有列出失敗重試策略。把它當成加分項而非核心功能來評估會比較合理。同樣的道理適用於側邊欄的沉浸閱讀：LaTeX 公式渲染與追問功能在 README 中被標為 Pre-release，這個標記本身就是提示。
AGPL-3.0 與維護節奏：導入前該看的兩件事
授權是 AGPL-3.0，不是 MIT。差別在於你若修改並以網路服務形式提供給他人使用，AGPL 要求你釋出對應原始碼。個人自用不受影響，但如果你打算把這個插件包進實驗室內部平台或任何對外服務，這條款需要先跟法務確認，這裡不提供法律意見。
維護方面，從版本節奏可以看到近期釋出集中在 4.1.0 的 beta 版，包括 v4.1.0-beta.1 與 beta.2，前一條線是 v4.0.3-beta.8。也就是說目前的主要版本以 beta 形式推進。Beta 不等於不能用，但意味著介面與設定鍵可能變動，而你依賴的是它寫進 Zotero 的筆記。筆記本身是 Markdown，存在 Zotero 條目下，即使插件日後停止維護，已產生的筆記仍在你的資料庫裡，這是這個架構相對安全的地方。
專案有 DOI（10.5281/zenodo.20457937）與引用說明，README 也明確表示插件本身沒有任何收費管道，所有費用發生在你與模型服務商之間。
什麼情況下它是錯的工具
第一種是隱私邊界嚴格的場景。若你的論文受保密協議約束，或機構禁止把未發表稿件送往外部 API，Base64 上傳與文字提取兩條路都違規，本地 Ollama 是唯一出路，但 README 對 Ollama 的說明只有一行，且需搭配文字提取或 MinerU，實際上等於放棄多模態能力。
第二種是只需要書目管理的人。這個插件不改善檢索、不改善引用格式、不改善協作，它只處理全文。
第三種是把 AI 筆記當成事實來源的人。多輪精讀會強制覆蓋既有筆記，模型也可能在圖表解讀上出錯，而 README 沒有描述任何人工校驗流程。筆記是初稿，不是定稿。
替代方案方面，Zotero 生態裡另有以本機模型為主的整合路徑（例如透過 Ollama 的通用 Zotero 整合），差別在於它們通常一次處理一篇、沒有佇列與批次回溯，換來的是資料不離開本機。這個插件的取捨正好相反：用佇列與多平台換取吞吐量，代價是資料外送與 API 成本。兩者不是誰取代誰，而是你願意把哪一項放在前面。
編輯結論
如果你已經在用 Zotero 管理文獻，而且願意自己申請 API Key、自己維護提示詞，這個插件值得裝來試；它的價值在批次佇列與多輪精讀，不在單篇摘要。若你不想把 PDF 以 Base64 送到第三方模型、或不接受 AGPL-3.0 的傳染性條款，就別導入。動手前先確認三件事：你的模型是否支援多模態、你的 API 額度能否負擔整庫回溯、以及你的 Zotero 版本是否落在插件支援範圍內，因為 Zotero 本體升級經常直接讓插件失效。
社群筆記