docs(requirements): 补充飞书接入与法规规则源口径

2026-06-02 23:49:25 +08:00
parent 59d522be0c
commit dc4c605723
8 changed files with 409 additions and 82 deletions
--- a/docs/需求分析/0.需求重构总览与待确认事项.md
+++ b/docs/需求分析/0.需求重构总览与待确认事项.md
@@ -12,7 +12,7 @@
 ## 2. 原始材料所反映的真实业务目标
-根据 `docs/【模拟题二】试剂盒临床注册文件准备与审核Agent/【模拟题二】试剂盒临床注册文件准备与审核Agent.md`、`docs/目标产品说明书.docx`、`docs/附件 4 体外诊断试剂注册申报资料要求及说明.doc` 以及 `docs/第1章 监管信息/` 下样例文件，可以确认本题的核心目标不是“泛化问答 Agent”，而是一个围绕注册申报资料整理、核查、回填、比对和预警的垂直 Agent 系统。
+根据 `docs/【模拟题二】试剂盒临床注册文件准备与审核Agent/【模拟题二】试剂盒临床注册文件准备与审核Agent.md`、`docs/目标产品说明书.docx`、`docs/附件 4 体外诊断试剂注册申报资料要求及说明.doc`、`docs/原始材料/关于公布体外诊断试剂注册申报资料要求和批准证明文件格式的公告/` 下公告附件，以及 `docs/第1章 监管信息/` 下样例文件，可以确认本题的核心目标不是“泛化问答 Agent”，而是一个围绕注册申报资料整理、核查、回填、比对和预警的垂直 Agent 系统。
 系统需要覆盖的业务闭环至少包括：
@@ -73,7 +73,7 @@
 ### 5.2 本题非常强调“章节点”和“法规目录”
-从 `附件 4 体外诊断试剂注册申报资料要求及说明` 可看出，资料并不是简单的“有或没有”，而是存在固定层级结构，至少包含：
+从 `附件 4 体外诊断试剂注册申报资料要求及说明` 以及 `关于公布体外诊断试剂注册申报资料要求和批准证明文件格式的公告` 附件可看出，资料并不是简单的“有或没有”，而是存在固定层级结构和明确的附件格式要求，至少包含：
 - 第 1 章 监管信息
 - 第 2 章 综述资料
@@ -84,6 +84,13 @@
 这意味着审核规则必须识别“资料缺失”“章节点错误”“章节目录与实际文件不一致”等不同问题类型。
 同时，新增公告材料还表明系统不能只停留在“目录齐套性”这一层，还应预留以下法规校验层级：
 1. 注册申报资料要求及说明。
 2. 医疗器械注册申报资料和批准证明文件格式要求。
 3. 体外诊断试剂安全和性能基本原则清单。
 4. 注册证、变更注册（备案）文件等批准证明文件格式。
 ### 5.3 本题非常强调跨文档字段一致性
 现有样例材料中已经出现多个明显的潜在冲突点，例如：
@@ -91,7 +98,13 @@
 - 题面说明书是“新型冠状病毒 2019-nCoV 核酸检测试剂盒”。
 - 监管信息目录、申请表、产品列表则是“呼吸道合胞病毒、肺炎支原体核酸检测试剂盒”。
-这不是噪声，而是非常适合做演示的“真实异常样本”。需求分析必须把“跨文档字段冲突检测”写成核心能力，而不是附属功能。
+结合当前已确认口径，本项目目标是建立“通用的试剂盒临床注册文件准备与审核智能体”，因此这些样例差异不要求在需求阶段统一到某一个具体产品，而是要求系统具备：
 1. 按项目、批次、文档范围界定审核对象的能力。
 2. 对同一审核对象内文档执行严格一致性校验的能力。
 3. 对疑似混档、跨产品资料混入给出风险提示的能力。
 因此，需求分析必须把“跨文档字段冲突检测”写成核心能力，而不是附属功能。
 ### 5.4 本题不仅需要审核，还需要回填与生成
@@ -117,11 +130,72 @@
 5. 系统检查说明书、申请表、产品列表、声明文件之间的一致性。
 6. 系统输出风险清单、建议动作以及需要人工确认的问题。
