Files
DEMO-AGENT/docs/原型设计/1.整体原型设计.md

8.9 KiB
Raw Blame History

注册审核平台整体原型设计

1. 产品定位与演示目标

本轮原型面向:

试剂盒临床注册文件准备与审核智能体平台

原型不强调“通用 Agent 工具箱”,而是围绕 NMPA 体外诊断试剂注册申报资料场景,展示一条可讲解、可追溯、可协同的审核闭环。

本轮演示目标:

  1. 让评委在 1 分钟内理解平台解决什么问题。
  2. 让业务人员看到资料包导入、法规核查、字段抽取、一致性核查、风险预警、Word 回填、飞书协同的完整链路。
  3. 让技术评委看到系统具备规则优先、RAG 证据解释、结构化输出和治理后台能力。
  4. 为后续 Django 页面重构或前端实现提供可直接照做的页面规格。

2. 演示总动线

最新版原型采用“顶层 4 个 Tab + 对话内节点推进”的组织方式,推荐演示顺序如下:

  1. 先进入 审核智能体,展示左侧会话历史、中间对话区、右侧上传区和任务卡片区。
  2. 在对话页上传资料包,触发目录汇总、完整性检查、字段抽取、一致性核查和风险结论节点。
  3. 点击对话节点,解释每一步的结构化结果如何在右侧卡片实时更新状态。
  4. 切换到 资料包,展示资料包列表、按产品名称搜索、资料包与会话绑定关系,以及目录、页数、章节点结果。
  5. 切换到 知识库说明法规资料、业务资料、RAG 切片、字段 Schema、模板映射、责任人映射和飞书配置如何治理。
  6. 切换到 处理历史,说明如何按批次、产品和风险状态回看历史会话、资料规模和通知留痕。
  7. 返回对话中的风险与导出节点,最后展示飞书完成通知或异常通知如何直接 @ 处理人并携带 Web 详情链接。

法规依据不再以单独一级页面存在,而是作为知识库中的法规资料,由 RAG 在对话节点中返回依据说明。

3. 统一视觉风格

3.1 视觉关键词

  • 监管科技
  • 专业可信
  • 高信息密度
  • 可解释工作台
  • 演示友好

3.2 色彩建议

  • 主背景:以白色为主,辅以极浅灰蓝,保证整体简洁和专业。
  • 主强调色:克制的深青蓝,用于导航、主按钮、激活态和重点数值。
  • 风险色:铜橙、深红,用于缺失、冲突、高风险、阻断状态。
  • 成功色:低饱和绿色,用于完成、可通过、已同步状态。
  • 中性色:冷灰,用于说明文字、边框、标签和禁用态。

3.3 组件风格

  • 使用“带状布局 + 信息舱 + 分析表格”的组合,不做普通后台卡片堆砌。
  • 表格、目录树、证据侧栏、步骤时间线是核心表达方式。
  • 高风险结论必须同时展示证据来源和责任角色,避免只有颜色没有解释。

4. 统一交互规范

4.1 全局导航

  • 顶部固定展示:平台名称、顶层 Tab、右上角用户信息。
  • 顶层 Tab 固定为:审核智能体 / 资料包 / 知识库 / 处理历史
  • 审核智能体 内部采用三栏布局,不再使用左侧 8 页面流程导航。
  • 每个页面保留“打开治理台”或同等治理入口。

4.2 统一交互规则

  • 对话是主执行入口,页面切换是不同信息视角,而不是不同执行系统。
  • 所有结果区都支持“查看来源证据”。
  • 所有关键对象都支持“打开详情抽屉”。
  • 所有治理对象都遵循“列表 -> 详情 -> 新增 / 编辑 / 启停 / 删除”的统一 CRUD 结构。
  • 风险阻断项必须在对话节点、Word 导出区和飞书通知视图里持续可见,保证前后呼应。
  • 资料包必须可跳转到关联会话,会话标题默认采用解析后的 product_name

4.3 状态规范

统一状态口径:

  • 待导入
  • 处理中
  • 已完成
  • 待复核
  • 已阻断
  • 已发送
  • 失败

统一风险口径:

  • 待确认

5. 统一 Mock 数据口径

本轮所有文档和 HTML 共用同一组演示数据,避免页面间口径冲突。

