wecom_it_smart_desk/docs/01-产品文档/03-AI服务/PRD-REQ-AI-001-复杂场景与统一路由-v1.1.md

# IT智能服务台 - 复杂场景重构与统一路由 PRD（合并版）

**版本**：v1.2
**日期**：2026-07-27
**状态**：已评审
**作者**：许清楚
**子系统**：03-AI服务
**模块**：意图路由

---

## 一、文档变更记录

| 版本 | 日期 | 变更说明 |
|------|------|----------|
| v1.2 | 2026-07-27 | 新增4.1.1 打招呼检测规则：解决"您好+具体问题"被误判为纯打招呼的问题 |
| v1.1 | 2026-07-19 | 完成7个待确认问题的决策：<br>- 暂停超时阈值：可配置，默认8小时<br>- 可更正字段：按类型区分<br>- 压缩阈值：可配置，默认6000 tokens<br>- 撤销次数：默认3次<br>- 依赖关系：仅记录来源<br>- 业务类别：预设+管理员添加<br>- 路由置信度：可配置，默认0.7 |
| v1.0 | 2026-07-19 | 初始合并版本，整合以下文档：<br>- 复杂场景重构第一阶段<br>- 复杂场景重构第二阶段<br>- 业务路由推荐<br>- 统一意图路由层 |

---

## 二、产品目标

| # | 目标 | 衡量指标 |
|---|------|----------|
| G1 | **任务可中断、可恢复** — 员工因临时事务离开时，自动化处置流程不丢失，回来后一句话即可继续 | 暂停会话恢复成功率 ≥ 95%；恢复后无需重新输入已提供信息 |
| G2 | **信息可更正、可补充** — 员工说错或想补充信息时，系统能正确理解并更新，不重复询问已修正的信息 | 更正意图识别准确率 ≥ 90%；更正后信息项值正确更新率 ≥ 95% |
| G3 | **坐席可感知** — 坐席工作台能实时看到会话的暂停/恢复/更正事件，掌握员工处置进度 | 坐席端可查看暂停会话列表及恢复点信息；更正事件在会话时间线可见 |
| G4 | **长对话不中断** — 长对话场景下 AI 不因 token 超限而中断或丢失关键信息 | 超长会话（>6000 tokens）AI 正常响应率 ≥ 99%；关键信息项零丢失 |
| G5 | **多轮纠错** — 员工可在同一会话中多次更正/补充信息，系统自动维护版本与依赖 | 单 session 支持无限次更正；依赖联动提示准确率 ≥ 95% |
| G6 | **透明体验** — 压缩与多轮纠错对员工透明，不增加操作负担 | 员工无额外操作步骤；压缩过程用户无感知 |

---

## 三、用户故事

### 3.1 任务中断恢复

| # | 角色 | 用户故事 |
|---|------|----------|
| US-1 | 员工 | **As a** 员工, **I want** 在自动化处置过程中说"我先去开会"就能暂停任务, **so that** 我不用急急忙忙处理完，也不用担心中途离开导致流程丢失 |
| US-2 | 员工 | **As a** 员工, **I want** 回来后说"继续刚才的"就能从断点恢复, **so that** 我不需要重新描述问题、重新提供已填的信息 |
| US-3 | 员工 | **As a** 员工, **I want** 暂停后如果有多个未完成的任务，系统能提示我选择恢复哪个, **so that** 我不会搞混多个处置流程 |
| US-4 | 坐席 | **As a** 坐席, **I want** 在工作台看到员工会话的暂停/恢复状态和更正记录, **so that** 我能了解处置进度的完整上下文，在需要介入时不会信息缺失 |
| US-5 | 坐席 | **As a** 坐席, **I want** 能手动恢复或终止员工暂停过久的会话, **so that** 避免暂停任务长期堆积占用资源 |

### 3.2 信息更正与补充

