Files
backend/docs/08-AI辅助功能规划.md
T
34047007@qq.com a6cd99a4ca
CI / backend (push) Canceled after 0s
CI / frontend (push) Canceled after 0s
feat: initial commit - oncology literature search platform
OncoLit: a multi-tenant oncology literature search, feed, and
collaboration platform. Built with FastAPI + Vue 3 + PostgreSQL.
Includes PubMed pipeline, drug approvals, AI summaries, and
systematic review tools.
2026-07-27 07:59:18 +08:00

30 KiB
Raw Blame History

AI 辅助功能规划

最后更新:2026-07-12

一、定位与分级

核心理念

用户投入度分级——用得越深,价值越大,付费意愿越强。

层级 本质 用户投入 付费天花板
Tier 1 AI 解读 一次性信息压缩 零(进来就看) 免费/专业版
Tier 2 知识库 + RAG 持续积累的结构化资产 收藏/上传即建库 专业版/团队版
Tier 3 个性化 AI 主动助手,按需配置 设定研究方向/模板 团队版

与现有功能的关系

文献 ai_summary JSON 列已存在,但管道导入不生成,全部 1.4M 基线文献 ai_summary 均为 NULL。Tier 1 的核心是:有缓存直接展示,无缓存显示"生成 AI 解读"按钮,用户点击后调用 DeepSeek 并持久化到数据库。Tier 2 和 3 是全新功能,需要新建数据模型和服务。

与评分系统的协同

评分系统解决**"哪篇值得读"AI 辅助解决"读完后得到了什么"**。评分在前端排序层,AI 在内容展示层,互不依赖但互补——高分文献自动获得更深入的 AI 解读。


二、Tier 1AI 文献解读

定位

不改变用户习惯,进来就看。 核心价值是省时间,降低文献阅读的认知负担。

功能

