289 lines
17 KiB
Markdown
289 lines
17 KiB
Markdown
# 需求重构总览与待确认事项
|
||
|
||
## 1. 文档目的
|
||
|
||
本轮需求分析不再沿用“通用 AI Agent Demo 框架”的抽象表述，而是基于 `docs/` 目录下已经提供的真实笔试材料，重构为一个面向 **NMPA 境内第三类体外诊断试剂注册申报资料准备与审核** 的业务系统需求。
|
||
|
||
本文档作为总览，主要说明三件事：
|
||
|
||
1. 本次重构后的业务目标是什么。
|
||
2. 后续模块化需求分析采用什么拆分方式。
|
||
3. 当前原始材料中有哪些必须尽快向需求方确认的地方。
|
||
|
||
## 2. 原始材料所反映的真实业务目标
|
||
|
||
根据 `docs/【模拟题二】试剂盒临床注册文件准备与审核Agent/【模拟题二】试剂盒临床注册文件准备与审核Agent.md`、`docs/目标产品说明书.docx`、`docs/附件 4 体外诊断试剂注册申报资料要求及说明.doc`、`docs/原始材料/关于公布体外诊断试剂注册申报资料要求和批准证明文件格式的公告/` 下公告附件，以及 `docs/第1章 监管信息/` 下样例文件，可以确认本题的核心目标不是“泛化问答 Agent”，而是一个围绕注册申报资料整理、核查、回填、比对和预警的垂直 Agent 系统。
|
||
|
||
系统需要覆盖的业务闭环至少包括：
|
||
|
||
1. 导入申报资料包，支持批量文件、文件夹和压缩包形式，形成资料目录、文件清单、页数统计和章节点归属。
|
||
2. 基于法规要求和申报目录模板，判断资料是否齐全、是否放对位置、是否缺少关键附件。
|
||
3. 从说明书、申请表、产品列表、声明文件等材料中提取关键信息，形成统一字段池。
|
||
4. 利用统一字段池自动填入注册申报表格或法规对照清单。
|
||
5. 对跨文档的名称、规格、适用范围、靶标、机构、日期、标准清单等信息做一致性检查。
|
||
6. 输出可讲解、可演示、可追踪的风险预警和处理建议。
|
||
|
||
## 3. 建议的系统定位
|
||
|
||
### 3.1 不再定位为“通用题型适配器”
|
||
|
||
当前项目 README 中强调“拿到任何题都能快速适配”，这适合作为框架背景，但已经不适合作为本题需求文档主线。对于本次笔试题，系统更适合定位为：
|
||
|
||
> 试剂盒临床注册文件准备与审核智能体平台
|
||
|
||
它仍然保留配置化和可扩展能力，但产品叙事必须切换为“注册申报资料准备助手”，否则会削弱题目贴合度。
|
||
|
||
### 3.2 建议保留的底层架构
|
||
|
||
尽管业务定位变化较大，现有的架构边界仍然是合理的：
|
||
|
||
- `config`：系统配置、环境变量、路径、部署入口。
|
||
- `apps.scenarios`：场景定义与任务入口，但需要从“多题型模板”转向“注册申报子任务配置”。
|
||
- `apps.documents`：上传、解析、入库、目录构建、资料状态管理。
|
||
- `apps.chat`：面向操作人员的交互入口，展示审核结果与回填结果。
|
||
- `apps.audit`：记录每次审核、抽取、回填、预警的执行痕迹。
|
||
- `agent_core`：法规规则、抽取逻辑、结构化输出、工具编排、RAG 检索。
|
||
|
||
因此，本次需求分析采用“保留模块边界，重写模块职责”的方式推进，而不是推翻现有项目结构。
|
||
|
||
## 4. 本轮需求分析文档拆分方式
|
||
|
||
后续需求分析将按照现有项目主模块输出，不做过细拆分，避免把一个可演示系统拆成过多碎文件：
|
||
|
||
1. `1.config模块需求分析.md`
|
||
2. `2.scenarios模块需求分析.md`
|
||
3. `3.documents模块需求分析.md`
|
||
4. `4.chat模块需求分析.md`
|
||
5. `5.audit模块需求分析.md`
|
||
6. `6.agent_core模块需求分析.md`
|
||
|
||
这样的拆分有三个好处：
|
||
|
||
1. 与当前代码目录一致，后续重构时容易对照落地。
|
||
2. 每个模块既能写清职责，也能覆盖该模块承担的真实业务流程。
|
||
3. 复试讲解时可以从“页面层、资料层、编排层、合规层”自然展开。
|
||
|
||
## 5. 从原始材料中已经识别出的关键业务特征
|
||
|
||
### 5.1 本题的审核对象是“注册申报资料包”，不是单篇文档
|
||
|
||
题面要求明确包含“自动汇总注册申报文件夹中的所有文件及页数”“对照法规要求核查文件完整性”，这说明系统输入是一个资料集合，而不是只上传一个 PDF 后做问答。
|
||
|
||
因此，系统设计必须支持“文件夹视角”的审核。
|
||
|
||
### 5.2 本题非常强调“章节点”和“法规目录”
|
||
|
||
从 `附件 4 体外诊断试剂注册申报资料要求及说明` 以及 `关于公布体外诊断试剂注册申报资料要求和批准证明文件格式的公告` 附件可看出，资料并不是简单的“有或没有”，而是存在固定层级结构和明确的附件格式要求，至少包含：
|
||
|
||
- 第 1 章 监管信息
|
||
- 第 2 章 综述资料
|
||
- 第 3 章 非临床资料
|
||
- 第 4 章 临床评价资料
|
||
- 第 5 章 产品说明书和标签样稿
|
||
- 第 6 章 质量管理体系文件
|
||
|
||
这意味着审核规则必须识别“资料缺失”“章节点错误”“章节目录与实际文件不一致”等不同问题类型。
|
||
|
||
同时，新增公告材料还表明系统不能只停留在“目录齐套性”这一层，还应预留以下法规校验层级：
|
||
|
||
1. 注册申报资料要求及说明。
|
||
2. 医疗器械注册申报资料和批准证明文件格式要求。
|
||
3. 体外诊断试剂安全和性能基本原则清单。
|
||
4. 注册证、变更注册（备案）文件等批准证明文件格式。
|
||
|
||
### 5.3 本题非常强调跨文档字段一致性
|
||
|
||
现有样例材料中已经出现多个明显的潜在冲突点，例如：
|
||
|
||
- 题面说明书是“新型冠状病毒 2019-nCoV 核酸检测试剂盒”。
|
||
- 监管信息目录、申请表、产品列表则是“呼吸道合胞病毒、肺炎支原体核酸检测试剂盒”。
|
||
|
||
结合当前已确认口径，本项目目标是建立“通用的试剂盒临床注册文件准备与审核智能体”，因此这些样例差异不要求在需求阶段统一到某一个具体产品，而是要求系统具备：
|
||
|
||
1. 按项目、批次、文档范围界定审核对象的能力。
|
||
2. 对同一审核对象内文档执行严格一致性校验的能力。
|
||
3. 对疑似混档、跨产品资料混入给出风险提示的能力。
|
||
|
||
因此，需求分析必须把“跨文档字段冲突检测”写成核心能力，而不是附属功能。
|
||
|
||
### 5.4 本题不仅需要审核，还需要回填与生成
|
||
|
||
题面第三项写得很明确：从产品文件中提取关键信息并自动填写至目标文件。当前已确认回填目标为“注册申报表格或对照清单”，因此系统不是只出一份报告，还要支持“结构化字段输出 + 申报表格 / 对照清单自动回填”。
|
||
|
||
### 5.5 本题存在历史申报与监管沟通情境
|
||
|
||
`CH1.9 产品申报前沟通的说明.doc` 体现出：
|
||
|
||
- 当前申报可能是二次申报。
|
||
- 历史受理号、撤回信息、临床机构调整、总结报告重形成都需要保留痕迹。
|
||
|
||
因此，系统应考虑“申报轮次”“历史沟通记录”“版本来源说明”等能力，而不应只把资料看成静态附件。
|
||
|
||
## 6. 建议的演示主线
|
||
|
||
为了后续 Demo 更贴合复试陈述，建议整个系统的业务主线固定为：
|
||
|
||
1. 在 `审核智能体` 中上传一批注册资料或直接进入一个已有资料包。
|
||
2. 系统解析资料包，识别产品名称，并以该产品名称创建或绑定对话会话。
|
||
3. 系统自动形成申报目录、页数清单和章节点识别结果。
|
||
4. 系统根据法规目录检查缺失项、错放项、待补项。
|
||
5. 系统抽取产品核心信息并形成字段总表。
|
||
6. 系统检查说明书、申请表、产品列表、声明文件之间的一致性。
|
||
7. 系统输出风险清单、建议动作以及需要人工确认的问题。
|
||
8. 在对话中返回命中的法规依据、模板约束和资料来源说明。
|
||
|
||
导入环节已确认支持两种演示路径：一是直接批量上传样例文件，二是上传包含多级目录的压缩包并由系统自动解压。压缩包格式覆盖 `zip`、`rar`、`7z`，其中 `rar` 和 `7z` 必须采用纯 Python 实现，允许增加第三方 Python 包依赖，以便后续部署到服务器时不依赖系统级解压工具。
|
||
|
||
## 6.1 顶层产品形态补充说明
|
||
|
||
最新版原型已固定顶层 4 个入口：
|
||
|
||
1. `审核智能体`
|
||
2. `资料包`
|
||
3. `知识库`
|
||
4. `处理历史`
|
||
|
||
其中：
|
||
|
||
1. `审核智能体` 是唯一主执行入口，以对话和节点式结果承接完整审核流程。
|
||
2. `资料包` 负责按产品名称管理资料集合，并支持按产品名称或批次号搜索。
|
||
3. `知识库` 统一承载法规资料、业务资料和 RAG 治理能力，因此“法规依据”不再单独成页。
|
||
4. `处理历史` 负责按批次、按产品回看任务执行与通知留痕。
|
||
|
||
## 7. 已确认事项
|
||
|
||
以下内容已根据最新沟通结果确认，并已同步进入后续模块需求：
|
||
|
||
### 7.1 产品目标范围
|
||
|
||
- 系统目标是建立“通用的试剂盒临床注册文件准备与审核智能体”。
|
||
- 因此不需要把当前样例材料统一解释为同一个具体产品的唯一资料包。
|
||
- 实际审核时，应由系统或用户先界定当前参与核查的项目批次或文档范围。
|
||
|
||
### 7.2 飞书接入方向
|
||
|
||
- 系统需要支持飞书接入，并纳入本次 Demo 的明确交付范围。
|
||
- 目标交互包括：在飞书内完成任务选择、结果查看，以及通过飞书机器人 `@` 对应责任人或责任角色。
|
||
- 本次 Demo 需要支持手动配置责任人及飞书账号。
|
||
- 需要支持群聊机器人作为飞书入口形态之一。
|
||
|
||
### 7.3 一致性核查口径
|
||
|
||
- 当前阶段按完全一致处理。
|
||
- 不采用“语义相近即可视为一致”的放宽规则。
|
||
- 因此同一字段只要文案不一致，就应判为冲突或至少进入人工复核。
|
||
|
||
### 7.4 风险分级与准入规则
|
||
|
||
- 风险按高 / 中 / 低三级分类。
|
||
- 存在必须拦截提交的情形。
|
||
- 风险需要综合分析并分别打分。
|
||
- 只要存在任一高风险项，本次审核结果就不允许通过。
|
||
|
||
### 7.5 第 2 至第 6 章样本与模板口径
|
||
|
||
- 结合补充的公告附件包，可以确认第 2 至第 6 章对应的法规要求、章节点结构和资料模板口径已经存在。
|
||
- 这些材料可以作为系统进行完整性检查、章节归类、字段回填和生成审核结论的“监管模板 / 结构模板”。
|
||
- 但它们并不等于每一章都有完整可直接复用的企业填充样本，因此需求上应表述为“可作为法规模板与结构模板”，而不是“已经具备全量业务样本”。
|
||
- 已确认第 2 至第 6 章首版不补充企业真实样本，先按照 `docs/原始材料/关于公布体外诊断试剂注册申报资料要求和批准证明文件格式的公告/` 下公告附件包进行规则级初步确认。
|
||
|
||
### 7.9 资料包解析与责任人配置口径
|
||
|
||
- DOCX 页数必须精确统计，不能以估算页数作为 V1 验收结果。
|
||
- 压缩包内多层目录按原目录结构作为章节点识别依据。
|
||
- `rar`、`7z` 解压必须采用纯 Python 实现，允许增加第三方依赖包。
|
||
- 责任人先通过后台或配置文件手动维护，按资料章节配置责任人。
|
||
- 系统需要自动提取产品名称、检测靶标、适用范围、储存条件、性能指标等核心信息，并自动填入注册申报表格或对照清单。
|
||
- 资料包记录必须与对话会话绑定。
|
||
- 对话标题默认采用解析后的 `product_name`。
|
||
- `资料包` 页面必须提供按产品名称搜索入口，并支持从资料包跳转到关联会话。
|
||
|
||
### 7.6 输出文档形式
|
||
|
||
- 必须支持输出新的 Word 文档。
|
||
- 输出结果需要支持导出下载。
|
||
- 对目标模板的格式、标题层级、表格样式、盖章位和版式必须达到可直接报送级版式。
|
||
- 允许将用户后续编写的新模板纳入模板库，后续回填应以模板库中的标准模板为准。
|
||
|
||
### 7.7 法规主规则源与 RAG 口径
|
||
|
||
- 当前版本默认以 `关于公布体外诊断试剂注册申报资料要求和批准证明文件格式的公告` 附件包为主规则来源。
|
||
- `附件 4` 视为同源补充材料，不另立异源规则体系。
|
||
- 现版本不必把“法规可在线更新”做成显式能力。
|
||
- 法规材料需要按“章 -> 条 -> 要求项 -> 模板字段”四级结构维护。
|
||
- 需同步建设结构化规则文件，用于完整性校验、格式校验和模板字段映射，避免完全依赖检索文本。
|
||
- 法规材料仍建议切片入库到 RAG，用于证据检索、条款引用和审计追溯。
|
||
- 合规判断逻辑仍应坚持“结构化规则优先，RAG 辅助解释”，不能把 RAG 当成唯一规则引擎。
|
||
- 系统需要提供后端管理页面，保留人工校订入口和知识库更新入口。
|
||
|
||
### 7.8 飞书技术接入口径
|
||
|
||
- 飞书接入可参考飞书开放平台提供的 AI Agent 接入路线，而不是自定义一个模糊的消息转发方案。
|
||
- 首版需求应明确两条接入路径：
|
||
1. 飞书机器人 / Channel SDK 作为用户入口。
|
||
2. 飞书 CLI / OpenAPI MCP 作为 Agent 访问飞书消息、文档、日历、多维表格等能力的工具接入方式。
|
||
- 本次 Demo 需实现群聊机器人触发，并支持在飞书内完成任务选择、结果查看和责任人通知。
|
||
- 若需要责任人 `@`、回传摘要、文档评论回复或群消息触发，应在后续设计中按飞书应用权限、事件订阅和可见范围来实现。
|
||
|
||
## 8. 重新整理后的待确认事项
|
||
|
||
以下问题是在前序确认基础上重新收敛后的剩余待确认项。它们不影响当前需求分析继续推进，但会影响后续设计取舍和开发优先级。
|
||
|
||
### 8.1 V1 演示深度是否要求真正覆盖全六章流程
|
||
|
||
原因：
|
||
|
||
- 当前样例文件主要集中在第 1 章监管信息。
|
||
- 题面与法规附件实际要求覆盖六大章。
|
||
|
||
当前确认口径：
|
||
|
||
1. Demo 允许以第 1 章样本做主演示。
|
||
2. 第 2 至第 6 章不补充企业真实样本。
|
||
3. 第 2 至第 6 章先按公告附件包做资料要求、章节点结构和模板口径的规则级初步确认。
|
||
|
||
### 8.2 仍建议补充确认的业务细节
|
||
|
||
以下问题已经有明确主方向，但仍建议在进入详细设计前再确认实现细节：
|
||
|
||
1. Word 导出是否除 `docx` 外还要同步输出 PDF 归档件。
|
||
2. 用户新写模板进入模板库后，模板版本、生效范围和审批流程是否需要管理。
|
||
3. 责任人配置首版按资料章节手动维护，后续再扩展按任务类型、项目角色双维度维护。
|
||
4. 后端知识库更新入口是否只允许管理员使用，还是允许业务审核人员参与人工校订。
|
||
5. 后续如业务方另行提供专用 Word 模板，需要确认模板版本、生效范围和字段映射审批机制。
|
||
|
||
## 9. 本轮需求分析采用的默认假设
|
||
|
||
在需求方未进一步确认前，后续模块文档将先基于以下假设展开：
|
||
|
||
1. 系统以“注册申报资料审核与准备”作为唯一主线，不再强调通用多题型产品定位。
|
||
2. Demo 首版可先覆盖监管信息章，并为全章扩展预留结构。
|
||
3. 一致性检查前需要先确定当前审核范围，不能默认把所有原始材料视为同一产品资料包。
|
||
4. 法规完整性检查首版以本地结构化规则和本地法规材料为准，不强依赖联网抓取法规。
|
||
5. 法规材料会同步按“章 -> 条 -> 要求项 -> 模板字段”四级结构切片入 RAG，并同步维护结构化规则文件，规则判断以结构化规则优先，RAG 负责检索、引用和解释。
|
||
6. 回填能力必须达到“生成新的 Word 文档并支持导出，且版式可直接报送”的交付标准。
|
||
7. 一致性判断当前默认按完全一致执行。
|
||
8. 风险判断采用高 / 中 / 低三级，且任一高风险项直接判定不通过。
|
||
9. 飞书接入属于本次 Demo 明确范围，需支持在飞书内完成任务选择、结果查看和责任人通知，并支持群聊机器人入口。
|
||
10. V1 的法规任务边界先聚焦“注册申报”，变更备案和延续注册在规则架构上预留扩展位，但不作为当前主验收范围。
|
||
11. 系统需要提供后端管理页面，支持人工校订、模板管理、责任人维护和知识库更新。
|
||
12. 资料包导入首版应支持批量文件和压缩包，压缩包解包后保留原始相对路径。
|
||
13. DOCX 页数必须精确统计。
|
||
14. 压缩包内多层目录按原目录作为章节点依据。
|
||
15. `rar`、`7z` 解压必须纯 Python 实现，允许增加第三方依赖包。
|
||
16. 责任人首版按资料章节手动配置。
|
||
17. 第 2 至第 6 章首版不补充企业样本，按公告附件包做规则级初步确认。
|
||
18. 产品核心信息抽取后必须自动填入注册申报表格或对照清单。
|
||
19. 顶层导航固定为 `审核智能体 / 资料包 / 知识库 / 处理历史`。
|
||
20. 资料包与会话一一关联，对话标题取解析后的产品名称。
|
||
21. “法规依据”作为知识库中的法规资料与 RAG 命中结果呈现，不再单列顶级页面。
|
||
|
||
## 10. 结论
|
||
|
||
本次需求重构的关键，不是再补几条场景配置，而是把项目从“通用 Demo 基座”转向“IVD 注册申报资料审核平台”。只要模块需求始终围绕以下四件事展开，后续设计和实现就会比较稳：
|
||
|
||
1. 文件夹级资料治理。
|
||
2. 法规目录级完整性校验。
|
||
3. 跨文档字段抽取与一致性核查。
|
||
4. 可追踪的风险预警与回填辅助。
|