docs(需求分析): 按Agent原型重写核心需求

docs/需求分析/4.chat模块需求分析.md

@@ -2,307 +2,153 @@
 
 ## 1. 模块定位
 
-`apps.chat` 在当前项目中是用户输入问题并查看 Agent 返回结果的页面。对于本题，它依然是核心交互入口，但定位需要从“自由问答页面”升级为：
+`apps.chat` 已从传统“问答页面”升级为：
 
-> 注册申报审核工作台
+> 审核智能体工作台
 
-也就是说，Chat 模块不只是让用户随便问一句话，而是要承接“选择任务、限定资料范围、发起审核、查看结构化结论、查看证据和建议”的完整操作流程。
+它是 V1 的主入口，负责把资料包、对话、任务模板、节点结果、结构化结论、飞书通知结果串成一个完整的人机协作界面。
 
 ## 2. 模块目标
 
 本模块需要实现以下目标：
 
-1. 为注册审核人员提供统一的任务执行入口。
-2. 让用户能明确知道自己当前在执行哪类审核任务。
-3. 让系统输出不仅有自然语言回答，还有结构化结论、引用证据、回填字段、风险建议。
-4. 保证结果可追溯、可解释、可复核，而不是只给一个“大模型说了什么”。
-5. 支持通过 Web 工作台与飞书入口两类方式访问智能体、触发审核和查看结果，并保证核心流程可在飞书内闭环完成。
+1. 让用户通过对话发起审核任务。
+2. 让对话始终绑定到具体资料包和具体产品名称。
+3. 让任务结果按节点展示，而不是只返回一段自然语言。
+4. 让用户能直接看到 RAG 命中的法规依据、风险摘要和导出建议。
+5. 支持执行完成或异常后触发飞书 `@` 处理人。
 
-## 3. 为什么 Chat 模块仍然必要
+## 3. 页面形态要求
 
-虽然本题也可以做成一组固定报表，但保留 Chat / 工作台交互有三个价值：
+基于最新版原型，Chat 模块页面形态固定为三栏：
 
-1. 复试演示更直观，容易展示 Agent 的编排能力。
-2. 用户可以用自然语言提出临时核查要求，例如“只检查 CH1 监管信息”“比较说明书和申请表中的产品名称是否一致”。
-3. Chat 页面可以作为多个任务的统一结果承载层，而不需要为每个任务都单独写一套复杂页面。
+### 3.1 左栏：对话历史
 
-## 4. 交互定位建议
+1. 按资料包会话展示历史记录。
+2. 会话名称直接使用解析后的产品名称。
+3. 会话至少显示时间、状态、摘要。
+4. 点击会话可切换当前资料包上下文。
 
-### 4.1 不建议保持纯聊天式体验
+### 3.2 中栏：主对话区
 
-如果只保留一个输入框，让用户手工描述所有操作，体验会过于依赖 prompt，不像一个业务系统。
+1. 展示欢迎区、推荐提示词和节点导航。
+2. 展示用户消息、Agent 计划、节点结果和最终结论。
+3. 支持节点点击跳转。
+4. 支持底部输入框继续追问。
 
-建议采用“任务工作台 + 辅助对话”的模式，页面中同时提供：
+### 3.3 右栏：上传栏 + 功能卡片
 
-- 当前任务名称
-- 输入问题框
-- 资料范围选择
-- 建议提问模板
-- 结构化结果区
-- 证据引用区
-- 风险列表区
-- 审计入口
+1. 上半区展示上传资料入口和当前会话已上传附件。
+2. 下半区展示能力卡片。
+3. 能力卡片随任务模板变化展示不同内容。
 
-### 4.2 建议突出“任务上下文”
+## 4. 关键业务约束
 
-用户进入页面后，应明确看到：
+### 4.1 对话必须绑定资料包
 
-- 当前任务是什么
-- 当前使用了哪些资料
-- 当前是否启用了法规规则
-- 当前是否启用了字段池 / RAG / 工具
+用户不能在无上下文状态下执行审核。每次任务都应绑定：
 
-这对复试讲解非常重要，因为它能体现系统是“受控执行”而不是“随便问模型”。
+1. `conversation_id`
+2. `batch_id`
+3. `product_name`
+4. `document_scope`
 
-## 5. 典型使用场景
+### 4.2 对话名称必须来源于解析结果
 
-### 5.1 发起完整性检查
+会话标题默认使用资料包解析出的产品名称，而不是“新对话”或“注册批次审核主线”。
 
-用户输入类似：
+### 4.3 结果必须结构化
 
