docs(requirements): 明确核心信息自动回填目标

README.md

@@ -32,8 +32,9 @@ V1 采用：
 2. 汇总文件目录与页数。
 3. 对照法规要求检查完整性。
 4. 抽取产品关键信息。
-5. 核查跨文档一致性。
+5. 自动填入注册申报表格或对照清单。
-6. 输出风险预警与处理建议。
+6. 核查跨文档一致性。
+7. 输出风险预警与处理建议。
 
 ## 模块划分
 
@@ -100,7 +101,7 @@ V1 需要完成：
 - 文档解析与入库。
 - 目录与页数汇总。
 - 法规完整性检查。
-- 关键信息抽取与回填预览。
+- 关键信息抽取与注册申报表格 / 对照清单自动回填。
 - 一致性核查。
 - 风险预警与审计日志。
 - 模型 API 可配置。

agent_core/schemas/outputs.py

@@ -1,6 +1,11 @@
 SUPPORTED_OUTPUT_TYPES = {
     "general_answer",
     "document_review_report",
+    "registration_overview_report",
+    "registration_completeness_report",
+    "registration_field_extraction_report",
+    "registration_consistency_report",
+    "registration_risk_report",
     "ticket_response",
     "quality_report",
     "risk_audit_report",

apps/platform_ui/services.py

@@ -128,6 +128,176 @@ def get_platform_demo_context():
         {"time": "09:39", "title": "一致性检查", "detail": "检测到产品名称和样本类型存在跨文档冲突，升级为人工复核。"},
         {"time": "09:42", "title": "风险输出", "detail": "生成 3 条风险项、2 条补件建议与 1 条责任人通知任务。"},
     ]
+    command_batch = {
+        "id": "2025IVD-CL-0520-001",
+        "status": "进行中",
+        "workflow": "境内第三类",
+        "class": "III 类",
+        "created_at": "2025-05-20",
+        "applicant": "某某生物科技有限公司",
+        "reviewer": "张审评员",
+        "role": "审评专家",
+        "standard": "《体外诊断试剂注册与备案管理办法》及配套技术指导原则",
+        "version": "V2.1（2025-04-01）",
+    }
+    command_metrics = [
+        {
+            "key": "completeness",
+            "label": "资料包完整性得分",
+            "value": "68",
+            "suffix": "/100",
+            "level": "较差",
+            "detail": "上次得分 61（2025-05-19）",
+        },
+        {
+            "key": "health",
+            "label": "资料包健康度",
+            "value": "62",
+            "suffix": "项检查项",
+            "segments": [
+                {"label": "完整", "value": "28", "hint": "45%"},
+                {"label": "部分缺失", "value": "18", "hint": "29%"},
+                {"label": "缺失", "value": "16", "hint": "26%"},
+            ],
+        },
+        {
+            "key": "risk",
+            "label": "风险分布",
+            "value": "22",
+            "suffix": "项风险",
+            "segments": [
+                {"label": "高风险", "value": "3", "tone": "danger"},
+                {"label": "中风险", "value": "7", "tone": "warning"},
+                {"label": "低风险", "value": "12", "tone": "success"},
+            ],
+        },
+        {
+            "key": "progress",
+            "label": "审核进度",
+            "value": "46",
+            "suffix": "%",
+            "detail": "已完成 24 / 52 项任务",
+        },
+    ]
+    command_flow = [
+        {"step": "1", "title": "资料准备", "date": "2025-05-20", "state": "done"},
+        {"step": "2", "title": "形式审查", "date": "2025-05-21", "state": "done"},
+        {"step": "3", "title": "技术审评", "date": "进行中", "state": "active"},
+        {"step": "4", "title": "核查检验", "date": "待开始", "state": "todo"},
+        {"step": "5", "title": "综合评审", "date": "待开始", "state": "todo"},
+        {"step": "6", "title": "行政审批", "date": "待开始", "state": "todo"},
+        {"step": "7", "title": "制证发证", "date": "待开始", "state": "todo"},
+    ]
+    command_tabs = [
+        {"id": "completeness", "label": "注册完整性核查"},
+        {"id": "consistency", "label": "字段一致性"},
+        {"id": "risk", "label": "风险准入结论"},
+        {"id": "evidence", "label": "证据引用"},
+        {"id": "feishu", "label": "飞书通知状态"},
+    ]
+    command_checks = [
+        {
+            "chapter": "1.产品基本信息",
+            "item": "产品名称",
+            "rule": "办法 第十条",
+            "status": "完整",
+            "risk": "低风险",
+            "problem": "-",
+        },
+        {
+            "chapter": "1.产品基本信息",
+            "item": "预期用途",
+            "rule": "办法 第十条",
+            "status": "完整",
+            "risk": "低风险",
+            "problem": "-",
+        },
+        {
+            "chapter": "2.综述资料",
+            "item": "产品描述",
+            "rule": "指导原则4.2.1",
+            "status": "完整",
+            "risk": "低风险",
+            "problem": "-",
+        },
+        {
+            "chapter": "2.综述资料",
+            "item": "作用原理",
+            "rule": "指导原则4.2.2",
+            "status": "部分缺失",
+            "risk": "中风险",
+            "problem": "缺少关键原理图及验证数据说明",
+        },
+        {
+            "chapter": "3.研究资料",
+            "item": "分析性能评估",
+            "rule": "指导原则5.3.1",
+            "status": "部分缺失",
+            "risk": "中风险",
+            "problem": "线性范围验证数据不完整",
+        },
+        {
+            "chapter": "3.研究资料",
+            "item": "阳性判断值",
+            "rule": "指导原则5.3.2",
+            "status": "缺失",
+            "risk": "高风险",
+            "problem": "未提供阳性判断值确定依据",
+        },
+        {
+            "chapter": "4.临床评价资料",
+            "item": "临床试验方案",
+            "rule": "指导原则6.2.1",
+            "status": "完整",
+            "risk": "低风险",
+            "problem": "-",
+        },
+        {
+            "chapter": "4.临床评价资料",
+            "item": "临床试验报告",
+            "rule": "指导原则6.2.2",
+            "status": "部分缺失",
+            "risk": "中风险",
+            "problem": "有效性结果分析不完整",
+        },
+        {
+            "chapter": "4.临床评价资料",
+            "item": "不良事件汇总分析",
+            "rule": "指导原则6.2.4",
+            "status": "缺失",
+            "risk": "高风险",
+            "problem": "未提供不良事件汇总分析报告",
+        },
+        {
+            "chapter": "5.生产资料",
+            "item": "生产工艺验证",
+            "rule": "指导原则7.2.3",
+            "status": "完整",
+            "risk": "低风险",
+            "problem": "-",
+        },
+    ]
+    key_risks = [
+        {"title": "阳性判断值确定依据缺失", "level": "高风险"},
+        {"title": "不良事件汇总分析报告缺失", "level": "高风险"},
+        {"title": "临床试验方案偏离未充分说明", "level": "中风险"},
+    ]
+    next_actions = [
+        {"title": "退回企业补充资料", "detail": "需企业补充 3 项高风险资料", "state": "待处理", "tone": "danger"},
+        {"title": "补充说明或澄清", "detail": "需企业说明 7 项中风险问题", "state": "待处理", "tone": "warning"},
+        {"title": "进入核查检验环节（可选）", "detail": "风险可控后进入下一环节", "state": "待处理", "tone": "success"},
+    ]
+    owners = [
+        {"role": "审评专家", "name": "张审评员", "status": "当前处理人"},
+        {"role": "审核组长", "name": "李组长", "status": "待确认"},
+        {"role": "法规专员", "name": "王法规", "status": "协同处理"},
+        {"role": "临床专家", "name": "陈专家", "status": "协同处理"},
+    ]
+    operation_logs = [
+        {"time": "2025-05-21 10:24", "actor": "张审评员", "action": "发起完整性核查"},
+        {"time": "2025-05-21 10:26", "actor": "Agent Core", "action": "命中 62 项检查规则"},
+        {"time": "2025-05-21 10:28", "actor": "Agent Core", "action": "生成风险准入结论"},
+    ]
     knowledge_filters = [
         {"label": "全部", "active": True},
         {"label": "法规依据", "active": False},
@@ -169,4 +339,13 @@ def get_platform_demo_context():
         "mcp_connectors": mcp_connectors,
         "skills": skills,
         "workflow_steps": workflow_steps,
+        "command_batch": command_batch,
+        "command_metrics": command_metrics,
+        "command_flow": command_flow,
+        "command_tabs": command_tabs,
+        "command_checks": command_checks,
+        "key_risks": key_risks,
+        "next_actions": next_actions,
+        "owners": owners,
+        "operation_logs": operation_logs,
     }

