DEMO-AGENT/docs/需求分析/1.V1总需求文档.md

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
2. 2.scenarios模块需求分析.md
3. 3.documents模块需求分析.md
4. 4.chat模块需求分析.md
5. 5.audit模块需求分析.md
6. 6.agent_core模块需求分析.md

另附一份待确认事项文档，供与需求方沟通时直接使用：

• 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. 可追溯的风险预警与审计留痕