复杂场景重构第一阶段 — 增量 PRD
版本: v1.0
日期: 2026-07-20
作者: 许清楚(产品经理)
状态: 待评审
关联文档: 重构方案-复杂场景技术方案.md v1.1 / IT智能服务台-系统架构设计文档v2.md §15.5
1. 项目信息
| 字段 |
值 |
| 项目名称 |
complex_scenario_phase1 |
| 技术栈 |
H5端: Vue3 + Vant4 / 坐席端: Vue3 + Element Plus / 后端: FastAPI + SQLAlchemy + PostgreSQL + Redis / AI: Dify |
| 语言 |
中文 |
| 阶段范围 |
P0 任务中断恢复 + P1 信息更正(不依赖 Neo4j,使用现有 PostgreSQL + Redis) |
原始需求复述
IT智能服务台已有完整的自动化引擎骨架(阶段5),AutoSession 模型定义了 paused 状态但无暂停/恢复逻辑,IntentRouter 仅识别4种场景类型意图、不支持全局对话控制意图。本阶段在此骨架上实现两个复杂对话场景:
- 任务中断与恢复(P0):员工在自动化处置流程中因离开/超时/主动暂停而中断,后续可以恢复继续之前的流程。
- 信息更正(P1):员工在对话中更正或补充之前提供的信息,系统理解更正意图并更新上下文。
2. 产品目标
| # |
目标 |
衡量标准 |
| G1 |
任务可中断、可恢复 — 员工因临时事务离开时,自动化处置流程不丢失,回来后一句话即可继续 |
暂停会话恢复成功率 ≥ 95%;恢复后无需重新输入已提供信息 |
| G2 |
信息可更正、可补充 — 员工说错或想补充信息时,系统能正确理解并更新,不重复询问已修正的信息 |
更正意图识别准确率 ≥ 90%;更正后信息项值正确更新率 ≥ 95% |
| G3 |
坐席可感知 — 坐席工作台能实时看到会话的暂停/恢复/更正事件,掌握员工处置进度 |
坐席端可查看暂停会话列表及恢复点信息;更正事件在会话时间线可见 |
3. 用户故事
| # |
角色 |
用户故事 |
| US-1 |
员工 |
As a 员工, I want 在自动化处置过程中说"我先去开会"就能暂停任务, so that 我不用急急忙忙处理完,也不用担心中途离开导致流程丢失 |
| US-2 |
员工 |
As a 员工, I want 回来后说"继续刚才的"就能从断点恢复, so that 我不需要重新描述问题、重新提供已填的信息 |
| US-3 |
员工 |
As a 员工, I want 当我说错信息后(如用户名说成 zhangsan 实际是 lisi),系统自动更正, so that 不会因为口误导致处置结果错误 |
| US-4 |
员工 |
As a 员工, I want 能随时补充额外信息(如"顺便说一下,是财务部的电脑"), so that 系统掌握更完整的信息来精准处置 |
| US-5 |
员工 |
As a 员工, I want 暂停后如果有多个未完成的任务,系统能提示我选择恢复哪个, so that 我不会搞混多个处置流程 |
| US-6 |
坐席 |
As a 坐席, I want 在工作台看到员工会话的暂停/恢复状态和更正记录, so that 我能了解处置进度的完整上下文,在需要介入时不会信息缺失 |
| US-7 |
坐席 |
As a 坐席, I want 能手动恢复或终止员工暂停过久的会话, so that 避免暂停任务长期堆积占用资源 |
4. 需求池(P0 / P1 / P2)
P0 — 必须完成(任务中断恢复核心)
P0-1 全局意图识别扩展:PAUSE / RESUME_TASK
| 项目 |
说明 |
| 需求 |
在现有 IntentRouter 中新增全局对话控制意图识别,支持 PAUSE(暂停)和 RESUME_TASK(恢复)两种意图 |
| 识别策略 |
Dify Prompt 扩展优先(在现有意图识别 Prompt 中增加全局意图判断);Dify 未配置时走关键词兜底 |
| PAUSE 关键词 |
"先去开会""等会继续""先处理别的""暂停""我去忙一下""晚点再说" |
| RESUME_TASK 关键词 |
"继续""继续刚才""好了继续吧""接着来""恢复""回来了" |
| 优先级 |
全局意图识别优先于场景意图识别 — 用户在任何流程节点发出 PAUSE/RESUME_TASK,都应被捕获 |
| 输出格式 |
在现有 {scenario_key, confidence} 基础上新增 global_intent 字段,值为 pause / resume_task / null |
| 兼容性 |
现有4种场景意图识别逻辑不变,仅增加一层全局意图前置判断 |
P0-2 会话暂停逻辑
| 项目 |
说明 |
| 需求 |
当识别到 PAUSE 意图时,将 AutoSession 状态从 running 切换到 paused |
| 状态持久化 |
保存当前执行进度:当前动作 ID(current_action_id)、已收集的信息项快照、暂停时间戳 |
| Redis 快照 |
在 Redis 中存储会话恢复点(resume_point),包含:会话标题、场景类型、当前步骤描述、待决信息项列表、暂停时间 |
| 回复消息 |
暂停时向员工发送友好提示:"好的,您先忙~需要继续时跟我说一声「继续」就好。当前进度:{步骤描述}" |
| 超时处理 |
暂停超过 24 小时未恢复,自动将会话状态标记为 closed(closed_by = "system(timeout)"),并发送通知告知员工任务已超时关闭 |
| 边界处理 |
已处于终态(resolved/closed/handoff/error)的会话不可暂停;审批等待中(await_approval)的会话暂停时需同时挂起审批计时 |
P0-3 会话恢复逻辑
| 项目 |
说明 |
| 需求 |
当识别到 RESUME_TASK 意图时,从 Redis 加载恢复点,将 AutoSession 状态从 paused 切换回 running |
| 恢复点提示 |
恢复后向员工发送上下文回顾消息:"欢迎回来!您之前在处理「{会话标题}」,当前进度:{步骤描述},我们继续吧~" |
| 多任务选择 |
若同一员工有多个 paused 会话,列出可恢复的任务列表(标题 + 暂停时间 + 场景类型),让员工选择恢复哪一个 |
| 信息项校验 |
恢复后检查必需信息项是否完整;若有缺失,优先补全缺失项再继续执行 |
| 动作续行 |
从 current_action_id 对应的下一步继续执行,已完成的动作不重复执行 |
| 边界处理 |
超时关闭的会话不可恢复,提示员工"该任务已超时关闭,请重新发起" |
P0-4 新增 WS 事件
| 事件名 |
触发时机 |
负载 |
automation.paused |
会话暂停时 |
{session_id, title, paused_at, resume_hint} |
automation.resumed |
会话恢复时 |
{session_id, title, resumed_at, current_step} |
automation.timeout_closed |
暂停超时关闭时 |
{session_id, closed_at, reason} |
P0-5 H5端暂停/恢复交互
| 项目 |
说明 |
| 暂停入口 |
自然语言触发(说"先去开会"等),无需额外按钮 |
| 恢复入口 |
① 自然语言触发(说"继续");② 会话列表中 paused 状态的会话点击进入时自动提示恢复 |
| 恢复点卡片 |
恢复时展示一张轻量卡片,显示会话标题、场景类型、暂停时间、当前进度,带"继续处理"按钮 |
| 多任务选择 |
有多个暂停任务时,展示任务列表卡片(Vant Cell 列表),每项含标题 + 暂停时间 + 场景图标,点击选择恢复 |
| 暂停状态展示 |
会话列表中 paused 会话显示"已暂停"标签 + 暂停时长 |
P1 — 应该完成(信息更正核心)
P1-1 全局意图识别扩展:CORRECT / SUPPLEMENT
| 项目 |
说明 |
| 需求 |
在 IntentRouter 中新增 CORRECT(更正)和 SUPPLEMENT(补充)两种全局意图识别 |
| CORRECT 关键词 |
"刚才说错了""不是xx是xx""应该是""更正""说错了" |
| SUPPLEMENT 关键词 |
"再补充一下""顺便说一下""还有""对了补充""另外" |
| 输出格式 |
global_intent 字段扩展为 correct / supplement / pause / resume_task / null |
| 更正信息提取 |
CORRECT 意图需额外提取:corrected_field(更正的字段名)、old_value(旧值,可选)、new_value(新值) |
| 补充信息提取 |
SUPPLEMENT 意图需额外提取:supplement_field(补充的字段名,可推断)、supplement_value(补充的值) |
P1-2 信息项模型与版本管理
| 项目 |
说明 |
| 需求 |
新建 InformationItem 数据结构(PostgreSQL 表 auto_information_items),管理对话中收集的信息项及其变更历史 |
| 核心字段 |
session_id、name(信息项名称)、value(当前值)、modifiers(修饰符列表,JSON)、is_filled(是否已填写)、version(版本号)、update_history(变更历史,JSON)、updated_at |
| 修饰符 |
复用设计文档定义的6种:固定/增量/明确/隐含/复述/必需 |
| 更正策略 |
CORRECT 意图 → 旧值存入 update_history,value 更新为新值,version +1 |
| 补充策略 |
SUPPLEMENT 意图 → 若修饰符含 增量,追加到 value(分号分隔);否则同更正处理 |
| 复述确认 |
若修饰符含 复述,更正后需向员工发送确认消息:"已将{字段名}更正为{新值},确认无误吗?" |
P1-3 更正确认与上下文同步
| 项目 |
说明 |
| 更正确认 |
更正关键字段(用户名、终端ID等)后,向员工发送更正确认消息:"已更正:{字段名} 从「{旧值}」改为「{新值}」" |
| 下游影响 |
更正后若影响已生成的动作计划(如终端ID变更导致映射失效),需重新校验并提示员工"信息已更新,正在重新评估处置方案" |
| 坐席可见 |
更正事件通过 WS 推送到坐席端,坐席可在会话时间线中看到信息变更记录 |
P1-4 新增 WS 事件
| 事件名 |
触发时机 |
负载 |
automation.info_corrected |
信息更正成功时 |
{session_id, field, old_value, new_value, version} |
automation.info_supplemented |
信息补充成功时 |
{session_id, field, supplement_value, new_value} |
P1-5 H5端更正/补充交互
| 项目 |
说明 |
| 自然触发 |
员工在对话中自然语言更正/补充,系统自动识别处理 |
| 更正确认消息 |
更正后在对话流中展示一条系统消息(带「已更正」标签),显示字段名、旧值→新值 |
| 补充确认消息 |
补充后在对话流中展示一条系统消息(带「已补充」标签),显示补充的字段和内容 |
| 信息面板 |
会话详情页新增"已收集信息"折叠面板,展示当前所有信息项的名称、值、状态(已确认/待确认) |
P2 — 增强体验(本阶段可不做)
| 编号 |
需求 |
说明 |
| P2-1 |
暂停任务主动提醒 |
暂停 1 小时后通过企微消息主动提醒员工"您有一个待恢复的任务" |
| P2-2 |
信息更正历史可视化 |
坐席端以时间轴形式展示信息项的完整变更链 |
| P2-3 |
批量信息更正 |
一次性更正多个字段(如"用户名是 lisi,部门是财务部") |
| P2-4 |
暂停任务过期预警 |
暂停接近 24 小时时预警员工"任务即将超时" |
| P2-5 |
信息项智能推断 |
利用 隐含 修饰符从上下文自动推断信息(如从终端ID推断操作系统版本) |
5. 交互流程
5.1 任务中断与恢复流程(P0)
5.2 超时自动关闭流程
5.3 信息更正流程(P1)
5.4 信息补充流程(P1)
5.5 更正影响下游处置的场景
6. 坐席端影响
6.1 会话列表增强
| 改动 |
说明 |
新增 paused 状态筛选 |
会话列表状态筛选器增加"已暂停"选项,坐席可快速查看所有暂停中的会话 |
| 暂停时长展示 |
列表中 paused 会话显示暂停时长(如"已暂停 2h 15min") |
| 超时预警标记 |
接近 24 小时的暂停会话显示橙色预警标记 |
6.2 会话详情增强
| 改动 |
说明 |
| 恢复点信息展示 |
会话详情页展示恢复点信息(暂停时间、当前步骤、已收集信息项) |
| 信息变更时间线 |
会话时间线中展示更正/补充事件,格式:[信息更正] 用户名: zhangsan → lisi (v2) |
| 信息项面板 |
会话详情页新增"信息项"折叠面板,展示所有已收集信息项的名称、当前值、版本号、修饰符 |
6.3 坐席操作能力
| 操作 |
说明 |
| 手动恢复 |
坐席可在会话详情页点击"恢复任务"按钮,代替员工恢复暂停的会话 |
| 手动关闭 |
坐席可终止暂停过久的会话,状态 → closed,closed_by 记录坐席ID |
| 查看更正历史 |
点击信息项可展开完整变更历史(版本号、旧值、新值、变更时间) |
7. 待确认问题
| # |
问题 |
影响范围 |
建议方案 |
| Q1 |
暂停超时阈值是否固定 24 小时?是否需要按场景区分(如密码重置 2 小时、终端定位 24 小时)? |
P0-2 超时处理 |
建议本阶段统一 24 小时,后续按场景配置化 |
| Q2 |
信息更正是否需要区分"可更正"和"不可更正"字段?例如已执行完成的动作结果不可更正? |
P1-2 更正策略 |
建议引入修饰符控制:固定修饰符标记的字段在动作执行后不可更正,执行前可更正 |
| Q3 |
多个暂停任务恢复时,员工用自然语言选择(如"第一个")还是需要点击卡片? |
P0-5 多任务选择 |
建议两者都支持:卡片点击 + 自然语言序号选择 |
| Q4 |
信息更正后如果下游动作已部分执行(如病毒扫描已开始),如何处理?是终止重试还是继续? |
P1-3 下游影响 |
建议本阶段仅提示员工"部分操作已执行,无法撤回",不自动回滚;回滚能力留给后续阶段 |
| Q5 |
全局意图识别是复用现有 Dify Prompt 扩展,还是新建独立的 Dify 应用? |
P0-1 / P1-1 |
建议复用现有 Prompt 扩展,减少调用次数;但需确保全局意图判断不影响现有场景识别准确率 |
| Q6 |
暂停期间坐席是否可以代员工操作(如代为恢复并继续执行)?是否需要员工授权? |
6.3 坐席操作 |
建议坐席可直接恢复无需授权,但恢复后坐席端显示"坐席代恢复"标记 |
| Q7 |
InformationItem 是否需要在 AutoSession 表中新增字段关联,还是独立建表? |
P1-2 数据模型 |
建议独立建表 auto_information_items,通过 session_id 关联,便于版本管理和查询 |
8. 验收标准
8.1 P0 验收标准
8.2 P1 验收标准
本 PRD 仅描述第一阶段(P0+P1)新增/变更部分,不重复已有自动化引擎功能描述。
技术实现方案详见架构师产出文档。