115 lines
4.8 KiB
Markdown
115 lines
4.8 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章 监管信息/` 下的监管目录、申请表、产品列表、声明与沟通记录样例
|
|
|
|
## 4. V1 范围
|
|
|
|
V1 聚焦“可运行、可讲解、可演示”的注册资料审核闭环，不追求一次性做成完整商业平台。
|
|
|
|
### 4.1 V1 必须覆盖
|
|
|
|
1. 资料上传与管理
|
|
2. 文件目录与页数汇总
|
|
3. 法规完整性检查
|
|
4. 产品关键信息抽取
|
|
5. 跨文档一致性核查
|
|
6. 风险预警输出
|
|
7. 审计留痕
|
|
8. 本地可运行与 Docker 演示启动
|
|
|
|
### 4.2 V1 可接受的简化
|
|
|
|
1. 首版可优先覆盖第 1 章监管信息，并为全章扩展预留结构。
|
|
2. 首版可先展示“字段回填结果”和“回填预览”，不把保真 Word 导出作为硬门槛。
|
|
3. 首版法规校验可以本地规则为主，不强依赖联网抓取最新法规。
|
|
|
|
## 5. 业务闭环
|
|
|
|
建议按以下业务闭环理解整套系统：
|
|
|
|
1. 导入注册申报资料。
|
|
2. 识别文档、统计页数、构建目录。
|
|
3. 依据法规目录进行完整性核查。
|
|
4. 从说明书、申请表、产品列表等材料中抽取统一字段。
|
|
5. 对同名字段进行跨文档一致性比对。
|
|
6. 形成风险清单、回填结果和审计记录。
|
|
|
|
## 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 系统必须具备“冲突识别”
|
|
|
|
当前样例中已经存在不同产品资料混入的迹象，这类问题应被系统识别为高价值异常，而不是忽略。
|
|
|
|
### 7.4 系统必须具备“可解释性”
|
|
|
|
所有缺失判断、字段抽取和风险预警都应尽量有证据、有来源、有审计记录。
|
|
|
|
## 8. 后续文档与实现衔接建议
|
|
|
|
后续若继续推进设计与开发，建议按如下顺序展开：
|
|
|
|
1. 先确认待确认事项中的产品范围、回填目标和法规范围。
|
|
2. 基于模块需求文档输出设计文档。
|
|
3. 按 `config -> scenarios -> documents -> agent_core -> chat -> audit` 顺序推进重构。
|
|
4. 同步更新 README、AGENTS 和场景配置命名。
|
|
|
|
## 9. 结论
|
|
|
|
当前 V1 需求已经从“通用 Agent Demo 基座”重构为“注册申报资料审核系统”。后续所有设计、实现和讲解，建议都围绕以下四个关键词展开：
|
|
|
|
1. 文件夹级资料治理
|
|
2. 法规目录级完整性校验
|
|
3. 统一字段池与跨文档一致性检查
|
|
4. 可追溯的风险预警与审计留痕
|