-## 7. 待确认事项
+如果演示时间允许，建议再增加一个“法规依据展示”环节：
-以下问题不影响需求分析继续推进，但如果后续要做成更贴近真实业务的版本，建议尽快与你可直接沟通的目标用户确认。
+7. 系统展示当前完整性结论所依据的公告附件、资料要求和模板来源。
-### 7.1 本次系统覆盖的资料范围是否只要求“第 1 章监管信息”演示，还是要覆盖全申报包
+## 7. 已确认事项
 以下内容已根据最新沟通结果确认，并已同步进入后续模块需求：
 ### 7.1 产品目标范围
 - 系统目标是建立“通用的试剂盒临床注册文件准备与审核智能体”。
 - 因此不需要把当前样例材料统一解释为同一个具体产品的唯一资料包。
 - 实际审核时，应由系统或用户先界定当前参与核查的项目批次或文档范围。
 ### 7.2 飞书接入方向
 - 系统需要支持飞书接入，不再仅停留在“可扩展预留”层面。
 - 目标交互包括：通过飞书访问智能体，以及通过飞书机器人 `@` 对应责任人或责任角色。
 - 首版主体仍以 Web Demo 为主，但需求文档中应把飞书入口、回传摘要、责任通知链路写成明确建设项。
 ### 7.3 一致性核查口径
 - 当前阶段按完全一致处理。
 - 不采用“语义相近即可视为一致”的放宽规则。
 - 因此同一字段只要文案不一致，就应判为冲突或至少进入人工复核。
 ### 7.4 风险分级与准入规则
 - 风险按高 / 中 / 低三级分类。
 - 存在必须拦截提交的情形。
 - 风险需要综合分析并分别打分。
 - 只要存在任一高风险项，本次审核结果就不允许通过。
 ### 7.5 第 2 至第 6 章样本与模板口径
 - 结合补充的公告附件包，可以确认第 2 至第 6 章对应的法规要求、章节点结构和资料模板口径已经存在。
 - 这些材料可以作为系统进行完整性检查、章节归类、字段回填和生成审核结论的“监管模板 / 结构模板”。
 - 但它们并不等于每一章都有完整可直接复用的企业填充样本，因此需求上应表述为“可作为法规模板与结构模板”，而不是“已经具备全量业务样本”。
 ### 7.6 输出文档形式
 - 最好支持输出新的 Word 文档。
 - 输出结果需要支持导出下载。
 - 对目标模板的格式、标题层级、表格样式、盖章位和版式应尽量保持原始格式。
 ### 7.7 法规主规则源与 RAG 口径
 - 当前版本默认以 `关于公布体外诊断试剂注册申报资料要求和批准证明文件格式的公告` 附件包为主规则来源。
 - `附件 4` 视为同源补充材料，不另立异源规则体系。
 - 现版本不必把“法规可在线更新”做成显式能力。
 - 但法规材料仍建议切片入库到 RAG，用于证据检索、条款引用和审计追溯。
 - 合规判断逻辑仍应坚持“结构化规则优先，RAG 辅助解释”，不能把 RAG 当成唯一规则引擎。
 ### 7.8 飞书技术接入口径
 - 飞书接入可参考飞书开放平台提供的 AI Agent 接入路线，而不是自定义一个模糊的消息转发方案。
 - 首版需求应明确两条接入路径：
  1. 飞书机器人 / Channel SDK 作为用户入口。
  2. 飞书 CLI / OpenAPI MCP 作为 Agent 访问飞书消息、文档、日历、多维表格等能力的工具接入方式。
 - 若需要责任人 `@`、回传摘要、文档评论回复或群消息触发，应在后续设计中按飞书应用权限、事件订阅和可见范围来实现。
 ## 8. 重新整理后的待确认事项
 以下问题是在前序确认基础上重新收敛后的剩余待确认项。它们不影响当前需求分析继续推进，但会影响后续设计取舍和开发优先级。
 ### 8.1 V1 演示深度是否要求真正覆盖全六章流程
 原因：
@@ -130,77 +204,49 @@
 需确认的问题：
-1. Demo 是否允许只用第 1 章样例演示全流程能力。
+1. Demo 是否允许以第 1 章样本做主演示，同时以法规模板覆盖第 2 至第 6 章的完整性校验口径。
-2. 若要覆盖全章，是否还会补充第 2 至第 6 章的原始资料样本。
+2. 若后续要把第 2 至第 6 章做成更强的“内容级抽取与回填演示”，是否还会补充企业真实样本。
-### 7.2 目标产品是否以“新冠核酸检测试剂盒”为准，还是以“呼吸道合胞病毒/肺炎支原体核酸检测试剂盒”为准
+### 8.2 Word 导出的保真要求边界
-原因：
+已确认方向是“最好输出新的 Word 文档并保留原始格式”，但仍建议确认：
- `目标产品说明书.docx` 与 `第1章 监管信息` 下的样例材料对应的产品不是同一个。
+1. 首版是否要求所有回填任务都必须产出 Word，还是允许部分任务先输出结构化预览。
- 这可能是故意设置的审核异常，也可能是资料拼接造成的样本混杂。
+2. 保真要求是“尽量接近模板”还是“必须达到可直接报送级版式”。
 3. 是否需要同时导出 PDF 供审核留档。
-需确认的问题：
+### 8.3 飞书接入的最小可用范围
-1. 这是用于测试一致性核查的刻意异常，还是后续要统一成同一产品。
+已确认要实现飞书接入，但仍建议确认首版最小可用范围：
 2. 如果是刻意异常，Demo 是否应把它作为重点演示案例。
-### 7.3 自动回填的目标文件范围
+1. 首版是“飞书消息触发 + 返回摘要 + 结果链接”即可，还是要做到“在飞书内完成任务选择、结果查看和责任人通知”。
 2. 责任关系是按章节点、按任务类型还是按项目角色维护。
 3. 是否需要支持文档评论区 `@bot` 回复、群聊机器人、还是独立飞书应用会话三种入口中的一种或多种。
-需确认的问题：
+### 8.4 规则切片的颗粒度与维护方式
-1. 只需要回填申请表和对照清单，还是需要直接输出新的 Word 文档。
+已确认法规材料建议切片入 RAG，但还可进一步确认：
 2. 回填结果是否只展示在页面表格中即可，还是必须导出下载文件。
 3. 对 Word 模板的回填是否要求保留原版格式与盖章位。
-### 7.4 法规完整性校验的依据来源
+1. 切片是按“章 -> 条 -> 要求项 -> 模板字段”四级结构维护，还是先按文档段落切片即可。
 2. 是否需要在首版中同步建设结构化规则文件，以便让完整性校验不完全依赖检索文本。
 3. 后续谁来维护规则包与法规切片，是否需要保留人工校订入口。
