# 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. 对失败、冲突和不确定情况给出清楚的人工复核提示。