apps/platform_ui/urls.py

@@ -10,4 +10,5 @@ urlpatterns = [
     path("mcp-center/", views.mcp_center, name="mcp-center"),
     path("skills/", views.skill_studio, name="skills"),
     path("command-center/", views.command_center, name="command-center"),
+    path("command-center-v2/", views.command_center_v2, name="command-center-v2"),
 ]

apps/platform_ui/views.py

@@ -21,3 +21,8 @@ def skill_studio(request):
 def command_center(request):
     context = get_platform_demo_context()
     return render(request, "platform_ui/command_center.html", context)
+
+
+def command_center_v2(request):
+    context = get_platform_demo_context()
+    return render(request, "platform_ui/command_center_v2.html", context)

configs/document_review.yaml

@@ -1,22 +1,27 @@
 id: document_review
-name: 文档审核助手
+name: 注册资料审核助手
-description: 检查合同、制度或 SOP 中的风险点和缺失项
+description: 汇总体外诊断试剂注册申报资料目录与页数，并检查完整性、一致性和合规风险
 applicable_questions:
-  - 合同审核
+  - 资料目录与页数汇总
-  - 制度审核
+  - NMPA 注册申报资料完整性检查
+  - 产品关键信息抽取
+  - 跨文档一致性核查
+  - 合规风险预警
 agent:
-  role: 文档审核专家
+  role: 体外诊断试剂注册资料审核专家
-  goal: 根据审核规则和知识库内容输出结构化审核意见
+  goal: 根据 NMPA 注册申报资料要求、法规依据和上传资料输出结构化审核结论
   instructions:
+    - 优先围绕资料目录、页数、章节点、完整性、字段一致性和风险建议回答
+    - 法规判断应优先依据本地规则和知识库证据，不得凭空补全缺失资料
     - 不确定的问题必须标记为需人工复核
-    - 输出必须包含风险等级和修改建议
+    - 输出必须包含风险等级、涉及文件、法规或规则依据和处理建议
 rag:
   enabled: true
-  collection: document_review
+  collection: registration_documents
   top_k: 5
 tools:
   - check_required_fields
 output:
-  type: document_review_report
+  type: registration_risk_report
 audit:
   enabled: true

design-qa.md

@@ -0,0 +1,25 @@
+**Findings**
+- No actionable P0/P1/P2 findings remain.
+
+**Open Questions**
+- The source visual is an Image Gen concept rather than a pixel-locked Figma file, so exact icon glyphs and logo geometry were implemented as code-native UI marks. The final prototype preserves the selected direction's hierarchy, density, risk states, and operational layout.
+
+**Implementation Checklist**
+- Source visual truth path: `C:\Users\bruce\.codex\generated_images\019e8bb8-b097-72b3-9c89-97cfca019c7c\ig_0fe578f839e33933016a1fae76771c81918c954bf5cbfe72d2.png`
+- Implementation screenshot path: `D:\Code\DEMO-AGENT\output\playwright\command-center-v2-desktop.png`
+- Mobile screenshot path: `D:\Code\DEMO-AGENT\output\playwright\command-center-v2-mobile.png`
+- Full-view comparison evidence: `D:\Code\DEMO-AGENT\output\playwright\command-center-v2-comparison.png`
+- Viewport: desktop `1440 x 1024`, mobile `390 x 844`
+- State: default command-center workbench; desktop screenshot shows the selected direction's primary dashboard state.
+- Focused region comparison evidence: not separately required; this is a dense dashboard concept and the full-view comparison makes the critical regions visible enough: sidebar, batch strip, metrics, workflow, audit table, and right risk rail.
+- Fonts and typography: Segoe UI / PingFang SC / Microsoft YaHei fallback stack matches the professional enterprise SaaS feel; hierarchy and body sizes are readable, with no negative letter spacing.
+- Spacing and layout rhythm: Desktop uses the same left rail, top context strip, four metric blocks, workflow strip, table region, and right-side risk rail as the source. Mobile switches to stacked sections to avoid cramped table-dashboard density.
+- Colors and visual tokens: Deep navy sidebar, white work surface, cool gray borders, blue primary actions, red/orange/green semantic risk states match the selected visual direction.
+- Image quality and asset fidelity: The source concept did not require product photos or decorative raster assets. The implementation uses lightweight UI marks and CSS primitives appropriate for a Django dashboard prototype.
+- Copy and content: Chinese labels are aligned to the requirements: NMPA IVD review, registration batch, completeness check, risk gate, evidence, Feishu notification, responsible owners, and audit trail.
+- Patches made since previous QA pass: added mobile wrapping for the header and batch strip, converted mobile actions to a single-column grid, adjusted the health legend, and suppressed horizontal overflow.
+- final result: passed
+
+**Follow-up Polish**
+- P3: Replace letter-based placeholder nav icons with an icon font or library if the project later adds a frontend asset pipeline.
+- P3: Add separate interactive tab bodies for consistency, evidence, and Feishu cards if the prototype needs a longer live demo script.

docs/设计文档/1.注册资料审核Agent设计思路.md