-需确认的问题：
+## 9. 本轮需求分析采用的默认假设
 1. 本题是否默认以提供的 `附件 4` 为主要规则依据。
 2. 是否需要在演示中体现“法规版本可更新”能力。
 3. 是否要求系统直接联网抓取 NMPA / CMDE 最新条文，还是允许以本地固化规则做 Demo。
 ### 7.5 “通知责任人”是否需要真实消息触达
 题面提到“自动识别缺失文件并通知责任人”，但未说明通知方式。
 需确认的问题：
 1. Demo 只需生成待通知清单，还是要真的发邮件/企业微信。
 2. 若要触达，责任人是按章节点、按资料类型还是按项目角色分配。
 ### 7.6 一致性核查的判定标准是否允许“语义一致、措辞不同”
 例如：
 - “适用范围”在说明书中可能是完整长句。
 - 在申请表中可能是简化描述。
 需确认的问题：
 1. 是否允许“语义相同但表述长度不同”的情况判定为一致。
 2. 哪些字段必须完全一致，哪些字段允许近似匹配后人工复核。
 ### 7.7 风险分级口径
 需确认的问题：
 1. 风险是否按高/中/低三级即可。
 2. 是否存在必须拦截提交的“致命缺陷”级别。
 3. 风险分级依据是法规强制项、资料完整性、字段冲突程度，还是三者综合。
 ## 8. 本轮需求分析采用的默认假设
 在需求方未进一步确认前，后续模块文档将先基于以下假设展开：
 1. 系统以“注册申报资料审核与准备”作为唯一主线，不再强调通用多题型产品定位。
 2. Demo 首版可先覆盖监管信息章，并为全章扩展预留结构。
-3. 题面中出现的产品信息冲突被视为应被系统识别出的真实异常。
+3. 一致性检查前需要先确定当前审核范围，不能默认把所有原始材料视为同一产品资料包。
-4. 法规完整性检查首版以本地结构化规则和本地法规材料为准，不强依赖联网。
+4. 法规完整性检查首版以本地结构化规则和本地法规材料为准，不强依赖联网抓取法规。
-5. 回填能力首版以“结构化字段回填结果展示”和“生成待填数据”为主，不把保真 Word 编辑作为首要验收标准。
+5. 法规材料会同步切片入 RAG，但规则判断以结构化规则优先，RAG 负责检索、引用和解释。
 6. 回填能力目标默认包含“生成新的 Word 文档并支持导出”，但允许分阶段落地，先完成字段映射与预览，再补高保真写回。
 7. 一致性判断当前默认按完全一致执行。
 8. 风险判断采用高 / 中 / 低三级，且任一高风险项直接判定不通过。
 9. 飞书接入属于明确建设方向，首版主体仍以 Web Demo 为主，但设计阶段要把飞书入口与通知链路纳入范围。
 10. V1 的法规任务边界先聚焦“注册申报”，变更备案和延续注册在规则架构上预留扩展位，但不作为当前主验收范围。
-## 9. 结论
+## 10. 结论
 本次需求重构的关键，不是再补几条场景配置，而是把项目从“通用 Demo 基座”转向“IVD 注册申报资料审核平台”。只要模块需求始终围绕以下四件事展开，后续设计和实现就会比较稳：
--- a/docs/需求分析/1.V1总需求文档.md
+++ b/docs/需求分析/1.V1总需求文档.md
@@ -12,6 +12,8 @@
 本系统面向 **NMPA 境内第三类体外诊断试剂注册申报资料准备与审核** 场景，服务于需要整理、核查、抽取、回填和追踪注册资料的业务人员。
 系统主体围绕注册申报审核场景展开，但能力目标是沉淀为“通用的试剂盒临床注册文件准备与审核智能体”，而不是只绑定某一个具体试剂盒产品。
 系统不再以“适配任意业务题”的通用 Demo 作为对外主叙事，而是聚焦以下业务价值：
 1. 自动汇总注册资料目录与页数。
@@ -29,6 +31,18 @@
 2. `docs/目标产品说明书.docx`
 3. `docs/附件 4 体外诊断试剂注册申报资料要求及说明.doc`
 4. `docs/第1章 监管信息/` 下的监管目录、申请表、产品列表、声明与沟通记录样例
 5. `docs/原始材料/关于公布体外诊断试剂注册申报资料要求和批准证明文件格式的公告/` 下的公告附件包
 其中新增公告附件包使法规依据不再只是单篇“资料要求说明”，而是扩展为一组正式规则来源，包括：
 1. 体外诊断试剂注册申报资料要求及说明
 2. 医疗器械注册申报资料和批准证明文件格式要求（体外诊断试剂）
 3. 体外诊断试剂安全和性能基本原则清单
 4. 中华人民共和国医疗器械注册证（体外诊断试剂）格式
 5. 体外诊断试剂变更备案 / 变更注册申报资料要求及说明
 6. 体外诊断试剂延续注册申报资料要求及说明
 当前 V1 默认以“公告附件包”作为主规则来源，并将 `附件 4 体外诊断试剂注册申报资料要求及说明` 视作同源补充材料，而不是独立的第二套规则来源。
 ## 4. V1 范围
@@ -45,11 +59,19 @@ V1 聚焦“可运行、可讲解、可演示”的注册资料审核闭环，
 7. 审计留痕
 8. 本地可运行与 Docker 演示启动
 其中第 3 项“法规完整性检查”在 V1 中建议明确分为三层：
 1. 资料齐套性检查
 2. 章节点和结构合规性检查
 3. 批准证明文件格式与输出映射检查
 ### 4.2 V1 可接受的简化
 1. 首版可优先覆盖第 1 章监管信息，并为全章扩展预留结构。