| # | 角色 | 用户故事 |
|---|------|----------|
| US-6 | 员工 | **As a** 员工, **I want** 当我说错信息后（如用户名说成 zhangsan 实际是 lisi），系统自动更正, **so that** 不会因为口误导致处置结果错误 |
| US-7 | 员工 | **As a** 员工, **I want** 能随时补充额外信息（如"顺便说一下，是财务部的电脑"）, **so that** 系统掌握更完整的信息来精准处置 |
| US-8 | 员工 | **As a** 员工, **I want** 在对话过程中可以多次更正不同信息项（先更正工号，再更正设备型号），每次更正都被完整记录 |
| US-9 | 员工 | **As a** 员工, **I want** 更正某个信息项后，系统能提示我哪些关联信息需要一并更新，避免信息不一致 |
| US-10 | 员工 | **As a** 员工, **I want** 如果我更正错了，我可以撤销最近一次更正，恢复到更正前的状态 |
| US-11 | 坐席 | **As a** 坐席, **I want** 能在坐席端查看完整的信息项版本链，并对比任意两个版本的差异，以便快速理清员工多次更正的脉络 |

### 3.3 上下文压缩

| # | 角色 | 用户故事 |
|---|------|----------|
| US-12 | 员工 | **As a** 员工, **I want** 在超长对话中 AI 依然记得我之前提交的关键信息（如工号、申请事由），这样我不必反复重复 |
| US-13 | 员工 | **As a** 员工, **I want** 长对话被"智能记忆"后仍能继续正常审批与执行流程，不会因为对话太长而收到错误或中断 |
| US-14 | 运维 | **As a** 运维人员, **I want** 能够查看每次上下文压缩的日志记录，这样在 AI 行为异常时可以定位是否与压缩有关 |

### 3.4 业务路由

| # | 角色 | 用户故事 |
|---|------|----------|
| US-15 | 员工 | **As a** 员工, **I want** 当我咨询非IT业务时，系统能帮我转接到对应业务负责人, **so that** 我能得到正确的帮助 |
| US-16 | 坐席 | **As a** 坐席, **I want** 能看到业务路由的日志记录, **so that** 在需要时能追溯路由决策 |

---

## 四、架构总览

### 2.1 整体架构

```
用户消息到达
      │
      ├──→ 并行执行：
      │         ├── 控制意图识别（第0层）
      │         │         └── PAUSE/RESUME/CORRECT/SUPPLEMENT
      │         │                   │
      │         │                   └── 命中 → 优先处理控制逻辑
      │         │
      │         └── 业务意图识别（第1层）
      │                   └── approval/it_consult/non_it_routing/chitchat
      │                             │
      │                             └── 正常业务路由
      │
      ▼
消息合并器（单队列输出）
      │
      ▼
响应用户
```

### 2.2 分层说明

| 层级 | 名称 | 职责 | 响应目标 |
|------|------|------|----------|
| 第0层 | 控制意图层 | 识别PAUSE/RESUME/CORRECT/SUPPLEMENT | 优先级最高，秒级响应 |
| 第1层 | 业务意图层 | 识别approval/it_consult/non_it_routing/chitchat | 毫秒级响应 |
| 第2层 | 动态信息与诊断链 | 信息更正/版本链/排查步骤联动 | 版本变化触发重算 |

---

## 三、第0层：控制意图层

### 3.1 意图类型

| 意图 | 说明 | 响应目标 |
|------|------|----------|
| PAUSE | 用户主动暂停会话 | 立即响应，保存上下文 |
| RESUME_TASK | 用户恢复暂停的会话 | 立即响应，恢复进度 |
| CORRECT | 用户更正之前的信息 | 记录变更，触发版本链，联动排查步骤 |
| SUPPLEMENT | 用户补充缺失的信息 | 记录补充，触发版本链，联动排查步骤 |

### 3.2 设计原则

1. **并行识别**：控制意图识别与业务意图识别并行执行，互不阻塞
2. **优先级规则**：控制意图 > 业务意图
3. **消息合并**：同一轮对话只产出一条最终响应，避免多队列问题

### 3.3 场景示例

