在寫程式之前，如何利用AI進行頂層設計？

在正式寫程式碼之前，最重要的核心原則是絕不要在評審並批准書面計劃之前讓 AI 編寫程式碼。這種“先計劃、後執行”的分離可以防止無效勞動，並確保你對架構決策擁有絕對控制權。要想清楚你要什麼，不要直接說“幫我做一個XX產品”，這太模糊；要把產品邊界、技術選型、維運預期全部想清楚，寫進系統提示詞文件（如CLAUDE.md）中，不過這部分工作也可以使用AI來輔助。

1. 調研與深度研究 (Research)

先讓 AI 梳理出同類產品中的標杆，讓它瀏覽產品文件，並列出核心功能清單。通常來說，這裡面的任何一個功能模組都相當複雜，因此不能讓AI一次性全部完成。

[!Note] 提示詞 我計劃開發一款專門面向碩士及博士研究生的英文學術論文閱讀器。請幫我梳理該領域的行業標杆產品（Top 3-5個）。針對每個產品，用精煉的兩句話概括其核心定位與獨特優勢。提供每個產品的官方網站或開發者文件連結。

Codex很快給出了同類型優秀產品的清單，不僅做了簡要的介紹，還幫我們找到了它們的官網和文件，方便我們查閱。

下面這 5 個更適合作為你做“面向碩博研究生的英文學術論文閱讀器”時的核心競品池。它們分別代表了開源文獻管理、AI增強閱讀、機構級工作流、傳統學術參考管理，以及AI檢索閱讀這幾條主流路線。

  1. **Zotero**
     定位：Zotero 是學術界最強勢的開源文獻管理與論文閱讀工具之一，核心是“採集文獻 + 管理資料 + 閱讀標註 + 寫作引用”的一體化研究工作流。
     優勢：它的獨特價值不在炫技，而在於開放、穩定、可擴充套件，尤其適合碩博生做長期知識積累、跨裝置同步和外掛化深度定製。
     官網/文件：https://www.zotero.org/ ｜ https://www.zotero.org/why
  2. **ReadCube Papers**
     定位：ReadCube Papers 更像面向高強度科研使用者的高階學術閱讀與文獻工作臺，強調“發現-閱讀-整理-引用”全鏈路效率。
     優勢：它的差異化在於更強的增強閱讀體驗與 AI 工作流，能把文獻監測、上下文閱讀、團隊協作和系統綜述流程串成一個更商業化、更精細的產品體系。
     官網/文件：https://www.readcube.com/
  3. **EndNote**
     定位：EndNote 是高校、實驗室和資深研究者中長期佔據標杆地位的參考文獻管理工具，偏“專業級研究生產力平臺”。
     優勢：它的護城河是機構端滲透率高、引用與投稿流程成熟，並在最新版中繼續強化 AI 輔助檢索、文件總結和期刊匹配能力。
     官網/文件：https://endnote.com/ ｜ https://docs.endnote.com/
  4. **Mendeley**
     定位：Mendeley 是大眾認知度很高的免費學術參考管理產品，適合作為“文獻入庫、PDF 閱讀標註、協作共享”的輕中度科研入口。
     優勢：它的獨特優勢是上手門檻低、Web Importer 採集方便、團隊共享直觀，因此在學生群體和跨學科初中級研究者中一直有很強普及度。
     官網/文件：https://www.mendeley.com/features/
  5. **Semantic Scholar / Semantic Reader**
     定位：Semantic Scholar 本質上是 AI 驅動的學術檢索與發現平臺，而 Semantic Reader 則把它往“增強型論文閱讀器”方向推進。
     優勢：它最值得借鑑的不是傳統文管能力，而是基於語義檢索、引用上下文和增強閱讀去幫助使用者更快理解論文、找到相關工作與研究脈絡。
     官網/文件：https://www.semanticscholar.org/ ｜ https://www.semanticscholar.org/product

  如果你願意，我下一步可以繼續幫你把這 5 個產品按 目標使用者 / 核心功能 / AI能力 / 閱讀體驗 / 商業模式 / 你可切入的差異化機會 做成一張競品對比表。

最後一行中，Codex說可以幫我門生成競品對比表，那麼我們之前的提示詞可以多加這樣一句話：“將它們按 目標使用者 / 核心功能 / AI能力 / 閱讀體驗 / 商業模式 / 你可切入的差異化機會 做成一張競品對比表。”

有了這些資訊之後，我讓Codex進一步幫忙。

