AIclinicalresearch/docs/03-业务模块/ASL-AI智能文献/00-系统设计/V2.0 迭代升级/Deep Research V4.1 产品需求文档.md

产品需求文档 (PRD)：ASL - 智能文献检索 (Deep Research) V4.1

📑 1. 文档概述

属性	说明
产品名称	AI Clinical - ASL 智能文献模块
功能模块	Deep Research (智能文献检索)
文档版本	V4.1 (自然语言需求确认版)
目标受众	研发团队、UI/UX 设计师、测试工程师
当前痛点	传统医学检索要求医生手动编写复杂的布尔逻辑（Boolean Query），学习成本极高；MVP版本直接盲搜容易偏离意图；强加聊天框（Chat UI）又会破坏工具的沉浸感。
核心目标	采用**“单页瀑布流 + 自然语言需求扩写 (Requirement Expansion) + 人机协同编辑”**的极简专业工作流，彻底消除布尔逻辑的门槛，充分发挥底层深搜大模型的能力。

🎯 2. 用户故事与核心工作流 (User Workflow)

UX 核心理念：单页瀑布流 (Progressive Disclosure) + 大白话指令驱动

本版本摒弃了传统数据库必须的“检索式”，改为生成一份**“深度检索指令书”**。

标准工作流 (The Happy Path)：

1. 粗略输入 (Input)： 医生在顶部文本框中输入一个极其粗略的想法（如“他汀预防心血管疾病，要能下载PDF的”），并勾选数据库范围和年份。
2. 意图扩写 (Generate)： 点击“生成需求书”，系统内置的 LLM 将这句话扩写为一份结构严谨、逻辑清晰的**《自然语言检索指令书》**，并在下方展开【策略确认区】。
3. 人工核验与修改 (Edit - HITL)： 医生在可编辑的文本区内审查这份指令书。如果发现 AI 遗漏了限定条件（如未限定 RCT），可以直接像写邮件一样用大白话打字补充进去。
4. 异步深搜 (Execute)： 确认无误后点击“执行”，系统展开【AI 执行终端】。该自然语言指令被直接发送给底层 Unifuncs 深搜引擎，任务进入后台队列。
5. 透明执行 (Monitor)： 终端实时打印深搜引擎跨库检索、阅读、抓取 PDF 的进度日志。
6. 成果交付 (Results)： 任务完成后，最下方展开包含图表、文献清单、综合报告的【结果看板】。

💻 3. 详细功能需求说明 (Functional Requirements)

模块 3.1：检索立项配置区 (Step 1: Setup)

• 自然语言输入区 (Textarea)： 提供大号文本域，支持用户随意输入临床问题。
• 数据源与高级过滤 (Options)：
  • 目标数据源 (Checkbox)：PubMed/PMC, BMJ Open/Lancet(OA), Cochrane Library。
  • 发表年份 (Dropdown)：2010至今, 过去5年, 不限。
  • 目标文献数 (Dropdown)：~100篇(测试集), 全面检索。
  • 强制约束项 (Checkbox)：高亮显示“强制要求：仅限可获取免费全文 (PDF Open Access)”。
• 触发动作： 点击“解析并生成检索需求书”按钮。系统进行短暂 Loading 后，平滑向下滑出 Step 2。

模块 3.2：检索策略确认区 (Step 2: Strategy HITL)

设计意图： 破除代码恐惧感，建立基于自然语言的专业信任。

• 左侧 - 核心意图提炼 (Read-only 卡片)：
  • 用精简的 UI 块展示 AI 提取出的结构化要素（例如🎯核心目标、💊干预/疾病、📚文献标准）。
  • 包含一个“预估命中率”的视觉反馈标签。
• 右侧 - 深度检索指令书编辑器 (Code Editor UI, but Plain Text)：
  • (核心交互) 这是一个必须可编辑的宽大文本框 (Textarea)。
  • 里面展示由 AI 生成的一篇结构化大白话要求（如：【核心主题】...【目标文献类型】...【强制数据要求】...）。
  • 提示文案引导用户：“您可以像写邮件一样在这里补充任何大白话要求，底层的深搜大模型会完美理解。”
• 触发动作： 点击“确认需求，启动 Deep Research”。向下滑出 Step 3。

模块 3.3：AI 执行终端区 (Step 3: Agent Terminal)

• 极客暗黑终端 (Dark Mode Log View)： 固定高度（550px），内部滚动，顶部带脉冲闪烁的 Running 状态灯。
• 阶段化日志流 (Event Stream)： 实时打印后台 Worker 轮询获取到的状态，分为不同的视觉样式：
  • [Thinking] 紫色：AI 分析问题、过滤非 RCT 文献的思考过程。
  • [Action] 蓝色：执行具体站点的 Search 动作。
  • [Done] 绿色：阶段性爬取成功。
  • [Summary] 黄色：阶段性总结。
