在写程序之前，如何利用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人使用，代码内部怎么组织？给我方案对比。