182 lines
9.1 KiB
Markdown
182 lines
9.1 KiB
Markdown
# V1 总需求文档
|
||
|
||
## 1. 文档目的
|
||
|
||
本文档作为当前项目 V1 阶段的总需求索引文档，用于统一说明本轮笔试题对应的产品定位、目标用户、核心业务闭环、模块拆分方式和后续阅读路径。
|
||
|
||
与历史“通用 AI Agent Demo 框架”定位不同，本轮 V1 需求以 `docs/` 目录中的真实题面与资料样本为准，系统目标已经切换为：
|
||
|
||
> 试剂盒临床注册文件准备与审核智能体平台
|
||
|
||
## 2. 产品定位
|
||
|
||
本系统面向 **NMPA 境内第三类体外诊断试剂注册申报资料准备与审核** 场景，服务于需要整理、核查、抽取、回填和追踪注册资料的业务人员。
|
||
|
||
系统主体围绕注册申报审核场景展开，但能力目标是沉淀为“通用的试剂盒临床注册文件准备与审核智能体”，而不是只绑定某一个具体试剂盒产品。
|
||
|
||
系统不再以“适配任意业务题”的通用 Demo 作为对外主叙事，而是聚焦以下业务价值：
|
||
|
||
1. 自动汇总注册资料目录与页数。
|
||
2. 对照法规要求检查资料完整性。
|
||
3. 抽取产品关键信息并形成统一字段池。
|
||
4. 支持目标文件字段回填准备。
|
||
5. 核查跨文档信息一致性与章节规范性。
|
||
6. 输出合规风险预警和处理建议。
|
||
|
||
## 3. 原始材料依据
|
||
|
||
当前需求分析主要基于以下材料整理：
|
||
|
||
1. `docs/【模拟题二】试剂盒临床注册文件准备与审核Agent/【模拟题二】试剂盒临床注册文件准备与审核Agent.md`
|
||
2. `docs/目标产品说明书.docx`
|
||
3. `docs/附件 4 体外诊断试剂注册申报资料要求及说明.doc`
|
||
4. `docs/第1章 监管信息/` 下的监管目录、申请表、产品列表、声明与沟通记录样例
|
||
5. `docs/原始材料/关于公布体外诊断试剂注册申报资料要求和批准证明文件格式的公告/` 下的公告附件包
|
||
|
||
其中新增公告附件包使法规依据不再只是单篇“资料要求说明”，而是扩展为一组正式规则来源，包括：
|
||
|
||
1. 体外诊断试剂注册申报资料要求及说明
|
||
2. 医疗器械注册申报资料和批准证明文件格式要求（体外诊断试剂）
|
||
3. 体外诊断试剂安全和性能基本原则清单
|
||
4. 中华人民共和国医疗器械注册证（体外诊断试剂）格式
|
||
5. 体外诊断试剂变更备案 / 变更注册申报资料要求及说明
|
||
6. 体外诊断试剂延续注册申报资料要求及说明
|
||
|
||
当前 V1 默认以“公告附件包”作为主规则来源，并将 `附件 4 体外诊断试剂注册申报资料要求及说明` 视作同源补充材料，而不是独立的第二套规则来源。
|
||
|
||
## 4. V1 范围
|
||
|
||
V1 聚焦“可运行、可讲解、可演示”的注册资料审核闭环，不追求一次性做成完整商业平台。
|
||
|
||
### 4.1 V1 必须覆盖
|
||
|
||
1. 资料上传与管理
|
||
2. 资料包导入、压缩包解包、文件目录与页数汇总
|
||
3. 法规完整性检查
|
||
4. 产品关键信息抽取
|
||
5. 跨文档一致性核查
|
||
6. 风险预警输出
|
||
7. 审计留痕
|
||
8. 本地可运行与 Docker 演示启动
|
||
|
||
其中第 3 项“法规完整性检查”在 V1 中建议明确分为三层：
|
||
|
||
1. 资料齐套性检查
|
||
2. 章节点和结构合规性检查
|
||
3. 批准证明文件格式与输出映射检查
|
||
|
||
### 4.2 V1 可接受的简化
|
||
|
||
1. 首版可优先覆盖第 1 章监管信息，并为全章扩展预留结构。
|
||
2. 首版即要求具备“生成新的 Word 文档并支持导出”的能力，且输出版式必须达到可直接报送级别。
|
||
3. 首版法规校验可以本地规则为主，不强依赖联网抓取最新法规。
|
||
4. 首版需要支持飞书内完成任务选择、结果查看和责任人通知，并支持群聊机器人入口及手动维护责任人 / 飞书账号映射。
|
||
5. 首版法规任务边界以“注册申报”主流程为核心，变更备案和延续注册暂作为规则扩展方向。
|
||
6. DOCX 页数必须精确统计，不能以估算页数作为 V1 验收结果；DOC 如受格式限制无法精确统计，应标记为待复核。
|
||
7. 回填目标文件在业务未最终确认前，先以结构化回填字段表和模板回填预览作为交付口径。
|
||
|
||
## 5. 业务闭环
|
||
|
||
建议按以下业务闭环理解整套系统：
|
||
|
||
1. 导入注册申报资料。
|
||
2. 识别文档、统计页数、构建目录。
|
||
3. 依据法规目录进行完整性核查。
|
||
4. 从说明书、申请表、产品列表等材料中抽取统一字段。
|
||
5. 对同名字段进行跨文档一致性比对。
|
||
6. 形成风险清单、回填结果和审计记录。
|
||
|
||
在规则执行层，建议采用“双层知识底座”：
|
||
|
||
1. 结构化规则文件负责完整性判断、强一致比对和风险映射。
|
||
2. 公告附件原文切片入 RAG，负责条款引用、证据检索和解释说明。
|
||
|
||
其中法规知识维护方式应固定为：
|
||
|
||
1. 按“章 -> 条 -> 要求项 -> 模板字段”四级结构维护。
|
||
2. 同步建设结构化规则文件，避免让完整性校验完全依赖检索文本。
|
||
3. 提供后台管理页面，支持人工校订和知识库更新。
|
||
|
||
资料导入层需要按“资料包”而不是“单文件”设计。V1 至少应支持批量文件上传、文件夹导入和压缩包导入能力。压缩包导入支持 `zip`、`rar`、`7z`，解包后保留原始相对路径，并将压缩包内多层目录按原目录作为章节点识别依据。`rar`、`7z` 解压必须采用纯 Python 实现，允许增加第三方依赖包，避免服务器部署时依赖系统级解压工具。
|
||
|
||
第 2 至第 6 章首版不补充企业真实样本，先以公告附件包进行资料要求、章节点结构和模板口径的规则级初步确认。责任人首版通过后台或配置文件手动维护，并按资料章节配置。
|
||
|
||
在法规维度上，建议把完整流程理解为：
|
||
|
||
1. 识别当前审核任务属于“注册申报”主流程。
|
||
2. 匹配对应的资料要求与章节点模板。
|
||
3. 检查资料齐套性与章节结构。
|
||
4. 对需要回填或输出的批准证明文件格式做字段映射准备。
|
||
|
||
## 6. 模块拆分
|
||
|
||
V1 需求分析按项目现有主模块拆分，不做过度细分：
|
||
|
||
1. [1.config模块需求分析.md](F:\PyCharm\DEMO-AGENT\docs\需求分析\1.config模块需求分析.md)
|
||
2. [2.scenarios模块需求分析.md](F:\PyCharm\DEMO-AGENT\docs\需求分析\2.scenarios模块需求分析.md)
|
||
3. [3.documents模块需求分析.md](F:\PyCharm\DEMO-AGENT\docs\需求分析\3.documents模块需求分析.md)
|
||
4. [4.chat模块需求分析.md](F:\PyCharm\DEMO-AGENT\docs\需求分析\4.chat模块需求分析.md)
|
||
5. [5.audit模块需求分析.md](F:\PyCharm\DEMO-AGENT\docs\需求分析\5.audit模块需求分析.md)
|
||
6. [6.agent_core模块需求分析.md](F:\PyCharm\DEMO-AGENT\docs\需求分析\6.agent_core模块需求分析.md)
|
||
|
||
另附一份待确认事项文档，供与需求方沟通时直接使用：
|
||
|
||
- [0.需求重构总览与待确认事项.md](F:\PyCharm\DEMO-AGENT\docs\需求分析\0.需求重构总览与待确认事项.md)
|
||
|
||
## 7. 当前识别出的关键业务特征
|
||
|
||
### 7.1 审核对象是“资料包”
|
||
|
||
本题输入对象是整套注册申报资料，不是单篇文档问答。
|
||
|
||
### 7.2 审核标准是“法规目录 + 资料内容”
|
||
|
||
系统既要看是否有文件，也要看是否放对章节点、内容是否对应。
|
||
|
||
### 7.3 系统必须具备“冲突识别”
|
||
|
||
当前样例中已经存在不同产品资料混入的迹象。这不要求系统默认把全部材料视为同一个产品，而是要求系统具备以下能力：
|
||
|
||
1. 支持按项目批次或文档范围界定审核对象。
|
||
2. 对被划入同一审核对象的资料执行严格一致性检查。
|
||
3. 对混档、错归类和跨产品资料混入给出风险提示。
|
||
|
||
### 7.4 系统必须具备“可解释性”
|
||
|
||
所有缺失判断、字段抽取和风险预警都应尽量有证据、有来源、有审计记录。
|
||
|
||
### 7.5 系统必须具备“法规分层引用”
|
||
|
||
结合新增公告附件包，系统应能区分并引用不同层级的规则来源，而不是把所有法规依据混成一条说明：
|
||
|
||
1. 资料要求类依据
|
||
2. 格式要求类依据
|
||
3. 安全和性能基本原则类依据
|
||
4. 批准证明文件格式类依据
|
||
|
||
### 7.6 系统需要具备“多入口访问能力”
|
||
|
||
V1 除 Web 工作台外，还需要实际支持飞书入口能力，使审核任务可以从浏览器工作台扩展到飞书会话和飞书群聊机器人场景。
|
||
|
||
### 7.7 系统需要具备“后台治理能力”
|
||
|
||
除前台审核能力外，V1 还需要提供后台管理能力，用于维护规则包、模板库、责任人映射和知识库更新入口。
|
||
|
||
## 8. 后续文档与实现衔接建议
|
||
|
||
后续若继续推进设计与开发，建议按如下顺序展开：
|
||
|
||
1. 先确认待确认事项中的产品范围、回填目标和法规范围。
|
||
2. 基于模块需求文档输出设计文档。
|
||
3. 按 `config -> scenarios -> documents -> agent_core -> chat -> audit` 顺序推进重构。
|
||
4. 同步更新 README、AGENTS 和场景配置命名。
|
||
|
||
## 9. 结论
|
||
|
||
当前 V1 需求已经从“通用 Agent Demo 基座”重构为“注册申报资料审核系统”。后续所有设计、实现和讲解，建议都围绕以下四个关键词展开：
|
||
|
||
1. 文件夹级资料治理
|
||
2. 法规目录级完整性校验
|
||
3. 统一字段池与跨文档一致性检查
|
||
4. 可追溯的风险预警与审计留痕
|