@@ -0,0 +1,341 @@
+# 注册资料审核 Agent 需求分析与设计思路
+
+## 1. 题目理解
+
+本题要求建设的不是普通文档问答机器人，而是面向 NMPA 体外诊断试剂注册申报资料的“资料准备与审核 Agent”。
+
+系统需要围绕一个注册资料包完成以下闭环：
+
+1. 接收并解析一批申报资料。
+2. 自动汇总文件目录与页数。
+3. 对照 NMPA 法规和本地公告附件包检查资料完整性。
+4. 从产品资料中抽取核心字段。
+5. 将抽取结果填入申报表格、对照清单或目标模板。
+6. 检查文档结构、章节规范性和跨文档字段一致性。
+7. 输出合规风险预警、责任人通知建议和整改动作。
+
+因此，系统设计的重点应从“单文档对话”转向“资料包级审核编排”。
+
+## 2. 输入资料口径
+
+### 2.1 待审核资料
+
+题目第一项要求“自动汇总文件夹文件目录与页数”，这意味着首版输入不应只支持单文件上传，还要覆盖资料包导入。
+
+V1 建议支持以下导入方式：
+
+1. 多文件批量上传。
+2. 文件夹拖拽或前端批量选择文件。
+3. 压缩包上传并自动解压。
+
+压缩包格式覆盖：
+
+1. `zip`
+2. `rar`
+3. `7z`
+
+系统解包后应保留原始相对路径，用于还原资料目录、识别章节点和发现文件夹结构异常。压缩包内多层目录按原目录作为章节点识别依据。
+
+`rar`、`7z` 解压必须采用纯 Python 实现，允许新增第三方 Python 依赖包，避免服务器部署时依赖系统级解压工具。
+
+### 2.2 法规依据资料
+
+法规核查不应只依赖在线网页或大模型记忆。当前本地材料中已经提供了主规则依据：
+
+```text
+docs/原始材料/关于公布体外诊断试剂注册申报资料要求和批准证明文件格式的公告/
+```
+
+该目录下资料应作为 V1 的主规则包，包括注册申报资料要求、格式要求、安全和性能基本原则清单、注册证格式、变更和延续注册资料要求等。
+
+`docs/原始材料/附件 4 体外诊断试剂注册申报资料要求及说明.doc` 可作为同源补充材料。
+
+外部网站 `cmde.org.cn` 和 `nmpa.gov.cn` 在 V1 中主要作为法规来源说明和后续在线更新依据，不作为演示时的唯一实时依赖。
+
+## 3. 核心需求重整
+
+### 3.1 自动汇总文件目录与页数
+
+系统应扫描当前资料包中的所有文件，形成目录汇总表。
+
+目录汇总表至少包含：
+
+| 字段 | 说明 |
+|---|---|
+| 原始路径 | 解压或上传后的相对路径 |
+| 文件名 | 原始文件名 |
+| 文件类型 | PDF、DOCX、DOC、TXT、MD 等 |
+| 页数 | 精确页数或待复核状态 |
+| 章节点 | 如 CH1.2、CH1.4、CH1.11.5 |
+| 资料名称 | 识别出的注册资料名称 |
+| 处理状态 | 已解析、解析失败、待人工确认 |
+| 是否命中法规目录 | 用于后续完整性核查 |
+
+页数统计策略：
+
+1. PDF 优先用 `pdfplumber` 或 `PyMuPDF` 精确统计。
+2. DOCX 页数必须精确统计，不能以估算页数作为 V1 验收结果。
+3. DOC 可通过兼容解析工具或转换后处理，无法精确统计时标记为待人工复核。
+4. 扫描件或无法提取正文的文件标记为“需 OCR / 待人工复核”。
+
+### 3.2 按 NMPA 法规要求核查完整性
+
+完整性核查的规则来源应优先来自本地公告附件包。
+
+V1 规则建议拆成三层：
+
+1. 资料齐套性：是否具备注册申报资料要求中的必交文件。
+2. 章节点结构：文件是否落在正确章节，目录与实际文件是否一致。
+3. 格式模板：申请表、注册证、清单、声明类文件是否符合对应格式要求。
+
+核查结果需要区分：
+
+| 状态 | 说明 |
+|---|---|
+| 已提供 | 文件和章节点均匹配 |
+| 缺失 | 必交资料未找到 |
+| 疑似提供 | 文件名或内容疑似匹配，但命名/归类不规范 |
+| 错放 | 文件存在但章节点或目录位置不合理 |
+| 待复核 | 规则无法直接判定 |
+
+自动通知责任人属于完整性核查后的动作。V1 责任人先通过后台或配置文件手动维护，并按资料章节配置。系统可先输出责任角色和通知载荷，例如“CH4 临床评价资料缺失 -> 临床注册负责人”，后续再接飞书机器人执行 `@` 通知。
+
+### 3.3 产品关键信息抽取与回填
+
+题目中明确要求抽取：
+
+1. 产品名称
+2. 检测靶标
+3. 适用范围
+4. 储存条件
+5. 性能指标
+
+结合样例材料，首版建议以 `docs/原始材料/目标产品说明书.docx` 作为核心抽取样本，同时从申请表、产品列表、声明类文件中抽取可比对字段。
+
+抽取结果先进入“统一字段池”，再用于回填。
+
+统一字段池字段建议：
+
+| 字段 | 说明 |
+|---|---|
+| field_key | 标准字段编码 |
+| field_label | 中文字段名 |
+| value | 标准化字段值 |
+| raw_value | 原文值 |
+| source_document | 来源文件 |
+| source_location | 来源章节、表格或页码 |
+| confidence | 置信度 |
+| conflict_status | 一致、冲突、待确认 |
+| fillable | 是否可回填 |
+
+回填目标已确认。V1 应按两步走：
+
+1. 先输出结构化回填表，并自动填入注册申报表格或法规对照清单字段。
+2. 基于 Word 模板库生成可导出的目标文件。
+
+注册申报表格和对照清单都应在模板库中建立字段映射，而不是把回填逻辑写死在 Prompt 中。
+
+### 3.4 文档结构、信息一致性与章节规范性核查
+
+结构核查应覆盖两类对象：
+
+1. 单文档内部章节是否完整。
+2. 资料包整体章节点是否符合 NMPA 目录结构。
+
+以说明书或性能研究资料为例，需要检查是否包含分析灵敏度、特异性、重复性等必检项目。
+
+一致性核查应基于统一字段池执行。首版按当前项目口径采用严格一致规则，即同一审核范围内同一字段只要文本不一致，就标记为冲突或待人工复核。
+
+强一致字段建议包括：
+
+1. 产品名称
+2. 规格型号 / 包装规格
+3. 申请人名称
+4. 检测靶标
+5. 适用范围 / 预期用途
+6. 储存条件
+
+当前样例中存在“目标产品说明书”和第 1 章监管资料产品名称不一致的情况。系统不应在需求阶段强行解释为同一产品，而应设计为：
+
+1. 用户先选择审核范围或项目批次。
+2. 系统对选定范围内的文件做一致性核查。
+3. 若发现跨产品资料混入，输出混档风险。
+
+### 3.5 合规风险预警与处理建议
+
+风险清单应把完整性、结构、字段一致性和抽取失败结果统一汇总。
+
+风险项字段建议：
+
+| 字段 | 说明 |
+|---|---|
+| risk_level | 高 / 中 / 低 |
+| risk_type | 缺失、错放、冲突、格式不规范、混档、待复核 |
+| related_document | 涉及文件 |
+| requirement_source | 法规或规则来源 |
+| description | 问题描述 |
+| suggestion | 处理建议 |
+| owner_role | 建议责任角色 |
+| notification_message | 可发送给责任人的通知摘要 |
+
+示例：
+
+```text
+文件 CH4 临床评价资料：未在当前资料包中识别到临床评估报告。建议补充临床评价资料，并由临床注册负责人复核。
+```
+
+```text
+产品名称冲突：说明书中的产品名称与申请表中的产品名称不一致。建议先确认当前审核范围是否混入其他产品资料。
+```
+
+## 4. Agent 编排设计
+
+### 4.1 总体链路
+
+建议 Agent Core 采用固定编排链路：
+
+```text
+资料导入
+  -> 解压与文件扫描
+  -> 页数统计与目录汇总
+  -> 文本 / 表格 / 章节解析
+  -> 章节点归类
+  -> 法规规则匹配
+  -> 字段抽取与统一字段池
+  -> 一致性核查
+  -> 风险汇总
+  -> 申报表格 / 对照清单自动回填
+  -> Word 生成
+  -> 审计记录与责任人通知
+```
+
+### 4.2 规则优先，模型辅助
+
+法规完整性、必交项、章节点和强一致字段不应交给大模型自由判断。
+
+推荐分工：
+
+| 能力 | 处理方式 |
+|---|---|
+| 文件扫描、解压、页数统计 | 工具 / 服务层 |
+| 法规目录匹配 | 结构化规则 |
+| 必交项缺失判断 | 结构化规则 |
+| 固定字段抽取 | 正则、标题、表格规则 |
+| 长文本字段归纳 | LLM 辅助 |
+| 法规条款引用 | RAG 辅助 |
+| 风险文案与建议 | 规则结论 + LLM 组织语言 |
+
+### 4.3 RAG 的职责
+
+RAG 不作为最终合规判断引擎，只负责：
+
+1. 从法规原文中找证据。
+2. 从业务资料中找来源片段。
+3. 为审计记录保留可追溯依据。
+4. 支持用户追问“为什么这么判”。
+
+### 4.4 Tool Registry 建议工具
+
+Agent Core 后续应注册以下工具：
+
+1. `scan_submission_package`：扫描资料包并保留目录结构。
+2. `extract_archive`：解压 zip、rar、7z，其中 rar、7z 必须使用纯 Python 依赖实现。
+3. `count_document_pages`：统计页数，DOCX 必须精确统计。
+4. `classify_chapter_node`：识别章节点和资料名称。
+5. `check_nmpa_completeness`：按结构化规则检查齐套性。
+6. `extract_product_fields`：抽取产品核心字段。
+7. `compare_field_consistency`：执行字段一致性比对。
+8. `check_document_structure`：检查章节和必检项目。
+9. `build_risk_alerts`：汇总风险和处理建议。
+10. `build_fill_outputs`：生成注册申报表格或对照清单回填结果。
+11. `render_word_template`：按模板生成 Word 文件。
+12. `build_owner_notification`：生成责任人通知载荷。
+
+## 5. Django 模块落地思路
+
+### 5.1 Documents
+
+Documents 是资料治理中心，应从“单文件上传记录”升级为“资料包 + 文件记录 + 解析结果”。
+
+需要新增或强化：
+
+1. 资料包批次。
+2. 压缩包解压记录。
+3. 原始相对路径。
+4. 页数和页数可信度。
+5. 章节点识别状态。
+6. 文本、表格和标题解析状态。
+7. 业务资料与法规资料隔离。
+
+### 5.2 Agent Core
+
+Agent Core 是审核编排引擎，应沉淀：
+
+1. 注册资料审核专用输出 schema。
+2. NMPA 规则包加载器。
+3. 统一字段池。
+4. 风险映射规则。
+5. RAG 证据检索。
+6. Word 模板回填接口。
+
+### 5.3 Chat
+
+Chat 页面应升级为注册审核工作台。
+
+建议保留自然语言输入，同时提供快捷任务按钮：
+
+1. 汇总当前资料目录及页数。
+2. 检查资料完整性。
+3. 抽取产品核心信息。
+4. 检查一致性。
+5. 生成风险预警报告。
+
+### 5.4 Audit
+
+Audit 需要记录：
+
+1. 审核范围。
+2. 使用的规则版本。
+3. 参与文件清单。
+4. 工具调用结果。
+5. 风险结论。
+6. 回填输出文件。
+7. 通知责任人结果。
+
+## 6. V1 实现优先级
+
+建议按以下顺序落地，保证演示先闭环：
+
+1. 批量上传 / 压缩包解压 / 文件目录汇总。
+2. PDF、DOCX 页数统计和解析状态展示，其中 DOCX 必须精确统计。
+3. 基于公告附件包整理结构化必交项规则，第 2 至第 6 章先做规则级初步确认。
+4. 完整性核查与缺失项风险输出。
+5. 从目标产品说明书抽取产品名称、靶标、适用范围、储存条件、性能指标。
+6. 对说明书、申请表、产品列表做字段一致性核查。
+7. 输出综合风险报告和处理建议。
+8. 注册申报表格 / 对照清单自动回填和 Word 模板导出。
+9. 责任人通知载荷与飞书机器人演示。
+
+## 7. 已确认约束与剩余待确认事项
+
+以下约束已经确认，应作为后续实现依据：
+
+1. DOCX 页数必须精确统计。
+2. 压缩包内多层目录按原目录作为章节点依据。
+3. `rar`、`7z` 解压必须纯 Python 实现，允许新增第三方依赖包。
+4. 责任人先手动配置，按资料章节维护。
+5. 第 2 至第 6 章不补充企业真实样本，先按公告附件包进行规则级初步确认。
+
+剩余待确认事项：
+
+1. 后续如业务方另行提供专用 Word 模板，需要确认模板版本、生效范围和字段映射审批机制。
+
+## 8. 结论
+
+本题最稳的设计表达是：
+
+```text
+资料包治理 + 本地法规规则包 + 统一字段池 + 规则优先的 Agent 编排 + RAG 证据解释 + 风险与回填输出
+```
+
+这样既能覆盖题面五个要求，也能解释为什么系统需要 Django、Documents、Agent Core、RAG、Tool Registry 和 Audit 这些边界。

