docs: 补充产品说明和汇报材料

PRODUCT.md

@@ -0,0 +1,32 @@
+# Product
+
+## Register
+
+product
+
+## Users
+
+注册资料准备、法规审核和项目管理人员，在资料整理、法规核查、问题整改和申报文件填表过程中使用。
+
+## Product Purpose
+
+DEMO-AGENT 是一个体外诊断试剂注册资料审核工作台。它把上传资料、文件汇总、法规规则核查、RAG 依据检索、风险预警、整改复核和申报表填充组织成可追溯的工作流。
+
+## Brand Personality
+
+克制、可信、清晰。界面应服务审核任务，优先呈现状态、证据和下一步动作。
+
+## Anti-references
+
+避免营销页式大标题、装饰性卡片堆叠、过度动画、过亮的渐变和不必要的视觉噪声。
+
+## Design Principles
+
+- 证据优先：每个结论都应能回到来源文件、规则或检索片段。
+- 状态清楚：批次、节点、风险、异常和导出结果要一眼可辨。
+- 操作克制：页面提供必要动作，不把审核工作做成复杂后台。
+- 复用现有模式：新增页面沿用当前工作台导航、面板、表格和按钮体系。
+
+## Accessibility & Inclusion
+
+默认按 WCAG AA 方向处理对比度、键盘可访问和清晰标签。动效仅用于状态反馈，并尊重减少动态效果需求。

docs/7.汇报材料/架构搭建思路汇报稿.md

