# 需求重构总览与待确认事项 ## 1. 文档目的 本轮需求分析不再沿用“通用 AI Agent Demo 框架”的抽象表述,而是基于 `docs/` 目录下已经提供的真实笔试材料,重构为一个面向 **NMPA 境内第三类体外诊断试剂注册申报资料准备与审核** 的业务系统需求。 本文档作为总览,主要说明三件事: 1. 本次重构后的业务目标是什么。 2. 后续模块化需求分析采用什么拆分方式。 3. 当前原始材料中有哪些必须尽快向需求方确认的地方。 ## 2. 原始材料所反映的真实业务目标 根据 `docs/【模拟题二】试剂盒临床注册文件准备与审核Agent/【模拟题二】试剂盒临床注册文件准备与审核Agent.md`、`docs/目标产品说明书.docx`、`docs/附件 4 体外诊断试剂注册申报资料要求及说明.doc` 以及 `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 章 质量管理体系文件 这意味着审核规则必须识别“资料缺失”“章节点错误”“章节目录与实际文件不一致”等不同问题类型。 ### 5.3 本题非常强调跨文档字段一致性 现有样例材料中已经出现多个明显的潜在冲突点,例如: - 题面说明书是“新型冠状病毒 2019-nCoV 核酸检测试剂盒”。 - 监管信息目录、申请表、产品列表则是“呼吸道合胞病毒、肺炎支原体核酸检测试剂盒”。 这不是噪声,而是非常适合做演示的“真实异常样本”。需求分析必须把“跨文档字段冲突检测”写成核心能力,而不是附属功能。 ### 5.4 本题不仅需要审核,还需要回填与生成 题面第三项写得很明确:从产品文件中提取关键信息并自动填写至目标文件。因此系统不是只出一份报告,还要支持“结构化字段输出 + 对目标文件字段回填”。 ### 5.5 本题存在历史申报与监管沟通情境 `CH1.9 产品申报前沟通的说明.doc` 体现出: - 当前申报可能是二次申报。 - 历史受理号、撤回信息、临床机构调整、总结报告重形成都需要保留痕迹。 因此,系统应考虑“申报轮次”“历史沟通记录”“版本来源说明”等能力,而不应只把资料看成静态附件。 ## 6. 建议的演示主线 为了后续 Demo 更贴合复试陈述,建议整个系统的业务主线固定为: 1. 导入一批注册资料。 2. 系统自动形成申报目录与页数清单。 3. 系统根据法规目录检查缺失项、错放项、待补项。 4. 系统抽取产品核心信息并形成字段总表。 5. 系统检查说明书、申请表、产品列表、声明文件之间的一致性。 6. 系统输出风险清单、建议动作以及需要人工确认的问题。 ## 7. 待确认事项 以下问题不影响需求分析继续推进,但如果后续要做成更贴近真实业务的版本,建议尽快与你可直接沟通的目标用户确认。 ### 7.1 本次系统覆盖的资料范围是否只要求“第 1 章监管信息”演示,还是要覆盖全申报包 原因: - 当前样例文件主要集中在第 1 章监管信息。 - 题面与法规附件实际要求覆盖六大章。 需确认的问题: 1. Demo 是否允许只用第 1 章样例演示全流程能力。 2. 若要覆盖全章,是否还会补充第 2 至第 6 章的原始资料样本。 ### 7.2 目标产品是否以“新冠核酸检测试剂盒”为准,还是以“呼吸道合胞病毒/肺炎支原体核酸检测试剂盒”为准 原因: - `目标产品说明书.docx` 与 `第1章 监管信息` 下的样例材料对应的产品不是同一个。 - 这可能是故意设置的审核异常,也可能是资料拼接造成的样本混杂。 需确认的问题: 1. 这是用于测试一致性核查的刻意异常,还是后续要统一成同一产品。 2. 如果是刻意异常,Demo 是否应把它作为重点演示案例。 ### 7.3 自动回填的目标文件范围 需确认的问题: 1. 只需要回填申请表和对照清单,还是需要直接输出新的 Word 文档。 2. 回填结果是否只展示在页面表格中即可,还是必须导出下载文件。 3. 对 Word 模板的回填是否要求保留原版格式与盖章位。 ### 7.4 法规完整性校验的依据来源 需确认的问题: 1. 本题是否默认以提供的 `附件 4` 为主要规则依据。 2. 是否需要在演示中体现“法规版本可更新”能力。 3. 是否要求系统直接联网抓取 NMPA / CMDE 最新条文,还是允许以本地固化规则做 Demo。 ### 7.5 “通知责任人”是否需要真实消息触达 题面提到“自动识别缺失文件并通知责任人”,但未说明通知方式。 需确认的问题: 1. Demo 只需生成待通知清单,还是要真的发邮件/企业微信。 2. 若要触达,责任人是按章节点、按资料类型还是按项目角色分配。 ### 7.6 一致性核查的判定标准是否允许“语义一致、措辞不同” 例如: - “适用范围”在说明书中可能是完整长句。 - 在申请表中可能是简化描述。 需确认的问题: 1. 是否允许“语义相同但表述长度不同”的情况判定为一致。 2. 哪些字段必须完全一致,哪些字段允许近似匹配后人工复核。 ### 7.7 风险分级口径 需确认的问题: 1. 风险是否按高/中/低三级即可。 2. 是否存在必须拦截提交的“致命缺陷”级别。 3. 风险分级依据是法规强制项、资料完整性、字段冲突程度,还是三者综合。 ## 8. 本轮需求分析采用的默认假设 在需求方未进一步确认前,后续模块文档将先基于以下假设展开: 1. 系统以“注册申报资料审核与准备”作为唯一主线,不再强调通用多题型产品定位。 2. Demo 首版可先覆盖监管信息章,并为全章扩展预留结构。 3. 题面中出现的产品信息冲突被视为应被系统识别出的真实异常。 4. 法规完整性检查首版以本地结构化规则和本地法规材料为准,不强依赖联网。 5. 回填能力首版以“结构化字段回填结果展示”和“生成待填数据”为主,不把保真 Word 编辑作为首要验收标准。 ## 9. 结论 本次需求重构的关键,不是再补几条场景配置,而是把项目从“通用 Demo 基座”转向“IVD 注册申报资料审核平台”。只要模块需求始终围绕以下四件事展开,后续设计和实现就会比较稳: 1. 文件夹级资料治理。 2. 法规目录级完整性校验。 3. 跨文档字段抽取与一致性核查。 4. 可追踪的风险预警与回填辅助。