309 lines
8.6 KiB
Markdown
309 lines
8.6 KiB
Markdown
# Chat 模块需求分析
|
||
|
||
## 1. 模块定位
|
||
|
||
`apps.chat` 在当前项目中是用户输入问题并查看 Agent 返回结果的页面。对于本题，它依然是核心交互入口，但定位需要从“自由问答页面”升级为：
|
||
|
||
> 注册申报审核工作台
|
||
|
||
也就是说，Chat 模块不只是让用户随便问一句话，而是要承接“选择任务、限定资料范围、发起审核、查看结构化结论、查看证据和建议”的完整操作流程。
|
||
|
||
## 2. 模块目标
|
||
|
||
本模块需要实现以下目标：
|
||
|
||
1. 为注册审核人员提供统一的任务执行入口。
|
||
2. 让用户能明确知道自己当前在执行哪类审核任务。
|
||
3. 让系统输出不仅有自然语言回答，还有结构化结论、引用证据、回填字段、风险建议。
|
||
4. 保证结果可追溯、可解释、可复核，而不是只给一个“大模型说了什么”。
|
||
5. 支持通过 Web 工作台与飞书入口两类方式访问智能体、触发审核和查看结果，并保证核心流程可在飞书内闭环完成。
|
||
|
||
## 3. 为什么 Chat 模块仍然必要
|
||
|
||
虽然本题也可以做成一组固定报表，但保留 Chat / 工作台交互有三个价值：
|
||
|
||
1. 复试演示更直观，容易展示 Agent 的编排能力。
|
||
2. 用户可以用自然语言提出临时核查要求，例如“只检查 CH1 监管信息”“比较说明书和申请表中的产品名称是否一致”。
|
||
3. Chat 页面可以作为多个任务的统一结果承载层，而不需要为每个任务都单独写一套复杂页面。
|
||
|
||
## 4. 交互定位建议
|
||
|
||
### 4.1 不建议保持纯聊天式体验
|
||
|
||
如果只保留一个输入框，让用户手工描述所有操作，体验会过于依赖 prompt，不像一个业务系统。
|
||
|
||
建议采用“任务工作台 + 辅助对话”的模式，页面中同时提供：
|
||
|
||
- 当前任务名称
|
||
- 输入问题框
|
||
- 资料范围选择
|
||
- 建议提问模板
|
||
- 结构化结果区
|
||
- 证据引用区
|
||
- 风险列表区
|
||
- 审计入口
|
||
|
||
### 4.2 建议突出“任务上下文”
|
||
|
||
用户进入页面后，应明确看到：
|
||
|
||
- 当前任务是什么
|
||
- 当前使用了哪些资料
|
||
- 当前是否启用了法规规则
|
||
- 当前是否启用了字段池 / RAG / 工具
|
||
|
||
这对复试讲解非常重要，因为它能体现系统是“受控执行”而不是“随便问模型”。
|
||
|
||
## 5. 典型使用场景
|
||
|
||
### 5.1 发起完整性检查
|
||
|
||
用户输入类似：
|
||
|
||
- “检查当前上传资料是否满足第 1 章监管信息要求”
|
||
- “列出 CH1 缺失文件和风险等级”
|
||
|
||
系统返回：
|
||
|
||
- 已识别文件数
|
||
- 命中法规目录项
|
||
- 缺失项清单
|
||
- 错放项清单
|
||
- 处理建议
|
||
|
||
### 5.2 发起字段抽取
|
||
|
||
用户输入类似：
|
||
|
||
- “从说明书和产品列表抽取产品名称、检测靶标、适用范围、储存条件、性能指标，并填入申报表或对照清单”
|
||
|
||
系统返回：
|
||
|
||
- 统一字段表
|
||
- 字段来源文档
|
||
- 置信度或待确认状态
|
||
- 注册申报表格或对照清单的回填结果
|
||
- 字段冲突时的拦截提示
|
||
|
||
### 5.3 发起一致性核查
|
||
|
||
用户输入类似：
|
||
|
||
- “检查申请表、说明书、产品列表里的产品名称和规格是否一致”
|
||
|
||
系统返回：
|
||
|
||
- 一致字段
|
||
- 冲突字段
|
||
- 冲突来源
|
||
- 判定依据
|
||
- 建议处理动作
|
||
|
||
### 5.4 发起综合风险报告
|
||
|
||
用户输入类似：
|
||
|
||
- “生成本批申报资料的综合风险预警”
|
||
|
||
系统返回：
|
||
|
||
- 风险摘要
|
||
- 高优先级问题
|
||
- 待补文件
|
||
- 需人工确认事项
|
||
- 建议整改顺序
|
||
|
||
## 6. 输入层需求
|
||
|
||
### 6.1 用户输入类型
|
||
|
||
本模块应支持三类输入：
|
||
|
||
1. 自然语言问题
|
||
2. 结构化参数选择
|
||
3. 资料范围选择
|
||
|
||
### 6.2 结构化参数选择
|
||
|
||
建议用户在页面上可选：
|
||
|
||
- 审核任务类型
|
||
- 资料章节点范围
|
||
- 指定文档范围
|
||
- 输出模式
|
||
|
||
输出模式可包括：
|
||
|
||
- 简洁结论
|
||
- 结构化清单
|
||
- 回填字段视图
|
||
- 风险报告视图
|
||
|
||
### 6.3 建议提示词模板
|
||
|
||
页面上可给出快捷操作示例，例如：
|
||
|
||
- “汇总当前资料目录及页数”
|
||
- “检查 CH1 监管信息是否齐套”
|
||
- “抽取说明书中的核心产品信息并填入对照清单”
|
||
- “检查说明书与申请表是否一致”
|
||
|
||
这样能降低演示时的自由输入风险。
|
||
|
||
### 6.4 飞书访问入口
|
||
|
||
飞书交互不应只是消息转发，而应支持在飞书内完成关键流程。交互设计上至少应纳入以下能力：
|
||
|
||
1. 通过飞书消息或群聊机器人入口触发某个审核任务。
|
||
2. 在飞书内完成任务选择、结果查看和责任人通知。
|
||
3. 支持手动维护后的责任人 / 飞书账号映射生效。
|
||
|
||
飞书开放平台接入路线中，群聊机器人属于 Demo 必备入口；文档评论区 `@bot` 或应用会话能力可作为后续扩展。
|
||
|
||
## 7. 输出层需求
|
||
|
||
### 7.1 自然语言结论
|
||
|
||
仍然需要保留总体回答，用于快速概括结果。
|
||
|
||
### 7.2 结构化结果
|
||
|
||
结构化结果是本题的重点，建议至少支持以下几类：
|
||
|
||
- 目录汇总结果
|
||
- 完整性检查结果
|
||
- 字段抽取结果
|
||
- 一致性核查结果
|
||
- 风险预警结果
|
||
|
||
### 7.3 引用证据
|
||
|
||
每个关键结论尽量附带来源，例如：
|
||
|
||
- 来源文档名
|
||
- 来源章节
|
||
- 引用片段
|
||
- 引用页码或位置
|
||
|
||
对于法规完整性核查，还应尽量附带命中的法规条目或模板条目。
|
||
|
||
### 7.4 回填结果展示
|
||
|
||
对于“自动填写至目标文件”的题面要求，Chat 页面建议至少支持：
|
||
|
||
- 展示待回填字段
|
||
- 展示字段值
|
||
- 展示来源文档
|
||
- 展示是否存在冲突
|
||
- 展示已填入的注册申报表格或对照清单字段
|
||
- 展示是否已生成新的 Word 文档
|
||
- 展示导出入口
|
||
|
||
输出结果不仅要展示回填数据，还应明确展示“已自动填入注册申报表格 / 对照清单”“已按模板生成可直接报送版 Word”及其导出入口。
|
||
|
||
### 7.5 飞书端结果展示
|
||
|
||
飞书端至少应能展示：
|
||
|
||
- 当前任务名称
|
||
- 结果摘要
|
||
- 风险等级
|
||
- 关键缺失项或冲突项
|
||
- 责任人通知结果
|
||
- Web 详情页或导出文件链接
|
||
|
||
### 7.6 风险提示
|
||
|
||
风险输出不应混在普通回答里，建议单独展示：
|
||
|
||
- 风险等级
|
||
- 风险类型
|
||
- 涉及文档
|
||
- 问题描述
|
||
- 建议动作
|
||
- 是否需人工复核
|
||
|
||
## 8. 页面展示要求
|
||
|
||
### 8.1 结果要适合讲解
|
||
|
||
复试场景下，页面展示必须清楚，不适合只显示一个 JSON。建议将结果拆成几个清晰区块：
|
||
|
||
- 执行摘要
|
||
- 结构化结果
|
||
- 证据引用
|
||
- 工具调用记录
|
||
- 风险预警
|
||
- 审计入口
|
||
|
||
### 8.2 异常提示要业务化
|
||
|
||
不能只提示“调用失败”。应该尽量说明：
|
||
|
||
- 当前无可用文档
|
||
- 资料未完成入库
|
||
- 未找到目标章节点资料
|
||
- 字段抽取结果存在冲突，需人工确认
|
||
- 法规规则未配置，无法执行完整性检查
|
||
|
||
### 8.3 支持“只看选中文档”
|
||
|
||
当前测试已覆盖按文档 ID 传递范围，这在本题里非常有用。因为注册审核人员往往只想检查某一章或某几个文件。
|
||
|
||
## 9. 结果可信度与人工复核
|
||
|
||
本题不应把系统塑造成“自动替代注册专员”的黑盒工具，因此 Chat 页面必须支持“需人工复核”的输出状态。
|
||
|
||
适合标记人工复核的情况包括：
|
||
|
||
1. 文档抽取失败或疑似扫描件。
|
||
2. 字段在不同文档中出现冲突。
|
||
3. 章节归类不确定。
|
||
4. 规则无法直接判断是否缺失。
|
||
5. 审核范围界定不清，无法确认哪些资料属于同一项目批次。
|
||
|
||
## 10. 与其他模块的边界
|
||
|
||
### 10.1 与 Scenarios 模块
|
||
|
||
Scenarios 定义任务入口，Chat 承担任务执行界面。
|
||
|
||
### 10.2 与 Documents 模块
|
||
|
||
Documents 提供资料和元数据，Chat 负责让用户选择资料并展示结果。
|
||
|
||
### 10.3 与 Agent Core 模块
|
||
|
||
Agent Core 生成审核结果，Chat 只负责参数组织和结果呈现，不负责规则实现。
|
||
|
||
### 10.4 与 Audit 模块
|
||
|
||
Chat 是大多数审计记录的触发入口，应把每次关键执行与审计日志关联起来。
|
||
|
||
## 11. 当前代码基线下的重构建议
|
||
|
||
### 11.1 建议保留
|
||
|
||
- 用户输入表单和提交流程
|
||
- 结构化结果、引用片段、工具调用展示能力
|
||
- 审计入口跳转
|
||
- 选中文档范围传递机制
|
||
|
||
### 11.2 建议增强
|
||
|
||
1. 从“通用对话页”升级为“注册审核工作台”。
|
||
2. 增加任务上下文展示和建议操作模板。
|
||
3. 增加字段回填视图和风险清单视图。
|
||
4. 增加资料范围、章节点范围选择。
|
||
5. 增加人工复核标记的展示。
|
||
|
||
## 12. 验收标准
|
||
|
||
本模块验收时，应达到以下状态：
|
||
|
||
1. 用户能清楚知道当前执行的是哪项注册审核任务。
|
||
2. 结果输出同时包含自然语言总结和结构化内容。
|
||
3. 能查看引用证据、风险项和工具调用过程。
|
||
4. 能基于选中文档或章节点做定向审核。
|
||
5. 对失败、冲突和不确定情况给出清楚的人工复核提示。
|