diff --git a/docs/设计文档/1.注册资料审核Agent设计思路.md b/docs/设计文档/1.注册资料审核Agent设计思路.md index 7d644ed..c8c7c3b 100644 --- a/docs/设计文档/1.注册资料审核Agent设计思路.md +++ b/docs/设计文档/1.注册资料审核Agent设计思路.md @@ -28,13 +28,15 @@ V1 建议支持以下导入方式： 2. 文件夹拖拽或前端批量选择文件。 3. 压缩包上传并自动解压。 -压缩包格式建议覆盖： +压缩包格式覆盖： 1. `zip` 2. `rar` 3. `7z` -系统解包后应保留原始相对路径，用于还原资料目录、识别章节点和发现文件夹结构异常。 +系统解包后应保留原始相对路径，用于还原资料目录、识别章节点和发现文件夹结构异常。压缩包内多层目录按原目录作为章节点识别依据。 + +`rar`、`7z` 解压必须采用纯 Python 实现，允许新增第三方 Python 依赖包，避免服务器部署时依赖系统级解压工具。 ### 2.2 法规依据资料 @@ -63,7 +65,7 @@ docs/原始材料/关于公布体外诊断试剂注册申报资料要求和批 | 原始路径 | 解压或上传后的相对路径 | | 文件名 | 原始文件名 | | 文件类型 | PDF、DOCX、DOC、TXT、MD 等 | -| 页数 | 可精确统计或估算 | +| 页数 | 精确页数或待复核状态 | | 章节点 | 如 CH1.2、CH1.4、CH1.11.5 | | 资料名称 | 识别出的注册资料名称 | | 处理状态 | 已解析、解析失败、待人工确认 | @@ -72,8 +74,8 @@ docs/原始材料/关于公布体外诊断试剂注册申报资料要求和批 页数统计策略： 1. PDF 优先用 `pdfplumber` 或 `PyMuPDF` 精确统计。 -2. DOCX 优先解析段落、表格和属性，页数可先标记为估算或待确认。 -3. DOC 可通过兼容解析工具或转换后处理，失败时保留异常提示。 +2. DOCX 页数必须精确统计，不能以估算页数作为 V1 验收结果。 +3. DOC 可通过兼容解析工具或转换后处理，无法精确统计时标记为待人工复核。 4. 扫描件或无法提取正文的文件标记为“需 OCR / 待人工复核”。 ### 3.2 按 NMPA 法规要求核查完整性 @@ -96,7 +98,7 @@ V1 规则建议拆成三层： | 错放 | 文件存在但章节点或目录位置不合理 | | 待复核 | 规则无法直接判定 | -自动通知责任人属于完整性核查后的动作。V1 可先输出责任角色和通知载荷，例如“CH4 临床评价资料缺失 -> 临床注册负责人”，后续再接飞书机器人执行 `@` 通知。 +自动通知责任人属于完整性核查后的动作。V1 责任人先通过后台或配置文件手动维护，并按资料章节配置。系统可先输出责任角色和通知载荷，例如“CH4 临床评价资料缺失 -> 临床注册负责人”，后续再接飞书机器人执行 `@` 通知。 ### 3.3 产品关键信息抽取与回填 @@ -236,8 +238,8 @@ RAG 不作为最终合规判断引擎，只负责： Agent Core 后续应注册以下工具： 1. `scan_submission_package`：扫描资料包并保留目录结构。 -2. `extract_archive`：解压 zip、rar、7z。 -3. `count_document_pages`：统计或估算页数。 +2. `extract_archive`：解压 zip、rar、7z，其中 rar、7z 必须使用纯 Python 依赖实现。 +3. `count_document_pages`：统计页数，DOCX 必须精确统计。 4. `classify_chapter_node`：识别章节点和资料名称。 5. `check_nmpa_completeness`：按结构化规则检查齐套性。 6. `extract_product_fields`：抽取产品核心字段。 @@ -304,8 +306,8 @@ Audit 需要记录： 建议按以下顺序落地，保证演示先闭环： 1. 批量上传 / 压缩包解压 / 文件目录汇总。 -2. PDF、DOCX 页数统计和解析状态展示。 -3. 基于公告附件包整理结构化必交项规则。 +2. PDF、DOCX 页数统计和解析状态展示，其中 DOCX 必须精确统计。 +3. 基于公告附件包整理结构化必交项规则，第 2 至第 6 章先做规则级初步确认。 4. 完整性核查与缺失项风险输出。 5. 从目标产品说明书抽取产品名称、靶标、适用范围、储存条件、性能指标。 6. 对说明书、申请表、产品列表做字段一致性核查。 @@ -313,16 +315,19 @@ Audit 需要记录： 8. 回填预览和 Word 模板导出。 9. 责任人通知载荷与飞书机器人演示。 -## 7. 待确认事项 +## 7. 已确认约束与剩余待确认事项 -以下问题不阻塞 V1 需求整理，但会影响实现细节： +以下约束已经确认，应作为后续实现依据： + +1. DOCX 页数必须精确统计。 +2. 压缩包内多层目录按原目录作为章节点依据。 +3. `rar`、`7z` 解压必须纯 Python 实现，允许新增第三方依赖包。 +4. 责任人先手动配置，按资料章节维护。 +5. 第 2 至第 6 章不补充企业真实样本，先按公告附件包进行规则级初步确认。 + +剩余待确认事项： 1. “目标文件”具体是注册申请表、对照清单，还是另一个业务方指定模板。 -2. DOCX 页数是否必须精确，还是允许首版标记为估算。 -3. 压缩包内多层目录是否按原目录作为章节点依据。 -4. rar、7z 解压是否允许依赖系统工具，还是必须纯 Python 实现。 -5. 责任人是按章节点、资料类型、项目角色还是具体人员维护。 -6. 第 2 至第 6 章是否会补充企业真实样本用于内容级演示。 ## 8. 结论 diff --git a/docs/需求分析/0.需求重构总览与待确认事项.md b/docs/需求分析/0.需求重构总览与待确认事项.md index 4c0b5fa..26c28d4 100644 --- a/docs/需求分析/0.需求重构总览与待确认事项.md +++ b/docs/需求分析/0.需求重构总览与待确认事项.md @@ -134,7 +134,7 @@ 7. 系统展示当前完整性结论所依据的公告附件、资料要求和模板来源。 -导入环节建议明确支持两种演示路径：一是直接批量上传样例文件，二是上传包含多级目录的压缩包并由系统自动解压。压缩包格式建议覆盖 `zip`、`rar`、`7z`，其中 `rar` 和 `7z` 可在实现设计中根据本地依赖情况选择纯 Python 或系统工具方案。 +导入环节已确认支持两种演示路径：一是直接批量上传样例文件，二是上传包含多级目录的压缩包并由系统自动解压。压缩包格式覆盖 `zip`、`rar`、`7z`，其中 `rar` 和 `7z` 必须采用纯 Python 实现，允许增加第三方 Python 包依赖，以便后续部署到服务器时不依赖系统级解压工具。 ## 7. 已确认事项 @@ -171,6 +171,14 @@ - 结合补充的公告附件包，可以确认第 2 至第 6 章对应的法规要求、章节点结构和资料模板口径已经存在。 - 这些材料可以作为系统进行完整性检查、章节归类、字段回填和生成审核结论的“监管模板 / 结构模板”。 - 但它们并不等于每一章都有完整可直接复用的企业填充样本，因此需求上应表述为“可作为法规模板与结构模板”，而不是“已经具备全量业务样本”。 +- 已确认第 2 至第 6 章首版不补充企业真实样本，先按照 `docs/原始材料/关于公布体外诊断试剂注册申报资料要求和批准证明文件格式的公告/` 下公告附件包进行规则级初步确认。 + +### 7.9 资料包解析与责任人配置口径 + +- DOCX 页数必须精确统计，不能以估算页数作为 V1 验收结果。 +- 压缩包内多层目录按原目录结构作为章节点识别依据。 +- `rar`、`7z` 解压必须采用纯 Python 实现，允许增加第三方依赖包。 +- 责任人先通过后台或配置文件手动维护，按资料章节配置责任人。 ### 7.6 输出文档形式 @@ -210,10 +218,11 @@ - 当前样例文件主要集中在第 1 章监管信息。 - 题面与法规附件实际要求覆盖六大章。 -需确认的问题： +当前确认口径： -1. Demo 是否允许以第 1 章样本做主演示，同时以法规模板覆盖第 2 至第 6 章的完整性校验口径。 -2. 若后续要把第 2 至第 6 章做成更强的“内容级抽取与回填演示”，是否还会补充企业真实样本。 +1. Demo 允许以第 1 章样本做主演示。 +2. 第 2 至第 6 章不补充企业真实样本。 +3. 第 2 至第 6 章先按公告附件包做资料要求、章节点结构和模板口径的规则级初步确认。 ### 8.2 仍建议补充确认的业务细节 @@ -221,11 +230,9 @@ 1. Word 导出是否除 `docx` 外还要同步输出 PDF 归档件。 2. 用户新写模板进入模板库后，模板版本、生效范围和审批流程是否需要管理。 -3. 责任人配置是仅按章节点维护，还是同时支持按任务类型、项目角色双维度维护。 +3. 责任人配置首版按资料章节手动维护，后续再扩展按任务类型、项目角色双维度维护。 4. 后端知识库更新入口是否只允许管理员使用，还是允许业务审核人员参与人工校订。 5. “自动填写至目标文件”的目标文件具体是注册申请表、法规对照清单、章节目录，还是业务方另行提供的 Word 模板。 -6. DOCX / DOC 页数统计是否要求达到精确页数，还是允许首版使用估算页数并标记可信度。 -7. `rar`、`7z` 解包是否允许依赖本地系统工具，还是必须完全使用 Python 库实现。 ## 9. 本轮需求分析采用的默认假设 @@ -243,6 +250,11 @@ 10. V1 的法规任务边界先聚焦“注册申报”，变更备案和延续注册在规则架构上预留扩展位，但不作为当前主验收范围。 11. 系统需要提供后端管理页面，支持人工校订、模板管理、责任人维护和知识库更新。 12. 资料包导入首版应支持批量文件和压缩包，压缩包解包后保留原始相对路径。 +13. DOCX 页数必须精确统计。 +14. 压缩包内多层目录按原目录作为章节点依据。 +15. `rar`、`7z` 解压必须纯 Python 实现，允许增加第三方依赖包。 +16. 责任人首版按资料章节手动配置。 +17. 第 2 至第 6 章首版不补充企业样本，按公告附件包做规则级初步确认。 ## 10. 结论 diff --git a/docs/需求分析/1.V1总需求文档.md b/docs/需求分析/1.V1总需求文档.md index 2868404..b992f7d 100644 --- a/docs/需求分析/1.V1总需求文档.md +++ b/docs/需求分析/1.V1总需求文档.md @@ -72,7 +72,7 @@ V1 聚焦“可运行、可讲解、可演示”的注册资料审核闭环， 3. 首版法规校验可以本地规则为主，不强依赖联网抓取最新法规。 4. 首版需要支持飞书内完成任务选择、结果查看和责任人通知，并支持群聊机器人入口及手动维护责任人 / 飞书账号映射。 5. 首版法规任务边界以“注册申报”主流程为核心，变更备案和延续注册暂作为规则扩展方向。 -6. 首版如 DOCX / DOC 页数无法精确恢复，可标记为估算页数或待复核，但必须在目录汇总中明确可信度。 +6. DOCX 页数必须精确统计，不能以估算页数作为 V1 验收结果；DOC 如受格式限制无法精确统计，应标记为待复核。 7. 回填目标文件在业务未最终确认前，先以结构化回填字段表和模板回填预览作为交付口径。 ## 5. 业务闭环 @@ -97,7 +97,9 @@ V1 聚焦“可运行、可讲解、可演示”的注册资料审核闭环， 2. 同步建设结构化规则文件，避免让完整性校验完全依赖检索文本。 3. 提供后台管理页面，支持人工校订和知识库更新。 -资料导入层需要按“资料包”而不是“单文件”设计。V1 至少应支持批量文件上传，并预留文件夹导入和压缩包导入能力。压缩包导入建议支持 `zip`、`rar`、`7z`，解包后保留原始相对路径，用于生成目录汇总、识别章节点和发现文件夹结构异常。 +资料导入层需要按“资料包”而不是“单文件”设计。V1 至少应支持批量文件上传、文件夹导入和压缩包导入能力。压缩包导入支持 `zip`、`rar`、`7z`，解包后保留原始相对路径，并将压缩包内多层目录按原目录作为章节点识别依据。`rar`、`7z` 解压必须采用纯 Python 实现，允许增加第三方依赖包，避免服务器部署时依赖系统级解压工具。 + +第 2 至第 6 章首版不补充企业真实样本，先以公告附件包进行资料要求、章节点结构和模板口径的规则级初步确认。责任人首版通过后台或配置文件手动维护，并按资料章节配置。 在法规维度上，建议把完整流程理解为： diff --git a/docs/需求分析/1.config模块需求分析.md b/docs/需求分析/1.config模块需求分析.md index d52d7e6..d84bbce 100644 --- a/docs/需求分析/1.config模块需求分析.md +++ b/docs/需求分析/1.config模块需求分析.md @@ -25,6 +25,7 @@ - 上传目录不仅要按场景分，还要考虑按项目批次、申报轮次、资料章节分层。 - 规则来源不止一个 YAML，可能包括法规目录模板、字段抽取模板、一致性校验规则、风险分级规则，以及公告附件原文所对应的结构化法规包。 - 文档解析链路中可能同时使用 `pdfplumber`、`PyMuPDF`、Word 解析库、OCR 预留能力，因此要有可切换的解析策略配置。 +- 压缩包处理链路需要支持 `zip`、`rar`、`7z`，其中 `rar` 和 `7z` 必须使用纯 Python 依赖实现，不能依赖服务器系统级解压工具。 - 审计数据不能只保留“问答日志”，还要能关联具体资料批次和审核任务。 ### 3.2 Demo 与真实业务之间要有明确边界 @@ -161,11 +162,17 @@ 是否启用 OCR 兜底。 - `PAGE_COUNT_STRATEGY` - 页数统计策略，如 PDF 直接取页数、Word 按分页符或估算策略。 + 页数统计策略。PDF 和 DOCX 必须精确统计页数；DOC 如无法精确统计，应标记为待人工复核。 - `DOCX_PARSE_STRATEGY` 例如“仅提取文本”“提取文本和表格”“保留章节层级”。 +- `ARCHIVE_EXTRACT_STRATEGY` + 压缩包解包策略。V1 要求 `zip`、`rar`、`7z` 均通过 Python 依赖实现，并保留原始相对路径。 + +- `ARCHIVE_CHAPTER_SOURCE` + 章节点识别依据。V1 默认使用压缩包内多层目录作为章节点识别依据。 + ### 5.4 规则与版本配置项 - `REG_RULESET_VERSION` @@ -321,10 +328,11 @@ admin/ 1. 将当前偏“通用 Demo”的命名改造成更贴近注册申报业务的配置语义。 2. 增加抽取结果目录、报告目录、规则目录等配置。 3. 增加法规规则版本与字段 schema 版本配置。 -4. 为 `.doc`、`.docx`、PDF 页数统计和解析策略提供显式配置位。 +4. 为 `.doc`、`.docx`、PDF 页数统计和解析策略提供显式配置位，其中 DOCX 页数必须精确统计。 5. 增加法规原文目录、法规流程类型和文件格式模板版本配置。 6. 增加 Word 导出目录和飞书应用接入相关配置。 7. 增加模板库目录、规则管理目录和责任人映射配置。 +8. 增加纯 Python 压缩包解包依赖与策略配置，覆盖 `zip`、`rar`、`7z`。 ## 11. 本模块验收标准 diff --git a/docs/需求分析/3.documents模块需求分析.md b/docs/需求分析/3.documents模块需求分析.md index a0e04b9..2edc08a 100644 --- a/docs/需求分析/3.documents模块需求分析.md +++ b/docs/需求分析/3.documents模块需求分析.md @@ -48,7 +48,9 @@ - 文件夹选择或拖拽上传 - 压缩包上传并自动解包 -压缩包建议覆盖 `zip`、`rar`、`7z` 等常见格式。解包后应保留压缩包内的原始相对路径，用于还原资料目录、识别章节点和判断是否存在目录层级异常。 +压缩包覆盖 `zip`、`rar`、`7z` 等常见格式。解包后应保留压缩包内的原始相对路径，并将多层目录按原目录作为章节点识别依据，用于还原资料目录、识别章节点和判断是否存在目录层级异常。 + +`rar`、`7z` 解压必须采用纯 Python 实现，允许新增第三方 Python 包依赖，避免服务器部署时依赖系统级解压工具。 除用户上传的申报资料外，系统还需要支持管理平台内置法规资料，例如： @@ -234,10 +236,11 @@ 页数统计是本题显式要求，需支持： - PDF 精确页数统计 -- Word 文件页数估算或格式解析策略 +- DOCX 精确页数统计 +- DOC 文件页数统计或待人工复核策略 - 目录页码与实际文件页数比对 -即便首版不能对所有 Word 做精确页数恢复，也需要在需求上明确“统计可信度”和“估算标识”。 +DOCX 页数必须精确，不能以估算页数作为 V1 验收结果。DOC 如受格式限制无法精确统计，应标记为“待人工复核”。 页数结果建议拆分为： @@ -245,7 +248,7 @@ - `page_count_method` - `page_count_confidence` -例如 PDF 解析可标记为“精确”，DOCX 首版可标记为“估算”，DOC 或解析失败文件可标记为“待人工复核”。 +例如 PDF 和 DOCX 解析应标记为“精确”，DOC 或解析失败文件可标记为“待人工复核”。 ### 6.4 文本抽取与索引流程 diff --git a/docs/需求分析/6.agent_core模块需求分析.md b/docs/需求分析/6.agent_core模块需求分析.md index ed00b89..57c80e1 100644 --- a/docs/需求分析/6.agent_core模块需求分析.md +++ b/docs/需求分析/6.agent_core模块需求分析.md @@ -96,9 +96,10 @@ 1. 接收 Documents 模块提供的资料包、批量文件或压缩包解包结果。 2. 遍历当前项目 / 批次所有资料。 3. 保留原始相对路径、文件名、文件类型、页数、页数可信度和处理状态。 -4. 识别目录类文档与普通文档。 -5. 识别章节点、资料名称和是否命中法规目录项。 -6. 输出目录总表。 +4. 将压缩包内多层目录按原目录作为章节点识别依据。 +5. 识别目录类文档与普通文档。 +6. 识别章节点、资料名称和是否命中法规目录项。 +7. 输出目录总表。 ### 输出要求 @@ -111,6 +112,8 @@ - 已识别章节点 - 待确认文档 +DOCX 页数必须精确统计，不能以估算页数作为 V1 验收结果。DOC 如受格式限制无法精确统计，应标记为待人工复核。 + ## 5.2 法规完整性核查能力 ### 目标 @@ -449,8 +452,8 @@ LLM 负责把这些动作组织成自然语言建议，但不能改变底层规 建议工具方向包括： 1. 资料包扫描工具 -2. `zip` / `rar` / `7z` 压缩包解包工具 -3. 文档页数统计工具 +2. `zip` / `rar` / `7z` 压缩包解包工具，`rar` 和 `7z` 必须采用纯 Python 依赖实现 +3. 文档页数统计工具，DOCX 页数必须精确统计 4. 章节点识别工具 5. 必交项检查工具 6. 字段抽取工具 @@ -462,7 +465,7 @@ LLM 负责把这些动作组织成自然语言建议，但不能改变底层规 12. 格式模板映射工具 13. Word 模板回填与导出工具 14. 飞书消息摘要生成与通知载荷组装工具 -15. 责任人映射解析工具 +15. 责任人映射解析工具，首版按资料章节手动配置 16. 规则切片与结构化回写工具 这些工具都应通过 Tool Registry 注册，符合项目既有边界要求。 diff --git a/docs/需求分析/9.业务确认问答清单.md b/docs/需求分析/9.业务确认问答清单.md index c291e32..3e5e1b0 100644 --- a/docs/需求分析/9.业务确认问答清单.md +++ b/docs/需求分析/9.业务确认问答清单.md @@ -32,7 +32,12 @@ 7. 法规知识按“章 -> 条 -> 要求项 -> 模板字段”四级结构维护。 8. 飞书接入属于本次 Demo 范围，需要支持群聊机器人，并在飞书内完成任务选择、结果查看和责任人通知。 9. 系统需要提供后台管理页面，支持人工校订、知识库更新、模板管理和责任人维护。 -10. 资料导入应按资料包处理，首版支持批量文件和压缩包，压缩包建议覆盖 `zip`、`rar`、`7z`。 +10. 资料导入应按资料包处理，首版支持批量文件、文件夹和压缩包，压缩包覆盖 `zip`、`rar`、`7z`。 +11. DOCX 页数必须精确统计。 +12. 压缩包内多层目录按原目录作为章节点依据。 +13. `rar`、`7z` 解压必须纯 Python 实现，允许增加第三方依赖包。 +14. 责任人先手动配置，按资料章节维护。 +15. 第 2 至第 6 章不补充企业真实样本，先按公告附件包进行规则级初步确认。 --- @@ -175,9 +180,10 @@ 建议记录答案： -- 必须支持： +- 必须支持：批量文件、文件夹、zip、rar、7z - 可后续支持： -- 是否需要保留压缩包内原始目录： +- 是否需要保留压缩包内原始目录：是，多层目录按原目录作为章节点依据 +- rar / 7z 实现要求：必须纯 Python 实现，允许增加第三方依赖包 为什么要问： @@ -440,10 +446,10 @@ 建议记录答案： -- 按章节点： -- 按资料类型： -- 按项目角色： -- 按具体人员： +- 按章节点：首版已确认，按资料章节手动配置 +- 按资料类型：后续可扩展 +- 按项目角色：后续可扩展 +- 按具体人员：通过手动配置映射到章节责任人 为什么要问： @@ -605,7 +611,7 @@ 4. Q10 “可直接报送级版式”的验收标准 5. Q12 新模板进入模板库后的确认机制 6. Q18 飞书群聊机器人希望如何触发任务 -7. Q20 责任人如何定义 +7. Q20 责任人如何定义（已确认首版按资料章节手动配置） 8. Q26 本次 Demo 的通过标准 ---