• 前端交互：日志增加时，容器需自动滚动到最底部。

模块 3.4：最终交付结果大屏 (Step 4: Results Dashboard)

• 统计看板 (Top Row)： * 数量概览卡片（包含 OA 获取率、研究类型占比）。
  • 动态图表（Chart.js）：文献来源分布（饼图）、发表年份趋势（柱状图）。
• 详情双 Tab 视图：
  • Tab A - 核心文献清单： 表格展示 Title, Authors, Journal, Year, Type, PDF状态。
  • Tab B - 智能综合报告： AI 基于摘要生成的 Markdown 深度报告（背景、共识、研究空白 Gap）。
• 科研资产流转 (Actions)：
  • 推送至 ASL 初筛池（无缝流入下一阶段的筛选工作流）。
  • 导出 Excel、Word 报告、RIS 引文。

⚙️ 4. 技术架构与底层实现规约 (Architecture Specs)

4.1 系统数据流向

1. 指令扩写层 (本系统)： 前端提交 original_query -> Node.js 调用内部 DeepSeek-V3 -> 返回一段 Markdown 格式的自然语言检索需求书 (Requirement)。
2. 异步执行层 (pg-boss + Unifuncs)： 用户确认后的 confirmed_requirement -> 压入 pg-boss 队列 -> Worker 将该自然语言原封不动地发给 Unifuncs /v1/create_task 接口。由 Unifuncs 内部去理解大白话并自主执行复杂爬虫。
3. 状态透传层： Worker 轮询 Unifuncs 的 reasoning_content，正则提取并写入 PostgreSQL 的 execution_logs 数组。前端只负责拉取 DB 渲染，实现状态解耦。

4.2 数据库 Schema (Prisma)

model AslResearchTask {
id String @id @default(uuid())
user_id String

// Step 1: 原始输入配置
original_query String @db.Text
target_sources Json
filters Json

// Step 2: HITL 策略确认阶段
ai_intent_summary Json? // 左侧小卡片用的结构化摘要
confirmed_requirement String? @db.Text // 核心：用户最终复核并修改后的自然语言指令书

// Step 3: 执行与状态
status String // 'draft', 'pending', 'running', 'completed', 'failed'
unifuncs_task_id String? // 绑定的深搜任务ID
execution_logs Json? // 终端执行日志数组 (增量更新)

// Step 4: 交付资产
result_list Json? // 抓取到的文献元数据列表
synthesis_report String? @db.Text // Markdown 综合报告

created_at DateTime @default(now())
updated_at DateTime @updatedAt
}

4.3 Unifuncs 核心 Payload 规约

在 Worker 请求 Unifuncs 时，利用其强大的指令遵循能力，强制分离报告与 JSON 列表：

const unifuncsPayload = {
model: "s2",
messages: [{
role: "user",
content: `请严格根据以下检索需求执行深度研究：\n${task.confirmed_requirement}`
}],
// 核心约束：强制要求 XML tag 隔离输出，确保前端渲染不崩溃
output_prompt: `
请严格按照以下两部分输出结果，不要包含任何其他废话：
<REPORT_SECTION>
[此处撰写深度综合报告，包括研究背景、核心共识、分歧点]
</REPORT_SECTION>

\<JSON\_LIST\_SECTION\>  
\[此处输出文献元数据的严格 JSON 数组结构\]  
\</JSON\_LIST\_SECTION\>  

`
};

📅 5. 敏捷迭代开发计划建议 (Sprint Plan)

周期：1.5 周 (约 8 个工作日)

阶段	时间	前端任务 (Frontend)	后端任务 (Backend/Python)
Phase 1: 单页交互与需求扩写	Day 1-3	搭建 V4.1 瀑布流单页布局；开发 Step 1 和 Step 2 的 UI 联动；支持 Textarea 编辑。	升级 Schema；编写“需求扩写 (Requirement Expansion)” 的 Prompt；提供生成草稿接口。
Phase 2: 异步队列与终端日志	Day 4-6	开发暗黑 Terminal 组件；实现轮询接口对接与 auto-scroll 日志滚动逻辑。	对接 Unifuncs API；实现 pg-boss 长任务 Worker；解析 reasoning_content 转为增量 JSON 存入 DB。
Phase 3: 结果解析与多维导出	Day 7-8	集成 Chart.js 绘制双图表；完成 Tab 列表和 Markdown 报告渲染。	后端正则切割 <REPORT> 与 <JSON_LIST>；提供 Word (复用 Pandoc) 和 .ris 格式的导出接口联调。