docs/需求分析/0.需求重构总览与待确认事项.md

@@ -16,10 +16,10 @@
 
 系统需要覆盖的业务闭环至少包括：
 
-1. 扫描申报文件夹，形成资料目录、文件清单、页数统计和章节点归属。
+1. 导入申报资料包，支持批量文件、文件夹和压缩包形式，形成资料目录、文件清单、页数统计和章节点归属。
 2. 基于法规要求和申报目录模板，判断资料是否齐全、是否放对位置、是否缺少关键附件。
 3. 从说明书、申请表、产品列表、声明文件等材料中提取关键信息，形成统一字段池。
-4. 利用统一字段池回填申请表、对照清单、章节目录或其他待生成文件。
+4. 利用统一字段池自动填入注册申报表格或法规对照清单。
 5. 对跨文档的名称、规格、适用范围、靶标、机构、日期、标准清单等信息做一致性检查。
 6. 输出可讲解、可演示、可追踪的风险预警和处理建议。
 
@@ -108,7 +108,7 @@
 
 ### 5.4 本题不仅需要审核，还需要回填与生成
 
-题面第三项写得很明确：从产品文件中提取关键信息并自动填写至目标文件。因此系统不是只出一份报告，还要支持“结构化字段输出 + 对目标文件字段回填”。
+题面第三项写得很明确：从产品文件中提取关键信息并自动填写至目标文件。当前已确认回填目标为“注册申报表格或对照清单”，因此系统不是只出一份报告，还要支持“结构化字段输出 + 申报表格 / 对照清单自动回填”。
 
 ### 5.5 本题存在历史申报与监管沟通情境
 