```
场景1：用户暂停
用户：先去开会，稍后继续
系统：好的，您先忙～需要继续时跟我说一声「继续」就好。当前进度：{步骤描述}

场景2：用户恢复
用户：继续
系统：欢迎回来！您之前在处理「{会话标题}」，当前进度：{步骤描述}，我们继续吧～

场景3：用户更正
用户：抱歉，部门写错了，我是财务部的
系统：[记录更正] + [更新版本链] + [重新计算排查步骤]
     「好的，已更新为财务部。根据您的情况，建议重新排查以下步骤：...」

场景4：用户补充
用户：对了，电脑是台式机
系统：[记录补充] + [更新版本链] + [重新计算排查步骤]
     「好的，已记录。根据新信息，更新排查步骤如下：...」
```

---

## 四、第1层：业务意图层

### 4.1 意图类型

| 意图 | 说明 | 后续流程 |
|------|------|----------|
| approval | 审批需求 | 推送审批卡片 |
| it_consult | IT咨询 | 进入排查流程 |
| non_it_routing | 非IT业务 | 路由到业务联系人 |
| chitchat | 闲聊/打招呼 | 友好回复，不调用AI推理 |

#### 4.1.1 打招呼检测规则

为避免无意义的AI调用，系统在进入意图识别前会先进行打招呼检测：

- **纯打招呼**（如"你好"、"您好"、"hi"）→ 返回欢迎语，**不调用AI**
- **打招呼+实质问题**（如"您好，我电脑开不了机"）→ 跳过打招呼检测，继续意图识别

**技术实现**：`ai_handler.py` 的 `is_greeting()` 方法

```python
# 伪代码示意
def is_greeting(content):
    # 如果消息包含实质性问题关键词，不视为打招呼
    substantive_keywords = ["绑定", "连不上", "报错", "无法", "打印机", ...]
    if any(kw in content for kw in substantive_keywords):
        return False

    # 纯打招呼关键词检测
    greeting_keywords = ["你好", "您好", "hi", "hello", ...]
    is_greet = any(kw in content for kw in greeting_keywords)

    # 纯打招呼且消息足够短才触发
    return is_greet and len(content) <= 15
```

### 4.2 路由分层决策

| 层级 | 方法 | 适用场景 |
|------|------|----------|
| 第1层 | 本地规则 | 关键词匹配、常用语 |
| 第2层 | 知识图谱 | 实体识别、业务关联 |
| 第3层 | Dify | 复杂意图、多轮对话 |

### 4.3 业务路由联动

当用户更正信息（如部门）时，联动更新业务路由配置：

| 信息项 | 联动字段 | 说明 |
|--------|----------|------|
| 部门 | service_area | 业务路由的服务范围 |
| 姓名 | contact_name | 业务联系人姓名 |

**联动规则**：
1. 用户更正 → 信息项更新 → 触发业务路由同步
2. 优先级：人工配置 > 自动更正
3. 记录audit log，便于追溯

---

## 五、动态信息与诊断链（核心模块）

### 5.1 模块定位

本模块整合三个强耦合的功能：

1. **信息更正/补充** - 记录用户更正和补充的信息
2. **版本链** - 维护信息项的版本历史
3. **排查步骤** - 根据当前版本信息动态生成排查流程

### 5.2 核心设计原则

**版本变化触发排查步骤重新计算**：

```
用户更正/补充信息
       │
       ▼
版本链记录变更（新增版本快照）
       │
       ▼
触发排查步骤重新计算
       │    │
       │    ├── 重置diagnosis_stage到initial
       │    │
       │    └── 根据新版本信息重新生成排查流程
       │
       ▼
展示更新后的排查步骤
```

### 5.3 数据模型

#### InformationItem（信息项表）

| 字段 | 类型 | 说明 |
|------|------|------|
| session_id | UUID | 会话ID |
| name | String | 信息项名称 |
| value | String | 信息项值 |
| modifiers | Array | 修饰词 |
| is_filled | Boolean | 是否已填写 |
| version | Integer | 版本号 |
| derived_from | String | 推导来源 |
| correction_reason | String | 更正备注 |
| update_history | JSON | 更新历史 |
| updated_at | Timestamp | 更新时间 |

#### 版本快照

每次信息变更时，生成版本快照：
- 快照内容：当前所有信息项的值
- 快照关联：当前diagnosis_stage状态

### 5.4 排查步骤联动