-- “检查当前上传资料是否满足第 1 章监管信息要求”
-- “列出 CH1 缺失文件和风险等级”
+Chat 模块至少要展示：
 
-系统返回：
+1. 目录汇总结果
+2. 完整性检查结果
+3. 字段抽取结果
+4. 一致性核查结果
+5. 风险结论
+6. 飞书通知结果
 
-- 已识别文件数
-- 命中法规目录项
-- 缺失项清单
-- 错放项清单
-- 处理建议
+## 5. 输入需求
 
-### 5.2 发起字段抽取
+### 5.1 输入类型
 
-用户输入类似：
+1. 自然语言任务指令
+2. 资料上传
+3. 节点模板选择
+4. 建议提示词点击
 
-- “从说明书和产品列表抽取产品名称、检测靶标、适用范围、储存条件、性能指标，并填入申报表或对照清单”
+### 5.2 建议提示词
 
-系统返回：
+V1 推荐固定提供：
 
-- 统一字段表
-- 字段来源文档
-- 置信度或待确认状态
-- 注册申报表格或对照清单的回填结果
-- 字段冲突时的拦截提示
+1. 自动汇总文件夹目录与页数
+2. 执行法规完整性检查
+3. 抽取字段并生成字段池
+4. 解释冲突字段原因
+5. 给出整改与导出建议
 
-### 5.3 发起一致性核查
+### 5.3 附件上传
 
-用户输入类似：
+Chat 模块中的上传不是独立附件功能，而是资料包流程的会话入口，因此上传后应自动触发：
 
-- “检查申请表、说明书、产品列表里的产品名称和规格是否一致”
+1. 资料包批次创建或追加
+2. 产品名称解析
+3. 对话上下文绑定
 
-系统返回：
+## 6. 输出需求
 
-- 一致字段
-- 冲突字段
-- 冲突来源
-- 判定依据
-- 建议处理动作
+### 6.1 节点式结果
 
-### 5.4 发起综合风险报告
+结果不能只有长文本，必须形成节点：
 
-用户输入类似：
+1. 目录汇总
+2. 完整性检查
+3. 字段抽取
+4. 风险结论
 
-- “生成本批申报资料的综合风险预警”
+### 6.2 RAG 依据展示
 
-系统返回：
+当 Agent 在对话中引用法规或业务依据时，应展示：
 
-- 风险摘要
-- 高优先级问题
-- 待补文件
-- 需人工确认事项
-- 建议整改顺序
+1. 依据来源文档
+2. 命中条款或切片标签
+3. 解释摘要
 
-## 6. 输入层需求
+### 6.3 飞书通知结果展示
 
-### 6.1 用户输入类型
+当执行完成或发生异常后，Chat 模块应能展示：
 
-本模块应支持三类输入：
+1. 是否已触发飞书通知
+2. 通知原因
+3. 被 `@` 的处理人
+4. Web 详情链接
+5. 发送状态或失败原因
 
-1. 自然语言问题
-2. 结构化参数选择
-3. 资料范围选择
+## 7. 飞书相关需求
 
-### 6.2 结构化参数选择
+Chat 模块需要消费角色信息中的飞书字段。责任人实体至少包含：
 
-建议用户在页面上可选：
+1. `owner_role`
+2. `owner_name`
+3. `feishu_user_id`
+4. `feishu_open_id`
+5. `feishu_name`
+6. `notify_enabled`
 
-- 审核任务类型
-- 资料章节点范围
-- 指定文档范围
-- 输出模式
+当前 Demo 通知策略固定为：
 
-输出模式可包括：
+1. 审核任务执行完成后，飞书摘要卡片 `@` 处理人。
+2. 审核任务执行异常后，飞书异常消息 `@` 处理人。
 
-- 简洁结论
-- 结构化清单
-- 回填字段视图
-- 风险报告视图
+## 8. 与其他模块边界
 
-### 6.3 建议提示词模板
+1. `documents` 提供资料包、产品名称、文件范围和目录事实。
+2. `agent_core` 提供任务编排、RAG 检索和结构化输出。
+3. `audit` 提供处理历史和通知留痕。
 
-页面上可给出快捷操作示例，例如：
+## 9. 验收标准
 
-- “汇总当前资料目录及页数”
-- “检查 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. 对失败、冲突和不确定情况给出清楚的人工复核提示。
+1. 用户能在一个会话中完成资料上传、任务发起和结果查看。
+2. 对话历史以产品名称展示，而不是泛化标题。
+3. 节点式结果、RAG 依据和飞书通知结果都能在页面上承载。
+4. 执行完成或异常的飞书通知逻辑有明确展示位和字段依赖。