feat(ui): 重构注册审核平台原型界面
This commit is contained in:
597
docs/需求分析/9.业务确认问答清单.md
Normal file
597
docs/需求分析/9.业务确认问答清单.md
Normal file
@@ -0,0 +1,597 @@
|
||||
# 业务确认问答清单
|
||||
|
||||
## 1. 文档目的
|
||||
|
||||
本文档用于和业务方进一步确认需求边界、交付口径和演示重点。
|
||||
|
||||
它和 `0.需求重构总览与待确认事项.md` 的区别是：
|
||||
|
||||
1. 总览文档更偏内部需求分析。
|
||||
2. 本文档更偏“可直接拿去问业务”的沟通清单。
|
||||
3. 每个问题尽量使用业务语言，避免陷入实现细节。
|
||||
|
||||
建议使用方式：
|
||||
|
||||
1. 按章节逐条和业务确认。
|
||||
2. 每个问题尽量记录“明确答案 + 备注 + 示例材料来源”。
|
||||
3. 若业务方回答不确定，可先记为“当前默认口径”。
|
||||
4. 沟通完成后，再回填更新需求分析和设计文档。
|
||||
|
||||
---
|
||||
|
||||
## 2. 当前已确认口径摘要
|
||||
|
||||
以下内容目前已经有较明确的方向，和业务确认时可以先作为“我们的当前理解”说给对方听，请对方确认是否同意：
|
||||
|
||||
1. 系统目标是“通用的试剂盒临床注册文件准备与审核智能体”，不是只服务某一个固定产品。
|
||||
2. 一致性核查当前按完全一致处理，不采用“语义差不多即可”的宽松口径。
|
||||
3. 风险按高 / 中 / 低三级，任一高风险即不允许通过。
|
||||
4. 输出结果必须支持生成新的 Word 文档，并达到可直接报送级版式。
|
||||
5. 用户后续编写的新模板可以纳入模板库，后续按模板回填。
|
||||
6. 规则来源以公告附件包为主，`附件 4` 视作同源补充材料。
|
||||
7. 法规知识按“章 -> 条 -> 要求项 -> 模板字段”四级结构维护。
|
||||
8. 飞书接入属于本次 Demo 范围，需要支持群聊机器人，并在飞书内完成任务选择、结果查看和责任人通知。
|
||||
9. 系统需要提供后台管理页面，支持人工校订、知识库更新、模板管理和责任人维护。
|
||||
|
||||
---
|
||||
|
||||
## 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 当前样例中的跨产品材料混杂，是刻意测试异常，还是后续会统一资料包？
|
||||
|
||||
建议提问方式：
|
||||
|
||||
> 当前样例里存在不同产品名称的材料混在一起，这种情况是有意作为异常样例，还是后续会再整理成同一产品的一套资料？
|
||||
|
||||
建议记录答案：
|
||||
|
||||
- 属于刻意异常：
|
||||
- 属于样例混杂：
|
||||
- 后续是否会统一：
|
||||
|
||||
为什么要问：
|
||||
|
||||
- 决定一致性冲突是“核心演示点”还是“样本噪声”。
|
||||
|
||||
---
|
||||
|
||||
## 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 为规则依据，不额外纳入其他外部法规文件？
|
||||
|
||||
建议记录答案：
|
||||
|
||||
- 是否只用现有规则包：
|
||||
- 是否还要补充其他规则源：
|
||||
|
||||
为什么要问：
|
||||
|
||||
- 决定知识库首版范围。
|
||||
|
||||
### 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. 后续新增的设计文档
|
||||
Reference in New Issue
Block a user