# **产品需求文档 (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 格式的导出接口联调。 |