-2. 首版可先展示“字段回填结果”和“回填预览”，不把保真 Word 导出作为硬门槛。
+2. 首版允许分阶段完成 Word 输出能力，但目标交付应包含“生成新的 Word 文档并支持导出”，同时尽量保留原始格式。
 3. 首版法规校验可以本地规则为主，不强依赖联网抓取最新法规。
 4. 首版主体仍以 Web 工作台为主，但应纳入飞书接入方案，至少预留飞书消息触发、结果回传和责任人通知链路。
 5. 首版法规任务边界以“注册申报”主流程为核心，变更备案和延续注册暂作为规则扩展方向。
 ## 5. 业务闭环
@@ -62,6 +84,18 @@ V1 聚焦“可运行、可讲解、可演示”的注册资料审核闭环，
 5. 对同名字段进行跨文档一致性比对。
 6. 形成风险清单、回填结果和审计记录。
 在规则执行层，建议采用“双层知识底座”：
 1. 结构化规则文件负责完整性判断、强一致比对和风险映射。
 2. 公告附件原文切片入 RAG，负责条款引用、证据检索和解释说明。
 在法规维度上，建议把完整流程理解为：
 1. 识别当前审核任务属于“注册申报”主流程。
 2. 匹配对应的资料要求与章节点模板。
 3. 检查资料齐套性与章节结构。
 4. 对需要回填或输出的批准证明文件格式做字段映射准备。
 ## 6. 模块拆分
 V1 需求分析按项目现有主模块拆分，不做过度细分：
@@ -89,12 +123,29 @@ V1 需求分析按项目现有主模块拆分，不做过度细分：
 ### 7.3 系统必须具备“冲突识别”
-当前样例中已经存在不同产品资料混入的迹象，这类问题应被系统识别为高价值异常，而不是忽略。
+当前样例中已经存在不同产品资料混入的迹象。这不要求系统默认把全部材料视为同一个产品，而是要求系统具备以下能力：
 1. 支持按项目批次或文档范围界定审核对象。
 2. 对被划入同一审核对象的资料执行严格一致性检查。
 3. 对混档、错归类和跨产品资料混入给出风险提示。
 ### 7.4 系统必须具备“可解释性”
 所有缺失判断、字段抽取和风险预警都应尽量有证据、有来源、有审计记录。
 ### 7.5 系统必须具备“法规分层引用”
 结合新增公告附件包，系统应能区分并引用不同层级的规则来源，而不是把所有法规依据混成一条说明：
 1. 资料要求类依据
 2. 格式要求类依据
 3. 安全和性能基本原则类依据
 4. 批准证明文件格式类依据
 ### 7.6 系统需要具备“多入口访问能力”
 V1 主体虽然仍以 Web 端演示为主，但系统应预留并逐步实现飞书入口能力，使审核任务可以从浏览器工作台扩展到飞书会话、飞书机器人和文档评论协作场景。
 ## 8. 后续文档与实现衔接建议
 后续若继续推进设计与开发，建议按如下顺序展开：
--- a/docs/需求分析/1.config模块需求分析.md
+++ b/docs/需求分析/1.config模块需求分析.md
@@ -23,7 +23,7 @@
 题面要求系统处理的是“整包注册资料”，这意味着配置层必须面向文件密集型、规则密集型场景设计。与普通问答系统相比，本题配置上至少多出以下关注点：
 - 上传目录不仅要按场景分，还要考虑按项目批次、申报轮次、资料章节分层。
- 规则来源不止一个 YAML，可能包括法规目录模板、字段抽取模板、一致性校验规则和风险分级规则。
+- 规则来源不止一个 YAML，可能包括法规目录模板、字段抽取模板、一致性校验规则、风险分级规则，以及公告附件原文所对应的结构化法规包。
 - 文档解析链路中可能同时使用 `pdfplumber`、`PyMuPDF`、Word 解析库、OCR 预留能力，因此要有可切换的解析策略配置。
 - 审计数据不能只保留“问答日志”，还要能关联具体资料批次和审核任务。
@@ -54,6 +54,7 @@
 需要统一管理以下路径：
 - 原始上传文件根目录
 - 法规原文资料目录
 - 文本抽取中间结果目录
 - 结构化抽取结果目录
 - 向量库目录
@@ -75,6 +76,8 @@
 本题的法规完整性核查、一致性检查，很多内容应以规则为主、模型为辅，因此配置层应支持这种策略切换。
 同时，考虑到新增公告附件包中同时存在“注册申报”“变更备案 / 变更注册”“延续注册”等不同业务类型，配置层还应支持按任务类型切换规则集。
 ### 4.4 环境隔离与安全控制
 负责确保：
@@ -108,9 +111,15 @@
 - `REPORT_EXPORT_ROOT`
  审核报告导出目录。
 - `WORD_EXPORT_ROOT`
  Word 回填结果与新生成文档导出目录。
 - `RULESET_DIR`
  法规目录模板、字段规则、风险规则所在目录。
 - `REG_SOURCE_DIR`
  法规原文与公告附件所在目录。
 - `CHROMA_PATH`
  向量库目录。
@@ -162,8 +171,25 @@
 - `FIELD_SCHEMA_VERSION`
  当前产品关键信息字段定义版本。
 - `REG_WORKFLOW_TYPE`
  当前审核任务所对应的法规流程类型，如 `registration`、`change`、`renewal`。
 - `REG_FORMAT_TEMPLATE_VERSION`
  当前启用的批准证明文件格式模板版本。
 - `FEISHU_APP_ID`
 - `FEISHU_APP_SECRET`
 - `FEISHU_BOT_NAME`
 - `FEISHU_ENABLE_CHANNEL`
 - `FEISHU_CALLBACK_URL`
 - `FEISHU_CLI_ENABLED`
  用于支持飞书应用、机器人入口、事件回调和 CLI / MCP 工具接入。
 这三个配置很关键，因为题面中的法规条目和样例材料未来可能变化，系统必须能讲清楚“按哪个版本在审”。
 新增公告附件包后，这类版本配置的重要性进一步提高，因为系统不仅要说明“按哪个资料目录模板在审”，还要说明“按哪个公告附件包和哪个文件格式要求在审”。
 ## 6. 路径与目录结构需求
 ### 6.1 建议的目录设计
