679 lines
18 KiB
Markdown
679 lines
18 KiB
Markdown
# 业务确认问答清单
|
||
|
||
## 1. 文档目的
|
||
|
||
本文档用于和业务方进一步确认需求边界、交付口径和演示重点。
|
||
|
||
它和 `0.需求重构总览与待确认事项.md` 的区别是：
|
||
|
||
1. 总览文档更偏内部需求分析。
|
||
2. 本文档更偏“可直接拿去问业务”的沟通清单。
|
||
3. 每个问题尽量使用业务语言，避免陷入实现细节。
|
||
|
||
建议使用方式：
|
||
|
||
1. 按章节逐条和业务确认。
|
||
2. 每个问题尽量记录“明确答案 + 备注 + 示例材料来源”。
|
||
3. 若业务方回答不确定，可先记为“当前默认口径”。
|
||
4. 沟通完成后，再回填更新需求分析和设计文档。
|
||
|
||
---
|
||
|
||
## 2. 当前已确认口径摘要
|
||
|
||
以下内容目前已经有较明确的方向，和业务确认时可以先作为“我们的当前理解”说给对方听，请对方确认是否同意：
|
||
|
||
1. 系统目标是“通用的试剂盒临床注册文件准备与审核智能体”，不是只服务某一个固定产品。
|
||
2. 一致性核查当前按完全一致处理，不采用“语义差不多即可”的宽松口径。
|
||
3. 风险按高 / 中 / 低三级，任一高风险即不允许通过。
|
||
4. 输出结果必须支持生成新的 Word 文档，并达到可直接报送级版式。
|
||
5. 用户后续编写的新模板可以纳入模板库，后续按模板回填。
|
||
6. 规则来源以公告附件包为主，`附件 4` 视作同源补充材料。
|
||
7. 法规知识按“章 -> 条 -> 要求项 -> 模板字段”四级结构维护。
|
||
8. 飞书接入属于本次 Demo 范围，需要支持群聊机器人，并在飞书内完成任务选择、结果查看和责任人通知。
|
||
9. 系统需要提供后台管理页面，支持人工校订、知识库更新、模板管理和责任人维护。
|
||
10. 资料导入应按资料包处理，首版支持批量文件、文件夹和压缩包，压缩包覆盖 `zip`、`rar`、`7z`。
|
||
11. DOCX 页数必须精确统计。
|
||
12. 压缩包内多层目录按原目录作为章节点依据。
|
||
13. `rar`、`7z` 解压必须纯 Python 实现，允许增加第三方依赖包。
|
||
14. 责任人先手动配置，按资料章节维护。
|
||
15. 第 2 至第 6 章不补充企业真实样本，先按公告附件包进行规则级初步确认。
|
||
16. 顶层入口按 `审核智能体 / 资料包 / 知识库 / 处理历史` 组织，法规依据纳入知识库并通过 RAG 在对话中返回。
|
||
17. 资料包必须和会话绑定，会话标题默认采用解析后的产品名称，资料包页支持按产品名称搜索。
|
||
|
||
---
|
||
|
||
## 3. 建议的沟通原则
|
||
|
||
和业务沟通时，建议优先确认四类问题：
|
||
|
||
1. 交付结果长什么样。
|
||
2. 哪些结论能自动判，哪些必须人工复核。
|
||
3. 哪些材料算输入，哪些材料算规则依据。
|
||
4. Demo 要演示到什么深度。
|
||
|
||
对于每个问题，建议都尽量追问到这三个层次：
|
||
|
||
1. 业务目标是什么。
|
||
2. 验收标准是什么。
|
||
3. 出现例外时怎么处理。
|
||
|
||
---
|
||
|
||
## 4. 业务确认问答清单
|
||
|
||
## 4.1 业务目标与使用场景
|
||
|
||
### Q1 当前系统最核心要解决的业务问题是什么？
|
||
|
||
建议提问方式：
|
||
|
||
> 如果这次 Demo 只能重点解决 1 到 2 个最关键问题，您最希望它解决什么？
|
||
|
||
建议记录答案：
|
||
|
||
- 主问题：
|
||
- 次问题：
|
||
- 不在本次范围的问题：
|
||
|
||
为什么要问：
|
||
|
||
- 这个问题决定首页主叙事和演示主线。
|
||
- 也决定后续是偏“审核”还是偏“生成回填”。
|
||
|
||
### Q2 这个系统的主要使用人是谁？
|
||
|
||
建议提问方式：
|
||
|
||
> 这个系统主要是给注册专员、法规人员、项目经理，还是管理层演示用？是否会有不同角色看到不同内容？
|
||
|
||
建议记录答案：
|
||
|
||
- 主要用户角色：
|
||
- 次要用户角色：
|
||
- 是否区分角色权限：
|
||
|
||
为什么要问：
|
||
|
||
- 决定页面表述是否偏专业操作型。
|
||
- 决定飞书通知和责任人配置逻辑。
|
||
|
||
### Q3 业务更看重“审核发现问题”还是“自动生成报送材料”？
|
||
|
||
建议提问方式：
|
||
|
||
> 在您看来，这套系统最有价值的是先帮您发现资料问题，还是直接帮您产出可报送材料？
|
||
|
||
建议记录答案：
|
||
|
||
- 更偏审核：
|
||
- 更偏生成：
|
||
- 两者权重：
|
||
|
||
为什么要问：
|
||
|
||
- 决定 Demo 讲解时主功能排序。
|
||
- 决定开发时优先打磨哪个闭环。
|
||
|
||
---
|
||
|
||
## 4.2 输入资料范围
|
||
|
||
### Q4 本次 Demo 是否允许以第 1 章样本作为主演示材料？
|
||
|
||
建议提问方式：
|
||
|
||
> 目前样例材料主要集中在第 1 章，Demo 是否可以以第 1 章为主要演示对象，同时在规则上覆盖第 2 到第 6 章？
|
||
|
||
建议记录答案：
|
||
|
||
- 是否允许：
|
||
- 若不允许，需要补哪些章的样本：
|
||
|
||
为什么要问：
|
||
|
||
- 决定当前实现是否以“第 1 章内容级演示 + 全章规则级覆盖”为主。
|
||
|
||
### Q5 第 2 到第 6 章后续是否会补充真实业务样本？
|
||
|
||
建议提问方式：
|
||
|
||
> 如果希望 Demo 展示第 2 到第 6 章的抽取、比对和回填效果，后续是否会补充真实样本或脱敏样本？
|
||
|
||
建议记录答案：
|
||
|
||
- 是否补充：
|
||
- 预计补充哪些章：
|
||
- 预计补充时间：
|
||
|
||
为什么要问：
|
||
|
||
- 决定系统当前只做“结构合规”还是还能做“内容级审核”。
|
||
|
||
### Q6 当前样例中的跨产品材料混杂，是刻意测试异常，还是后续会统一资料包？
|
||
|
||
建议提问方式：
|
||
|
||
> 当前样例里存在不同产品名称的材料混在一起，这种情况是有意作为异常样例，还是后续会再整理成同一产品的一套资料？
|
||
|
||
建议记录答案：
|
||
|
||
- 属于刻意异常：
|
||
- 属于样例混杂：
|
||
- 后续是否会统一：
|
||
|
||
为什么要问：
|
||
|
||
- 决定一致性冲突是“核心演示点”还是“样本噪声”。
|
||
|
||
### Q6-1 资料包导入需要支持哪些输入形式？
|
||
|
||
建议提问方式：
|
||
|
||
> 资料一般会以什么形式交给系统？是直接选择一个文件夹、批量选择多个文件，还是上传一个压缩包？
|
||
|
||
建议引导业务按下列类型回答：
|
||
|
||
1. 批量文件
|
||
2. 文件夹
|
||
3. zip 压缩包
|
||
4. rar 压缩包
|
||
5. 7z 压缩包
|
||
|
||
建议记录答案：
|
||
|
||
- 必须支持：批量文件、文件夹、zip、rar、7z
|
||
- 可后续支持：
|
||
- 是否需要保留压缩包内原始目录：是，多层目录按原目录作为章节点依据
|
||
- rar / 7z 实现要求：必须纯 Python 实现，允许增加第三方依赖包
|
||
|
||
为什么要问：
|
||
|
||
- 决定 Documents 模块的上传、解包、目录还原和异常提示实现。
|
||
|
||
### Q6-2 资料包与会话是否固定绑定？
|
||
|
||
建议提问方式：
|
||
|
||
> 当前我们准备采用“一个资料包绑定一个主会话”的方式，并把会话标题直接使用解析后的产品名称。请确认这个口径是否符合您期望的使用方式？
|
||
|
||
建议记录答案：
|
||
|
||
- 是否一包一会话：
|
||
- 会话标题是否使用产品名称：
|
||
- 是否允许后续在同一资料包下追加子会话：
|
||
|
||
为什么要问：
|
||
|
||
- 这会直接影响资料包页、审核智能体页和处理历史页的主键设计。
|
||
|
||
### Q6-3 资料包页是否以产品名称作为主搜索字段？
|
||
|
||
建议提问方式：
|
||
|
||
> 在资料包列表里，您更习惯通过产品名称、批次号还是项目编号来查找资料？我们当前默认以产品名称和批次号作为主搜索条件。
|
||
|
||
建议记录答案：
|
||
|
||
- 主搜索字段：
|
||
- 次搜索字段：
|
||
- 是否需要模糊搜索：
|
||
|
||
为什么要问：
|
||
|
||
- 这会影响资料包列表页和历史页的默认检索体验。
|
||
|
||
---
|
||
|
||
## 4.3 自动审核与人工复核边界
|
||
|
||
### Q7 哪些类型的问题可以由系统直接判定，哪些必须人工复核？
|
||
|
||
建议提问方式：
|
||
|
||
> 对您来说，哪些问题系统可以直接下结论，哪些问题必须保留给人工复核？
|
||
|
||
建议引导业务按下列类型回答：
|
||
|
||
1. 文件缺失
|
||
2. 章节点归类错误
|
||
3. 字段不一致
|
||
4. 模板格式不符合
|
||
5. 历史申报事项解释
|
||
|
||
建议记录答案：
|
||
|
||
- 可自动判定：
|
||
- 必须人工复核：
|
||
- 自动判定后是否仍需人工确认：
|
||
|
||
为什么要问：
|
||
|
||
- 决定结果页里哪些内容标“通过/不通过”，哪些标“待复核”。
|
||
|
||
### Q8 “完全一致”的范围是否适用于所有字段？
|
||
|
||
建议提问方式：
|
||
|
||
> 我们当前理解是：同一审核范围内，相同字段默认按完全一致处理。请确认是否所有关键字段都按这个标准执行，还是有少数字段允许格式差异但含义一致。
|
||
|
||
建议引导业务按字段类别回答：
|
||
|
||
1. 产品名称
|
||
2. 申请人名称
|
||
3. 规格型号
|
||
4. 适用范围
|
||
5. 储存条件
|
||
6. 样本类型
|
||
|
||
建议记录答案：
|
||
|
||
- 必须完全一致的字段：
|
||
- 允许人工判断等价的字段：
|
||
|
||
为什么要问：
|
||
|
||
- 虽然当前默认口径是完全一致，但和业务再确认一次更稳。
|
||
|
||
### Q9 风险评分结果里，“不通过”是否只看高风险，还是还要加总分门槛？
|
||
|
||
建议提问方式：
|
||
|
||
> 当前理解是“任一高风险即不通过”。除此之外，是否还需要总分门槛，比如中风险积累到一定程度也不通过？
|
||
|
||
建议记录答案：
|
||
|
||
- 是否仅以高风险阻断：
|
||
- 是否需要总分门槛：
|
||
- 是否需要“有条件通过 / 整改后复核”状态：
|
||
|
||
为什么要问：
|
||
|
||
- 决定风险报告的最终判定逻辑。
|
||
|
||
---
|
||
|
||
## 4.4 Word 生成与模板管理
|
||
|
||
### Q10 业务侧对“可直接报送级版式”的验收标准是什么？
|
||
|
||
建议提问方式：
|
||
|
||
> 对于导出的 Word，您认为达到“可直接报送”的最低标准是什么？哪些版式元素是绝对不能错的？
|
||
|
||
建议引导业务从以下维度回答：
|
||
|
||
1. 标题层级
|
||
2. 段落格式
|
||
3. 表格样式
|
||
4. 页眉页脚
|
||
5. 页码
|
||
6. 盖章位
|
||
7. 附件格式
|
||
|
||
建议记录答案：
|
||
|
||
- 必须严格保留的版式元素：
|
||
- 可接受微调的版式元素：
|
||
- 不可接受的典型错误：
|
||
|
||
为什么要问：
|
||
|
||
- 这是 Word 导出能否被认为“可交付”的关键。
|
||
|
||
### Q11 是否需要同时导出 PDF 归档件？
|
||
|
||
建议提问方式：
|
||
|
||
> 除了 Word 报送稿，是否还需要系统同步导出 PDF 作为归档、流转或内部审核附件？
|
||
|
||
建议记录答案：
|
||
|
||
- 是否需要 PDF：
|
||
- Word 和 PDF 哪个是主交付件：
|
||
|
||
为什么要问：
|
||
|
||
- 决定导出链路和验收文件类型。
|
||
|
||
### Q12 新模板进入模板库后，谁来确认它是正式模板？
|
||
|
||
建议提问方式：
|
||
|
||
> 如果后续由您这边提供新的模板，系统纳入模板库之前，是否需要指定某个角色进行确认、审批或启用？
|
||
|
||
建议记录答案：
|
||
|
||
- 模板提供方：
|
||
- 模板审核方：
|
||
- 模板启用规则：
|
||
|
||
为什么要问：
|
||
|
||
- 决定后台模板管理页是否需要版本和审批状态。
|
||
|
||
### Q13 模板是按什么维度区分的？
|
||
|
||
建议提问方式：
|
||
|
||
> 模板需要按哪些维度区分，例如注册申报 / 变更 / 延续、不同章节点、不同产品类型，还是不同企业内部模板版本？
|
||
|
||
建议记录答案：
|
||
|
||
- 按流程类型：
|
||
- 按章节点：
|
||
- 按产品类型：
|
||
- 按企业版本：
|
||
|
||
为什么要问：
|
||
|
||
- 决定模板库数据结构。
|
||
|
||
---
|
||
|
||
## 4.5 法规规则与知识库治理
|
||
|
||
### Q14 当前法规规则源是否只以现有公告附件包为准？
|
||
|
||
建议提问方式：
|
||
|
||
> 当前 Demo 是否可以只以现有公告附件包和附件 4 为规则依据，不额外纳入其他外部法规文件？
|
||
|
||
建议记录答案：
|
||
|
||
- 是否只用现有规则包：
|
||
- 是否还要补充其他规则源：
|
||
|
||
为什么要问：
|
||
|
||
- 决定知识库首版范围。
|
||
|
||
### Q14-1 法规依据是否可以完全收敛到知识库页面维护？
|
||
|
||
建议提问方式：
|
||
|
||
> 当前原型里我们不再单独做“法规依据”一级页面，而是把法规资料统一放进知识库，由 Agent 对话通过 RAG 命中后返回依据说明。请确认这种呈现方式是否符合您的预期？
|
||
|
||
建议记录答案：
|
||
|
||
- 是否接受：
|
||
- 是否仍需单独法规页：
|
||
- 是否需要在结果里展示来源版本：
|
||
|
||
为什么要问：
|
||
|
||
- 这会影响顶层导航是否继续精简，以及法规解释的展示形态。
|
||
|
||
### Q15 后台知识库更新入口由谁使用？
|
||
|
||
建议提问方式：
|
||
|
||
> 后台的知识库更新和人工校订功能，预计是只有管理员可用，还是法规/注册业务人员也会参与维护？
|
||
|
||
建议记录答案：
|
||
|
||
- 仅管理员：
|
||
- 管理员 + 业务人员：
|
||
- 是否需要操作留痕：
|
||
|
||
为什么要问：
|
||
|
||
- 决定后台权限模型和审计范围。
|
||
|
||
### Q16 人工校订主要校订哪些内容？
|
||
|
||
建议提问方式：
|
||
|
||
> 您希望人工校订功能主要用于改哪些内容？是法规切片、字段映射、模板字段、责任人映射，还是审核结论备注？
|
||
|
||
建议记录答案：
|
||
|
||
- 允许校订的内容：
|
||
- 不允许业务侧直接改的内容：
|
||
|
||
为什么要问：
|
||
|
||
- 决定后台管理页具体有哪些编辑入口。
|
||
|
||
### Q17 知识库更新后，是否需要重新审核历史项目？
|
||
|
||
建议提问方式：
|
||
|
||
> 如果法规规则或模板更新了，历史项目是否需要按新规则重新检查，还是仅影响新项目？
|
||
|
||
建议记录答案：
|
||
|
||
- 仅影响新项目：
|
||
- 历史项目需要重跑：
|
||
- 是否保留旧版本结果：
|
||
|
||
为什么要问：
|
||
|
||
- 决定规则版本管理和历史审计口径。
|
||
|
||
---
|
||
|
||
## 4.6 飞书接入与责任人通知
|
||
|
||
### Q18 飞书群聊机器人里，业务最希望怎么触发任务？
|
||
|
||
建议提问方式：
|
||
|
||
> 在飞书群聊里，您更希望通过固定命令触发，还是通过菜单、卡片按钮、表单方式选择任务？
|
||
|
||
建议记录答案：
|
||
|
||
- 命令式：
|
||
- 卡片式：
|
||
- 菜单式：
|
||
- 其他偏好：
|
||
|
||
为什么要问：
|
||
|
||
- 决定飞书端交互体验复杂度。
|
||
|
||
### Q19 飞书里“结果查看”希望看到多详细？
|
||
|
||
建议提问方式：
|
||
|
||
> 在飞书里，您更希望看到简短摘要，还是希望直接看到缺失项、风险等级、责任人、下载链接这些完整信息？
|
||
|
||
建议记录答案：
|
||
|
||
- 仅摘要：
|
||
- 摘要 + 关键问题：
|
||
- 尽可能完整：
|
||
|
||
为什么要问：
|
||
|
||
- 决定飞书卡片内容设计。
|
||
|
||
### Q20 责任人是如何定义的？
|
||
|
||
建议提问方式：
|
||
|
||
> 责任人是按章节点、按资料类型、按项目角色，还是按项目具体人员来分配？
|
||
|
||
建议记录答案：
|
||
|
||
- 按章节点：首版已确认，按资料章节手动配置
|
||
- 按资料类型：后续可扩展
|
||
- 按项目角色：后续可扩展
|
||
- 按具体人员：通过手动配置映射到章节责任人
|
||
|
||
为什么要问：
|
||
|
||
- 决定责任人配置表结构。
|
||
|
||
### Q21 责任人通知只要 `@人`，还是还要带整改动作？
|
||
|
||
建议提问方式：
|
||
|
||
> 飞书通知时，您是只希望 `@` 到对应责任人，还是希望同时带上问题摘要、整改建议、资料链接和截止时间？
|
||
|
||
建议记录答案：
|
||
|
||
- 只需 `@人`：
|
||
- 需要问题摘要：
|
||
- 需要整改建议：
|
||
- 需要截止时间：
|
||
|
||
为什么要问：
|
||
|
||
- 决定飞书通知卡片结构。
|
||
|
||
### Q22 是否需要支持多人负责同一项问题？
|
||
|
||
建议提问方式：
|
||
|
||
> 同一章节点或同一风险项，是否可能对应多个责任人，例如主责人 + 复核人？
|
||
|
||
建议记录答案：
|
||
|
||
- 是否支持多人：
|
||
- 是否区分主责 / 协同 / 复核：
|
||
|
||
为什么要问：
|
||
|
||
- 决定责任人映射是否是一对一还是一对多。
|
||
|
||
---
|
||
|
||
## 4.7 审计、追溯与管理要求
|
||
|
||
### Q23 业务最关心审计记录里看到什么？
|
||
|
||
建议提问方式：
|
||
|
||
> 如果后续回看一次审核记录，您最希望一眼看到哪些信息？
|
||
|
||
建议引导业务回答：
|
||
|
||
1. 审核时间
|
||
2. 审核人
|
||
3. 使用的资料范围
|
||
4. 风险等级
|
||
5. 不通过原因
|
||
6. 导出文件
|
||
7. 飞书通知记录
|
||
|
||
建议记录答案：
|
||
|
||
- 必看信息：
|
||
- 次要信息：
|
||
|
||
为什么要问：
|
||
|
||
- 决定审计列表和详情页优先展示字段。
|
||
|
||
### Q24 是否需要区分“系统自动结论”和“人工修改后结论”？
|
||
|
||
建议提问方式：
|
||
|
||
> 如果系统先给出自动判断，后续又经过人工校订或人工确认，是否需要把这两个结果区分记录？
|
||
|
||
建议记录答案：
|
||
|
||
- 是否区分：
|
||
- 是否保留修改原因：
|
||
- 是否保留修改人：
|
||
|
||
为什么要问：
|
||
|
||
- 决定审计模型是否需要版本链。
|
||
|
||
---
|
||
|
||
## 4.8 Demo 演示与验收方式
|
||
|
||
### Q25 Demo 现场最希望看到哪条完整链路？
|
||
|
||
建议提问方式：
|
||
|
||
> 如果现场只演示一条最完整的链路，您最希望看到哪一种？
|
||
|
||
建议给业务三个选项帮助回答：
|
||
|
||
1. 导入资料 -> 自动检查缺失 -> 输出风险报告
|
||
2. 导入资料 -> 抽取字段 -> 自动生成 Word
|
||
3. 飞书群聊触发 -> 查看结果 -> 通知责任人
|
||
|
||
建议记录答案：
|
||
|
||
- 首选演示链路：
|
||
- 次选演示链路：
|
||
|
||
为什么要问：
|
||
|
||
- 决定 Demo 讲解脚本和开发优先级。
|
||
|
||
### Q26 本次 Demo 的“通过标准”是什么？
|
||
|
||
建议提问方式：
|
||
|
||
> 对您来说，这次 Demo 达到什么程度，就可以认为是比较成功的？
|
||
|
||
建议引导业务从以下角度回答：
|
||
|
||
1. 能看出业务理解到位
|
||
2. 能自动发现主要问题
|
||
3. 能自动生成较完整材料
|
||
4. 能在飞书里顺畅演示
|
||
5. 能展示后台治理能力
|
||
|
||
建议记录答案：
|
||
|
||
- 必须达到：
|
||
- 加分项：
|
||
- 本次不强求：
|
||
|
||
为什么要问：
|
||
|
||
- 这是项目收敛范围的总开关。
|
||
|
||
---
|
||
|
||
## 5. 建议的会议记录模板
|
||
|
||
建议你每次和业务沟通时，按下面格式记录：
|
||
|
||
```text
|
||
问题编号：
|
||
问题主题：
|
||
业务回答：
|
||
是否已明确：是 / 否
|
||
当前默认口径：
|
||
是否影响需求文档：是 / 否
|
||
是否影响设计文档：是 / 否
|
||
需要补充材料：
|
||
备注：
|
||
```
|
||
|
||
---
|
||
|
||
## 6. 沟通优先级建议
|
||
|
||
如果时间有限，建议优先确认以下 8 个问题：
|
||
|
||
1. Q4 Demo 是否允许以第 1 章作为主演示材料
|
||
2. Q6 当前混档样例是否是刻意异常
|
||
3. Q7 哪些结论可自动判、哪些必须人工复核
|
||
4. Q10 “可直接报送级版式”的验收标准
|
||
5. Q12 新模板进入模板库后的确认机制
|
||
6. Q18 飞书群聊机器人希望如何触发任务
|
||
7. Q20 责任人如何定义（已确认首版按资料章节手动配置）
|
||
8. Q26 本次 Demo 的通过标准
|
||
|
||
---
|
||
|
||
## 7. 结论
|
||
|
||
这份问答清单的目标，不是把所有问题一次性问完，而是帮助你优先确认真正影响范围和验收的关键信息。
|
||
|
||
如果后续拿到新的业务回答，建议同步更新：
|
||
|
||
1. `docs/需求分析/0.需求重构总览与待确认事项.md`
|
||
2. `docs/需求分析/1.V1总需求文档.md`
|
||
3. 对应模块需求分析文档
|
||
4. 后续新增的设计文档
|