5.1 批次口径

  • batch_id: SUB-20260603-001
  • workflow_type: registration
  • product_name: 新型冠状病毒 2019-nCoV 核酸检测试剂盒
  • conversation_id: conv-001
  • applicant_name: 示例生物科技(上海)有限公司
  • chapter_scope: CH1 ~ CH6

5.2 主线风险口径

固定演示问题:

  1. CH1.11.4 缺少一份必交声明类资料。
  2. 一份沟通记录疑似错放到 CH1.9 目录。
  3. 说明书与申请表中的产品名称存在文本不一致。
  4. 储存条件字段存在待人工复核状态。
  5. 风险等级为高,当前批次不允许正式导出,仅允许生成草稿。
  6. 飞书通知在任务完成或出现异常后直接 @注册资料负责人@注册申报负责人

5.3 共用对象定义

文档和 HTML 共用以下结构化对象名称:

  • registration_overview_report
  • registration_completeness_report
  • registration_field_extraction_report
  • registration_consistency_report
  • registration_risk_report
  • registration_word_export_report
  • feishu_notification_report

治理台对象:

  • knowledge_rule_package
  • rag_source_document
  • rag_chunk_item
  • field_schema_item
  • template_mapping_item
  • owner_mapping_item
  • feishu_channel_config

6. 页面跳转关系

主页面关系调整为:

顶部导航
  -> 审核智能体
  -> 资料包
  -> 知识库
  -> 处理历史

审核智能体内部节点
  -> 资料包导入
  -> 法规完整性检查
  -> 字段抽取与字段池
  -> 一致性核查
  -> 风险预警
  -> Word 回填导出
  -> 飞书通知

跨页关系约束:

  • 资料包导入页产出 registration_overview_report
  • 法规完整性检查页消费 registration_overview_report,产出 registration_completeness_report
  • 字段抽取与字段池页消费导入结果和完整性结果,产出 registration_field_extraction_report
  • 一致性核查页消费字段池,产出 registration_consistency_report
  • 风险预警页消费前三类报告,产出 registration_risk_report
  • Word 回填导出页消费字段池、一致性和风险报告,产出 registration_word_export_report
  • 飞书通知视图消费风险报告和导出报告,产出 feishu_notification_report

7. HTML 演示站说明

7.1 交付方式

交付一个单文件 HTML

docs/原型设计/registration-prototype-demo.html

该文件仅展示 mock 内容,不接真实 Django 路由,不调用真实接口。

7.2 HTML 结构要求

  • 一个全局 App Shell
  • 四个顶层页面 section
  • 一个以对话节点为核心的审核智能体 section
  • 一个治理台抽屉层
  • 一份统一 mock 数据对象
  • 一组轻量 JavaScript 交互

7.3 必备交互

  • 切换 审核智能体 / 资料包 / 知识库 / 处理历史 视图
  • 切换会话历史
  • 点击对话节点定位到对应执行阶段
  • 展开 / 收起目录树
  • 资料包按产品名称或批次号搜索
  • 打开治理台抽屉
  • 切换治理对象 CRUD 子视图
  • 模拟 Word 导出状态切换
  • 模拟飞书消息卡片预览

8. 文档拆分说明

本轮分页文档如下:

  1. 1.1.资料包导入页原型设计
  2. 1.2.审核智能体页原型设计
  3. 1.3.法规完整性检查页原型设计
  4. 1.4.字段抽取与字段池页原型设计
  5. 1.5.一致性核查页原型设计
  6. 1.6.风险预警页原型设计
  7. 1.7.Word回填导出页原型设计
  8. 1.8.飞书通知视图原型设计
  9. 1.9.知识库与治理台原型设计

9. 实现边界

本轮原型只解决:

  1. 演示表达
  2. 页面结构
  3. 模块关系
  4. 数据口径
  5. 治理台 CRUD 展示

本轮原型不直接承诺:

  1. 后端真实接口联调
  2. Django 模板替换
  3. 真实 RAG 召回
  4. 真实 Word 文件生成
  5. 真实飞书 OpenAPI 调用

10. 结论

这套原型的核心讲法应统一为:

以对话为核心的审核智能体
  -> 资料包解析与会话绑定
  -> 节点式审核推进
  -> 知识库 / RAG 解释
  -> 风险与导出决策
  -> 飞书协同闭环

治理台负责回答“规则和知识如何维护”,审核智能体负责回答“这一批资料现在审核到了哪里、为什么这样判断、下一步谁来处理”。