8.4 KiB
Chat 模块需求分析
1. 模块定位
apps.chat 在当前项目中是用户输入问题并查看 Agent 返回结果的页面。对于本题，它依然是核心交互入口，但定位需要从“自由问答页面”升级为：
注册申报审核工作台
也就是说，Chat 模块不只是让用户随便问一句话，而是要承接“选择任务、限定资料范围、发起审核、查看结构化结论、查看证据和建议”的完整操作流程。
2. 模块目标
本模块需要实现以下目标：
- 为注册审核人员提供统一的任务执行入口。
- 让用户能明确知道自己当前在执行哪类审核任务。
- 让系统输出不仅有自然语言回答，还有结构化结论、引用证据、回填字段、风险建议。
- 保证结果可追溯、可解释、可复核，而不是只给一个“大模型说了什么”。
- 支持通过 Web 工作台与飞书入口两类方式访问智能体、触发审核和查看结果，并保证核心流程可在飞书内闭环完成。
3. 为什么 Chat 模块仍然必要
虽然本题也可以做成一组固定报表，但保留 Chat / 工作台交互有三个价值：
- 复试演示更直观，容易展示 Agent 的编排能力。
- 用户可以用自然语言提出临时核查要求，例如“只检查 CH1 监管信息”“比较说明书和申请表中的产品名称是否一致”。
- Chat 页面可以作为多个任务的统一结果承载层，而不需要为每个任务都单独写一套复杂页面。
4. 交互定位建议
4.1 不建议保持纯聊天式体验
如果只保留一个输入框，让用户手工描述所有操作，体验会过于依赖 prompt，不像一个业务系统。
建议采用“任务工作台 + 辅助对话”的模式，页面中同时提供：
- 当前任务名称
- 输入问题框
- 资料范围选择
- 建议提问模板
- 结构化结果区
- 证据引用区
- 风险列表区
- 审计入口
4.2 建议突出“任务上下文”
用户进入页面后，应明确看到：
- 当前任务是什么
- 当前使用了哪些资料
- 当前是否启用了法规规则
- 当前是否启用了字段池 / RAG / 工具
这对复试讲解非常重要，因为它能体现系统是“受控执行”而不是“随便问模型”。
5. 典型使用场景
5.1 发起完整性检查
用户输入类似：
- “检查当前上传资料是否满足第 1 章监管信息要求”
- “列出 CH1 缺失文件和风险等级”
系统返回：
- 已识别文件数
- 命中法规目录项
- 缺失项清单
- 错放项清单
- 处理建议
5.2 发起字段抽取
用户输入类似：
- “从说明书和产品列表抽取产品名称、规格、靶标、适用范围、储存条件”
系统返回：
- 统一字段表
- 字段来源文档
- 置信度或待确认状态
- 可回填目标字段
5.3 发起一致性核查
用户输入类似：
- “检查申请表、说明书、产品列表里的产品名称和规格是否一致”
系统返回：
- 一致字段
- 冲突字段
- 冲突来源
- 判定依据
- 建议处理动作
5.4 发起综合风险报告
用户输入类似：
- “生成本批申报资料的综合风险预警”
系统返回：
- 风险摘要
- 高优先级问题
- 待补文件
- 需人工确认事项
- 建议整改顺序
6. 输入层需求
6.1 用户输入类型
本模块应支持三类输入：
- 自然语言问题
- 结构化参数选择
- 资料范围选择
6.2 结构化参数选择
建议用户在页面上可选：
- 审核任务类型
- 资料章节点范围
- 指定文档范围
- 输出模式
输出模式可包括：
- 简洁结论
- 结构化清单
- 回填字段视图
- 风险报告视图
6.3 建议提示词模板
页面上可给出快捷操作示例，例如：
- “汇总当前资料目录及页数”
- “检查 CH1 监管信息是否齐套”
- “抽取说明书中的核心产品信息”
- “检查说明书与申请表是否一致”
这样能降低演示时的自由输入风险。
6.4 飞书访问入口
飞书交互不应只是消息转发，而应支持在飞书内完成关键流程。交互设计上至少应纳入以下能力：
- 通过飞书消息或群聊机器人入口触发某个审核任务。
- 在飞书内完成任务选择、结果查看和责任人通知。
- 支持手动维护后的责任人 / 飞书账号映射生效。
飞书开放平台接入路线中，群聊机器人属于 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 页面必须支持“需人工复核”的输出状态。
适合标记人工复核的情况包括：
- 文档抽取失败或疑似扫描件。
- 字段在不同文档中出现冲突。
- 章节归类不确定。
- 规则无法直接判断是否缺失。
- 审核范围界定不清，无法确认哪些资料属于同一项目批次。
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 建议增强
- 从“通用对话页”升级为“注册审核工作台”。
- 增加任务上下文展示和建议操作模板。
- 增加字段回填视图和风险清单视图。
- 增加资料范围、章节点范围选择。
- 增加人工复核标记的展示。
12. 验收标准
本模块验收时，应达到以下状态：
- 用户能清楚知道当前执行的是哪项注册审核任务。
- 结果输出同时包含自然语言总结和结构化内容。
- 能查看引用证据、风险项和工具调用过程。
- 能基于选中文档或章节点做定向审核。
- 对失败、冲突和不确定情况给出清楚的人工复核提示。