DEMO-AGENT/docs/需求分析/9.业务确认问答清单.md

业务确认问答清单

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. 建议的会议记录模板

建议你每次和业务沟通时，按下面格式记录：

问题编号：
问题主题：
业务回答：
是否已明确：是 / 否
当前默认口径：
是否影响需求文档：是 / 否
是否影响设计文档：是 / 否
需要补充材料：
备注：

---

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. 后续新增的设计文档