| 触发条件 | 排查步骤行为 |
|---------|-------------|
| 用户更正信息 | 自动重新触发排查步骤 |
| 坐席切换版本 | 自动重新触发排查步骤 |
| 坐席撤销更正 | 回滚到上一版本 + 重新触发排查步骤 |

**diagnosis_stage重置规则**：
- 当版本切换时，diagnosis_stage重置为`initial`
- 重新进入gathering_info阶段收集信息

### 5.5 版本链可视化

| 功能 | 说明 |
|------|------|
| 时间线展示 | 按时间顺序展示信息项变更记录 |
| diff对比 | 版本间差异对比 |
| 撤销恢复 | 坐席可回滚到历史版本 |

---

## 六、上下文压缩

### 6.1 触发条件

当对话token超过8000阈值时，触发上下文压缩。

### 6.2 压缩策略

| 策略 | 说明 |
|------|------|
| Token阈值检测 | 监控对话总token数 |
| 压缩摘要 | 将早期消息压缩为摘要 |
| 快照保存 | 保留完整版本快照 |

### 6.3 推送策略

**不进行实时WebSocket推送**。

原因：
1. 压缩对用户无感知，界面无变化
2. 减少消息干扰
3. 可通过AI回复自然提及

**替代方案**：
- AI在回复中可自然提及："由于对话较长，我简化了早期上下文，如有需要请提醒我补充"

---

## 七、WS事件定义

### 7.1 控制意图事件

| 事件名 | 说明 | 载荷 |
|--------|------|------|
| automation.paused | 会话已暂停 | session_id, resume_point, step_description |
| automation.resumed | 会话已恢复 | session_id, resume_point, step_description |
| automation.timeout_closed | 暂停超时关闭 | session_id, timeout_duration |
| automation.info_corrected | 信息已更正 | session_id, item_name, old_value, new_value, new_version |
| automation.info_supplemented | 信息已补充 | session_id, item_name, new_value, new_version |

### 7.2 事件推送规则

- 所有事件通过WebSocket推送
- 消息合并器确保单队列输出
- 同一轮对话只推送一条消息

---

## 八、非目标（Non-Goals）

本PRD**不包含**以下内容：

1. ~~控制意图的WebSocket实时推送~~（由AI回复承载）
2. ~~上下文压缩的实时推送~~（对用户透明）
3. ~~时间线与版本链的分离设计~~（已整合为动态信息与诊断链）
4. ~~信息更正与业务路由的解耦~~（需要联动）

---

## 九、已确认配置参数

| 问题 | 结论 | 说明 |
|------|------|------|
| Q1: 暂停超时阈值 | **可配置，默认8小时** | 支持管理员调整，建议超时前15分钟提醒 |
| Q2: 可更正/不可更正字段 | **按字段类型区分** | 可编辑：用户相关字段（部门、工号等）；只读：会话元数据、AI生成字段 |
| Q3: 上下文压缩阈值 | **可配置，默认6000 tokens** | 支持管理员调整 |
| Q4: 更正撤销次数限制 | **默认3次** | 防止滥用，控制版本链复杂度 |
| Q5: 信息项依赖关系 | **仅记录来源** | 使用derived_from字段记录推导来源，不自动推导 |
| Q6: 业务类别清单 | **预设+管理员添加** | 预设常见类别，支持管理员动态添加 |
| Q7: routing_confidence阈值 | **可配置，全局默认0.7** | 支持不同业务类别不同阈值 |

---

## 十、附录

### 10.1 文档来源

- 复杂场景重构第一阶段-增量PRD.md（已整合）
- 复杂场景重构第二阶段-增量PRD.md（已整合）
- ht-zx-ly-业务路由推荐-PRD-V2.1.1.md（已整合）
- 统一意图路由层PRD.md（已整合）

### 10.3 关联技术文档

| 文件 | 说明 |
|------|------|
| `02-技术文档/实现配置/dify_main_chat_prompt_v1.3_D1合并.md` | Dify主对话Prompt配置 |
| `02-技术文档/实现配置/dify_main_chat_prompt_v1.md` | Dify主对话Prompt v1 |
| `02-技术文档/实现配置/dify_unified_intent_prompt_v3.md` | 统一意图Prompt |
| `02-技术文档/实现配置/dify_approval_system_prompt_v2.md` | 审批系统Prompt |
| `02-技术文档/实现配置/dify_byod_intent_prompt.md` | BYOD意图Prompt |
| `02-技术文档/实现配置/AI对话链路全栈改造实施计划-v1.0.md` | 实施计划 |
| `02-技术文档/实现配置/Dify_App改造与AI供给链路修复方案-v1.0.md` | 修复方案 |
| `02-技术文档/实现配置/approval_templates.json` | 审批模板配置 |