@@ -134,6 +134,8 @@
 
 7. 系统展示当前完整性结论所依据的公告附件、资料要求和模板来源。
 
+导入环节已确认支持两种演示路径：一是直接批量上传样例文件，二是上传包含多级目录的压缩包并由系统自动解压。压缩包格式覆盖 `zip`、`rar`、`7z`，其中 `rar` 和 `7z` 必须采用纯 Python 实现，允许增加第三方 Python 包依赖，以便后续部署到服务器时不依赖系统级解压工具。
+
 ## 7. 已确认事项
 
 以下内容已根据最新沟通结果确认，并已同步进入后续模块需求：
@@ -169,6 +171,15 @@
 - 结合补充的公告附件包，可以确认第 2 至第 6 章对应的法规要求、章节点结构和资料模板口径已经存在。
 - 这些材料可以作为系统进行完整性检查、章节归类、字段回填和生成审核结论的“监管模板 / 结构模板”。
 - 但它们并不等于每一章都有完整可直接复用的企业填充样本，因此需求上应表述为“可作为法规模板与结构模板”，而不是“已经具备全量业务样本”。
+- 已确认第 2 至第 6 章首版不补充企业真实样本，先按照 `docs/原始材料/关于公布体外诊断试剂注册申报资料要求和批准证明文件格式的公告/` 下公告附件包进行规则级初步确认。
+
+### 7.9 资料包解析与责任人配置口径
+
+- DOCX 页数必须精确统计，不能以估算页数作为 V1 验收结果。
+- 压缩包内多层目录按原目录结构作为章节点识别依据。
+- `rar`、`7z` 解压必须采用纯 Python 实现，允许增加第三方依赖包。
+- 责任人先通过后台或配置文件手动维护，按资料章节配置责任人。
+- 系统需要自动提取产品名称、检测靶标、适用范围、储存条件、性能指标等核心信息，并自动填入注册申报表格或对照清单。
 
 ### 7.6 输出文档形式
 
@@ -208,10 +219,11 @@
 - 当前样例文件主要集中在第 1 章监管信息。
 - 题面与法规附件实际要求覆盖六大章。
 
-需确认的问题：
+当前确认口径：
 
-1. Demo 是否允许以第 1 章样本做主演示，同时以法规模板覆盖第 2 至第 6 章的完整性校验口径。
+1. Demo 允许以第 1 章样本做主演示。
-2. 若后续要把第 2 至第 6 章做成更强的“内容级抽取与回填演示”，是否还会补充企业真实样本。
+2. 第 2 至第 6 章不补充企业真实样本。
+3. 第 2 至第 6 章先按公告附件包做资料要求、章节点结构和模板口径的规则级初步确认。
 
 ### 8.2 仍建议补充确认的业务细节
 
@@ -219,8 +231,9 @@
 
 1. Word 导出是否除 `docx` 外还要同步输出 PDF 归档件。
 2. 用户新写模板进入模板库后，模板版本、生效范围和审批流程是否需要管理。
-3. 责任人配置是仅按章节点维护，还是同时支持按任务类型、项目角色双维度维护。
+3. 责任人配置首版按资料章节手动维护，后续再扩展按任务类型、项目角色双维度维护。
 4. 后端知识库更新入口是否只允许管理员使用，还是允许业务审核人员参与人工校订。
+5. 后续如业务方另行提供专用 Word 模板，需要确认模板版本、生效范围和字段映射审批机制。
 
 ## 9. 本轮需求分析采用的默认假设
 
@@ -237,6 +250,13 @@
 9. 飞书接入属于本次 Demo 明确范围，需支持在飞书内完成任务选择、结果查看和责任人通知，并支持群聊机器人入口。
 10. V1 的法规任务边界先聚焦“注册申报”，变更备案和延续注册在规则架构上预留扩展位，但不作为当前主验收范围。
 11. 系统需要提供后端管理页面，支持人工校订、模板管理、责任人维护和知识库更新。
+12. 资料包导入首版应支持批量文件和压缩包，压缩包解包后保留原始相对路径。
+13. DOCX 页数必须精确统计。
+14. 压缩包内多层目录按原目录作为章节点依据。
+15. `rar`、`7z` 解压必须纯 Python 实现，允许增加第三方依赖包。
+16. 责任人首版按资料章节手动配置。
+17. 第 2 至第 6 章首版不补充企业样本，按公告附件包做规则级初步确认。
+18. 产品核心信息抽取后必须自动填入注册申报表格或对照清单。
 
 ## 10. 结论
 

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

@@ -19,7 +19,7 @@
 1. 自动汇总注册资料目录与页数。
 2. 对照法规要求检查资料完整性。
 3. 抽取产品关键信息并形成统一字段池。
-4. 支持目标文件字段回填准备。
+4. 支持将产品核心信息自动填入注册申报表格或对照清单。
 5. 核查跨文档信息一致性与章节规范性。
 6. 输出合规风险预警和处理建议。
 
@@ -51,7 +51,7 @@ V1 聚焦“可运行、可讲解、可演示”的注册资料审核闭环，
 ### 4.1 V1 必须覆盖
 
 1. 资料上传与管理
-2. 文件目录与页数汇总
+2. 资料包导入、压缩包解包、文件目录与页数汇总
 3. 法规完整性检查
 4. 产品关键信息抽取
 5. 跨文档一致性核查