@@ -0,0 +1,333 @@
+# 架构搭建思路汇报稿（基于 Demo 版）
+
+## 一、汇报开场
+
+各位老师好，我本次 Demo 搭建的是一个面向体外诊断试剂注册资料准备与审核的智能体原型。
+
+这个 Demo 的目标不是简单做文件上传、文件解析或问答，而是把注册资料审核中几个高频、耗时、容易出错的环节串成一个可追溯的智能工作流，包括文件目录汇总、法规完整性核查、产品关键信息提取、申报表自动填充，以及异常风险预警。
+
+从整体定位上看，它更像是一个“注册资料审核助手”：用户上传一批申报资料后，系统能够先把资料包结构化，再对照法规规则做核查，之后输出风险清单和整改建议，并把抽取到的产品信息继续复用到申报模板填表中。
+
+## 二、Demo 运行结果展示
+
+本次 Demo 目前可以展示四类核心运行结果。
+
+### 1. 文件目录汇总表
+
+用户上传注册资料文件夹、散装文件或压缩包后，系统会自动完成附件固化、压缩包解压、文件扫描和页数统计。
+
+最终系统会生成 Markdown 汇总报告和 Excel 文件明细表，主要字段包括：
+
+| 字段 | 说明 |
+| --- | --- |
+| 序号 | 文件在批次中的顺序 |
+| 目录层级 | 文件所在的相对目录 |
+| 文件名 | 原始文件名 |
+| 类型 | PDF、Word、Excel、PPT 等文件类型 |
+| 页数 | PDF 页数、Word 页数、PPT 幻灯片数或 Excel 工作表数 |
+| 路径 | 文件在批次工作目录中的相对路径 |
+| 状态 | success、failed、unsupported、uncertain 等 |
+| 重试次数 | 页数统计失败时的重试记录 |
+| 异常说明 | 不支持、不可确定或解析失败的原因 |
+
+这个结果解决的是资料包进入系统后的第一步问题：先把杂乱的文件夹变成结构化的文件清单。
+
+### 2. 法规完整性报告
+
+在文件汇总结果基础上，系统会调用法规核查工作流，对照 NMPA 体外诊断试剂注册申报资料要求进行完整性检查。
+
+Demo 中使用 `review_agent/regulatory_review/rules/nmpa_ivd_registration_v1.yaml` 作为结构化规则文件。规则文件中配置了附件 4 的资料要求，例如监管信息、综述资料、非临床资料、临床评价资料、说明书和标签样稿、质量管理体系文件等。
+
+系统会检查是否缺少关键资料，例如：
+
+| 检查对象 | 风险示例 |
+| --- | --- |
+| 注册申请表 | 缺失时生成阻断项或高风险 |
+| 符合性声明 | 缺失时生成阻断项 |
+| 产品技术要求 | 缺失时生成阻断项 |
+| 注册检验报告 | 缺失时生成阻断项 |
+| 产品说明书 | 缺失或章节不完整时生成高风险 |
+| 标签样稿 | 缺失时生成高风险 |
+| 临床评价资料 | 按适用条件生成条件性风险 |
+| 质量管理体系文件 | 缺失时生成高风险 |
+
+最终输出包括 Markdown 法规核查报告、Excel 问题清单和 JSON 结构化结果包。
+
+### 3. 信息提取对照表
+
+系统会从说明书、产品技术要求、注册检验报告、申请表等文件中抽取产品关键信息。
+
+当前 Demo 中重点抽取的字段包括：
+
+| 字段 | 用途 |
+| --- | --- |
+| 产品名称 | 用于一致性核查和申报表填充 |
+| 型号规格 | 用于跨文件比对 |
+| 预期用途 | 用于法规适用条件和模板填充 |
+| 管理类别 | 用于法规判断 |
+| 分类编码 | 用于注册资料核对 |
+| 注册类型 | 用于模板选择和法规规则裁剪 |
+| 临床评价路径 | 用于临床资料适用性判断 |
+
+每个抽取结果都会保留来源文件、来源角色、证据片段、抽取方式和置信度。这样后续生成的填表内容不是黑盒结果，而是能够回溯到原始文件。
+
+### 4. 异常预警列表
+
+系统会把完整性缺失、章节异常、字段冲突、文本抽取失败、页数不可确定、通知失败等问题统一沉淀为风险项。
+
+风险等级目前分为：
+
+| 风险等级 | 含义 |
+| --- | --- |
+| 阻断项 | 影响注册资料完整性或关键合规判断，需要优先整改 |
+| 高风险 | 可能影响审评，需要重点关注 |
+| 中风险 | 建议整改或补充说明 |
+| 低风险 | 轻微问题或格式提示 |
+| 提示项 | 不直接影响结论，但建议人工确认 |
+
+例如，如果系统发现不同文件中的“产品名称”或“型号规格”不一致，会生成一致性风险；如果缺少注册检验报告，会生成阻断项，并给出补充注册检验报告的整改建议。
+
+## 三、智能体整体工作流
+
+结合当前 Demo 的实现，智能体整体工作流可以概括为：
+
+```text
+文件扫描
+-> 目录汇总
+-> 法规匹配
+-> 信息提取
+-> 一致性核查
+-> 风险预警
+-> 报告导出
+-> 通知与整改复核
+```
+
+从代码实现上看，系统拆成三条主链路。
+
+### 1. 文件汇总链路
+
+对应模块：`review_agent/file_summary`
+
+主要流程为：
+
+```text
+文件上传
+-> 附件固化
+-> 压缩包解压
+-> 文件扫描
+-> 页数统计
+-> 产品名识别
+-> 报告输出
+```
+
+这个链路的核心作用是把原始资料包转换成结构化数据。系统会生成 `FileSummaryBatch` 和 `FileSummaryItem`，后续法规核查和自动填表都复用这套文件清单，不再重复扫描文件。
+
+### 2. 法规核查链路
+
+对应模块：`review_agent/regulatory_review`
+
+主要流程为：
+
+```text
+准备资料
+-> 适用条件确认
+-> 规则范围裁剪
+-> 完整性核查
+-> 文本抽取
+-> 章节核查
+-> 一致性核查
+-> 风险评估
+-> 报告输出
+```
+
+这条链路的核心设计原则是：规则优先，RAG 补依据，LLM 做辅助。
+
+也就是说，法规结论不直接交给大模型自由判断，而是优先由结构化规则文件决定；RAG 负责检索法规依据和原文片段；LLM 主要用于低置信度字段抽取、自然语言条件解析和结果复核。
+
+### 3. 自动填表链路
+
+对应模块：`review_agent/application_form_fill`
+
+主要流程为：
+
+```text
+准备资料
+-> 模板选择
+-> 模板复制
+-> 字段抽取
+-> 冲突归并
+-> Word 填写
+-> 追溯清单导出
+-> 结果通知
+```
+
+这条链路会复用前面抽取到的产品信息，自动选择申报模板，并将字段填入 Word 模板。对于冲突字段，Demo 中采用“说明书优先”的策略，同时在结果中保留冲突摘要和来源追溯。
+
+## 四、Demo 实际调用的关键工具和库
+
+本 Demo 在工具选型上以轻量、可本地运行、可解释、便于测试为原则。
+
+### 1. 文件解析类工具
+
+| 工具/库 | Demo 中的用途 | 选用理由 |
+| --- | --- | --- |
+| `pypdf` | PDF 页数统计和文本抽取 | 轻量、安装简单，适合 Demo 阶段快速处理 PDF |
+| `python-docx` | DOCX 文本读取、Word 模板填充 | 可读取段落和表格，也能写入 Word 模板 |
+| `python-pptx` | PPTX 幻灯片数量统计和文本读取 | 适合统计幻灯片数量和抽取文本 |
+| `openpyxl` | XLSX 工作表统计、Excel 报告导出 | 同时支持读取和生成 Excel |
+| `xlrd` | 旧版 XLS 文件读取 | 补充对历史 Excel 格式的支持 |
+| `olefile` | 判断老 Office 文件 OLE 结构 | 用于 doc、xls、ppt 等老格式的兜底识别 |
+| `py7zr` | 7z 压缩包解压 | 支持常见资料包压缩格式 |
+| Python `zipfile` | ZIP 压缩包解压 | 标准库能力，无额外依赖 |
+
+Demo 中没有选择重型 OCR 或复杂版式引擎，是因为当前阶段重点是打通审核链路和规则闭环。对于扫描件、图片 PDF、复杂版式 PDF，后续可以再接入 OCR 和更强的版式解析能力。
+
+### 2. 规则和正则
+
+系统使用 YAML 维护法规规则，例如 `nmpa_ivd_registration_v1.yaml`。每条规则包含规则编码、附件 4 编码、标题、资料类型、风险等级、匹配关键词、整改建议和 RAG 检索查询词。
+
+正则表达式用于抽取结构化字段，例如：
+
+```text
+产品名称：xxx
+型号规格：xxx
+预期用途：xxx
+管理类别：xxx
+分类编码：xxx
+```
+
+选用规则和正则的原因是：这类注册资料中有大量固定标题和固定字段，使用确定性规则可以提高可解释性，也便于定位问题来源。
+
+### 3. RAG 和向量检索
+
+Demo 使用 ChromaDB 构建本地法规 RAG 索引。法规原文材料会被切分为文本块，并保存来源文件、chunk 编号等元数据。
+
+向量 embedding 支持两种模式：
+
+| 模式 | 用途 |
+| --- | --- |
+| SiliconFlow embedding | 用于真实语义检索 |
+| deterministic/local embedding | 用于测试和 dry run |
+
+RAG 在系统中的定位不是直接判断合规，而是为风险问题补充法规依据。例如完整性规则已经判断“缺少注册检验报告”，RAG 再检索相关法规条款，输出来源文件和依据片段，增强报告的可解释性。
+
+### 4. LLM 调用
+
+LLM 在 Demo 中主要承担辅助角色，包括：
+
+| 场景 | LLM 作用 |
+| --- | --- |
+| 自然语言适用条件解析 | 将用户输入转换为结构化字段 |
+| 低置信度字段抽取 | 正则抽取不足时补充结构化 JSON |
+| 工作流结果复核 | 对中间结果做总结和校验 |
+| 整改建议润色 | 在规则模板基础上优化表达 |
+
+风险等级、法规结论和完整性判断不直接交给 LLM 决定，而是由规则引擎和风险评估服务控制。
+
+### 5. 工作流和状态管理
+
+系统使用 Django ORM 保存批次、节点、事件和导出文件。
+
+关键模型包括：
+
+| 模型 | 作用 |
+| --- | --- |
+| `FileSummaryBatch` | 文件汇总批次 |
+| `FileSummaryItem` | 文件明细 |
+| `RegulatoryReviewBatch` | 法规核查批次 |
+| `RegulatoryIssue` | 法规问题和风险项 |
+| `RegulatoryArtifact` | 法规核查过程产物 |
+| `ApplicationFormFillBatch` | 自动填表批次 |
+| `WorkflowNodeRun` | 工作流节点状态 |
+| `WorkflowEvent` | SSE 事件和进度记录 |
+| `ExportedSummaryFile` | Markdown、Excel、JSON、Word 等导出文件 |
+
+前端通过 SSE 事件实时展示工作流卡片状态，使用户能够看到每个节点是否正在执行、是否成功、是否等待确认或失败。
+
+## 五、难点规则处理方式
+
+### 1. 文件完整性检测
+
+文件完整性检测的难点在于：注册资料不是固定文件名，企业可能用不同命名方式组织材料。
+
+Demo 的处理方式是使用多层匹配：
+
+```text
+规则要求项
+-> 文件名关键词匹配
+-> 相对路径匹配
+-> 目录层级匹配
+-> 必要时结合首页文本和字段候选
+```
+
+例如规则中要求“注册检验报告”，系统不仅查找文件名中是否包含“注册检验报告”，也会查找路径和目录中是否包含“检验报告”“检测报告”等别名。
+
+如果没有匹配到文件，系统会生成 `Finding`，再由风险评估服务转换为 `RegulatoryIssue`。这样完整性问题既能被结构化记录，也能进入最终风险报告。
+
+### 2. 信息一致性核查
+
+一致性核查的难点在于：同一个字段可能散落在说明书、注册检验报告、产品技术要求、申请表等多个文件中。
+
+Demo 的处理方式是：
+
+```text
+文本抽取
+-> 字段正则识别
+-> 同字段归并
+-> 不同取值比对
+-> 生成一致性风险
+```
+
+例如系统会从多个文件中抽取“产品名称”“型号规格”“预期用途”等字段。如果同一字段出现多个不同值，系统会生成高风险问题，并在证据中记录每个取值对应的来源文件。
+
+这类结果可以直接辅助人工审核人员定位冲突来源。
+
+### 3. 法规条款匹配
+
+法规条款匹配的难点在于：法规原文长、条款多，直接让大模型判断容易不稳定，纯规则又缺少解释能力。
+
+Demo 采用“双层法规能力”：
+
+| 层级 | 职责 |
+| --- | --- |
+| 结构化规则库 | 负责判断应有哪些文件、哪些章节、哪些字段，以及风险等级 |
+| RAG 法规依据索引 | 负责检索法规原文片段，补充依据说明 |
+
+这种设计的好处是：判断逻辑稳定，报告解释充分，后续规则也可以由法规人员维护。
+
+### 4. 过程留痕和可追溯
+
+审核类系统不能只输出一个结论，还必须说明结论从哪里来。
+
+Demo 中对关键过程都做了留痕：
+
+| 过程 | 留痕内容 |
+| --- | --- |
+| 文件汇总 | 文件路径、页数、统计状态、异常说明 |
+| 文本抽取 | 文本 hash、首页文本、章节候选、字段候选 |
+| 完整性核查 | 规则编码、匹配关键词、命中文件或缺失证据 |
+| 一致性核查 | 字段值、来源文件、冲突取值 |
+| RAG 检索 | 法规来源、片段文本、检索分数 |
+| 报告导出 | Markdown、Excel、JSON 结果包 |
+| 自动填表 | 字段来源、冲突摘要、追溯清单 |
+
+这保证了 Demo 输出的结果不是一次性回答，而是可以复核、下载、整改和继续追踪的过程资产。
+
+## 六、总结
+
+整体来看，本 Demo 的架构搭建思路可以概括为：
+
+```text
+先结构化资料
+再匹配法规
+再抽取字段
+再核查一致性
+再输出风险和报告
+最后支持填表和整改闭环
+```
+
+它体现的是一个“资料输入、规则判断、证据追溯、风险输出、整改闭环”的智能体原型。
+
+当前 Demo 已经完成了文件汇总、法规完整性核查、信息抽取、风险预警、报告导出和自动填表主链路。后续如果继续增强，可以重点补充 OCR、扫描件识别、复杂 PDF 版式解析、规则后台维护、人工确认界面、飞书真实消息闭环，以及更完整的多智能体编排能力。
+
+最终希望这个智能体能够从一个 Demo 原型，逐步演进为注册资料准备和审核过程中的智能协作平台。