### 10.4 原型设计

| 文件 | 说明 |
|------|------|
| `04-原型设计/01-员工端-暂停恢复.html` | 员工端暂停/恢复交互（已参考prototypes-原型图设计风格） |
| `04-原型设计/02-坐席端-版本链.html` | 坐席端版本链可视化与Diff对比 |
| `04-原型设计/03-坐席端-业务路由.html` | 坐席端业务路由分发（待参考现有原型） |
| `04-原型设计/04-坐席端-排查步骤联动.html` | 坐席端排查步骤与版本联动（待参考现有原型） |

### 10.4 关键决策记录

| 决策项 | 结论 | 日期 |
|--------|------|------|
| 全局意图定位 | 第0层（最高优先级），并行识别 | 2026-07-19 |
| 信息更正与业务路由联动 | 需要联动 | 2026-07-19 |
| 上下文压缩推送 | 不需要实时推送 | 2026-07-19 |
| 时间线/版本链/排查步骤 | 合并为"动态信息与诊断链"模块 | 2026-07-19 |
| 暂停超时阈值 | 可配置，默认8小时 | 2026-07-19 |
| 可更正字段区分 | 按字段类型区分 | 2026-07-19 |
| 上下文压缩阈值 | 可配置，默认6000 tokens | 2026-07-19 |
| 更正撤销次数限制 | 默认3次 | 2026-07-19 |
| 信息项依赖关系 | 仅记录来源 | 2026-07-19 |
| 业务类别清单 | 预设+管理员添加 | 2026-07-19 |
| routing_confidence阈值 | 可配置，默认0.7 | 2026-07-19 |

---

## 十一、验收标准

### 11.1 任务中断恢复

| ID | 验收标准 |
|----|----------|
| AC-US-1 | 员工说"先去开会"等关键词时，系统暂停会话并返回确认消息 |
| AC-US-2 | 暂停后员工说"继续"，系统恢复会话并展示之前进度 |
| AC-US-3 | 多个暂停会话时，系统展示选择列表供员工选择恢复哪一个 |
| AC-US-4 | 坐席端可查看所有暂停会话列表及恢复点信息 |
| AC-US-5 | 暂停超过8小时未恢复，系统自动关闭并通知员工 |

### 11.2 信息更正与补充

| ID | 验收标准 |
|----|----------|
| AC-US-6 | 员工更正信息时，系统正确识别CORRECT意图并更新信息项 |
| AC-US-7 | 员工补充信息时，系统正确识别SUPPLEMENT意图并新增信息项 |
| AC-US-8 | 更正/补充后，系统自动触发排查步骤重新计算 |
| AC-US-9 | 坐席端可查看信息项的版本时间线 |
| AC-US-10 | 坐席端可对比任意两个版本的差异（diff） |
| AC-US-11 | 员工可撤销最近一次更正（限制3次） |
| AC-US-12 | 撤销后，系统回滚到上一版本并重新计算排查步骤 |

### 11.3 上下文压缩

| ID | 验收标准 |
|----|----------|
| AC-US-13 | 当token超过6000阈值时，系统自动触发压缩 |
| AC-US-14 | 压缩后AI仍能正确回答"我之前填的工号是多少"等回溯问题 |
| AC-US-15 | 压缩过程对用户透明，无额外操作步骤 |
| AC-US-16 | 运维可查看压缩日志（保留90天） |

### 11.4 业务路由

| ID | 验收标准 |
|----|----------|
| AC-US-17 | 员工咨询非IT业务时，系统识别为non_it_routing意图 |
| AC-US-18 | 系统根据业务类别路由到对应联系人 |
| AC-US-19 | routing_confidence低于0.7时，不自动路由 |

---

*文档结束*