@@ -72,6 +72,8 @@ V1 聚焦“可运行、可讲解、可演示”的注册资料审核闭环，
 3. 首版法规校验可以本地规则为主，不强依赖联网抓取最新法规。
 4. 首版需要支持飞书内完成任务选择、结果查看和责任人通知，并支持群聊机器人入口及手动维护责任人 / 飞书账号映射。
 5. 首版法规任务边界以“注册申报”主流程为核心，变更备案和延续注册暂作为规则扩展方向。
+6. DOCX 页数必须精确统计，不能以估算页数作为 V1 验收结果；DOC 如受格式限制无法精确统计，应标记为待复核。
+7. 回填目标已确认为注册申报表格或对照清单，首版应输出结构化回填结果，并支持按模板生成 Word 文件。
 
 ## 5. 业务闭环
 
@@ -81,8 +83,9 @@ V1 聚焦“可运行、可讲解、可演示”的注册资料审核闭环，
 2. 识别文档、统计页数、构建目录。
 3. 依据法规目录进行完整性核查。
 4. 从说明书、申请表、产品列表等材料中抽取统一字段。
-5. 对同名字段进行跨文档一致性比对。
+5. 将产品名称、检测靶标、适用范围、储存条件、性能指标等核心信息自动填入注册申报表格或对照清单。
-6. 形成风险清单、回填结果和审计记录。
+6. 对同名字段进行跨文档一致性比对。
+7. 形成风险清单、回填结果和审计记录。
 
 在规则执行层，建议采用“双层知识底座”：
 
@@ -95,6 +98,10 @@ V1 聚焦“可运行、可讲解、可演示”的注册资料审核闭环，
 2. 同步建设结构化规则文件，避免让完整性校验完全依赖检索文本。
 3. 提供后台管理页面，支持人工校订和知识库更新。
 
+资料导入层需要按“资料包”而不是“单文件”设计。V1 至少应支持批量文件上传、文件夹导入和压缩包导入能力。压缩包导入支持 `zip`、`rar`、`7z`，解包后保留原始相对路径，并将压缩包内多层目录按原目录作为章节点识别依据。`rar`、`7z` 解压必须采用纯 Python 实现，允许增加第三方依赖包，避免服务器部署时依赖系统级解压工具。
+
+第 2 至第 6 章首版不补充企业真实样本，先以公告附件包进行资料要求、章节点结构和模板口径的规则级初步确认。责任人首版通过后台或配置文件手动维护，并按资料章节配置。
+
 在法规维度上，建议把完整流程理解为：
 
 1. 识别当前审核任务属于“注册申报”主流程。

docs/需求分析/1.config模块需求分析.md

@@ -25,6 +25,7 @@
 - 上传目录不仅要按场景分，还要考虑按项目批次、申报轮次、资料章节分层。
 - 规则来源不止一个 YAML，可能包括法规目录模板、字段抽取模板、一致性校验规则、风险分级规则，以及公告附件原文所对应的结构化法规包。
 - 文档解析链路中可能同时使用 `pdfplumber`、`PyMuPDF`、Word 解析库、OCR 预留能力，因此要有可切换的解析策略配置。
+- 压缩包处理链路需要支持 `zip`、`rar`、`7z`，其中 `rar` 和 `7z` 必须使用纯 Python 依赖实现，不能依赖服务器系统级解压工具。
 - 审计数据不能只保留“问答日志”，还要能关联具体资料批次和审核任务。
 
 ### 3.2 Demo 与真实业务之间要有明确边界
@@ -161,11 +162,17 @@
   是否启用 OCR 兜底。
 
 - `PAGE_COUNT_STRATEGY`
-  页数统计策略，如 PDF 直接取页数、Word 按分页符或估算策略。
+  页数统计策略。PDF 和 DOCX 必须精确统计页数；DOC 如无法精确统计，应标记为待人工复核。
 
 - `DOCX_PARSE_STRATEGY`
   例如“仅提取文本”“提取文本和表格”“保留章节层级”。
 
+- `ARCHIVE_EXTRACT_STRATEGY`
+  压缩包解包策略。V1 要求 `zip`、`rar`、`7z` 均通过 Python 依赖实现，并保留原始相对路径。
+
+- `ARCHIVE_CHAPTER_SOURCE`
+  章节点识别依据。V1 默认使用压缩包内多层目录作为章节点识别依据。
+
 ### 5.4 规则与版本配置项
 
 - `REG_RULESET_VERSION`
@@ -321,10 +328,11 @@ admin/
 1. 将当前偏“通用 Demo”的命名改造成更贴近注册申报业务的配置语义。
 2. 增加抽取结果目录、报告目录、规则目录等配置。
 3. 增加法规规则版本与字段 schema 版本配置。
-4. 为 `.doc`、`.docx`、PDF 页数统计和解析策略提供显式配置位。
+4. 为 `.doc`、`.docx`、PDF 页数统计和解析策略提供显式配置位，其中 DOCX 页数必须精确统计。
 5. 增加法规原文目录、法规流程类型和文件格式模板版本配置。
 6. 增加 Word 导出目录和飞书应用接入相关配置。
 7. 增加模板库目录、规则管理目录和责任人映射配置。
+8. 增加纯 Python 压缩包解包依赖与策略配置，覆盖 `zip`、`rar`、`7z`。
 
 ## 11. 本模块验收标准
 

docs/需求分析/2.scenarios模块需求分析.md

@@ -40,7 +40,7 @@
    法规完整性核查助手
 
 3. `registration_field_extraction`
-   产品关键信息抽取助手
+   产品关键信息抽取与回填助手
 
 4. `registration_consistency_review`
    跨文档一致性核查助手
@@ -168,12 +168,15 @@
 
 - 从说明书、申请表、产品列表等材料提取产品名称、靶标、适用范围、规格、储存条件、性能信息等
 - 形成统一字段池
+- 将产品名称、检测靶标、适用范围、储存条件、性能指标等核心信息自动填入注册申报表格或对照清单
 
 配置上需要指定：
 
 - 目标字段 schema
 - 字段来源优先级
 - 是否允许 LLM 兜底抽取
+- 注册申报表格 / 对照清单的字段映射关系
+- 是否生成 Word 输出和导出入口
 
 ### 7.4 一致性核查任务
 
@@ -290,6 +293,7 @@ configs/registration/
 2. 每个任务的输入前提、输出类型和所依赖规则清晰可见。
 3. 任务配置变更主要通过 YAML 完成，不需要频繁改 Python 代码。
 4. 至少能清楚区分“目录汇总、完整性检查、字段抽取、一致性核查、风险预警”五类任务。
+5. 字段抽取任务必须能表达“抽取核心信息并自动填入注册申报表格或对照清单”的输出目标。
 
 ## 12. 当前代码基线下的重构建议
 

docs/需求分析/3.documents模块需求分析.md

@@ -42,6 +42,16 @@
 
 必要时为后续 OCR 或图片扫描件预留扩展位。
 
