7.2 KiB
7.2 KiB
V1 总需求文档
1. 文档目的
本文档用于基于最新版演示原型、现有原始材料和项目边界,重新定义 V1 阶段的需求基线。
当前系统不再按“传统审核系统多页面菜单”叙事,而是明确采用:
以 Agent 对话为核心的试剂盒临床注册文件准备与审核平台
V1 需要同时满足三类目标:
- 能用对话驱动审核任务。
- 能把资料包、知识库、审核记录和飞书通知纳入统一闭环。
- 能以可讲解、可追溯、可扩展的方式支撑后续 Django 实现。
2. 产品定位
本系统面向 NMPA 境内第三类体外诊断试剂注册申报资料准备与审核场景,服务对象包括:
- 注册申报专员
- 注册资料负责人
- 质量/法规专员
- 审核复核人员
- 平台治理管理员
产品不再只是“上传文件后生成报表”的审核系统,也不只是“自由聊天的问答机器人”,而是一个围绕资料包审核任务编排的 Agent 工作台。
3. 最新版原型对应的产品形态
基于当前最新版原型,V1 顶层产品形态固定为 4 个一级入口:
审核智能体资料包知识库处理历史
这 4 个入口分别承担:
3.1 审核智能体
作为统一任务入口,承接:
- 资料上传
- 自然语言提问
- 任务模板选择
- 节点式审核执行
- 结构化结论查看
- 风险与整改建议输出
3.2 资料包
作为资料治理入口,承接:
- 资料包导入
- 按产品名称建立资料包记录
- 资料包与对话会话关联
- 目录、页数、章节点、异常结果查看
- 按产品名称或批次号搜索资料包
3.3 知识库
作为治理入口,承接:
- 法规资料上传
- 业务资料上传
- RAG 文档源管理
- 切片解析与向量入库
- 字段 Schema 管理
- 模板映射管理
- 飞书通知配置与责任人映射
其中“法规依据”不再单独作为顶级页面存在,而是作为知识库中的法规资料,通过 RAG 命中在 Agent 对话中返回。
3.4 处理历史
作为留痕入口,承接:
- 按批次回看历史任务
- 查看资料规模和任务类型
- 查看最终结论和风险状态
- 查看关联会话、附件和摘要
- 支撑审计与复核
4. 原始材料依据
当前需求分析以以下资料为主:
docs/原始材料/【模拟题二】试剂盒临床注册文件准备与审核Agent.docxdocs/原始材料/目标产品说明书.docxdocs/原始材料/附件 4 体外诊断试剂注册申报资料要求及说明.docdocs/原始材料/第1章 监管信息/下样例资料docs/原始材料/关于公布体外诊断试剂注册申报资料要求和批准证明文件格式的公告/下公告附件包- 最新版原型文件
docs/原型设计/registration-prototype-demo.html
5. V1 核心业务闭环
V1 需要围绕以下闭环展开:
- 导入资料包。
- 解析资料包并识别产品名称。
- 以解析后的产品名称建立资料包记录和对话会话。
- 汇总目录、页数和章节点。
- 基于法规规则和 RAG 证据执行完整性检查。
- 抽取统一字段池并执行一致性核查。
- 汇总风险并给出是否允许正式导出的结论。
- 在任务完成或出现异常时,通过飞书
@对应处理人。 - 将过程结果写入处理历史与审计留痕。
6. V1 必须覆盖的能力
6.1 Agent 对话驱动
- 支持通过对话发起审核任务。
- 支持上传附件并结合当前会话继续执行。
- 支持推荐提示词模板。
- 支持以节点方式展示目录汇总、完整性检查、字段抽取、一致性核查和风险结论。
6.2 资料包中心
- 支持批量文件、文件夹、压缩包导入。
- 支持资料包与会话一一关联。
- 对话名称默认采用解析后的产品名称。
- 支持按产品名称和批次号搜索资料包。
- 支持从资料包跳转回对应对话。
6.3 知识库与 RAG
- 支持法规资料和业务资料分层管理。
- 支持 RAG 文档源 CRUD。
- 支持切片解析、重建向量和召回状态管理。
- 支持在对话中返回法规命中依据。
- 支持字段 Schema、模板映射、责任人映射和飞书配置治理。
6.4 风险与导出
- 支持完整性风险、字段冲突风险、混档风险、低置信度风险统一汇总。
- 支持草稿导出与正式导出阻断。
- 支持结构化整改建议。
6.5 飞书协同
- 支持飞书群聊/机器人通知。
- 风险任务执行完成或执行异常时,可直接
@处理人。 - 责任人信息中必须包含飞书账号相关字段。
- 支持通过 Web 详情链接回到平台查看完整结果。
7. 关键业务对象
7.1 资料包
资料包是 V1 的一级业务对象,不再把“单文件”视为默认审核对象。
资料包至少包含:
batch_idproduct_nameconversation_idworkflow_typefile_countpage_countchapter_summaryimport_status
7.2 对话会话
会话与资料包绑定,至少包含:
conversation_idproduct_namebatch_idtask_statusmessagesnode_results
7.3 角色信息
角色信息需要从“只有角色名”升级为“可通知的责任人实体”,至少包含:
owner_roleowner_namedepartmentchapter_scoperisk_scopefeishu_user_idfeishu_open_idfeishu_namenotify_enabled
7.4 飞书通知任务
飞书通知对象至少包含:
batch_idconversation_idtrigger_sourcenotify_reasonowner_rolefeishu_user_idmessage_statusweb_detail_url
8. 需求约束
8.1 规则优先
完整性检查、强一致判断、导出阻断必须规则优先,LLM 只做解释和补充。
8.2 RAG 职责边界
RAG 负责:
- 法规依据定位
- 业务资料证据定位
- 对话解释支撑
RAG 不直接代替规则引擎输出最终合规结论。
8.3 飞书通知触发方式
当前 Demo 要求固定支持两类通知时机:
- 任务执行完成后发送结果摘要并
@处理人。 - 任务执行异常后发送异常摘要并
@处理人。
8.4 本地可演示
V1 必须保持:
- Web 可访问
- 关键流程可离线演示
- 不依赖真实大模型在线调用才能完成基础演示
9. 模块拆分建议
仍按现有模块边界推进,但职责解释需要更新:
config:配置、静态资源、环境变量、飞书集成基础配置documents:资料包、文档、页数、目录、章节点、资料搜索chat:Agent 对话工作台、节点执行区、提示词模板、会话历史audit:处理历史、审计链路、通知留痕agent_core:审核编排、规则执行、RAG 检索、结构化输出
10. 本轮重写结论
V1 现在的正确叙事应是:
- 以资料包为审核对象。
- 以 Agent 对话为主要执行入口。
- 以知识库/RAG 为法规和业务依据底座。
- 以处理历史和飞书协同保证可追溯和可协同。
这意味着后续需求分析和详细设计都应围绕“Agent 工作台式产品”继续重写,而不再沿用旧的固定报表式多页面系统思路。