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

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 章样例演示全流程能力。
-2. 若要覆盖全章，是否还会补充第 2 至第 6 章的原始资料样本。
+1. Demo 是否允许以第 1 章样本做主演示，同时以法规模板覆盖第 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 文档。
-2. 回填结果是否只展示在页面表格中即可，还是必须导出下载文件。
-3. 对 Word 模板的回填是否要求保留原版格式与盖章位。
+已确认法规材料建议切片入 RAG，但还可进一步确认：
 
-### 7.4 法规完整性校验的依据来源
+1. 切片是按“章 -> 条 -> 要求项 -> 模板字段”四级结构维护，还是先按文档段落切片即可。
+2. 是否需要在首版中同步建设结构化规则文件，以便让完整性校验不完全依赖检索文本。
+3. 后续谁来维护规则包与法规切片，是否需要保留人工校订入口。
 
-需确认的问题：
-
-1. 本题是否默认以提供的 `附件 4` 为主要规则依据。
-2. 是否需要在演示中体现“法规版本可更新”能力。
-3. 是否要求系统直接联网抓取 NMPA / CMDE 最新条文，还是允许以本地固化规则做 Demo。
-
-### 7.5 “通知责任人”是否需要真实消息触达
-
-题面提到“自动识别缺失文件并通知责任人”，但未说明通知方式。
-
-需确认的问题：
-
-1. Demo 只需生成待通知清单，还是要真的发邮件/企业微信。
-2. 若要触达，责任人是按章节点、按资料类型还是按项目角色分配。
-
-### 7.6 一致性核查的判定标准是否允许“语义一致、措辞不同”
-
-例如：
-
-- “适用范围”在说明书中可能是完整长句。
-- 在申请表中可能是简化描述。
-
-需确认的问题：
-
-1. 是否允许“语义相同但表述长度不同”的情况判定为一致。
-2. 哪些字段必须完全一致，哪些字段允许近似匹配后人工复核。
-
-### 7.7 风险分级口径
-
-需确认的问题：
-
-1. 风险是否按高/中/低三级即可。
-2. 是否存在必须拦截提交的“致命缺陷”级别。
-3. 风险分级依据是法规强制项、资料完整性、字段冲突程度，还是三者综合。
-
-## 8. 本轮需求分析采用的默认假设
+## 9. 本轮需求分析采用的默认假设
 
 在需求方未进一步确认前，后续模块文档将先基于以下假设展开：
 
 1. 系统以“注册申报资料审核与准备”作为唯一主线，不再强调通用多题型产品定位。
 2. Demo 首版可先覆盖监管信息章，并为全章扩展预留结构。
-3. 题面中出现的产品信息冲突被视为应被系统识别出的真实异常。
-4. 法规完整性检查首版以本地结构化规则和本地法规材料为准，不强依赖联网。
-5. 回填能力首版以“结构化字段回填结果展示”和“生成待填数据”为主，不把保真 Word 编辑作为首要验收标准。
+3. 一致性检查前需要先确定当前审核范围，不能默认把所有原始材料视为同一产品资料包。
+4. 法规完整性检查首版以本地结构化规则和本地法规材料为准，不强依赖联网抓取法规。
+5. 法规材料会同步切片入 RAG，但规则判断以结构化规则优先，RAG 负责检索、引用和解释。
+6. 回填能力目标默认包含“生成新的 Word 文档并支持导出”，但允许分阶段落地，先完成字段映射与预览，再补高保真写回。
+7. 一致性判断当前默认按完全一致执行。
+8. 风险判断采用高 / 中 / 低三级，且任一高风险项直接判定不通过。
+9. 飞书接入属于明确建设方向，首版主体仍以 Web Demo 为主，但设计阶段要把飞书入口与通知链路纳入范围。
+10. V1 的法规任务边界先聚焦“注册申报”，变更备案和延续注册在规则架构上预留扩展位，但不作为当前主验收范围。
 
-## 9. 结论
+## 10. 结论
 
 本次需求重构的关键，不是再补几条场景配置，而是把项目从“通用 Demo 基座”转向“IVD 注册申报资料审核平台”。只要模块需求始终围绕以下四件事展开，后续设计和实现就会比较稳：