+结合题面“自动汇总文件夹文件目录与页数”的要求，Documents 模块还需要支持资料包级导入，而不是只支持单文件：
+
+- 多文件批量上传
+- 文件夹选择或拖拽上传
+- 压缩包上传并自动解包
+
+压缩包覆盖 `zip`、`rar`、`7z` 等常见格式。解包后应保留压缩包内的原始相对路径，并将多层目录按原目录作为章节点识别依据，用于还原资料目录、识别章节点和判断是否存在目录层级异常。
+
+`rar`、`7z` 解压必须采用纯 Python 实现，允许新增第三方 Python 包依赖，避免服务器部署时依赖系统级解压工具。
+
 除用户上传的申报资料外，系统还需要支持管理平台内置法规资料，例如：
 
 - 注册申报资料要求及说明
@@ -194,6 +204,15 @@
 
 如果是批量导入，系统还应支持一次性上传多个资料。
 
+如果上传的是压缩包，流程应扩展为：
+
+1. 保存原始压缩包。
+2. 校验压缩包格式和大小。
+3. 解包到当前项目 / 批次的隔离目录。
+4. 遍历解包后的文件并创建文档记录。
+5. 保留每个文件的原始相对路径和所属压缩包来源。
+6. 对解包失败、空包、嵌套异常或不支持格式给出业务化提示。
+
 ### 6.2 文件识别与归类流程
 
 上传后，系统应尽量自动识别文件属于哪个章节点。识别依据可以包括：
@@ -217,10 +236,19 @@
 页数统计是本题显式要求，需支持：
 
 - PDF 精确页数统计
-- Word 文件页数估算或格式解析策略
+- DOCX 精确页数统计
+- DOC 文件页数统计或待人工复核策略
 - 目录页码与实际文件页数比对
 
-即便首版不能对所有 Word 做精确页数恢复，也需要在需求上明确“统计可信度”和“估算标识”。
+DOCX 页数必须精确，不能以估算页数作为 V1 验收结果。DOC 如受格式限制无法精确统计，应标记为“待人工复核”。
+
+页数结果建议拆分为：
+
+- `page_count`
+- `page_count_method`
+- `page_count_confidence`
+
+例如 PDF 和 DOCX 解析应标记为“精确”，DOC 或解析失败文件可标记为“待人工复核”。
 
 ### 6.4 文本抽取与索引流程
 
@@ -289,9 +317,11 @@ Documents 模块应能直接输出一份“资料目录总览”，字段建议
 文档列表页不应只是“文件上传记录”，而应成为资料治理面板。建议展示：
 
 - 文件名
+- 原始相对路径
 - 章节点
 - 资料名称
 - 页数
+- 页数可信度
 - 所属项目 / 批次
 - 解析状态
 - 入库状态
@@ -364,6 +394,7 @@ Documents 不负责审计结论，但应为审计提供文档 ID、处理过程
 4. 增加文档归类与页数统计能力。
 5. 增加重复版本识别和疑似混档识别。
 6. 增加法规资料类型识别与业务资料 / 法规资料隔离管理。
+7. 增加资料包导入、压缩包解包、原始相对路径记录和解包异常提示。
 
 ## 13. 验收标准
 

docs/需求分析/4.chat模块需求分析.md

@@ -75,14 +75,15 @@
 
 用户输入类似：
 
-- “从说明书和产品列表抽取产品名称、规格、靶标、适用范围、储存条件”
+- “从说明书和产品列表抽取产品名称、检测靶标、适用范围、储存条件、性能指标，并填入申报表或对照清单”
 
 系统返回：
 
 - 统一字段表
 - 字段来源文档
 - 置信度或待确认状态
-- 可回填目标字段
+- 注册申报表格或对照清单的回填结果
+- 字段冲突时的拦截提示
 
 ### 5.3 发起一致性核查
 
@@ -144,7 +145,7 @@
 
 - “汇总当前资料目录及页数”
 - “检查 CH1 监管信息是否齐套”
-- “抽取说明书中的核心产品信息”
+- “抽取说明书中的核心产品信息并填入对照清单”
 - “检查说明书与申请表是否一致”
 
 这样能降低演示时的自由输入风险。
@@ -194,10 +195,11 @@
 - 展示字段值
 - 展示来源文档
 - 展示是否存在冲突
+- 展示已填入的注册申报表格或对照清单字段
 - 展示是否已生成新的 Word 文档
 - 展示导出入口
 
-输出结果不仅要展示回填数据，还应明确展示“已按模板生成可直接报送版 Word”及其导出入口。
+输出结果不仅要展示回填数据，还应明确展示“已自动填入注册申报表格 / 对照清单”“已按模板生成可直接报送版 Word”及其导出入口。
 
 ### 7.5 飞书端结果展示
 

docs/需求分析/6.agent_core模块需求分析.md

@@ -12,7 +12,7 @@
 
 本模块需要完成以下目标：
 
-1. 基于题面要求完成文件目录汇总、完整性核查、字段抽取、回填准备、一致性检查和风险预警。
+1. 基于题面要求完成文件目录汇总、完整性核查、字段抽取、自动回填、一致性检查和风险预警。
 2. 形成规则优先、模型辅助的审核框架，而不是完全依赖自由生成。
 3. 提供结构化、可追溯、可测试的输出。
 4. 保持与 Django 页面层和数据层的边界清晰。
@@ -93,10 +93,13 @@
 
 ### 处理逻辑
 
-1. 遍历当前项目 / 批次所有资料。
+1. 接收 Documents 模块提供的资料包、批量文件或压缩包解包结果。
-2. 汇总文件名、章节点、页数、状态。
+2. 遍历当前项目 / 批次所有资料。
-3. 识别目录类文档与普通文档。
+3. 保留原始相对路径、文件名、文件类型、页数、页数可信度和处理状态。
-4. 输出目录总表。
+4. 将压缩包内多层目录按原目录作为章节点识别依据。
+5. 识别目录类文档与普通文档。
+6. 识别章节点、资料名称和是否命中法规目录项。
+7. 输出目录总表。
 
 ### 输出要求
 
@@ -105,9 +108,12 @@
 - 文件清单
 - 文件数量
 - 总页数
+- 页数统计可信度
 - 已识别章节点
 - 待确认文档
 
+DOCX 页数必须精确统计，不能以估算页数作为 V1 验收结果。DOC 如受格式限制无法精确统计，应标记为待人工复核。
+
 ## 5.2 法规完整性核查能力
 
 ### 目标
@@ -123,6 +129,8 @@
 - 题面中提及的 NMPA / CMDE 法规来源
 - `关于公布体外诊断试剂注册申报资料要求和批准证明文件格式的公告` 附件包
 