@@ -187,6 +213,8 @@ data/
 rules/
  registration/
    completeness/
    format/
    essential-principles/
    extraction/
    consistency/
    risk/
@@ -198,6 +226,8 @@ rules/
 - 同一项目多批资料
 - 原始文件与处理中间结果分离
 - 规则版本独立维护
 - 注册申报、变更备案、延续注册可分开维护规则包
 - Word 输出模板与导出结果独立管理
 ### 6.2 路径命名要求
@@ -277,6 +307,8 @@ rules/
 2. 增加抽取结果目录、报告目录、规则目录等配置。
 3. 增加法规规则版本与字段 schema 版本配置。
 4. 为 `.doc`、`.docx`、PDF 页数统计和解析策略提供显式配置位。
 5. 增加法规原文目录、法规流程类型和文件格式模板版本配置。
 6. 增加 Word 导出目录和飞书应用接入相关配置。
 ## 11. 本模块验收标准
--- a/docs/需求分析/2.scenarios模块需求分析.md
+++ b/docs/需求分析/2.scenarios模块需求分析.md
@@ -17,6 +17,8 @@
 3. 支撑后续 Demo 演示时快速切换不同任务视角，而不是频繁改代码。
 4. 保持与 `agent_core` 的边界清晰，即场景模块只定义任务，不实现任务逻辑。
 结合新增公告材料，场景模块还应承担“法规流程类型选择器”的角色，避免把注册申报、变更备案、延续注册三类任务混成一个入口。
 ## 3. 为什么本题仍然需要场景模块
 虽然本题更像一个垂直系统，但场景模块依然有价值，原因有三：
@@ -46,6 +48,11 @@
 5. `registration_risk_report`
   合规风险预警助手
 首版仍建议以 `registration_*` 作为主任务族，但应在配置语义上预留后续扩展族，例如：
 - `change_registration_*`
 - `renewal_registration_*`
 ### 4.2 是否需要多个场景还是一个总场景
 建议首版保留“一个主场景 + 若干子任务配置”的思路：
@@ -143,6 +150,12 @@
 - 比对当前资料是否齐套
 - 识别缺失文件、错放文件、待人工确认项
 结合公告附件包，该任务还应明确区分三层依据：
 1. 注册申报资料要求及说明
 2. 批准证明文件格式要求
 3. 安全和性能基本原则清单
 配置上需要指定：
 - 对应法规规则版本
@@ -172,7 +185,7 @@
 配置上需要指定：
 - 必须完全一致的字段
- 允许语义近似的字段
+- 默认按完全一致处理的字段
 - 风险分级规则
 ### 7.5 风险预警任务
@@ -189,20 +202,44 @@
 - 高中低风险判定口径
 - 责任归属字段
 ### 7.6 法规依据展示任务或结果区
 基于新增公告材料，建议在任务配置中增加法规依据展示能力，至少能让系统说明：
 1. 当前任务对应的是哪类法规流程。
 2. 使用了哪份资料要求说明。
 3. 使用了哪份格式要求或批准证明文件模板。
 ## 8. 与原始材料对应的任务设计要点
 ### 8.1 要能体现“资料结构化目录”的任务价值
 `CH1.2 监管信息目录.docx` 已经给出一个非常适合 Demo 的目录样例，场景模块应支持把“监管目录核对”配置成单独任务，而不是只能在自由聊天中触发。
 结合新增公告材料，这个任务还应能够说明当前目录核对所引用的是“资料要求说明”而不是任意自由目录。
 ### 8.2 要能体现“跨文档冲突识别”的任务价值
-当前材料中的产品名称冲突非常典型，建议将“一致性核查”场景作为重点入口之一。
+当前材料中的产品名称冲突非常典型，但结合最新确认，系统目标是通用试剂盒注册审核智能体，而不是只围绕某一个固定产品。因此，一致性核查任务应强调：
 1. 先界定审核范围，再执行严格一致性检查。
 2. 对同一审核范围内的字段按完全一致规则比对。
 3. 对疑似混档资料单独输出风险提示。
 ### 8.3 要能体现“历史申报沟通说明”的任务价值
 `CH1.9` 所反映的历史受理、撤回、替换临床机构等内容，适合在风险预警任务中作为“历史事项复核”子项展示。
 ### 8.4 要为飞书接入预留并实现任务入口语义
 结合当前确认结果，场景模块建议为飞书访问统一维护任务标识和简短描述，便于后续：
 1. 在飞书机器人中按任务 ID 触发。
 2. 在飞书侧展示任务摘要和结果链接。
 3. 将“通知责任人”与任务类型建立映射。
 如果后续采用飞书开放平台的 Agent 接入路线，还应确保这些任务标识可以映射到飞书消息指令、评论触发或会话菜单项。
 ## 9. 场景模块与其他模块的边界
 ### 9.1 与 Chat 模块的边界
--- a/docs/需求分析/3.documents模块需求分析.md
+++ b/docs/需求分析/3.documents模块需求分析.md
@@ -18,6 +18,8 @@
 4. 为法规完整性核查和一致性核查提供可靠的文档底座。
 5. 为抽取、回填、审计和导出提供统一的文档主数据。
 结合新增公告材料，本模块还应承担“法规原文资料资产管理”的基础职责，即把上传的业务资料与平台内置的法规依据材料区分管理。
 ## 3. 为什么 Documents 模块是本题核心
 题面第一条就要求“自动汇总注册申报文件夹中的所有文件及页数”，第二条要求“对照 NMPA 法规要求核查文件完整性”。这两个要求都建立在一个前提上：