功能 数据来源 当前状态
一句话总结(one-liner ai_summary.summary 空(需按需生成)
结构化解读(背景/方法/结果/结论) ai_summary.sections 空(需按需生成)
中文翻译 ai_summary.translation 空(需按需生成)
PICO 抽取 pico 字段(population/intervention/comparison/outcome Meta 分析已有,前端未展示
关键数据提取 ai_summary.tables(样本量、HR、PFS/OS 等) 后端无此格式,需新增输出模板

前端展示

在文献详情页新增「AI 解读」标签页,与「摘要」「全文」并列:

┌──────────────────────────────────────────────┐
│ 摘要 │ AI 解读 │ 全文     ← 标签页切换         │
├──────────────────────────────────────────────┤
│                                              │
│ 一句话总结                                    │
│ 这项 III 期研究显示 Amivantamab 联合化疗比化  │
│ 疗显著改善 PFS(9.2 vs 5.8 月),可能改变     │
│ EGFR Exon20ins 一线标准。                     │
│                                              │
│ ── 研究背景 ──                                │
│ EGFR Exon20ins 对传统 TKI 不敏感...           │
│                                              │
│ ── 关键数据 ──                                │
│ │ 指标      │ 试验组 │ 对照组 │ HR   │       │
│ │ mPFS     │ 9.2mo  │ 5.8mo  │ 0.58 │       │
│ │ 客观缓解率 │ 53%    │ 29%    │      │       │
│ │ 3级AE    │ 42%    │ 36%    │      │       │
│                                              │
│ ── 临床意义 ──                                │
│ 首个针对 EGFR Exon20ins 一线 III 期数据,     │
│ 已纳入 NCCN 指南推荐。                         │
└──────────────────────────────────────────────┘

免费 vs 付费差异

功能 免费 专业版 团队版
一句话总结 每日前 5 篇 无限 无限
结构化解读
关键数据表格
中文翻译

执行

前端工作 + 调用已有后端 API。

  • ai_summary 的文献(新管道导入后可能有)→ 直接渲染展示
  • ai_summary 的文献(全部基线 1.4M 篇 + 管道未触发生成的)→ 显示「生成 AI 解读」按钮
  • 用户点击 → 调 POST /ai/generate/{pmid} → DeepSeek 生成 → 写入 ai_summary JSON 列 → 返回前端展示
  • 后续任何用户打开同篇文献 → 直接命中数据库
  • 不做批量预生成、无定时任务、不改变管道导入逻辑

这个按需生成用现有 AiProviderConfig 配置即可,不依赖 embedding/ES,只取 title+abstract → DeepSeek → 入库。


三、Tier 2:知识库 + RAG

定位

从"收藏夹"升级为"用户的第二个大脑"。 用户收藏的文献、上传的文件、写的笔记,混合成一个可检索、可问答的个人知识库。

3.1 核心原则:收藏即建库

用户不需要做任何额外操作。收藏一篇文章,自动进入知识库。知识库不是另一个页面,而是收藏功能的自然延伸。

用户点击收藏
    ↓
写入 user_favorite(已有表)
    ↓
新增一条 knowledge_entry
    ↓
异步 embeddingARQ 任务)
    ↓
写入 ES 向量索引

3.2 多源融合

知识库不只装文献,而是三类数据的混合:

来源 进入方式 存储
平台文献 用户收藏/评分(自动) 已有 DB + ES
用户笔记 在文献详情页写笔记(自动关联) 已有 notes 表
用户上传文件 手动上传 PDF/Word/PPT/Markdown 对象存储 MinIO/COS
第三方文档 乐享集成/本地同步(预留接口) 适配器模式

所有来源统一进入 knowledge_entries 表,统一 embedding,统一检索。

3.3 RAG 问答

用户在知识库页面提问,基于自己的知识库回答:

用户提问:EGFR 20ins 耐药机制有哪些?
    ↓
1. query embedding(调 embedding 服务转为向量)
    ↓
2. 向量检索(ES knn,过滤 tenant + usertop_k=8
    ↓
3. 召回结果 + metadata 拼入 prompt
    ↓
4. DeepSeek 生成回答 + 标注引用来源

引用来源标注:

回答:
目前针对 EGFR Exon20ins 的耐药机制主要包括...

参考文献:
[1] Amivantamab in EGFR Exon20ins NSCLC... (PMID: 38712345)
[2] Mobocertinib 耐药机制分析... (您收藏的文献)
[3] 您整理的耐药机制笔记.docx (您上传的文件)

3.4 知识图谱(分步实施)

设计说明

知识图谱不是 RAG 的前置依赖,而是在 RAG 有了用户和内容之后自然长出的增值特性。RAG 擅长"找相似文本",图谱擅长"看关系路径"——两者互补。

不存在时先不产生价值,与其急着做不如等用户有数据积累后再做。

Phase 1:共现关系图谱(最简单,有收藏数据即可跑)

用户收藏了 100 篇文献
    ↓
后台 NER 提取药物、基因、疾病、研究类型等实体
    ↓
同一篇文献中出现的实体自动建立共现关系
    ↓
前端展示为"探索"视图:实体节点 + 关联线

用户看到的是:

[奥希替尼] ─── 出现在 12 篇收藏中 ─── [EGFR Exon19del]
     │                                        │
     │ 出现在 5 篇收藏中                       │ 出现在 8 篇收藏中
     │                                        │
[Amivantamab] ─── 出现在 3 篇收藏中 ─── [EGFR Exon20ins]

对用户的价值:"我收藏的文献里,哪些概念是关联的?"——帮助用户发现自己的知识盲区或研究热点。

Phase 2:外部知识融合(需要对接外部数据源)

将 PubChem、DrugBank、ClinicalTrials.gov 的结构化关系导入,叠加在用户图谱之上:

[奥希替尼] ── 靶向 ──→ [EGFR T790M]     ← 权威层 (DrugBank)
[奥希替尼] ── 获批适应症 ──→ [NSCLC]     ← 权威层
[奥希替尼] ── 用户标注 ──→ [耐药机制笔记]  ← 用户层

两层叠加:用户看到的不只是"哪些文献提到了奥希替尼",还包括"奥希替尼的靶点是什么、获批了哪些适应症"。

Phase 3:图谱问答(融合 RAG + Graph)

用户问"奥希替尼耐药后有哪些方案",系统先查图谱关系链:

[奥希替尼] ── 耐药后方案 ──→ [Amivantamab, 化疗, MET抑制剂...]
    ↓
找到关联文献(每篇文献可能对应多个方案)
    ↓
RAG 检索具体数据(HR、PFS、OS)
    ↓
回答:"奥希替尼耐药后可选方案包括:1) Amivantamab + 化疗(mPFS 9.2mo..."

这本质是 GraphRAG,但对当前阶段太远了。 Phase 1-2 足够先用起来。

3.5 数据模型

class KnowledgeEntry(Base):
    """知识库条目——收藏/上传/笔记的统一入口"""
    __tablename__ = "knowledge_entries"

    id: Mapped[uuid.UUID] = mapped_column(primary_key=True)
    tenant_id: Mapped[uuid.UUID] = mapped_column(ForeignKey("tenants.id"))
    user_id: Mapped[uuid.UUID] = mapped_column(ForeignKey("users.id"))

    entry_type: Mapped[str]     # literature | note | file
    source_type: Mapped[str | None]  # global_literature | user_note | upload
    source_id: Mapped[str | None]    # pmid | note_id | upload_id

    chunk_text: Mapped[str]     # 分块后的文本
    chunk_index: Mapped[int]    # 第几块(一篇文献可多块)
    metadata: Mapped[dict | None]   # JSON,来源/页码/标签

    embedding_id: Mapped[str | None] # ES doc id
    is_embedded: Mapped[bool] = mapped_column(default=False)
    created_at: Mapped[datetime] = mapped_column(server_default=func.now())

3.6 前端展示

知识库页面布局:

┌──────────────────────────────────────────────────┐
│  🔍 搜索知识库...                         视图切换 │
├──────────────────────────────────────────────────┤
│  筛选: 全部 | 文献 | 笔记 | 上传文件              │
├──────────────────────────────────────────────────┤
│ ┌────────────────────┐  ┌────────────────────┐   │
│ │ 📄 肺癌新辅助免疫   │  │ 📎 耐药机制笔记    │   │
│ │ 治疗III期研究...    │  │ 上传 2026-07-11   │   │
│ │ 收藏 2026-07-10    │  │ 2页 · docx        │   │
│ │ EGFR, 免疫治疗     │  │                   │   │
│ └────────────────────┘  └────────────────────┘   │
│ ┌────────────────────────────────────────┐        │
│ │ 💬 问你的知识库...              [发送]   │        │
│ └────────────────────────────────────────┘        │
└──────────────────────────────────────────────────┘

同时保留现有 LibraryView(收藏夹管理),在其上加一个入口:"探索知识库"。


四、Tier 3:个性化 AI

定位

从"被动应答"到"主动理解"。 用户告诉 AI 自己的研究方向,AI 据此调整所有解读的角度。

4.1 研究方向配置

用户设定:

{
  "direction": "肺癌靶向治疗和耐药机制",
  "focus": ["EGFR突变", "耐药机制", "双抗"],
  "patient_population": "EGFR突变NSCLC患者",
  "preferred_therapy": ["靶向治疗", "ADC"],
  "avoid": ["基础研究", "cell line实验"]
}

设定后,Tier 1 和 Tier 2 的所有输出自动适配:

场景 无研究方向时 有研究方向时
AI 解读 标准结构化摘要 重点突出 EGFR 相关数据、耐药机制讨论
RAG 问答 泛泛回答 优先引用靶向治疗相关的收藏文献
每日 Feed 按评分排序 研究方向相关文献自动提升优先级

4.2 自定义 Prompt 模板(高阶)

用户可编写自己的 AI 解读模板:

用户预设模板(免疫方向):
"请重点分析:1) 肿瘤微环境相关数据(TIL、PD-L1、TMB)
2) 免疫相关不良事件(irAE)的发生率和处理
3) 生物标志物分析(如适用)"