+V1 默认以 `docs/原始材料/关于公布体外诊断试剂注册申报资料要求和批准证明文件格式的公告/` 下的公告附件包作为主规则源。NMPA / CMDE 官网链接用于说明法规来源和后续在线更新方向，不作为当前演示时的唯一实时依赖。
+
 结合新增公告附件包，法规规则来源建议分层管理：
 
 1. 注册申报资料要求及说明
@@ -170,7 +178,7 @@
 
 ### 目标
 
-从产品文件中提取关键信息并自动填写到目标文件或结构化结果中。
+从产品文件中提取关键信息，并自动填写到注册申报表格或对照清单中。
 
 ### 目标字段建议
 
@@ -223,13 +231,13 @@
 - 来源文档
 - 来源片段
 - 是否冲突
-- 是否可直接回填
+- 是否已填入注册申报表格或对照清单
 
-## 5.4 自动回填准备能力
+## 5.4 自动回填能力
 
 ### 目标
 
-将抽取得到的信息填入目标文件或目标字段。
+将抽取得到的产品名称、检测靶标、适用范围、储存条件、性能指标等核心信息填入注册申报表格或对照清单。
 
 ### 首版建议范围
 
@@ -237,16 +245,19 @@
 
 - 申请表字段回填数据集
 - 对照清单字段回填数据集
-- 页面可视化回填预览
+- 页面可视化回填结果
 - 新的 Word 文档生成与导出能力
 - 基于模板库的高保真版式回填能力
 
+当前已确认回填目标为注册申报表格或对照清单。V1 默认先把 `目标产品说明书` 中抽取的产品名称、检测靶标、适用范围、储存条件、性能指标等字段写入统一字段池，再按申请表 / 对照清单字段映射自动生成回填结果。若后续提供专用 Word 模板，则通过模板库字段映射生成具体 Word 文件。
+
 ### 处理逻辑
 
 1. 根据目标模板定义字段映射。
 2. 从统一字段池读取值。
 3. 对冲突字段进行拦截或提示。
-4. 生成回填预览结果。
+4. 写入注册申报表格或对照清单的目标字段。
+5. 生成回填结果、导出文件和审计记录。
 
 ### 后续扩展
 
@@ -441,19 +452,22 @@ LLM 负责把这些动作组织成自然语言建议，但不能改变底层规
 
 建议工具方向包括：
 
-1. 文档页数统计工具
+1. 资料包扫描工具
-2. 章节点识别工具
+2. `zip` / `rar` / `7z` 压缩包解包工具，`rar` 和 `7z` 必须采用纯 Python 依赖实现
-3. 必交项检查工具
+3. 文档页数统计工具，DOCX 页数必须精确统计
-4. 字段抽取工具
+4. 章节点识别工具
-5. 字段一致性比对工具
+5. 必交项检查工具
-6. 风险汇总工具
+6. 字段抽取工具
-7. 审核范围确认工具
+7. 字段一致性比对工具
-8. 法规流程识别工具
+8. 文档结构规范检查工具
-9. 格式模板映射工具
+9. 风险汇总工具
-10. Word 模板回填与导出工具
+10. 审核范围确认工具
-11. 飞书消息摘要生成与通知载荷组装工具
+11. 法规流程识别工具
-12. 责任人映射解析工具
+12. 格式模板映射工具
-13. 规则切片与结构化回写工具
+13. Word 模板回填与导出工具
+14. 飞书消息摘要生成与通知载荷组装工具
+15. 责任人映射解析工具，首版按资料章节手动配置
+16. 规则切片与结构化回写工具
 
 这些工具都应通过 Tool Registry 注册，符合项目既有边界要求。
 
@@ -518,7 +532,7 @@ Audit 负责记录过程和结果；Agent Core 负责产出可记录的结构化
 2. 增加法规完整性规则和目录模板匹配逻辑。
 3. 增加统一字段池。
 4. 增加一致性核查与风险汇总工具。
-5. 将“回填准备结果”纳入正式输出结构。
+5. 将“注册申报表格 / 对照清单回填结果”纳入正式输出结构。
 6. 增加“是否通过”和“风险评分明细”输出字段。
 7. 增加法规分层规则管理，以及注册申报 / 变更 / 延续三类流程的扩展边界。
 8. 增加模板库驱动的高保真 Word 生成链路。

docs/需求分析/9.业务确认问答清单.md

@@ -32,6 +32,12 @@
 7. 法规知识按“章 -> 条 -> 要求项 -> 模板字段”四级结构维护。
 8. 飞书接入属于本次 Demo 范围，需要支持群聊机器人，并在飞书内完成任务选择、结果查看和责任人通知。
 9. 系统需要提供后台管理页面，支持人工校订、知识库更新、模板管理和责任人维护。
+10. 资料导入应按资料包处理，首版支持批量文件、文件夹和压缩包，压缩包覆盖 `zip`、`rar`、`7z`。
+11. DOCX 页数必须精确统计。
+12. 压缩包内多层目录按原目录作为章节点依据。
+13. `rar`、`7z` 解压必须纯 Python 实现，允许增加第三方依赖包。
+14. 责任人先手动配置，按资料章节维护。
+15. 第 2 至第 6 章不补充企业真实样本，先按公告附件包进行规则级初步确认。
 
 ---
 
@@ -158,6 +164,31 @@
 
 - 决定一致性冲突是“核心演示点”还是“样本噪声”。
 
+### Q6-1 资料包导入需要支持哪些输入形式？
+
+建议提问方式：
+
+> 资料一般会以什么形式交给系统？是直接选择一个文件夹、批量选择多个文件，还是上传一个压缩包？
+
+建议引导业务按下列类型回答：
+
+1. 批量文件
+2. 文件夹
+3. zip 压缩包
+4. rar 压缩包
+5. 7z 压缩包
+
+建议记录答案：
+
+- 必须支持：批量文件、文件夹、zip、rar、7z
+- 可后续支持：
+- 是否需要保留压缩包内原始目录：是，多层目录按原目录作为章节点依据
+- rar / 7z 实现要求：必须纯 Python 实现，允许增加第三方依赖包
+
+为什么要问：
+
+- 决定 Documents 模块的上传、解包、目录还原和异常提示实现。
+
 ---
 
 ## 4.3 自动审核与人工复核边界
@@ -415,10 +446,10 @@
 
 建议记录答案：
 
-- 按章节点：
+- 按章节点：首版已确认，按资料章节手动配置
-- 按资料类型：
+- 按资料类型：后续可扩展
-- 按项目角色：
+- 按项目角色：后续可扩展
-- 按具体人员：
+- 按具体人员：通过手动配置映射到章节责任人
 
 为什么要问：
 
@@ -580,7 +611,7 @@
 4. Q10 “可直接报送级版式”的验收标准
 5. Q12 新模板进入模板库后的确认机制
 6. Q18 飞书群聊机器人希望如何触发任务
-7. Q20 责任人如何定义
+7. Q20 责任人如何定义（已确认首版按资料章节手动配置）
 8. Q26 本次 Demo 的通过标准
 
 ---