@@ -40,6 +42,13 @@
 必要时为后续 OCR 或图片扫描件预留扩展位。
 除用户上传的申报资料外，系统还需要支持管理平台内置法规资料，例如：
 - 注册申报资料要求及说明
 - 批准证明文件格式要求
 - 安全和性能基本原则清单
 - 注册证 / 变更注册（备案）文件格式
 ### 4.2 文件基础信息管理
 每份资料至少要记录：
@@ -53,6 +62,13 @@
 - 所属任务或场景
 - 当前处理状态
 对于法规资料，建议额外记录：
 - 法规类型
 - 法规流程类型
 - 版本来源
 - 是否为系统内置规则依据
 ### 4.3 页数统计与目录归属
 系统要能为每份文件识别：
@@ -79,6 +95,13 @@
 对适合检索的内容建立索引，供 `agent_core` 的 RAG 或规则定位使用。
 对法规原文资料，建议单独建立“法规知识索引”，切片时优先保留以下结构语义：
 - 所属法规文档
 - 适用流程类型
 - 章 / 条 / 清单项编号
 - 模板字段或格式要求类型
 ### 4.6 状态反馈与异常处理
 文件处理流程要有明确状态，例如：
@@ -145,6 +168,19 @@
 这些字段会直接影响后续审核可信度。
 #### 5.2.4 规则来源字段
 建议增加：
 - `source_role`
  区分“业务申报资料”与“法规依据资料”。
 - `workflow_type`
  区分 `registration`、`change`、`renewal` 等流程类型。
 - `format_template_type`
  标记该文件是否属于批准证明文件格式模板。
 ## 6. 关键业务流程需求
 ### 6.1 文件上传流程
@@ -169,6 +205,13 @@
 如果自动识别不确定，应标记为“待人工确认”，而不是强行归类。
 对于法规资料，还应进一步识别其所属层级，例如：
 1. 资料要求说明
 2. 格式要求说明
 3. 安全和性能基本原则
 4. 批准证明文件格式
 ### 6.3 页数统计流程
 页数统计是本题显式要求，需支持：
@@ -230,6 +273,15 @@ Documents 模块应能直接输出一份“资料目录总览”，字段建议
 `CH1.9 产品申报前沟通的说明.doc` 体现出历史申报背景和监管沟通信息，这类文件在合规审查中重要性很高，应单独分类标记。
 ### 7.4 要能区分业务资料与法规依据资料
 结合新增公告材料，Documents 模块应把以下两类材料明确分开管理：
 1. 待审核的业务申报资料
 2. 用于审核的法规依据与模板资料
 否则后续在索引、引用和一致性检查时，容易把法规模板错误混入业务资料集合。
 ## 8. 列表页与上传页需求
 ### 8.1 文档列表页需求
@@ -284,6 +336,8 @@ Documents 不负责审计结论，但应为审计提供文档 ID、处理过程
 第 6 点尤其重要，因为当前样例材料已经体现出不同产品信息混杂的问题。
 此外，还应避免把法规依据资料误当成业务申报资料写入同一业务索引集合。
 ## 11. 首版建议的可交付结果
 首版建议 Documents 模块至少能产出三类结果：
@@ -309,6 +363,7 @@ Documents 不负责审计结论，但应为审计提供文档 ID、处理过程
 3. 增加表格抽取和目录类文件识别。
 4. 增加文档归类与页数统计能力。
 5. 增加重复版本识别和疑似混档识别。
 6. 增加法规资料类型识别与业务资料 / 法规资料隔离管理。
 ## 13. 验收标准
--- a/docs/需求分析/4.chat模块需求分析.md
+++ b/docs/需求分析/4.chat模块需求分析.md
@@ -16,6 +16,7 @@
 2. 让用户能明确知道自己当前在执行哪类审核任务。
 3. 让系统输出不仅有自然语言回答，还有结构化结论、引用证据、回填字段、风险建议。
 4. 保证结果可追溯、可解释、可复核，而不是只给一个“大模型说了什么”。
 5. 支持通过 Web 工作台与飞书入口两类方式访问智能体、触发审核和查看结果。
 ## 3. 为什么 Chat 模块仍然必要
@@ -148,6 +149,15 @@
 这样能降低演示时的自由输入风险。
 ### 6.4 飞书访问入口
 当前 Demo 主体仍以 Web 工作台为主，但交互设计上应纳入两类飞书能力：
 1. 通过飞书消息入口触发某个审核任务。
 2. 在审核完成后回传摘要结果，并支持通过飞书机器人 `@` 责任人。
 后续若采用飞书开放平台的 Agent 接入路线，还应支持文档评论区 `@bot`、群聊机器人或应用会话中的至少一种触发方式。
 ## 7. 输出层需求
 ### 7.1 自然语言结论
@@ -183,8 +193,10 @@
 - 展示字段值
 - 展示来源文档
 - 展示是否存在冲突
 - 展示是否已生成新的 Word 文档
 - 展示导出入口
-即便首版不直接写回 Word 文件，也应把“可回填结果”明确展示出来。
+即便首版先完成字段映射与预览，也应把“可回填结果”和“导出进度”明确展示出来。
 ### 7.5 风险提示
@@ -234,7 +246,7 @@
 2. 字段在不同文档中出现冲突。
 3. 章节归类不确定。
 4. 规则无法直接判断是否缺失。
