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个待确认问题的决策： - 暂停超时阈值：可配置，默认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() 方法

# 伪代码示意
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时，不自动路由

---

文档结束