docs: 重构真实题目下的需求与资料文档体系

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

@@ -0,0 +1,282 @@
+# Chat 模块需求分析
+
+## 1. 模块定位
+
+`apps.chat` 在当前项目中是用户输入问题并查看 Agent 返回结果的页面。对于本题，它依然是核心交互入口，但定位需要从“自由问答页面”升级为：
+
+> 注册申报审核工作台
+
+也就是说，Chat 模块不只是让用户随便问一句话，而是要承接“选择任务、限定资料范围、发起审核、查看结构化结论、查看证据和建议”的完整操作流程。
+
+## 2. 模块目标
+
+本模块需要实现以下目标：
+
+1. 为注册审核人员提供统一的任务执行入口。
+2. 让用户能明确知道自己当前在执行哪类审核任务。
+3. 让系统输出不仅有自然语言回答，还有结构化结论、引用证据、回填字段、风险建议。
+4. 保证结果可追溯、可解释、可复核，而不是只给一个“大模型说了什么”。
+
+## 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 监管信息是否齐套”
+- “抽取说明书中的核心产品信息”
+- “检查说明书与申请表是否一致”
+
+这样能降低演示时的自由输入风险。
+
+## 7. 输出层需求
+
+### 7.1 自然语言结论
+
+仍然需要保留总体回答，用于快速概括结果。
+
+### 7.2 结构化结果
+
+结构化结果是本题的重点，建议至少支持以下几类：
+
+- 目录汇总结果
+- 完整性检查结果
+- 字段抽取结果
+- 一致性核查结果
+- 风险预警结果
+
+### 7.3 引用证据
+
+每个关键结论尽量附带来源，例如：
+
+- 来源文档名
+- 来源章节
+- 引用片段
+- 引用页码或位置
+
+对于法规完整性核查，还应尽量附带命中的法规条目或模板条目。
+
+### 7.4 回填结果展示
+
+对于“自动填写至目标文件”的题面要求，Chat 页面建议至少支持：
+
+- 展示待回填字段
+- 展示字段值
+- 展示来源文档
+- 展示是否存在冲突
+
+即便首版不直接写回 Word 文件，也应把“可回填结果”明确展示出来。
+
+### 7.5 风险提示
+
+风险输出不应混在普通回答里，建议单独展示：
+
+- 风险等级
+- 风险类型
+- 涉及文档
+- 问题描述
+- 建议动作
+- 是否需人工复核
+
+## 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. 对失败、冲突和不确定情况给出清楚的人工复核提示。