-5. 语义相似但不确定是否合规等价。
+5. 审核范围界定不清，无法确认哪些资料属于同一项目批次。
 ## 10. 与其他模块的边界
--- a/docs/需求分析/5.audit模块需求分析.md
+++ b/docs/需求分析/5.audit模块需求分析.md
@@ -16,6 +16,7 @@
 2. 保留输入条件、处理范围、输出结果、证据来源和失败原因。
 3. 为演示“系统不是黑盒”提供直接支撑。
 4. 在不泄露敏感信息的前提下，支持问题追溯和结果复核。
 5. 为 Web 端与飞书端的多入口执行留存统一审计链路。
 ## 3. 为什么本题对审计要求更高
@@ -104,12 +105,15 @@
 - 章节点范围
 - 规则版本
 - 模型名称
 - 触发入口类型（Web / 飞书群聊 / 飞书评论 / 飞书应用会话）
 - 飞书会话或消息标识
 ### 6.3 输出字段
 - 最终摘要
 - 结构化输出 JSON
 - 风险等级
 - 是否通过
 - 是否存在人工复核项
 - 缺失项数量
 - 冲突项数量
@@ -120,6 +124,7 @@
 - 引用片段
 - 工具调用结果
 - 命中规则项
 - 风险评分明细
 ### 6.5 错误字段
@@ -140,7 +145,7 @@
 ### 7.2 对一致性冲突留痕
-当前样例中产品名称明显冲突，因此系统若判定：
+当系统判定：
 > 说明书与申请表中的产品名称不一致
@@ -150,6 +155,9 @@
 - 冲突值
 - 对应来源文档
 - 判定时间
 - 所属审核范围
 当前项目目标是通用试剂盒注册审核智能体，因此审计还必须能够说明“这些文档为什么会被纳入同一轮一致性核查”，否则冲突结论容易失真。
 ### 7.3 对历史申报说明的审计价值
@@ -240,6 +248,7 @@ Agent Core 负责产出结论与证据；Audit 负责记录这些产出及其上
 2. 增加项目批次、任务类型、章节点范围、规则版本等字段。
 3. 增加缺失项数、冲突项数、人工复核标记等业务指标。
 4. 增加法规命中项、字段来源和风险依据的留痕。
 5. 增加飞书触发来源、回传状态和责任人通知记录。
 ## 12. 验收标准
@@ -250,3 +259,4 @@ Agent Core 负责产出结论与证据；Audit 负责记录这些产出及其上
 3. 成功、失败和待人工复核都可记录。
 4. 页面层可快速筛选高风险或异常记录。
 5. 敏感密钥不会进入审计内容。
 6. 审计中能够明确体现“任一高风险即不通过”的最终判定依据。
--- a/docs/需求分析/6.agent_core模块需求分析.md
+++ b/docs/需求分析/6.agent_core模块需求分析.md
@@ -57,7 +57,6 @@
 对以下事项由 LLM 作为辅助：
 - 长段文本中的字段归纳
 - 语义等价判断
 - 风险说明文案生成
 - 处理建议生成
 - 无法通过简单规则覆盖的异常解释
@@ -66,6 +65,14 @@
 用于在文档较长、规则或用户问题较细时，从已入库资料中定位证据片段，为回答和审计提供支撑。
 对本题而言，RAG 不仅要覆盖业务申报资料，也要覆盖公告附件包等法规原文资料。但它的职责应限定为：
 1. 为规则判断提供证据定位。
 2. 为结果解释提供法规引用。
 3. 为审计留痕提供可追溯片段。
 不能把 RAG 检索命中的段落直接等同于最终合规判断。
 ### 4.5 结构化输出
 将每类任务输出为明确 schema，而不是一段随意文本。
@@ -114,6 +121,16 @@
 - `附件 4 体外诊断试剂注册申报资料要求及说明`
 - `CH1.2 监管信息目录`
 - 题面中提及的 NMPA / CMDE 法规来源
 - `关于公布体外诊断试剂注册申报资料要求和批准证明文件格式的公告` 附件包
 结合新增公告附件包，法规规则来源建议分层管理：
 1. 注册申报资料要求及说明
 2. 医疗器械注册申报资料和批准证明文件格式要求（体外诊断试剂）
 3. 体外诊断试剂安全和性能基本原则清单
 4. 中华人民共和国医疗器械注册证（体外诊断试剂）格式
 5. 变更备案 / 变更注册申报资料要求及说明
 6. 延续注册申报资料要求及说明
 ### 处理逻辑
@@ -135,6 +152,12 @@
 - 目录中声明有但实际文件找不到
 - 文件存在但内容不符合该章节点用途
 此外，还需要区分：
 - 资料要求缺失
 - 文件格式要求不满足
 - 安全和性能基本原则映射不完整
 ### 输出要求
 - 命中项列表
@@ -171,6 +194,8 @@
 - 标准清单
 - 申报日期
 考虑到系统目标是“通用的试剂盒临床注册文件准备与审核智能体”，字段 schema 应优先沉淀通用注册字段，而不是只对某一具体产品定制。
 ### 字段来源优先级
 需要明确来源优先级，例如：
@@ -208,11 +233,12 @@
 ### 首版建议范围
-首版不必以“完整保真写回 Word 模板”为核心验收，而可以先实现：
+首版可以分阶段建设，但目标应明确指向：
 - 申请表字段回填数据集
 - 对照清单字段回填数据集
 - 页面可视化回填预览
 - 新的 Word 文档生成与导出能力
 ### 处理逻辑
@@ -223,7 +249,16 @@
 ### 后续扩展
