# IT智能服务台 - 复杂场景重构与统一路由 PRD(合并版)
**版本**:v1.2
**日期**:2026-07-27
**状态**:已评审
**作者**:许清楚
**子系统**:03-AI服务
**模块**:意图路由
---
## 一、文档变更记录
| 版本 | 日期 | 变更说明 |
|------|------|----------|
| v1.2 | 2026-07-27 | 新增4.1.1 打招呼检测规则:解决"您好+具体问题"被误判为纯打招呼的问题 |
| v1.1 | 2026-07-19 | 完成7个待确认问题的决策:
- 暂停超时阈值:可配置,默认8小时
- 可更正字段:按类型区分
- 压缩阈值:可配置,默认6000 tokens
- 撤销次数:默认3次
- 依赖关系:仅记录来源
- 业务类别:预设+管理员添加
- 路由置信度:可配置,默认0.7 |
| v1.0 | 2026-07-19 | 初始合并版本,整合以下文档:
- 复杂场景重构第一阶段
- 复杂场景重构第二阶段
- 业务路由推荐
- 统一意图路由层 |
---
## 二、产品目标
| # | 目标 | 衡量指标 |
|---|------|----------|
| 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时,不自动路由 |
---
*文档结束*