[!Note] 提示詞 幫我梳理Zotero(https://www.zotero.org/support/start） 等產品的核心功能模組，整合成一份清單，功能模型按類別分組，每個模組用一兩句話說明它做什麼。

下面是一份可直接用於產品定義的“英文學術論文閱讀器核心功能模組清單”。我按類別合併了 Zotero、ReadCube、Mendeley、EndNote、Semantic Scholar 等產品中最有代表性的能力，並儘量用產品語言而不是實現細節來描述。

  一、文獻獲取

  - 網頁一鍵採集
    從 Google Scholar、出版社頁面、資料庫檢索頁或期刊官網一鍵儲存論文題錄、作者、摘要、DOI 與附件。核心作用是降低“收集文獻”的操作成本，避免手工錄入。
  - PDF 匯入與後設資料識別
    支援拖拽本地 PDF 匯入，並自動識別標題、作者、期刊、年份等後設資料。適合處理導師轉發資料、歷史論文包和手動下載的文獻。
  - 批次匯入與格式相容
    支援 BibTeX、RIS、EndNote XML 等常見學術格式匯入。作用是方便使用者從其他文管工具遷移，或從資料庫批次建庫。
  - 全文獲取與附件補全
    根據 DOI、題錄或機構許可權自動嘗試匹配和下載全文。它解決的是“條目有了但 PDF 不全”的問題，提升文獻庫完整度。

  二、文獻庫管理

  - 文獻庫總覽
    集中管理論文條目、PDF、補充材料、網頁快照和相關附件。它是整個研究資料的主容器，也是後續閱讀、檢索和寫作的基礎。
  - 資料夾/專題集合
    允許按課程、課題、綜述主題、實驗方向等建立層級化集合。它幫助研究生把分散閱讀任務組織成清晰的知識結構。
  - 標籤與狀態管理
    通過標籤、顏色或自定義狀態標記“待讀 / 已讀 / 精讀 / 可引用 / 待複核”等。作用是把文獻管理從靜態儲存提升為動態研究流程管理。
  - 去重與版本管理
    自動識別重複條目、合併後設資料，並處理同一論文的不同版本。它能減少庫內混亂，避免引用錯誤和閱讀重複勞動。
  - 關聯文獻連結
    支援把“原始論文、復現論文、綜述、作者後續工作”等條目建立關聯。它的價值是幫助使用者搭建研究脈絡，而不是隻存一堆獨立 PDF。

  三、檢索與發現

  - 庫內檢索
    支援按標題、作者、關鍵詞、標籤、年份、期刊和全文內容搜尋。核心作用是讓使用者快速找回“我之前看過的那篇論文”。
  - 高階篩選與智慧查詢
    支援組合篩選條件，或儲存常用檢索規則形成動態文獻列表。適合系統綜述、某方法路線跟蹤和導師彙報前的集中整理。
  - 相關論文推薦
    基於主題、共引關係、相似文本或使用者閱讀歷史推薦相關文章。它幫助使用者從單篇論文出發，快速擴充套件到同一研究脈絡。
  - 研究動態追蹤
    圍繞某個主題、作者、關鍵詞或文獻庫持續推送新論文。對博士生尤其重要，因為前沿跟蹤本身就是長期任務。

  四、論文閱讀

  - 內建 PDF 閱讀器
    支援在產品內直接開啟和閱讀論文，不必頻繁切換外部閱讀器。好的閱讀器應重點保證速度、排版清晰度和跨裝置一致體驗。
  - 多形態標註
    支援高亮、下劃線、刪除線、框選、便籤、手寫或繪圖等標註方式。它的核心價值是把“閱讀痕跡”沉澱下來，而不是讓標註停留在一次性操作。
  - 結構化導航
    提供目錄、章節跳轉、圖表定位、參考文獻跳轉和補充材料入口。它能顯著降低長論文和方法論文的閱讀摩擦。
  - 增強閱讀上下文
    在文中直接展示術語解釋、引用卡片、圖表關聯或補充說明。這個模組的目標不是替代原文，而是幫助使用者更快理解關鍵上下文。

  五、筆記與知識沉澱

  - 論文級筆記
    使用者可圍繞單篇論文記錄摘要、方法、貢獻、侷限、可復現性和個人評價。它適合形成標準化閱讀卡片，為後續寫綜述和開題做準備。
  - 標註轉筆記
    支援將高亮與批註自動彙總為可編輯筆記。核心作用是把零散閱讀痕跡快速轉化為可複用的研究材料。
  - 跨論文主題筆記
    允許把多篇論文中的觀點、結果和方法彙總到同一主題筆記下。它特別適合做文獻綜述、方法比較和研究空白梳理。
  - 知識連結與回溯
    筆記可反向連結到原文頁碼、具體句段或圖表位置。這樣使用者在寫作或覆盤時，能快速回到證據來源而不是重新翻全文。

  六、AI 輔助理解

  - 論文問答
    支援對單篇論文直接提問，例如“作者的核心貢獻是什麼”或“實驗設定有什麼限制”。重點是回答必須儘量繫結原文出處，避免脫離文本的泛化總結。
  - 自動摘要與要點提煉
    自動提煉研究問題、方法、實驗設計、結論和侷限。它適合幫助使用者做初篩，但不應替代精讀判斷。
  - 術語解釋與翻譯
    對專業術語、縮寫、公式描述和複雜句子提供解釋或學術化翻譯。這個模組對非英語母語研究生的價值非常高。
  - 對比與歸納
    支援跨多篇論文比較方法差異、資料集差異、優缺點和研究趨勢。它更接近研究助手，而不只是閱讀助手。
  - 閱讀引導
    根據論文型別生成“建議先讀哪裡”“哪些章節最關鍵”“哪些前置知識需要補足”。這對剛進入新領域的碩士生尤其有用。

  七、引用與寫作支援

  - 引用插入
    在 Word、Google Docs 或 LaTeX 工作流中快速插入參考文獻。它把閱讀器與寫作場景打通，避免後期重新整理引用。
  - 參考文獻格式生成
    自動生成並切換不同期刊、會議或學校格式。它能減少格式調整的機械勞動，尤其適合投稿和畢業論文場景。
  - 快速匯出引文
    支援一鍵複製標準引用文本，或匯出 BibTeX、RIS 等格式。這個模組適合使用者在多種寫作工具之間切換使用。
  - 寫作證據回鏈
    從筆記或高亮片段直接插入帶出處的內容到寫作環境。它的價值是縮短“讀到寫”的距離，提高引用準確性。

  八、協作與共享

  - 共享文獻庫
    允許課題組、合作者或學生團隊共享論文、標籤和組織結構。它解決的是多人研究專案中的資料統一問題。
  - 共享批註與討論
    團隊成員可以檢視彼此標註、筆記和評論。它適合 journal club、導師組會準備和聯合寫作場景。
  - 公開清單與成果展示
    可將某一專題文獻集、閱讀清單或個人成果集公開分享。它既能用於學術傳播，也能用於團隊知識沉澱。

  九、同步與跨端體驗

  - 多端同步
    在桌面端、Web 端和平板端同步文獻、標註、筆記與閱讀進度。對研究生來說，這決定了是否能形成連續的學習與研究體驗。
  - 雲端儲存與備份
    保證 PDF、批註和後設資料安全儲存，並支援歷史恢復。核心價值是防止研究資料丟失，這屬於高頻但高風險需求。
  - 離線閱讀
    允許提前下載論文，在無網環境下繼續閱讀和標註。這個模組雖然基礎，但對通勤、出差和校園網路不穩定場景很實用。

  十、研究工作流增強

  - 閱讀任務管理
    支援把論文加入待讀佇列、設定優先順序、截止時間和閱讀計劃。它幫助使用者把文獻閱讀從“想起來再看”變成可執行任務流。
  - 方法/資料集/結論欄位化整理
    將論文中的方法、任務、資料集、指標和結論抽成結構化欄位。這樣後續做橫向比較、實驗設計或綜述時會明顯更高效。
  - 投稿與研究產出輔助
    根據已有文獻和稿件內容輔助推薦目標期刊、整理相關工作或檢查引用完整性。這個模組更偏博士後期和高頻投稿使用者。

有了這份清單後，結合我自己的想法，最終形成了一份功能全景。

  一、文獻獲取
   - RSS 訂閱
    支援訂閱期刊、會議、arXiv 分類、關鍵詞檢索結果或作者動態的 RSS 源。它的價值是把“主動搜尋文獻”擴充套件為“持續接收最新研究流”。

	四、論文閱讀
  - 劃詞英文翻譯
    支援對單詞、短語或句子進行即點即譯，優先保留學術語境和專業含義。這個模組對非英語母語研究生非常實用。
  - 生詞表
    使用者可將劃詞結果加入個人生詞表，記錄釋義、原句、出現論文和複習狀態。它把一次性的閱讀障礙，轉化成長期可積累的學術英語學習資產。

  七、知識編譯層（Raw-Wiki）

  - 原始資料層 Raw Layer
    將 PDF、網頁、補充材料、程式碼倉庫、作者主頁、影片等作為原始知識源儲存。它是所有 AI 總結與知識頁面的最終證據層。
  - 研究 Wiki 層
    系統自動把原始論文編譯成可持續更新的知識頁面，而不是停留在“每篇論文一個摘要”。它讓使用者面對的是一個研究知識系統，而不是一堆孤立 PDF。
  - 主題頁 Topic Pages
    圍繞某個研究方向自動維護主題頁，沉澱代表論文、發展脈絡、關鍵方法和未解決問題。它適合支援開題、文獻綜述和領域入門。
  - 方法頁 / 資料集頁 / 指標頁
    將方法、資料集、評價指標從論文中抽離成獨立物件，記錄定義、用途、代表工作和侷限。這樣使用者可以跨論文做結構化比較。
  - 論點頁 Claim Pages
    圍繞關鍵研究論斷組織支援、反駁和補充證據。它能把“論文怎麼說”提升到“這個領域對某個問題形成了什麼共識或分歧”。
  - 開放問題頁 Open Questions
    持續歸納某一方向尚未解決的問題、方法侷限和未來研究機會。這個模組很適合幫助研究生尋找選題與研究空白。
  - 閱讀路徑頁 Reading Paths
    根據使用者目標自動生成“入門路徑 / 開題路徑 / 復現路徑 / 綜述路徑”。它能把複雜領域拆成更易執行的閱讀路線。

  十、同步、儲存與跨端體驗

  - 【新增】本地儲存
    支援將題錄、PDF、批註、筆記、生詞表和知識頁面儲存在本地。它的意義不僅是離線可用，也包括資料自主可控、隱私更強和更低的雲依賴。

  十一、模型與推理配置

  - 使用者自定義 API 接入
    使用者可自行填寫 API Key、Base URL 和模型名稱，接入任意相容介面的模型服務。產品本身不提供模型，只提供接入與呼叫能力。
  - 多模型配置與切換
    使用者可儲存多組模型配置，並選擇當前預設模型。這樣可以相容不同服務商、不同預算和不同使用偏好。
  - 按功能選擇模型
    使用者可為翻譯、摘要、論文問答等功能分別指定模型。這樣能在效果和成本之間做更靈活的平衡。
  - 連線測試與錯誤診斷
    系統提供連線測試、模型可用性校驗和錯誤提示。這樣使用者能快速定位是 URL、Key 還是 模型名 的問題。
  - 金鑰本地安全儲存
    API Key 僅儲存在使用者本地，預設脫敏展示，並儘量使用安全儲存機制。這樣可以降低憑證洩露風險。
  - 呼叫用量與成本視覺化
    展示各模型的請求次數、token 用量、估算費用和功能消耗分佈。這個模組能幫助研究生使用者控制預算，也便於你後續設計付費策略。

![[Gemini_Generated_Image_knh20pknh20pknh2.png]]

儘量在開源專案的基礎上開發，儘量重用已經寫好的程式碼。 source：瀏覽器外掛採集、RSS訂閱； manage：資料夾、標籤等； review：pdf標註、筆記、翻譯、AI輔助； write：latex寫作、引用生成； other：本地儲存、多端同步、20人協作（藉助github等）；

2. 功能取捨 (Feature Scoping)

做開發產品時，往往需要先生產出一個最小可行性單元（MVP），上一步得到的功能模組可能是冗餘或不必要的，此時需要對功能進行取捨，只保留核心需求。

先利用AI來做一輪初步分析，讓它將功能分為：必須做、簡化做、不做這三個檔次。

[!Note] 提示詞 我要參考 Zotero 做一個簡化版的 Paper Reader 工具，叫 ResearchLM。約束條件：一個人開發，面向實驗室組內 10-20 人使用，本地部署。請從剛才梳理的功能列表中，幫我判斷哪些是必須做的核心功能，哪些可以簡化做，哪些是可以砍掉的，給出每個的理由和方案。

先定邊界：ResearchLM 是 1人開發、10-20人實驗室內使用、本地部署，所以產品目標不該是“對標 Zotero + ReadCube + Semantic Scholar”，而應是做成一個實驗室內部可用的、比 Zotero 更貼近論文閱讀與知識沉澱的輕量工具。因此判斷標準只有三個：是否高頻、是否能明顯提升組內效率、單人是否能穩妥維護。

  我建議把功能分成三層：必須做、簡化做、先砍掉。

  一、必須做的核心功能

  這些是沒有就不成立的。

  - 本地文獻庫
    理由：沒有穩定的本地條目管理，產品就不是論文閱讀器，只是 PDF 檢視器。
    方案：先支援 條目 + PDF 附件 + 基本後設資料，底層可用 SQLite + 本地檔案目錄。
  - PDF 匯入與後設資料識別
    理由：實驗室真實使用裡，大量論文來自手動下載和轉發，匯入體驗決定是否有人願意用。
    方案：先做 拖拽匯入 PDF + DOI/標題解析，識別失敗時允許手工編輯。
  - 資料夾/集合管理
    理由：組內使用者一定會按課題、方向、專案整理論文，這是最基本的資訊架構。
    方案：只做 層級資料夾/集合，先不要上覆雜智慧資料夾。
  - 標籤與閱讀狀態
    理由：這是最輕量但最有效的流程管理能力，能支援“待讀/已讀/精讀/可引用”。
    方案：只做少量預置狀態 + 自定義標籤，不做複雜規則引擎。
  - 庫內檢索
    理由：找回論文是核心剛需，否則庫越大越難用。
    方案：先支援 標題/作者/年份/標籤/摘要 檢索，全文檢索可作為增強項。
  - 內建 PDF 閱讀器
    理由：你做的是 Paper Reader，閱讀必須是中心，而不是外鏈開啟。
    方案：優先保證 開啟快、翻頁穩、目錄可跳轉、位置記憶，不要一開始追求花哨互動。
  - 基礎標註
    理由：高亮和批註是閱讀閉環的最小單元，沒有它使用者仍會回到別的閱讀器。
    方案：先做 高亮 + 批註 + 批註列表，手寫、繪圖先砍掉。
  - 論文級筆記
    理由：研究生真正要沉澱的是“我怎麼看這篇論文”，而不是隻有高亮。
    方案：每篇論文給一個固定結構筆記區，如 問題/方法/貢獻/侷限/啟發。
  - 標註回鏈
    理由：筆記若不能回到原文位置，後續寫作和覆盤會很痛苦。
    方案：筆記和高亮都儲存頁碼與錨點，點選可跳回 PDF 位置。
  - 本地儲存
    理由：你已明確本地部署，而且組內規模小，本地優先比雲優先更合理。
    方案：所有 PDF、題錄、批註、筆記、配置 預設本地儲存，先不依賴外部雲。
  - 基礎共享
    理由：10-20 人組內使用，不共享就失去“實驗室工具”的意義。
    方案：不要做複雜即時協同，只做 共享文獻庫 / 共享只讀筆記 / 匯出匯入 即可。
  - API Key / Base URL / Model Name 配置
    理由：這是 AI 功能成立的前提。既然你不提供模型，使用者就必須自己完成接入，否則摘要、問答、翻譯這些功能都無法使用。


  二、建議簡化做的功能

  這些有價值，但不能按完整競品形態做。

  - 網頁一鍵採集
    理由：有用，但瀏覽器外掛開發和站點相容成本高。
    方案：第一版只支援 DOI/arXiv URL 匯入，後續再擴充套件瀏覽器外掛。
  - 批次匯入與格式相容
    理由：遷移需求真實存在，但不需要一次支援全部格式。
    方案：優先支援 BibTeX 和 RIS，夠覆蓋絕大多數科研場景。
  - 全文獲取與附件補全
    理由：自動找全文很爽，但許可權、來源和適配複雜。
    方案：只做 根據 DOI 跳官方頁面 或嘗試開放來源，不做複雜抓取。
  - 去重與版本管理
    理由：必要但可以輕做。
    方案：先按 DOI + 標題相似度 提示重複，不做自動合併和複雜版本樹。
  - 全文檢索
    理由：價值高，但 PDF 文本抽取和索引質量要花時間。
    方案：先做非同步索引，只支援基礎關鍵詞全文搜尋，不做語義檢索。
  - 劃詞英文翻譯
    理由：對學生很實用，但不必做成複雜語言學習系統。
    方案：先做 選中文本 -> 呼叫模型/詞典翻譯，結果浮層展示。
  - 生詞表
    理由：有用，但不是所有人都高頻使用。
    方案：只儲存 單詞/短語 + 釋義 + 原句 + 來源論文，不做完整記憶曲線系統。
  - 論文問答
    理由：這是 ResearchLM 的差異化，但如果做重了會吞噬大量開發時間。
    方案：只做 單篇論文問答，並且嚴格綁定當前 PDF 或當前筆記，不做全庫 Agent。
  - 自動摘要與要點提煉
    理由：適合初篩，但很容易變成“看起來厲害但經常不準”的功能。
    方案：只產出固定結構，如 問題/方法/實驗/結論/侷限，並顯示出處。
  - 術語解釋與翻譯
    理由：和劃詞翻譯天然相關，適合論文閱讀場景。
    方案：僅在選中文本時觸發，不做全域性術語知識庫。
  - 閱讀任務管理
    理由：能幫助組內管理 journal club 和待讀清單，但沒必要做成專案管理軟體。
    方案：只做 待讀列表 + 優先順序 + 截止日期。
  - RSS 訂閱
    理由：對持續跟蹤前沿有價值，但不是第一階段阻塞項。
    方案：只支援少量固定源，如 arXiv RSS / 期刊 RSS，先不做複雜聚合與規則過濾。
  - 引用匯出
    理由：讀論文的人最終會寫論文，但你不必一開始做完整 Zotero 寫作生態。
    方案：先做 BibTeX 匯出 + 一鍵複製 citation，先不做 Word 外掛。
  - 基礎 Raw-Wiki
    理由：這是你的方向亮點，但絕不能一上來做成完整知識編譯系統。
    方案：只保留 2 個最小實體：Paper Page 和 Topic Page。
    Paper Page 自動彙總單篇論文摘要、筆記、問答、標註。
    Topic Page 先由使用者手動建主題，系統只負責把論文掛進去並生成簡要聚合摘要。
  - 個人研究記憶庫
    理由：長期價值高，但不要抽象過頭。
    方案：本質上先用 主題頁 + 論文筆記 + 標籤 組合實現，不另做複雜系統。

  三、當前可以砍掉的功能

  這些不是沒價值，而是對你的約束條件不划算。

  - 多模型提供商管理 / API Key 自助平臺化
    理由：10-20 人組內本地部署，不需要做成通用 SaaS 平臺。
    方案：保留一個簡單設定頁，支援管理員配置 1-2 個模型介面 即可，不必做複雜 provider 管理。
  - 模型路由與任務分配
    理由：這是平臺型能力，不是實驗室閱讀器的早期核心。
    方案：先固定幾類任務用哪個模型，寫死在配置裡。
  - 本地模型 / 私有模型多種接入
    理由：如果你的部署環境明確，做太多適配只會增加維護成本。
    方案：第一版只支援 一個主模型後端，例如 OpenAI-compatible API。
  - 多端同步
    理由：本地部署 + 小團隊，不值得一開始做複雜同步衝突處理。
    方案：優先做桌面/Web 單端；如果必須跨裝置，先做服務端集中儲存而不是離線雙向同步。
  - 雲端儲存與備份
    理由：和本地部署目標不一致。
    方案：改成 本地資料庫備份/匯出 即可。
  - 離線閱讀
    理由：如果本來就是本地部署和本地儲存，這幾乎天然具備，不需要作為獨立複雜模組建設。
    方案：只保證斷網時本機可用。
  - 共享批註即時協作
    理由：即時協同難度高，組內收益有限。
    方案：只做“儲存後可見”的非同步共享。
  - 公開清單與成果展示
    理由：這是對外傳播功能，不是組內工具核心。
    方案：直接砍掉。
  - 相關論文推薦
    理由：高質量推薦需要較強資料和演算法支撐，單人開發不划算。
    方案：短期砍掉；用 RSS 和手動主題整理替代。
  - 研究動態追蹤
    理由：完整動態追蹤依賴推薦/訂閱/監控系統。
    方案：先由 RSS 訂閱 部分替代。
  - 跨多篇論文對比與歸納
    理由：很有吸引力，但實現可靠性和 UI 複雜度都高。
    方案：先砍掉自動化部分，改為使用者手動在 Topic Page 裡組織。
  - 方法頁 / 資料集頁 / 指標頁 / 論點頁 / 開放問題頁 / 閱讀路徑頁
    理由：這是完整 raw-wiki 願景的一部分，但一上來做會把你拖進知識圖譜和編譯管線泥潭。
    方案：第一階段全部砍掉，只保留 Topic Page 作為最小知識編譯層。
  - 研究觀點演化追蹤
    理由：學術價值高，但依賴上面的結構化知識層。
    方案：砍掉，後續等 Topic Page 穩定後再加。
  - 投稿與研究產出輔助
    理由：離核心閱讀場景較遠，且質量門檻高。
    方案：砍掉。
  - Word/Google Docs 深度引用整合
    理由：開發和維護成本高，且實驗室內部不一定高頻依賴。
    方案：用 BibTeX 匯出 和 複製引用 代替。

  四、我建議的最小可行版本

  如果只做一版真正可落地的 ResearchLM v0.1，我會保留這些：

  - 文獻匯入：PDF 匯入、DOI/arXiv URL 匯入、基礎後設資料識別
  - 文獻管理：集合、標籤、閱讀狀態、去重提示
  - 檢索：標題/作者/標籤/摘要搜尋
  - 閱讀：內建 PDF、目錄跳轉、高亮、批註、劃詞翻譯
  - 筆記：論文級筆記、標註回鏈
  - AI：單篇論文摘要、單篇論文問答
  - 知識層：最小 Topic Page
  - 協作：組內共享庫、共享只讀筆記
  - 儲存：本地儲存、資料庫備份
  - 輸入流：RSS 訂閱
  - 輸出流：BibTeX 匯出、複製引用

  五、一個更務實的開發順序

  按單人開發效率，建議順序是：

  1. 本地文獻庫 + PDF 匯入 + 基本後設資料
  2. 集合/標籤/檢索
  3. PDF 閱讀器 + 高亮批註 + 論文筆記
  4. 本地儲存與組內共享
  5. 劃詞翻譯 + 單篇摘要 + 單篇問答
  6. RSS 訂閱
  7. 最小 Topic Page
  8. BibTeX 匯出與備份

  六、最終判斷原則

  對你這個專案，最重要的不是“功能全”，而是這三點：

  - 比 Zotero 更順手地讀論文
  - 比普通 PDF 工具更容易沉澱研究筆記
  - 比 AI 聊天工具更可追溯、更貼近實驗室日常

  一句話收斂：
  ResearchLM 第一版不要做成“小號 Zotero”，而應做成“Zotero 的最小文庫能力 + 更強的閱讀/筆記/單篇 AI 理解 + 很輕的組內知識沉澱”。

  如果你願意，我下一步可以直接把這些判斷整理成一張更明確的表：功能項 | 必須做/簡化做/砍掉 | 理由 | MVP方案。

AI在這一步上可以幫助我們拓寬思路，但是最終的功能取捨仍然取決於自己，可以通過這三個問題來認為確定功能範圍，當然Codex也的確是這樣思考的，整理出最終功能清單。

• 第一問：沒有它產品還成立嗎？ → 區分核心和邊緣功能。
• 第二問：做到什麼程度夠用？ → 功能不必做滿，只需滿足基本場景。
• 第三問：能不能一句話說清楚？ → 用一句話概括產品定位。

3. 技術選型 (Tech Selection)

根據約束條件（一個人開發、本地部署、目標使用者規模）選擇最匹配的技術棧，而不是盲目追求先進。通過和AI溝通，確定出最匹配出前後端、容器相關的技術。

[!Note] 提示詞 ResearchLM 是一個Paper Reader工具，一個人開發，本地部署，目標 10-20 人使用。幫我給出兩個技術方案（技術棧），並對比方案的優劣。

  **方案一**：Web 全棧方案
  FastAPI + SQLite/PostgreSQL + React + TypeScript + PDF.js + Tauri（可選桌面殼）

  適合你想把產品做成“瀏覽器可用，也可以後面打包桌面端”的形態。

  - 後端
    FastAPI 負責文獻庫、筆記、標註、搜尋、AI 呼叫代理、RSS 拉取、檔案管理。
  - 資料庫
    早期用 SQLite 就夠，後期如果組內多人同時使用明顯增多，再切 PostgreSQL。
  - 前端
    React + TypeScript 做文獻庫、閱讀器 UI、設定頁、知識頁。
  - PDF 閱讀
    用 PDF.js，這是最穩妥的瀏覽器端 PDF 閱讀基礎設施。
  - 桌面化
    如果你希望單機體驗更像 Zotero，可後續用 Tauri 打包。

  優點：

  - 產品形態最靈活
    既能做區域網 Web，也能後續封裝成桌面應用。
  - 前後端邊界清晰
    便於後面逐步擴充套件 AI、知識頁、共享功能。
  - 生態成熟
    FastAPI、React、PDF.js 都很成熟，資料多，踩坑相對可控。
  - 更適合做閱讀器體驗
    前端 UI 可控性強，後續做高亮、批註、側邊欄、主題頁更自然。

  缺點：

  - 單人開發成本更高
    你要同時維護前端、後端、打包、狀態管理。
  - 工程複雜度更高
    比較容易在“前端互動細節”上消耗大量時間。
  - 部署鏈條略長
    即使本地部署，也通常涉及前後端服務或打包流程。

  適用判斷：

  - 如果你把 ResearchLM 視為一個長期產品，而不只是組內小工具，這個方案更穩。

  ———

  **方案二**：Python 桌面應用方案
  PySide6 / Qt + SQLite + PDFium/PyMuPDF + FastAPI（僅 AI/同步輔助，可選）

  適合你想快速做一個“像 Zotero 一樣的本地桌面工具”。

  - 桌面端
    用 PySide6 做主介面、文獻庫、側邊欄、設定頁、筆記面板。
  - 資料庫
    用 SQLite 儲存題錄、標籤、筆記、標註、模型配置。
  - PDF 閱讀
    可以考慮 Qt PDF、PDFium 封裝，或 PyMuPDF 做解析與標註支援。
  - AI 能力
    直接在本地 Python 層呼叫使用者配置的 API；如果以後需要區域網共享，再加一個輕量 FastAPI 服務層。

  優點：

  - 更接近 Zotero 的使用方式
    本地應用、檔案系統友好、離線優先。
  - 單人開發路徑更短
    主要用一門語言 Python，上下文切換少。
  - 本地檔案和資料庫處理方便
    PDF、附件、匯出、備份都更直接。
  - 部署更符合“本地部署”
    對 10-20 人組內環境，可以直接發安裝包或執行目錄。

  缺點：

  - UI 現代感和互動靈活度不如 Web
    想把閱讀器互動做到很精緻，會比 React 更吃力。
  - PDF 閱讀體驗實現難度不一定更低
    Qt 桌面 PDF 方案能用，但很多細節不如 PDF.js 成熟。
  - 多人共享擴充套件性一般
    如果後面真要多人同時協作、跨裝置訪問，桌面優先架構會逐漸吃虧。

  適用判斷：

  - 如果你當前目標是 儘快做出可用版本，並且主要場景是個人或實驗室內部固定電腦使用，這個方案更務實。

  ———

  直接對比

  - 開發效率
    方案二通常更高，因為主要在 Python 內完成。
  - 閱讀器體驗上限
    方案一通常更高，尤其是 PDF 閱讀、批註和側欄互動。
  - 本地部署契合度
    方案二更天然。
  - 後續擴充套件為多人區域網產品
    方案一更好。
  - 維護複雜度
    方案二前期更低，方案一長期更規範。
  - 實現 raw-wiki / AI 知識頁
    兩者都能做，但方案一更適合複雜知識介面。
  - 像 Zotero 的感覺
    方案二更像桌面工具，方案一更像現代研究 Web 應用。

由於我目前想一個人儘快做出實驗室內可用版本，所以我選擇方案二：PySide6 + SQLite + Python 本地 AI 接入。

4. 維運預期 (Ops Expectations)

開發前需要提前考慮執行環境，對 ResearchLM 這種 單人開發 + 本地部署 + 10-20 人組內使用 的工具，維運重點不是高併發，而是：能裝起來、不丟資料、出問題能恢復、你自己維護得動。也就是說，提前考慮的不是“大廠式維運”，而是“小團隊長期可用性”。這一步需要一定的開發經驗，考慮好後再讓AI查缺補漏。

[!Note] 提示詞 Researchlm 是一個Paper Reader工具，單機桌面部署，安裝包雙擊安裝，列出需要提前考慮的維運事項。

 對 ResearchLM 這種 單機桌面部署 + 雙擊安裝 + 個人維護 的工具，維運重點不是伺服器擴容，而是 安裝穩定、升級不壞、資料不丟、出問題能定位。
  可以提前按下面幾類考慮。

  一、安裝與釋出

  - 安裝包形態
    先確定用 msi、exe 安裝器，還是綠色版。核心是讓使用者雙擊即可安裝，並儘量減少額外依賴。
  - 執行環境打包
    要決定是否把執行時一起打包，比如 Python、Qt/WebView、資料庫驅動。原則是不要依賴使用者自己裝環境。
  - 安裝路徑與許可權
    需要提前想清楚程式裝在哪裡、資料預設放在哪裡，是否會遇到系統許可權問題。應用目錄和使用者資料目錄最好分離。
  - 自動更新或手動更新
    要決定後續是讓使用者下載新安裝包覆蓋安裝，還是做內建更新。對單人專案來說，手動更新通常更穩。
  - 程式碼簽名與殺軟誤報
    桌面安裝包很容易被 Windows Defender 或殺軟攔截。要提前考慮簽名、白名單說明或最小化誤報策略。

  二、資料儲存與備份

  - 資料目錄設計
    需要明確哪些資料存本地：題錄、PDF、標註、筆記、生詞表、模型配置、日誌。目錄結構一開始就要清晰。
  - 資料庫與附件分離
    建議把 SQLite 資料庫和 PDF/附件 分開存。這樣更容易備份、恢復和遷移。
  - 備份機制
    至少要支援一鍵匯出備份。更穩妥的是支援自動備份資料庫和關鍵配置。
  - 恢復流程
    不只是能備份，還要能恢復。你需要提前驗證：換一臺機器後，能否用備份完整恢復文獻庫和筆記。
  - 誤刪保護
    論文、筆記、標註最好不要直接永久刪除。至少要有軟刪除或回收站思路。

  三、升級與相容

  - 覆蓋安裝是否保留資料
    使用者升級時最關心“舊資料還在不在”。安裝和升級流程必須保證使用者資料目錄不被覆蓋。
  - 資料庫遷移
    一旦版本升級改了表結構，就要有遷移機制。否則舊版本使用者一升級就會損庫。
  - 配置相容
    使用者的 API Key、Base URL、模型名、閱讀器設定、路徑設定應儘量保留。不要讓每次升級都重新配置。
  - 回滾能力
    至少要考慮升級失敗後怎麼恢復舊版本和舊資料。哪怕沒有自動回滾，也要有人工回滾方案。

  四、安全與隱私

  - API Key 本地安全儲存
    既然使用者自己配置模型，金鑰必須本地儲存、脫敏顯示，避免明文暴露在介面和日誌裡。
  - 本地資料隱私
    論文內容、筆記和問答結果可能包含敏感研究內容。要提前考慮哪些資料只儲存在本機，哪些會發給模型介面。
  - 日誌脫敏
    日誌裡不能直接寫 API Key、完整請求頭或不必要的論文正文。排障和隱私要平衡。
  - 網路請求邊界
    要清楚哪些功能會訪問外網，比如 RSS、後設資料解析、模型呼叫。最好讓使用者知道哪些資料會離開本機。

  五、穩定性與異常處理

  - 單點故障隔離
    一篇壞 PDF、一次翻譯失敗、一個 RSS 源報錯，不應該把整個應用拖崩。區域性失敗要能隔離。
  - 任務失敗重試
    像後設資料識別、全文索引、AI 摘要、RSS 拉取這些後臺任務，最好有最簡單的失敗重試機制。
  - 損壞檔案處理
    需要考慮 PDF 打不開、附件路徑丟失、資料庫異常時怎麼辦。至少要給出明確提示，而不是靜默失敗。
  - 啟動失敗診斷
    如果應用啟動不起來，最好能留下日誌或錯誤報告。否則你幾乎無法遠端幫使用者排查。

  六、日誌與排障

  - 本地日誌
    必須有日誌檔案，至少記錄啟動、資料庫、檔案讀寫、模型呼叫、任務錯誤。沒有日誌就很難維護。
  - 日誌分級
    最少區分 info / warning / error。這樣使用者出問題時你能快速定位重點。
  - 診斷資訊匯出
    最好支援一鍵匯出版本號、系統資訊、配置摘要和日誌。組員報障時這會非常省時間。

  七、效能與資源

  - 磁碟佔用
    論文 PDF、附件和索引會越來越大。要提前考慮預設儲存位置、可否改目錄、磁碟不足時如何提示。
  - 索引與 AI 任務資源佔用
    全文檢索、PDF 解析、摘要問答都會吃 CPU 和記憶體。要避免這些任務阻塞主介面。
  - 模型請求超時
    使用者填寫的模型 URL 可能很慢或不可達。呼叫必須有超時、取消和錯誤提示，否則會卡住體驗。

  八、使用者支援與文件

  - 安裝說明
    要寫清楚安裝步驟、支援系統版本、常見報錯。雙擊安裝不等於零問題。
  - 備份恢復說明
    使用者必須知道資料在哪、怎麼備份、怎麼遷移到新電腦。
  - 升級說明
    每次發新版都要說明是否涉及資料庫遷移、是否需要備份、有什麼相容變化。
  - 常見問題
    例如 PDF 打不開、模型連不上、RSS 失敗、資料庫損壞，這些最好提前整理成 FAQ。

  九、桌面應用特有事項

  - 檔案關聯
    是否支援雙擊 PDF 用 ResearchLM 開啟，要不要搶預設開啟方式，這要提前想清楚。
  - 系統托盤與後臺行為
    關閉視窗後是退出程式還是最小化到托盤，這會影響使用者理解和後臺任務行為。
  - 多例項策略
    是否允許同時開啟多個例項。桌面應用如果多開，容易引發資料庫鎖或資料衝突。
  - 路徑遷移
    使用者換盤、換電腦、移動文獻目錄後，系統能否重新定位附件路徑，這一點很重要。

  一句話收斂

  對單機桌面版 ResearchLM，最該提前考慮的維運事項是：

  怎麼順利安裝，怎麼安全存資料，怎麼備份恢復，怎麼平穩升級，怎麼記錄日誌並排查問題。

讀懂AI的建議同樣需要一定的開發經驗，因此對於專業程式設計師來說，相對普通人進行Vibe Coding是有相當優勢的。這些有關維運預期判斷雖然不需要很精確，但它們會反向影響技術選型和架構決策。

5. 落成規範與計劃 (Planning & Annotation)

將上述所有決定（產品定義、功能範圍、技術選型、維運預期等）寫入專案根目錄的規範檔案，如 CLAUDE.md、cursor.rules 或 windsurf.rules。這將作為 AI 的“長期記憶”和工作指南，在每次對話時作為系統提示詞發給模型。

[!Note] 提示詞 根據我們的討論，幫我把 ResearchLM 的專案概述寫進 AGENTS.md 的“專案概述”部分。包括產品定位、做什麼、不做什麼、技術棧、部署與維運預期。格式簡潔明瞭。

## 專案概述  
  
ResearchLM 是一個面向實驗室內部 10-20 人使用、支援本地部署和使用者自帶模型接入的 AI 增強型 Paper Reader。
  
### 做什麼  

- 文獻匯入：PDF 匯入、DOI/arXiv URL 匯入、基礎後設資料識別
- 文獻管理：集合、標籤、閱讀狀態、去重提示
- 檢索：標題/作者/標籤/摘要搜尋
- 閱讀：內建 PDF、目錄跳轉、高亮、批註、劃詞翻譯
- 筆記：論文級筆記、標註回鏈
- AI：單篇論文摘要、單篇論文問答
- 知識層：最小 Topic Page
- 儲存：本地儲存、Github備份
- 輸入流：RSS 訂閱
- 輸出流：BibTeX 匯出、複製引用  
  
### 不做什麼  
  
- 不做面向公網的 SaaS。  
- 不做開發者託管模型。  
- 不做複雜多租戶許可權系統。  
- 不做重型推薦系統。  
- 不做完整平臺級模型路由、計費和多提供商生態適配。  
- 不在第一階段追求跨端同步、複雜協同和大而全的知識圖譜。  
  
### 技術棧  
  
- 採用 `PySide6 / Qt + SQLite + PDFium/PyMuPDF + FastAPI`。  
- `PySide6` 負責桌面主介面、文獻庫、閱讀器、設定頁和筆記面板。  
- `SQLite` 儲存題錄、標籤、筆記、標註和模型配置。  
- PDF 相關能力由 `Qt PDF`、`PDFium` 封裝或 `PyMuPDF` 提供。  
- AI 功能預設在本地 Python 層呼叫使用者自行配置的 `API Key + Base URL + Model`。  
- `FastAPI` 僅作為後續需要輕量共享能力時的可選服務層。  
  
### 部署與維運預期  
  
- 以單機桌面部署為主，通過雙擊安裝包交付。  
- 預設本地儲存 PDF、題錄、標註、筆記、Topic Page、日誌和模型配置。  
- 維運重點是安裝穩定、升級相容、資料庫與附件備份恢復、日誌排障和 API Key 本地安全儲存。  
- 壞 PDF、失敗任務和外部 API 異常不應拖垮整個應用。  
- 不引入雲端擴縮容和複雜基礎設施管理。

這步也可以使用Codex提供的/init命令，它會自動將討論內容寫入AGENTS.檔案。AI形成初稿之後要人工review一遍，然後隨著專案推進不斷更新。

[!Note] 提示詞 ResearchLM是一個Python應用，功能包括文獻匯入、文獻管理、檢索、閱讀、筆記、AI輔助閱讀、儲存、RSS訂閱、匯出、模型管理等功能。一個人開發、10人使用，程式碼內部怎麼組織？給我方案對比。