-如需求方确认需要真实文档导出，再增加 Word 模板写回。
+Word 输出阶段建议逐步增强为：
 1. 字段映射与预览
 2. 模板占位写回
 3. 尽量保留原始样式、表格和版式的高保真导出
 结合新增公告附件包中的批准证明文件格式材料，回填能力的后续扩展方向应进一步明确为：
 1. 按注册证 / 批准证明文件格式模板生成字段映射。
 2. 按不同法规流程类型切换不同输出模板。
 ## 5.5 一致性核查能力
@@ -241,13 +276,16 @@
 - 分类编码
 - 申报产品名称对应的章节点标题
-### 语义一致字段
+结合最新确认，当前阶段不采用“语义一致即可通过”的宽松规则。对于被纳入同一审核范围的相同字段，默认按完全一致处理；如出现措辞差异，也应先判为冲突或待复核。
-可按语义一致或近似一致处理的字段包括：
+### 审核范围前置规则
- 预期用途 / 适用范围
+一致性核查前必须先明确：
- 储存条件描述
+
- 适用样本类型
+1. 哪些文档属于同一项目 / 批次 / 审核范围。
 2. 哪些文档只是通用样本材料，不能直接混入同一轮一致性比对。
 因此，一致性核查链路应包含“审核范围确认”这一步，而不是直接对全部文档做全量比较。
 ### 结构核查
@@ -262,8 +300,8 @@
 根据当前样例，系统应能识别：
- 说明书产品是“2019-nCoV”，申请表和产品列表是“呼吸道合胞病毒、肺炎支原体”。
+- 若这些文档被划入同一审核范围，则“2019-nCoV”与“呼吸道合胞病毒、肺炎支原体”构成明确冲突。
- 这类冲突应被直接标记为高风险或至少中高风险。
+- 若这些文档本身被认定属于不同资料组，则系统应提示“存在跨产品样例混入，不应直接合并审核”。
 ### 输出要求
@@ -287,6 +325,7 @@
 - 章节不规范风险
 - 历史申报事项风险
 - 资料真实性 / 版本一致性风险
 - 法规适用情形错误风险
 ### 风险分级建议
@@ -295,7 +334,24 @@
 - 高风险
 - 中风险
 - 低风险
- 待人工确认
+
 另行保留“待人工复核”状态，但它不是风险等级，而是处理状态。
 ### 风险准入规则
 风险判定应采用综合分析机制，对至少以下维度分别评分：
 1. 法规完整性
 2. 跨文档字段一致性
 3. 文档结构与章节规范性
 4. 历史事项与版本风险
 5. 法规流程适用性风险
 综合规则如下：
 1. 任一维度出现高风险项，则本次审核直接判定为不通过。
 2. 无高风险但存在多个中风险项时，应给出“待整改后复核”的建议。
 3. 低风险项可进入整改建议清单，但不单独阻断。
 ### 处理建议生成逻辑
@@ -334,6 +390,12 @@ LLM 负责把这些动作组织成自然语言建议，但不能改变底层规
 - 当前资料是否命中
 - 缺失是否构成高风险
 这里应进一步拆为三个子层：
 1. 资料要求层完整性规则
 2. 结构目录层完整性规则
 3. 格式模板层完整性规则
 ### 7.2 抽取规则
 用于：
@@ -342,17 +404,31 @@ LLM 负责把这些动作组织成自然语言建议，但不能改变底层规
 - 表格字段映射
 - 固定格式声明提取
 对于法规资料本身，还应支持抽取：
 - 附件编号
 - 法规流程类型
 - 适用范围说明
 - 批准证明文件格式字段
 ### 7.3 一致性规则
 用于定义：
 - 哪些字段必须完全一致
 - 哪些字段允许近似匹配
 - 如何判断冲突严重度
 - 如何在执行前确认审核范围
 ### 7.4 风险映射规则
-用于把缺失、冲突、不确定结果映射为风险级别和处理建议。
+用于把缺失、冲突、不确定结果映射为风险级别、综合得分、是否通过和处理建议。
 新增公告材料后，风险映射还应能够体现“适用情形错误”的风险，例如：
 1. 把变更备案规则误用于首次注册申报
 2. 把延续注册格式误用于注册申报输出
 同时，若系统生成 Word 输出失败、模板字段无法落位或导出格式破坏严重，也应形成独立的交付风险提示。
 ## 8. 工具体系需求
@@ -366,6 +442,11 @@ LLM 负责把这些动作组织成自然语言建议，但不能改变底层规
 4. 字段抽取工具
 5. 字段一致性比对工具
 6. 风险汇总工具
 7. 审核范围确认工具
 8. 法规流程识别工具
 9. 格式模板映射工具
 10. Word 模板回填与导出工具
 11. 飞书消息摘要生成与通知载荷组装工具
 这些工具都应通过 Tool Registry 注册，符合项目既有边界要求。
@@ -431,6 +512,8 @@ Audit 负责记录过程和结果；Agent Core 负责产出可记录的结构化
 3. 增加统一字段池。
 4. 增加一致性核查与风险汇总工具。
 5. 将“回填准备结果”纳入正式输出结构。
 6. 增加“是否通过”和“风险评分明细”输出字段。
 7. 增加法规分层规则管理，以及注册申报 / 变更 / 延续三类流程的扩展边界。
 ## 13. 验收标准
@@ -441,3 +524,4 @@ Audit 负责记录过程和结果；Agent Core 负责产出可记录的结构化
 3. 规则和模型分工清晰，法规判断不完全依赖大模型生成。
 4. 输出能关联到具体文档和证据片段。
 5. 测试环境下可以通过 Mock Provider 验证主要编排逻辑。
 6. 法规原文可切片入 RAG，但最终完整性与准入判断仍由规则链路主导。