如何让 AI 参与临床证据检索，同时保留人工审阅边界、数据库语义差异和证据链可追溯性？

临床证据分析通常要经历问题理解、数据库查询设计、命中范围审阅、记录抓取、研究分类、结构化抽取和结果交付。每一步都可能影响证据范围和最终判断。

这个项目把流程拆成 human-in-the-loop 的工程节点，目标不是替代专家判断，而是提高证据检索的可复现性、可追溯性和扩展能力。

我设计 parent workflow，将自然语言需求、查询转换、人审门控和数据源执行分离；同时搭建 PubMed 与 ClinicalTrials.gov 的 source-specific subgraph，避免不同数据库语义混用。

在分类与交付层，我采用规则优先、LLM fallback 补充的方式处理证据等级和试验阶段，并输出 JSON、Markdown 与 literature delivery package，保留 source ID、分类依据和结构化字段。

流程从 natural-language clinical request 开始，经 LLM intent parsing 生成 query translation report；只有人工审阅批准后，系统才进入 PubMed 与 ClinicalTrials.gov 两条子流程。

PubMed 与 CT.gov 分别保留独立的 fetch、normalize、classify、extract 和 package 逻辑，最终汇合到 traceable evidence packages，而不是把不同来源压平成一个黑箱结果。

查询转换报告保留 generated query、database translation、hit count 和 warnings，下载前必须人工确认，避免模型生成查询后直接执行造成证据范围漂移。

证据等级和试验阶段优先通过规则判断，LLM fallback 只处理 unknown 或不确定字段；这样可以在利用模型灵活性的同时保留 classification basis 和 confidence。

典型输出包括 query_translation_report、pubmed_package、ctgov_package 和 literature_pdf_package。每个包都服务于后续人工复核和交付，而不是只给出一组不可追溯的文献列表。

仓库中的 examples 使用 synthetic、desensitized 数据，适合公开展示输出形态，同时避免暴露真实患者、真实产品、论文全文或商业敏感信息。

核心实现包括 src/pipeline_graph.py 的 parent workflow、src/graph.py 的 source subgraph factory、query_translation 模块、sources 数据源适配、classifiers 分类器和 nodes 交付包生成。

测试覆盖分类器、查询参数传递、approval gate、全文下载和交付包生成，说明该项目重点不是展示 UI，而是验证证据工作流的边界和可复现性。

该项目用于科研和临床证据流程原型开发，不提供医学建议，不替代系统综述方法，也不保证证据完整性。

网页只展示代码、架构、脱敏示例输出和 synthetic examples；不展示真实患者数据、真实商业项目数据、受版权限制的全文内容或未经核验的医学结论。