docs(requirements): 收紧报送版式与飞书闭环要求
This commit is contained in:
Binary file not shown.
Binary file not shown.
Binary file not shown.
BIN
docs/原始材料/关于公布体外诊断试剂注册申报资料要求和批准证明文件格式的公告/体外诊断试剂安全和性能基本原则清单.doc
Normal file
BIN
docs/原始材料/关于公布体外诊断试剂注册申报资料要求和批准证明文件格式的公告/体外诊断试剂安全和性能基本原则清单.doc
Normal file
Binary file not shown.
BIN
docs/原始材料/关于公布体外诊断试剂注册申报资料要求和批准证明文件格式的公告/体外诊断试剂延续注册申报资料要求及说明.doc
Normal file
BIN
docs/原始材料/关于公布体外诊断试剂注册申报资料要求和批准证明文件格式的公告/体外诊断试剂延续注册申报资料要求及说明.doc
Normal file
Binary file not shown.
BIN
docs/原始材料/关于公布体外诊断试剂注册申报资料要求和批准证明文件格式的公告/体外诊断试剂注册申报资料要求及说明.doc
Normal file
BIN
docs/原始材料/关于公布体外诊断试剂注册申报资料要求和批准证明文件格式的公告/体外诊断试剂注册申报资料要求及说明.doc
Normal file
Binary file not shown.
Binary file not shown.
@@ -146,9 +146,10 @@
|
||||
|
||||
### 7.2 飞书接入方向
|
||||
|
||||
- 系统需要支持飞书接入,不再仅停留在“可扩展预留”层面。
|
||||
- 目标交互包括:通过飞书访问智能体,以及通过飞书机器人 `@` 对应责任人或责任角色。
|
||||
- 首版主体仍以 Web Demo 为主,但需求文档中应把飞书入口、回传摘要、责任通知链路写成明确建设项。
|
||||
- 系统需要支持飞书接入,并纳入本次 Demo 的明确交付范围。
|
||||
- 目标交互包括:在飞书内完成任务选择、结果查看,以及通过飞书机器人 `@` 对应责任人或责任角色。
|
||||
- 本次 Demo 需要支持手动配置责任人及飞书账号。
|
||||
- 需要支持群聊机器人作为飞书入口形态之一。
|
||||
|
||||
### 7.3 一致性核查口径
|
||||
|
||||
@@ -171,17 +172,21 @@
|
||||
|
||||
### 7.6 输出文档形式
|
||||
|
||||
- 最好支持输出新的 Word 文档。
|
||||
- 必须支持输出新的 Word 文档。
|
||||
- 输出结果需要支持导出下载。
|
||||
- 对目标模板的格式、标题层级、表格样式、盖章位和版式应尽量保持原始格式。
|
||||
- 对目标模板的格式、标题层级、表格样式、盖章位和版式必须达到可直接报送级版式。
|
||||
- 允许将用户后续编写的新模板纳入模板库,后续回填应以模板库中的标准模板为准。
|
||||
|
||||
### 7.7 法规主规则源与 RAG 口径
|
||||
|
||||
- 当前版本默认以 `关于公布体外诊断试剂注册申报资料要求和批准证明文件格式的公告` 附件包为主规则来源。
|
||||
- `附件 4` 视为同源补充材料,不另立异源规则体系。
|
||||
- 现版本不必把“法规可在线更新”做成显式能力。
|
||||
- 但法规材料仍建议切片入库到 RAG,用于证据检索、条款引用和审计追溯。
|
||||
- 法规材料需要按“章 -> 条 -> 要求项 -> 模板字段”四级结构维护。
|
||||
- 需同步建设结构化规则文件,用于完整性校验、格式校验和模板字段映射,避免完全依赖检索文本。
|
||||
- 法规材料仍建议切片入库到 RAG,用于证据检索、条款引用和审计追溯。
|
||||
- 合规判断逻辑仍应坚持“结构化规则优先,RAG 辅助解释”,不能把 RAG 当成唯一规则引擎。
|
||||
- 系统需要提供后端管理页面,保留人工校订入口和知识库更新入口。
|
||||
|
||||
### 7.8 飞书技术接入口径
|
||||
|
||||
@@ -189,6 +194,7 @@
|
||||
- 首版需求应明确两条接入路径:
|
||||
1. 飞书机器人 / Channel SDK 作为用户入口。
|
||||
2. 飞书 CLI / OpenAPI MCP 作为 Agent 访问飞书消息、文档、日历、多维表格等能力的工具接入方式。
|
||||
- 本次 Demo 需实现群聊机器人触发,并支持在飞书内完成任务选择、结果查看和责任人通知。
|
||||
- 若需要责任人 `@`、回传摘要、文档评论回复或群消息触发,应在后续设计中按飞书应用权限、事件订阅和可见范围来实现。
|
||||
|
||||
## 8. 重新整理后的待确认事项
|
||||
@@ -207,29 +213,14 @@
|
||||
1. Demo 是否允许以第 1 章样本做主演示,同时以法规模板覆盖第 2 至第 6 章的完整性校验口径。
|
||||
2. 若后续要把第 2 至第 6 章做成更强的“内容级抽取与回填演示”,是否还会补充企业真实样本。
|
||||
|
||||
### 8.2 Word 导出的保真要求边界
|
||||
### 8.2 仍建议补充确认的业务细节
|
||||
|
||||
已确认方向是“最好输出新的 Word 文档并保留原始格式”,但仍建议确认:
|
||||
以下问题已经有明确主方向,但仍建议在进入详细设计前再确认实现细节:
|
||||
|
||||
1. 首版是否要求所有回填任务都必须产出 Word,还是允许部分任务先输出结构化预览。
|
||||
2. 保真要求是“尽量接近模板”还是“必须达到可直接报送级版式”。
|
||||
3. 是否需要同时导出 PDF 供审核留档。
|
||||
|
||||
### 8.3 飞书接入的最小可用范围
|
||||
|
||||
已确认要实现飞书接入,但仍建议确认首版最小可用范围:
|
||||
|
||||
1. 首版是“飞书消息触发 + 返回摘要 + 结果链接”即可,还是要做到“在飞书内完成任务选择、结果查看和责任人通知”。
|
||||
2. 责任关系是按章节点、按任务类型还是按项目角色维护。
|
||||
3. 是否需要支持文档评论区 `@bot` 回复、群聊机器人、还是独立飞书应用会话三种入口中的一种或多种。
|
||||
|
||||
### 8.4 规则切片的颗粒度与维护方式
|
||||
|
||||
已确认法规材料建议切片入 RAG,但还可进一步确认:
|
||||
|
||||
1. 切片是按“章 -> 条 -> 要求项 -> 模板字段”四级结构维护,还是先按文档段落切片即可。
|
||||
2. 是否需要在首版中同步建设结构化规则文件,以便让完整性校验不完全依赖检索文本。
|
||||
3. 后续谁来维护规则包与法规切片,是否需要保留人工校订入口。
|
||||
1. Word 导出是否除 `docx` 外还要同步输出 PDF 归档件。
|
||||
2. 用户新写模板进入模板库后,模板版本、生效范围和审批流程是否需要管理。
|
||||
3. 责任人配置是仅按章节点维护,还是同时支持按任务类型、项目角色双维度维护。
|
||||
4. 后端知识库更新入口是否只允许管理员使用,还是允许业务审核人员参与人工校订。
|
||||
|
||||
## 9. 本轮需求分析采用的默认假设
|
||||
|
||||
@@ -239,12 +230,13 @@
|
||||
2. Demo 首版可先覆盖监管信息章,并为全章扩展预留结构。
|
||||
3. 一致性检查前需要先确定当前审核范围,不能默认把所有原始材料视为同一产品资料包。
|
||||
4. 法规完整性检查首版以本地结构化规则和本地法规材料为准,不强依赖联网抓取法规。
|
||||
5. 法规材料会同步切片入 RAG,但规则判断以结构化规则优先,RAG 负责检索、引用和解释。
|
||||
6. 回填能力目标默认包含“生成新的 Word 文档并支持导出”,但允许分阶段落地,先完成字段映射与预览,再补高保真写回。
|
||||
5. 法规材料会同步按“章 -> 条 -> 要求项 -> 模板字段”四级结构切片入 RAG,并同步维护结构化规则文件,规则判断以结构化规则优先,RAG 负责检索、引用和解释。
|
||||
6. 回填能力必须达到“生成新的 Word 文档并支持导出,且版式可直接报送”的交付标准。
|
||||
7. 一致性判断当前默认按完全一致执行。
|
||||
8. 风险判断采用高 / 中 / 低三级,且任一高风险项直接判定不通过。
|
||||
9. 飞书接入属于明确建设方向,首版主体仍以 Web Demo 为主,但设计阶段要把飞书入口与通知链路纳入范围。
|
||||
9. 飞书接入属于本次 Demo 明确范围,需支持在飞书内完成任务选择、结果查看和责任人通知,并支持群聊机器人入口。
|
||||
10. V1 的法规任务边界先聚焦“注册申报”,变更备案和延续注册在规则架构上预留扩展位,但不作为当前主验收范围。
|
||||
11. 系统需要提供后端管理页面,支持人工校订、模板管理、责任人维护和知识库更新。
|
||||
|
||||
## 10. 结论
|
||||
|
||||
|
||||
@@ -68,9 +68,9 @@ V1 聚焦“可运行、可讲解、可演示”的注册资料审核闭环,
|
||||
### 4.2 V1 可接受的简化
|
||||
|
||||
1. 首版可优先覆盖第 1 章监管信息,并为全章扩展预留结构。
|
||||
2. 首版允许分阶段完成 Word 输出能力,但目标交付应包含“生成新的 Word 文档并支持导出”,同时尽量保留原始格式。
|
||||
2. 首版即要求具备“生成新的 Word 文档并支持导出”的能力,且输出版式必须达到可直接报送级别。
|
||||
3. 首版法规校验可以本地规则为主,不强依赖联网抓取最新法规。
|
||||
4. 首版主体仍以 Web 工作台为主,但应纳入飞书接入方案,至少预留飞书消息触发、结果回传和责任人通知链路。
|
||||
4. 首版需要支持飞书内完成任务选择、结果查看和责任人通知,并支持群聊机器人入口及手动维护责任人 / 飞书账号映射。
|
||||
5. 首版法规任务边界以“注册申报”主流程为核心,变更备案和延续注册暂作为规则扩展方向。
|
||||
|
||||
## 5. 业务闭环
|
||||
@@ -89,6 +89,12 @@ V1 聚焦“可运行、可讲解、可演示”的注册资料审核闭环,
|
||||
1. 结构化规则文件负责完整性判断、强一致比对和风险映射。
|
||||
2. 公告附件原文切片入 RAG,负责条款引用、证据检索和解释说明。
|
||||
|
||||
其中法规知识维护方式应固定为:
|
||||
|
||||
1. 按“章 -> 条 -> 要求项 -> 模板字段”四级结构维护。
|
||||
2. 同步建设结构化规则文件,避免让完整性校验完全依赖检索文本。
|
||||
3. 提供后台管理页面,支持人工校订和知识库更新。
|
||||
|
||||
在法规维度上,建议把完整流程理解为:
|
||||
|
||||
1. 识别当前审核任务属于“注册申报”主流程。
|
||||
@@ -144,7 +150,11 @@ V1 需求分析按项目现有主模块拆分,不做过度细分:
|
||||
|
||||
### 7.6 系统需要具备“多入口访问能力”
|
||||
|
||||
V1 主体虽然仍以 Web 端演示为主,但系统应预留并逐步实现飞书入口能力,使审核任务可以从浏览器工作台扩展到飞书会话、飞书机器人和文档评论协作场景。
|
||||
V1 除 Web 工作台外,还需要实际支持飞书入口能力,使审核任务可以从浏览器工作台扩展到飞书会话和飞书群聊机器人场景。
|
||||
|
||||
### 7.7 系统需要具备“后台治理能力”
|
||||
|
||||
除前台审核能力外,V1 还需要提供后台管理能力,用于维护规则包、模板库、责任人映射和知识库更新入口。
|
||||
|
||||
## 8. 后续文档与实现衔接建议
|
||||
|
||||
|
||||
@@ -114,6 +114,12 @@
|
||||
- `WORD_EXPORT_ROOT`
|
||||
Word 回填结果与新生成文档导出目录。
|
||||
|
||||
- `WORD_TEMPLATE_ROOT`
|
||||
可直接报送级 Word 模板库目录。
|
||||
|
||||
- `RULE_ADMIN_UPLOAD_ROOT`
|
||||
规则包、切片文件和人工校订结果上传目录。
|
||||
|
||||
- `RULESET_DIR`
|
||||
法规目录模板、字段规则、风险规则所在目录。
|
||||
|
||||
@@ -183,6 +189,8 @@
|
||||
- `FEISHU_ENABLE_CHANNEL`
|
||||
- `FEISHU_CALLBACK_URL`
|
||||
- `FEISHU_CLI_ENABLED`
|
||||
- `FEISHU_GROUP_BOT_ENABLED`
|
||||
- `FEISHU_ACCOUNT_MAPPING_SOURCE`
|
||||
|
||||
用于支持飞书应用、机器人入口、事件回调和 CLI / MCP 工具接入。
|
||||
|
||||
@@ -218,6 +226,12 @@ rules/
|
||||
extraction/
|
||||
consistency/
|
||||
risk/
|
||||
knowledge/
|
||||
templates/
|
||||
admin/
|
||||
rule_updates/
|
||||
template_library/
|
||||
responsibility_mapping/
|
||||
```
|
||||
|
||||
这样的结构比“统一丢进某个场景目录”更适合注册资料业务,因为它天然支持:
|
||||
@@ -228,6 +242,7 @@ rules/
|
||||
- 规则版本独立维护
|
||||
- 注册申报、变更备案、延续注册可分开维护规则包
|
||||
- Word 输出模板与导出结果独立管理
|
||||
- 规则切片、人工校订结果和模板库可独立维护
|
||||
|
||||
### 6.2 路径命名要求
|
||||
|
||||
@@ -309,6 +324,7 @@ rules/
|
||||
4. 为 `.doc`、`.docx`、PDF 页数统计和解析策略提供显式配置位。
|
||||
5. 增加法规原文目录、法规流程类型和文件格式模板版本配置。
|
||||
6. 增加 Word 导出目录和飞书应用接入相关配置。
|
||||
7. 增加模板库目录、规则管理目录和责任人映射配置。
|
||||
|
||||
## 11. 本模块验收标准
|
||||
|
||||
|
||||
@@ -201,6 +201,7 @@
|
||||
- 风险合并策略
|
||||
- 高中低风险判定口径
|
||||
- 责任归属字段
|
||||
- 飞书通知目标字段
|
||||
|
||||
### 7.6 法规依据展示任务或结果区
|
||||
|
||||
@@ -237,6 +238,7 @@
|
||||
1. 在飞书机器人中按任务 ID 触发。
|
||||
2. 在飞书侧展示任务摘要和结果链接。
|
||||
3. 将“通知责任人”与任务类型建立映射。
|
||||
4. 支持群聊机器人中的任务选择与结果查看。
|
||||
|
||||
如果后续采用飞书开放平台的 Agent 接入路线,还应确保这些任务标识可以映射到飞书消息指令、评论触发或会话菜单项。
|
||||
|
||||
|
||||
@@ -16,7 +16,7 @@
|
||||
2. 让用户能明确知道自己当前在执行哪类审核任务。
|
||||
3. 让系统输出不仅有自然语言回答,还有结构化结论、引用证据、回填字段、风险建议。
|
||||
4. 保证结果可追溯、可解释、可复核,而不是只给一个“大模型说了什么”。
|
||||
5. 支持通过 Web 工作台与飞书入口两类方式访问智能体、触发审核和查看结果。
|
||||
5. 支持通过 Web 工作台与飞书入口两类方式访问智能体、触发审核和查看结果,并保证核心流程可在飞书内闭环完成。
|
||||
|
||||
## 3. 为什么 Chat 模块仍然必要
|
||||
|
||||
@@ -151,12 +151,13 @@
|
||||
|
||||
### 6.4 飞书访问入口
|
||||
|
||||
当前 Demo 主体仍以 Web 工作台为主,但交互设计上应纳入两类飞书能力:
|
||||
飞书交互不应只是消息转发,而应支持在飞书内完成关键流程。交互设计上至少应纳入以下能力:
|
||||
|
||||
1. 通过飞书消息入口触发某个审核任务。
|
||||
2. 在审核完成后回传摘要结果,并支持通过飞书机器人 `@` 责任人。
|
||||
1. 通过飞书消息或群聊机器人入口触发某个审核任务。
|
||||
2. 在飞书内完成任务选择、结果查看和责任人通知。
|
||||
3. 支持手动维护后的责任人 / 飞书账号映射生效。
|
||||
|
||||
后续若采用飞书开放平台的 Agent 接入路线,还应支持文档评论区 `@bot`、群聊机器人或应用会话中的至少一种触发方式。
|
||||
飞书开放平台接入路线中,群聊机器人属于 Demo 必备入口;文档评论区 `@bot` 或应用会话能力可作为后续扩展。
|
||||
|
||||
## 7. 输出层需求
|
||||
|
||||
@@ -196,9 +197,20 @@
|
||||
- 展示是否已生成新的 Word 文档
|
||||
- 展示导出入口
|
||||
|
||||
即便首版先完成字段映射与预览,也应把“可回填结果”和“导出进度”明确展示出来。
|
||||
输出结果不仅要展示回填数据,还应明确展示“已按模板生成可直接报送版 Word”及其导出入口。
|
||||
|
||||
### 7.5 风险提示
|
||||
### 7.5 飞书端结果展示
|
||||
|
||||
飞书端至少应能展示:
|
||||
|
||||
- 当前任务名称
|
||||
- 结果摘要
|
||||
- 风险等级
|
||||
- 关键缺失项或冲突项
|
||||
- 责任人通知结果
|
||||
- Web 详情页或导出文件链接
|
||||
|
||||
### 7.6 风险提示
|
||||
|
||||
风险输出不应混在普通回答里,建议单独展示:
|
||||
|
||||
|
||||
@@ -233,12 +233,13 @@
|
||||
|
||||
### 首版建议范围
|
||||
|
||||
首版可以分阶段建设,但目标应明确指向:
|
||||
首版即需要满足以下交付目标:
|
||||
|
||||
- 申请表字段回填数据集
|
||||
- 对照清单字段回填数据集
|
||||
- 页面可视化回填预览
|
||||
- 新的 Word 文档生成与导出能力
|
||||
- 基于模板库的高保真版式回填能力
|
||||
|
||||
### 处理逻辑
|
||||
|
||||
@@ -249,11 +250,11 @@
|
||||
|
||||
### 后续扩展
|
||||
|
||||
Word 输出阶段建议逐步增强为:
|
||||
Word 输出必须满足以下要求:
|
||||
|
||||
1. 字段映射与预览
|
||||
2. 模板占位写回
|
||||
3. 尽量保留原始样式、表格和版式的高保真导出
|
||||
1. 支持将用户新增模板纳入模板库。
|
||||
2. 回填时按模板字段映射写入指定模板。
|
||||
3. 输出文档的标题层级、表格、页眉页脚、盖章位和整体版式需达到可直接报送级别。
|
||||
|
||||
结合新增公告附件包中的批准证明文件格式材料,回填能力的后续扩展方向应进一步明确为:
|
||||
|
||||
@@ -396,6 +397,8 @@ LLM 负责把这些动作组织成自然语言建议,但不能改变底层规
|
||||
2. 结构目录层完整性规则
|
||||
3. 格式模板层完整性规则
|
||||
|
||||
同时,这三层规则都应能映射回“章 -> 条 -> 要求项 -> 模板字段”四级知识结构。
|
||||
|
||||
### 7.2 抽取规则
|
||||
|
||||
用于:
|
||||
@@ -411,6 +414,8 @@ LLM 负责把这些动作组织成自然语言建议,但不能改变底层规
|
||||
- 适用范围说明
|
||||
- 批准证明文件格式字段
|
||||
|
||||
并为后台管理页面提供人工校订后的结构化回写入口。
|
||||
|
||||
### 7.3 一致性规则
|
||||
|
||||
用于定义:
|
||||
@@ -447,6 +452,8 @@ LLM 负责把这些动作组织成自然语言建议,但不能改变底层规
|
||||
9. 格式模板映射工具
|
||||
10. Word 模板回填与导出工具
|
||||
11. 飞书消息摘要生成与通知载荷组装工具
|
||||
12. 责任人映射解析工具
|
||||
13. 规则切片与结构化回写工具
|
||||
|
||||
这些工具都应通过 Tool Registry 注册,符合项目既有边界要求。
|
||||
|
||||
@@ -514,6 +521,8 @@ Audit 负责记录过程和结果;Agent Core 负责产出可记录的结构化
|
||||
5. 将“回填准备结果”纳入正式输出结构。
|
||||
6. 增加“是否通过”和“风险评分明细”输出字段。
|
||||
7. 增加法规分层规则管理,以及注册申报 / 变更 / 延续三类流程的扩展边界。
|
||||
8. 增加模板库驱动的高保真 Word 生成链路。
|
||||
9. 增加后端管理入口所需的规则回写、人工校订和责任人映射能力。
|
||||
|
||||
## 13. 验收标准
|
||||
|
||||
@@ -525,3 +534,4 @@ Audit 负责记录过程和结果;Agent Core 负责产出可记录的结构化
|
||||
4. 输出能关联到具体文档和证据片段。
|
||||
5. 测试环境下可以通过 Mock Provider 验证主要编排逻辑。
|
||||
6. 法规原文可切片入 RAG,但最终完整性与准入判断仍由规则链路主导。
|
||||
7. Word 输出结果能够基于模板库生成可直接报送级版式文档。
|
||||
|
||||
Reference in New Issue
Block a user