→ 之后每次 AI 解读都按此模板执行

实现方式:prompt 模板不涉及后端改动,在 AiProviderConfig 的 prompt 字段中附加用户模板。每次调用 DeepSeek 时拼接。

4.3 多模型选择

模型 用途 成本 适用层级
DeepSeek(默认) 日常解读、RAG 问答 Tier 1+2
GPT-4o 深度分析、复杂推理 Tier 3
本地模型(Ollama 敏感数据不经过外网 零 API 费用 团队版私有部署

用户可在设置中选择默认模型。不同模型走不同的 API Key 配置(AiProviderConfig 已有此设计)。

4.4 免费 vs 付费差异

功能 免费 专业版 团队版
研究方向配置 1 个方向 不限
AI 解读按方向适配
自定义 prompt 模板 (管理员设)
多模型选择
模型调用量配额 5 次/天 50 次/天 按需

五、执行顺序

Phase 1  Tier 1 AI 解读前端 + 按需生成(合并原 Phase 1 + Phase 5
         读写:LiteratureDetailView.vue 新增 AI 解读标签页 + "生成"按钮
         依赖:`ai_summary` JSON 列 + POST /ai/generate/{pmid} API(均有)
         说明:无批量预生成,全部用户触发。不依赖 embedding/ES。

Phase 2  Tier 2 基础——收藏即入知识库
         读写:knowledge_entries 表 + 收藏时自动插入
         依赖:无(新增模型 + 简单逻辑)
         注意:此阶段不上 embedding 和 RAG,只做"浏览我的知识库"

Phase 3  Tier 2 增强——embedding + 全文搜索
         读写:embedding 服务 + ES 向量索引 + ARQ 任务
         依赖:需要部署 embedding 模型(bge-m3
         注意:此阶段仍不上 RAG Q&A,知识库可搜索即可

Phase 4  Tier 2 完成——RAG 问答
         读写:POST /kb/ask API + 前端对话界面
         依赖:Phase 3 完成后才可检索

Phase 5  知识图谱 Phase 1——共现关系图谱
         读写:NER 抽取 + 实体-关系存储 + 前端探索视图
         依赖:用户收藏达到一定量级(建议 500+ 条/租户)

Phase 6  Tier 3 个性化 AI
         读写:研究方向配置 UI + prompt 模板 + 模型选择
         依赖:Tier 1+2 稳定运行,有活跃用户

Phase 7  Tier 2 用户上传文件
         读写:文件上传 API + 解析(PDF/Word + 入知识库
         依赖:对象存储基础设施已就绪

Phase 8  知识图谱 Phase 2——外部知识融合
...

分阶段原则

  • Phase 1 可独立上线——前端 + 调用已有 API,无外部依赖。基线文献全部无 AI 摘要,默认展示"生成"按钮
  • Phase 2-4 是 Tier 2 的三步走——先不 embed 先可浏览,再可搜索,再可问答。每一步都能独立上线,每一步都比上一步更有价值
  • Phase 5 不急于做——等用户收藏量上来再做,不然图谱是空的
  • Phase 6+ 依赖活跃用户基础

六、基础设施依赖

Tier 1(AI 解读)无需新基础设施——复用现有 DeepSeek APIAiProviderConfig)、ai_summary 字段、POST /ai/generate/{pmid} 端点。不依赖 embedding/ES。

以下为 Tier 2/3 及图谱所需的新组件:

新组件 用途 用于 Tier 可复用现有
knowledge_entries 知识库条目 Tier 2 新表
embedding 服务 文本→向量 Tier 2+3 新部署
ES dense_vector 索引 向量存储 Tier 2 ES 已有
NER 抽取服务 实体识别 图谱 新服务
对象存储(文件上传) PDF/Word 存储 Tier 2 MinIO/COS 已有
文件解析服务 PDF→文本 Tier 2 新模块

embedding 服务部署建议:

sentence-transformers + bge-m3 模型,FastAPI 包装。单容器 2GB 内存,CPU 推理足够(每日 ~50 个收藏动作)。先部署一个最小实例,不够再加 GPU。

# embedding_service.py(示意)
from sentence_transformers import SentenceTransformer

model = SentenceTransformer("BAAI/bge-m3")

@app.post("/embed")
async def embed(texts: list[str]):
    embeddings = model.encode(texts, normalize_embeddings=True)
    return {"embeddings": embeddings.tolist()}

七、AI 辅助科研(未来方向)

7.1 定位与前提

从"帮医生省时间读文献"升级到"帮医生发现研究机会"。

前三个 Tier 解决的是信息过载Tier 1 → 省时间、Tier 2 → 建知识库、Tier 3 → 个性化),AI 辅助科研解决的是知识到洞察的跨越

关键判断: AI 辅助科研不是独立产品,而是现有 73 万篇肿瘤文献数据库 + AI 能力之上的一层分析应用。不做垂直的"科研 AI 平台",而是让用户在看完文献后,自然产生下一步研究思路。

前提条件(当前阶段不实现):

  • 基线导入完成,数据库稳定在 100 万+ 篇文献
  • ClinicalTrials.gov 集成完成(数据源计划
  • PubChem 或 DrugBank 集成完成
  • 有活跃的付费用户基础(专业版/团队版)

7.2 功能矩阵

功能 核心能力 数据依赖 价值 复杂度
趋势扫描 MeSH 标签时间序列分析 仅需现有数据库 发现热点/冷点
空白分析 研究设计 × 癌种 × 药物交叉 现有 DB + ClinicalTrials 发现未被充分研究的领域
证据综合 系统性综述辅助(PRISMA 流程) 现有 DB + 搜索 加速综述写作
假设生成 跨领域关联推理 现有 DB + 外部知识库 新研究思路
写作辅助 引用推荐 + 文献综述段落生成 现有 DB + RAG 提高论文写作效率

7.3 功能详解

7.3.1 趋势扫描(Research Trend Scout

本质: 把 MeSH 标签当成时间序列,看什么在增长、什么在衰退。

数据基础: 我们的数据库按年组织,每条文献有 MeSH 标签。统计每年每个标签下的文献数量,就能画出趋势线。

标签:双特异性抗体(Bispecific Antibodies

2021:  12 篇  ████████
2022:  28 篇  ██████████████████
2023:  45 篇  ██████████████████████████████
2024:  89 篇  ██████████████████████████████████████████████████████
2025: 142 篇  ████████████████████████████████████████████████████████████████████████████████

增长率: 2024→2025 = +59.6%
相关标签: ADC, CD3, DLL3, 血液肿瘤, 实体瘤

用户价值:

  • 肿瘤科主任了解领域全貌:"今年肺癌免疫治疗还有哪些新方向?"
  • 研究生选题:"有什么快速增长但还不太卷的方向?"
  • MDT 团队规划:"我们科室应该关注哪些新技术?"

实现路径:

  • 不需要新数据源,只用现有 global_literature + global_literature_tags
  • 按年统计每个标签的文献数 → 计算增长率(YoY, 3-year CAGR
  • 标签间相关性分析(哪些标签经常同篇出现 → 发现研究热点群组)
  • 前端:趋势线图 + 热力图 + 标签关联网络

复杂度评估:低。 纯 SQL 聚合 + 前端图表。后端 100 行代码,前端可复用现有图表组件。

7.3.2 空白分析(Research Gap Analyzer

本质: 已知某药物在某癌种有效,但同一机制在其他癌种是否被研究过?

典型场景:

  • "免疫治疗在胰腺癌中为什么失败率高?有多少研究涉及?"
  • "ADC 药物在 HER2-low 乳腺癌之外,哪些癌种也有 HER2 低表达?"
  • "哪个癌种在 2026 年还没有 III 期 RCT 更新?"

数据基础:

  • 现有数据库:文献总量 + 研究设计分类 + PICO
  • ClinicalTrials.gov(需集成):临床试验全景
  • PubChem/DrugBank:药物-靶点关系

分析维度交叉:

                  NSCLC  SCLC  Breast  Pancreatic  CRC  Gastric
免疫治疗           ████    ██    ███     ██        ██    ██
ADC                ███    █     ████     █         █     █
CAR-T              █      ███   ██       █         ██    █
双抗               ██     █     ██       █         █     ██
T cell engager     █      █     █        █         ██    █

色阶: █=1-10篇  ██=11-50  ███=51-200  ████=200+
空白 = 该领域几乎没有研究 = 潜在的研究方向

用户价值:

  • 帮助研究者找到真正的研究空白(不是"没人做过"而是"有理论基础但没人做过")
  • 基金申请时用来论证"本研究填补了XX空白"
  • 科室科研规划时明确投入方向

复杂度评估:中。 主要是 ClinicalTrials.gov 的集成工作量。数据集成本身已在规划中(参考数据源丰富计划),分析逻辑本身不复杂。

7.3.3 证据综合(Evidence Synthesis / AI Systematic Review

本质: 系统性综述是肿瘤学研究的核心方法。AI 不是替代研究者,而是把最机械的部分自动化。

用户旅程:

研究者提出 PICOS 问题:
"在 EGFR 20ins NSCLC 中,Amivantamab 对比化疗的疗效和安全性?"

Step 1: AI 生成搜索策略
  └→ 自动构造 PubMed 查询语句
  └→ 推荐 MeSH 词 + 自由词组合
  └→ 输出 PRISMA 流程图可用的搜索策略

Step 2: 检索 + 去重
  └→ 在我们的数据库中搜索 + 可扩展到 PubMed
  └→ 自动去重(基于 PMID

Step 3: AI 筛选(Title/Abstract)
  └→ 对每篇文献判断是否符合纳入标准
  └→ 输出:"纳入 12 篇 / 排除 48 篇 / 存疑 5 篇(需人工判断)"

Step 4: 数据提取
  └→ 从纳入文献提取:样本量、人群、干预、对照、结局
  └→ 输出结构化证据表格

Step 5: 辅助合成
  └→ 森林图草稿
  └→ 异质性分析提示
  └→ 证据质量评价(GRADE 辅助)

与现有功能的关系:

  • 搜索策略生成 → 复用现有搜索 API(search_engine.py
  • 筛选 → 需要新的 AI 判断 pipeline
  • 数据提取 → 复用现有 PICO 抽取(pico 字段)
  • 导出 → 复用现有批量导出

价值判断: 这是 AI 辅助科研中用户需求最强烈的功能。每个肿瘤科研究生/年轻医生在写综述时都经历过"筛 3000 篇文献"的痛苦。但工程复杂度也最高。

复杂度评估:中高。 影响范围大(搜索 + 筛选 + 提取 + 合成),需要独立模块。建议从 Step 1-3(搜索策略 + 自动筛选)开始 MVP,确认用户买单再做 Step 4-5。

7.3.4 假设生成(Hypothesis Generator

本质: 跨文献、跨癌种、跨药物的模式匹配——发现"这个药在那个癌种有效,同样的机制在另一个癌种可能也有效"。

数据驱动 vs 模型驱动:

  • 数据驱动(可行): 找相同靶点的药在不同癌种的疗效差异。如果 Drug X 靶向靶点 T,在 Cancer A 有阳性 III 期数据,但在 Cancer B 只有病例报告,则 Cancer B 可能是研究空白
  • 模型驱动(远期): 让 AI 阅读大量文献后,"猜测"某个新组合可能有效。这需要更强大的推理能力和已知的知识图谱,当前阶段不建议做

数据驱动的实现思路:

1. 从 PubChem/DrugBank 获取药物-靶点关系
2. 从文献中提取药物-癌种疗效数据
3. 交叉匹配:
   药物 X → 靶点 T → 在 Cancer A 有效
   药物 Y → 靶点 T → 在 Cancer B 有数据吗?
4. 输出假设:
   "Drug X 在 Cancer A 中显示 ORR 60%,机制是靶向 T。
    Cancer C 也高度表达 T(来自文献 PMID: 12345),
    但尚无 Drug X 在 Cancer C 的研究。
    建议探索 Drug X 在 Cancer C 中的疗效。"

复杂度评估:高。 需要 PubChem 完整集成、药物-靶点命名标准化、实体对齐。这是最远离当前产品的能力。

7.3.5 写作辅助(Writing Assistant

本质: 利用文献数据库 + AI,在用户写作时提供引用推荐和背景段落。

功能:

  • 智能引用推荐: 用户在写"EGFR 突变在亚洲 NSCLC 患者中的发生率"时,AI 自动推荐最相关、最高引的 3-5 篇参考文献
  • 文献综述段落生成: "写一段关于 Amivantamab 临床开发历程的综述,引用关键研究"
  • 格式自动匹配: 引文格式自动转为目标期刊格式

实现方式:

  • 引用推荐 → 基于搜索 API(已有)+ 评分排序(即将有)
  • 段落生成 → 基于 RAG(Tier 2 完成后的自然延伸)
  • 格式转换 → 已有导出模块

复杂度评估:中。 Tier 2 的 RAG 完成后,写作辅助是上层应用。引用推荐最实用、最轻量,可以独立先行。

7.4 与现有产品的关系

现有产品核心:
帮用户"发现"值得读的文献
    │
Tier 1-3 AI 辅助:
帮用户"理解"已发现的文献
    │
AI 辅助科研(本节):
帮用户"创造"新的知识

三者串起来,用户在每个环节都有价值:

发现 → 已有能力(标签匹配 + Feed + 搜索 + 评分排序)
  ↓
理解 → Tier 1-3(AI 解读 + 知识库 + 个性化)
  ↓
创造 → AI 辅助科研(趋势 + 空白 + 综合 + 假设 + 写作)

不冲突的地方:

  • AI 辅助科研不改变 Feed/搜索/收藏等核心链路
  • 是对"高级用户"(研究人员、研究生、PI)的增值功能
  • 可作为独立的付费附加模块(按需付费或更高的订阅层级)

7.5 执行顺序与条件

┌─────────────────────────────────────────────────────┐
│  条件:基线导入完成 + ClinicalTrials.gov 集成就绪   │
└─────────────────────────────────────────────────────┘
                            │
                            ▼
Phase A  趋势扫描(低复杂度,独立可用)
         读写:后端趋势分析 API + 前端趋势图
         数据:仅需现有数据库
         工期:~1 周(后端 2 天 + 前端 3 天)

Phase B  证据综合 MVP(搜索策略 + AI 筛选)
         读写:AI 筛选 pipeline + PRISMA 流程管理
         数据:现有 DB + DeepSeek
         工期:~2 周
         注意:验证用户是否愿意为"自动筛选"付费

            ←─ 在此验证用户需求,再决定是否继续 ─→

Phase C  空白分析
         读写:ClinicaTrials 集成 + 交叉分析
         数据:ClinicalTrials.gov 完整导入后
         工期:依赖数据集成进度

Phase D  写作辅助
         读写:引用推荐 API + 段落生成
         数据:Tier 2 RAG 完成后
         工期:依赖 Tier 2 进度

Phase E  假设生成
         读写:PubChem 集成 + 实体对齐 + 关联推理
         数据:PubChem/DrugBank 完整导入后
         工期:远期

核心判断:不做则已,要做就做 Phase A 先。 趋势扫描基于现有数据,无外部依赖,是证明"AI 辅助科研"这个方向是否有用户买单的最小闭环。

7.6 风险与取舍

风险 说明 缓解措施
用户不需要"科研辅助" 可能目标用户(临床医生)只想看文献,不想做研究 Phase A 先验证,不做大规模开发
趋势扫描价值不够深 只是"统计图",用户看一眼就完了 结合空白分析才有深度,但走得太快可能做无用功
证据综合做成了"学术不端"工具 AI 写综述可能被滥用绕过真正的文献阅读 定位为"辅助"不是"替代",要求人工确认每一步
数据量不够支撑有意义的趋势分析 73 万篇肿瘤文献对一个癌种细分后可能太少 先做粗粒度趋势(癌种级),细粒度(突变级)等基线完成后
合规风险(AI 辅助科研的学术诚信) 期刊可能不允许 AI 生成内容 所有 AI 输出标注"AI generated",引文必须人工验证

八、不做的改动

  • 知识库不替代收藏夹——收藏夹仍是"快速保存到列表",知识库是"自动积累可检索"。两者共存,收藏夹入口保留在 LibraryView
  • 不上 GraphRAG(当前阶段)——Phase 1-2 的共现图谱已经足够提供"探索"体验,GraphRAG 的工程复杂度远高于收益,等用户量和数据量足够再说
  • 不上 agents/workflow 编排——Tier 3 的个性化只是 prompt 模板 + 模型选择,不做多 agent 编排
  • 不重建文件预览——上传的 PDF/Word 用对象存储的预览 URL 或用 iframe 嵌入,不做自建文档阅读器
  • 不改变现有 Feed 引擎——研究方向配置影响的是 AI 解读角度,不是 Feed 匹配逻辑
  • 不做用户级 embedding 模型微调——方向配置通过 prompt 工程实现,不训练模型