# 企微智能IT支持服务台 — 产品需求文档 (PRD)
> **文档版本**: v1.8
> **创建日期**: 2025-07-11
> **最近更新**: 2026-07-05
> **产品经理**: 许清楚 (Xu) · 宋献
> **状态**: 阶段一开发完成，待端到端验证
> **说明**: 本文档已合并原 `PRD-v53-incremental.md` 内容（v5.3 坐席工作台增量需求）。v1.0 更新：新增管理后台远景规划（§17）、系统生态与集成规划（§18）、阶段细化与并行推进策略（§19）；明确管理后台为第三端产品；确立 AI 混合策略（流程图+AI+标注+迭代）；将阶段一细化为 1A/1B/1C 子阶段；新增零基础人员原则。v1.1 更新：新增邀请功能设计（§20），将邀请功能纳入M1 MVP（1A子阶段），新增P0-09~P0-11和P1-14~P1-16需求。v1.2 更新：整合 `PRD-增量-人工按钮与术语统一.md` 内容为新章节§10 术语与图标规范。v1.3 更新：新增 §4.7 指标体系详细设计；修复 §16 v5.3 内部章节编号；将 v5.3 项目信息移至 §1.1。v1.4 更新（2026-07-04）：**产品经理视角重构**——新增 §1 产品愿景与目标、§1.5 用户画像、§1.6 非目标章节；补充竞品分析至产品定义章节。v1.8 更新（2026-07-06）：新增P1功能需求（满意度评价P1-24、知识库基础P1-25）；新增P2功能需求（自动摘要P2-11、数据看板P2-12）；创建「功能详细规格说明书-P1P2功能.md」作为专项文档；完成技术可行性研究。
> **章节编号说明**: 主文档章节编号为 1-21，附录使用独立编号体系（附录A、附录B、附录C）。后续新增章节应按顺序递增。
> **文档合并记录 (2026-07-05)**:
> - ✅ 归档 `PRD-admin.md` → 内容已整合至 §17 管理后台远景规划
> - ✅ 归档 `重构方案-增量PRD.md` → 内容已由重构方案文档覆盖
> - ✅ 归档 `PRD-增量-GoFly与知识图谱重构.md` → 内容已移至archive
> - ✅ 整合 `PRD-增量-人工按钮与术语统一.md` → 内容已整合至 §10 术语与图标规范
> - ✅ 整合 `03-需求-应急降级页发布预演.md` → 内容已整合至 §21 应急降级页设计
---
## 目录
1. [产品愿景与目标](#1-产品愿景与目标)
- 1.1 产品愿景
- 1.2 产品定位
- 1.3 产品目标
- 1.5 用户画像
- 1.6 非目标
2. [项目背景](#2-项目背景)
3. [方案可行性判断](#3-方案可行性判断)
4. [产品定义](#4-产品定义)
- 4.1 产品目标
- 4.1.5 非目标
- 4.2 用户故事
- 4.3 竞品分析
5. [五阶段演进路径](#5-五阶段演进路径)
6. [需求池](#6-需求池)
7. [并行协作模式](#7-并行协作模式)
8. [界面设计](#8-界面设计)
9. [摇人功能设计](#9-摇人功能设计)
10. [术语与图标规范](#10-术语与图标规范)
11. [技术约束](#11-技术约束（原§10）)
12. [数据模型核心设计](#12-数据模型核心设计)
13. [待确认问题](#13-待确认问题)
14. [里程碑与交付物](#14-里程碑与交付物)
15. [AI Wingman — 坐席智能辅助设计](#15-ai-wingman--坐席智能辅助设计)
16. [v5.3 坐席工作台增量需求](#16-v53-坐席工作台增量需求)
17. [管理后台远景规划](#17-管理后台远景规划)
18. [系统生态与集成规划](#18-系统生态与集成规划)
19. [阶段细化与并行推进策略](#19-阶段细化与并行推进策略)
20. [邀请功能设计 — 多人会话协作](#20-邀请功能设计--多人会话协作)
21. [应急降级页设计 — BC/DR 业务连续性保障](#21-应急降级页设计--bcdr-业务连续性保障)
22. [阶段5 自动化闭环需求](#22-阶段5-自动化闭环需求)
---
附录 A: [术语表](#附录-a-术语表)
附录 B: [企微API关键接口](#附录-b-企微api关键接口)
附录 C: [TeliChat 技术分析](#附录-c-telichat-技术分析)
| 字段 | 值 |
|------|------|
| 项目名称 | `wecom_it_smart_desk` |
| 编程语言 | 后端: FastAPI + Redis + PostgreSQL / 前端: Vue3 + ElementPlus |
| 部署环境 | Linux 服务器 (4核8GB+), Docker |
| 文档语言 | 中文 |
| 原始需求 | 基于企微自建应用消息API，自研IT服务坐席系统，替代企微"员工服务"模块，解决员工体验（绕过AI/另开窗口/无法跨主体）和管理人效（质量不稳定/成长慢/经验流失/缺乏数据）七项痛点 |
---
## 1. 产品愿景与目标
> **新增日期**: 2026-07-04 | **状态**: 核心章节
### 1.1 产品愿景
**一句话描述**：打造基于企业微信生态的**免费开源企业级IT服务台**，让IT支持像发微信一样简单。
**核心价值主张**：
- **员工视角**：IT问题"像发微信一样简单"——AI先答、人工无缝衔接、不用切换窗口
- **IT管理者视角**：低成本、高效率、可量化——坐席减负70%、AI解决80%、数据驱动决策
- **CTO/IT负责人视角**：自主可控、安全合规——私有化部署、国产大模型集成、终端安全一体化
### 1.2 产品定位
| 维度 | 定位 |
|------|------|
| **产品类型** | 企业级ITSM（IT服务管理） |
| **目标客户** | 3000-10000人中型企业，使用企业微信 |
| **核心差异** | 企微原生集成 + 终端安全（火绒+联软）+ AI混合策略 |
| **商业模式** | 社区版免费，专业版定制收费 |
### 1.3 产品目标
1. **效率目标**：AI首答解决率≥80%，人工坐席响应时间≤60秒
2. **体验目标**：员工满意度≥4.5星，问题解决率≥90%
3. **运营目标**：坐席人均日处理≤30会话，自助服务率≥40%
---
## 1.4 用户画像
> **新增日期**: 2026-07-04 | **状态**: 核心章节
### 1.4.1 核心用户角色
| 角色 | 用户故事 | 痛点 | 期望 |
|------|---------|------|------|
| **普通员工** | "我的电脑突然上不了网了" | 不知道找谁、描述不清、等待时间长 | 快速响应、一次解决 |
| **VIP员工**（总监及以上） | "我的VPN怎么连不上" | 不想排队等待、要求优先处理 | 优先响应、专属通道 |
| **IT坐席** | "每天处理50个重复问题" | 重复回答、手工录入、低效沟通 | 智能辅助、快捷回复 |
| **IT主管** | "如何提升团队效率" | 缺乏数据、难以量化、经验流失 | 数据看板、绩效分析 |
| **系统管理员** | "配置新功能上线" | 操作复杂、风险难控、权限混乱 | 简单配置、权限明晰 |
### 1.4.2 典型用户场景
| 场景 | 角色 | 行为 | 期望结果 |
|------|------|------|---------|
| 电脑故障咨询 | 普通员工 | 企微发消息→AI回复→未解决→转人工 | 10分钟内解决问题 |
| 紧急IT故障 | VIP员工 | 直接@IT负责人 | 5分钟内响应，30分钟内解决 |
| 批量软件安装 | IT坐席 | 使用快速回复模板 | 单会话30秒内完成 |
| 周报汇总 | IT主管 | 查看数据看板 | 一键生成周报 |
---
## 1.5 非目标（Out of Scope）
以下内容**不在本产品范围内**：
| # | 非目标 | 原因 | 后续规划 |
|---|--------|------|---------|
| N1 | 移动端独立App | 企微H5已满足移动办公需求 | 暂不考虑 |
| N2 | 微信生态（仅企微） | 公司统一使用企微 | 暂不支持 |
| N3 | 跨企业共享（母子公司） | 阶段三目标，当前不实现 | 阶段三 |
| N4 | 完整ITSM工单系统 | 聚焦咨询场景，工单用现有系统 | 与现有工单系统集成 |
| N5 | 企微设备管理API | 付费功能，公司未购买 | 待采购后 |
| N6 | 视频客服能力 | 当前无此需求 | 未来可选 |
---
## 2. 项目背景
公司是一家约6000人的上市公司，全国主要城市设有分子机构，使用企业微信作为内部即时通讯系统。
### 2.1 现有生产环境现状
公司已通过企微AI机器人API接口与本地化千问模型、RAGFlow、Dify实现智能IT助手回答内部员工IT咨询。转人工环节使用关键字命中后返回企微员工服务功能跳转链接。
**现有系统架构**：
```
┌────────────────────────────────────────────────────────────────┐
│ 现有生产环境架构 │
│ │
│ 员工 ←─1对1消息─→ 企微AI机器人应用 │
│ │ │
│ ├─ AI回复 → RAGFlow + Dify + 千问 │
│ │ （知识库语义检索 + 大模型生成） │
│ │ │
│ ├─ 关键字触发 → 推送"员工服务"入口链接 │
│ │ （如输入"转人工"/"人工"等关键字） │
│ │ │
│ └─ 员工点击链接 → 跳转企微-员工服务-桌面IT支持 │
│ （新窗口，人工坐席处理） │
│ │
│ 企微-员工服务-桌面IT支持： │
│ · 企微内置客服模块，员工服务号接入 │
│ · 排队分配 → 人工坐席1对1对话 │
│ · 无AI辅助、无知识管理、无数据统计 │
└────────────────────────────────────────────────────────────────┘
```
**现有系统组成**：
| 组件 | 说明 | 状态 |
|------|------|------|
| 企微AI机器人 | 企微自建应用，1对1消息交互 | 已上线运行 |
| RAGFlow | 检索增强生成引擎，知识库语义检索 | 已上线运行 |
| Dify | AI应用开发平台，编排千问模型 | 已上线运行 |
| 千问（通义） | 阿里云大模型，AI回复生成 | 已上线运行 |
| 企微-员工服务 | 企微内置客服模块，人工坐席服务 | 已上线运行 |
| 关键字触发转人工 | 输入指定关键字后推送员工服务链接 | 已上线运行 |
**现有系统核心问题**：
| # | 问题 | 现状描述 |
|---|------|---------|
| 1 | AI→人工跳转割裂 | 关键字触发后仅推送链接，员工需手动点击跳转到"员工服务"新窗口 |
| 2 | 无法强制AI前置 | 员工可直接进入"员工服务"入口绕过AI，AI筛选比例低 |
| 3 | 坐席无AI辅助 | 人工坐席在"员工服务"模块中纯手动回复，无智能推荐、无快速回复 |
| 4 | 知识无法积累 | 坐席个人经验无法沉淀，AI知识库与坐席实际工作脱节 |
| 5 | 无数据闭环 | 缺乏坐席绩效、AI回答质量、员工满意度的量化数据 |
| 6 | 跨主体不可达 | "员工服务"模块不支持互联企业，跨企业员工无法使用 |
### 2.2 痛点分析
> **痛点归纳说明**：将原7条痛点归纳为4条核心痛点，每条对应明确的解决阶段，便于追溯开发升级功能的针对性。
| # | 核心痛点 | 具体表现（归纳自原痛点） | 影响 | 解决阶段 |
|---|---------|----------------------|------|---------|
| 1 | **员工入口体验差** | ①员工可绕过AI直达人工，AI筛选比例极低；②转人工需另开新窗口，体验割裂；③AI机器人和员工服务无法跨主体共享，跨企业服务不可达 | AI使用率低，员工困惑，服务覆盖范围受限 | **阶段二** |
| 2 | **坐席能力不稳定** | ①坐席回复质量依赖个人能力和经验，受情绪/状态影响；②实习生成长慢，辅导老师投入大但产出低，知识传承断档 | 服务质量参差不齐，人才培养投入产出比低 | **阶段三** |
| 3 | **知识无法积累传承** | 坐席个人经验和成果无法有效积累、传承、迭代更新，人员离职即经验流失 | 团队整体能力无法持续提升，重复踩坑 | **阶段四** |
| 4 | **管理缺乏数据支撑** | 坐席能力和绩效、IT支持员工满意度缺乏有效数据支撑，管理决策凭感觉 | 无法量化评估和持续优化，管理盲区大 | **阶段四** |
> **核心约束**: 所有对象都是企业内员工，必须避免使用企微微信客服能力。
> **痛点与阶段映射**: 痛点1（员工体验层）→ 阶段二解决；痛点2（坐席能力层）→ 阶段三解决；痛点3~4（管理迭代层）→ 阶段四解决。阶段五（自动/辅助审核开单结单）进一步解决多系统切换效率问题，提升整体人效。
---
## 3. 方案可行性判断
### 3.1 方案对比
> **对比基准**：新增"现有生产环境"行（企微AI机器人 + RAGFlow + Dify + 千问 + 员工服务），作为各方案的改进参照。
| 方案 | 痛点1
入口体验差 | 痛点2
能力不稳定 | 痛点3
知识不传承 | 痛点4
缺数据 | 推荐度 |
|------|:-:|:-:|:-:|:-:|--------|
| **现有：AI机器人+员工服务** | ❌ | ❌ | ❌ | ❌ | ⬅️ 对比基准 |
| 方式一：企微自建应用API + 员工服务转接 | ❌ | ❌ | ❌ | ❌ | ❌ 不推荐 |
| 方式二：企微自建应用消息 + 自研坐席后台 | ✅ | ✅ | ✅ | ✅ | ✅ 推荐 |
| 方式三：企微WebView嵌入 + 开源客服 | ⚠️ | ⚠️ | ❌ | ⚠️ | 有条件推荐 |
| **方式四：混合分阶段演进路径（H5优先）** | **✅** | **✅** | **✅** | **✅** | **✅ 当前推进方案** |
| 方式五：企微原生1对1 + 外援群聊 | ⚠️ | ✅ | ✅ | ✅ | 应急备选 |
> **说明**: 痛点1为体验层（方案对比核心维度），痛点2为坐席能力层，痛点3-4为管理与人效层（依赖自研坐席后台能力，方式一/三不具备）。
>
> **现有系统 vs 各方案的关键差异**：现有系统的"员工入口体验差"（可绕过AI、需另开窗口、无法跨主体）是最大体验短板。方式四通过H5 WebView在同一页面内完成AI→人工无缝切换，彻底解决此问题。
### 3.2 各方案原理与优劣
#### 方式一：企微自建应用API + 员工服务转接
**原理**：自建应用接收员工消息，通过企微"员工服务"模块的API将对话转接到人工坐席。员工在自建应用中与AI对话，转人工时跳转到企微"员工服务"窗口。
| 优点 | 缺点 |
|------|------|
| 开发量最小，复用企微现有员工服务能力 | 仍需另开窗口（员工服务与自建应用是两个独立窗口） |
| 员工服务模块有基础的排队、分配功能 | 无法强制AI前置筛选，员工可直接进入员工服务 |
| | 无法跨主体共享（员工服务模块不支持互联企业） |
| | 无自研坐席后台，痛点2-4无法解决 |
**结论**：❌ 不推荐 — 本质上只是给现有流程加了一层AI入口，核心痛点（员工入口体验差、坐席能力不稳定、无人效管理）均未解决。
#### 方式二：企微自建应用消息 + 自研坐席后台
**原理**：完全基于企微自建应用消息API，员工在自建应用中发消息，后端接收回调后路由至AI或坐席。坐席使用自研工作台处理会话，回复通过 `/message/send` 推送回员工端。
| 优点 | 缺点 |
|------|------|
| 消息路由完全可控，可强制AI前置筛选 | 员工端体验受限于企微应用消息格式 |
| 自研坐席后台，全面解决痛点2-4 | 开发量较大（坐席工作台 + 员工端 + 后端） |
| 支持跨主体（互联企业应用共享） | |
| 消息全量经后端，天然存档 | |
**结论**：✅ 推荐 — 技术路线正确，是方式四/五的架构基础。
#### 方式三：企微WebView嵌入 + 开源客服
**原理**：在自建应用中嵌入WebView加载开源客服系统（如 Chatwoot），员工在H5页面内完成AI+人工全流程对话。
| 优点 | 缺点 |
|------|------|
| 开源客服系统提供现成UI和管理后台 | 无法强制AI前置筛选（员工可直接联系人工） |
| 跨主体可通过H5嵌入其他平台实现 | 开源客服难以深度定制坐席智能辅助功能 |
| | 开源客服的知识管理和数据能力有限，痛点3-4覆盖不足 |
| | 员工端依赖WebView，体验不如原生 |
**结论**：有条件推荐 — 适合快速验证MVP，但长期来看坐席侧能力受限于开源客服的上限。
#### 方式四：混合分阶段演进路径（H5优先）⭐ 当前推进方案
**原理**：基于方式二的架构，员工端采用 H5 WebView（Vue3 + Vant4）嵌入企微自建应用，坐席端采用自研工作台（Vue3 + Element Plus）。消息流全量经后端路由，支持AI前置筛选、AI-人工无缝切换、跨主体扩展。
```
┌─────────────────────────────────────────────────────────────────┐
│ 员工端（H5 WebView） │
│ │
│ 员工 ──消息──→ 企微自建应用 H5 页面 │
│ │ │
│ ├─ AI回复 → H5 内气泡显示（同一对话流） │
│ ├─ 转人工 → H5 内无缝切换（同一对话流） │
│ ├─ 摇人按钮 → 一键呼叫坐席 │
│ └─ 满意度评分 → H5 内评分组件 │
│ │
└─────────────────────────────────────────────────────────────────┘
↕ WebSocket + REST API
┌─────────────────────────────────────────────────────────────────┐
│ 坐席端（自研工作台） │
│ │
│ 坐席 ←── 会话列表（按紧急度排序） │
│ ├── 聊天区（AI建议内联 + 快速回复 + 排查步骤） │
│ ├── 用户信息栏（IT等级徽标 + VIP标记） │
│ └── 待办面板（工单/审批/设备任务） │
│ │
└─────────────────────────────────────────────────────────────────┘
↕
┌─────────────────────────────────────────────────────────────────┐
│ 后端服务 │
│ │
│ 消息路由层（强制AI前置）→ Dify/RAGFlow → 评分 → 分配坐席 │
│ 快速回复知识库（180条模板）→ 排查步骤模板 → 摇人调度 │
│ │
└─────────────────────────────────────────────────────────────────┘
```
**核心交互路径**：
| 阶段 | 交互路径 | 员工端体验 |
|------|---------|-----------|
| AI 自助 | 员工发消息 → 后端路由 → Dify/RAGFlow → H5 内气泡 | AI回复在**同一对话流**中显示 |
| 转人工触发 | AI回复N轮后触发 / 员工点击"摇人"按钮 / 关键词匹配 | **同一对话流**内无缝切换，无跳转 |
| 坐席介入 | 坐席工作台接收会话 → AI推荐回复 → 快速回复 | 员工端仍在**同一对话流**中收到人工回复 |
| 满意度评分 | 会话结束 → H5 内评分组件弹窗 | 原地评分，无需跳转 |
**五阶段演进路径**（详见 §5）：
| 阶段 | 目标 | 员工端 | 坐席端 | AI能力 |
|------|------|--------|--------|--------|
| 阶段一 | 转人工改H5+坐席工作台MVP | H5 登录+身份识别 + 转人工链接改H5 | 自研工作台MVP（会话列表+聊天+快速回复） | 不变（复用现有） |
| 阶段二 | 智能咨询集成 | H5 全流程 + 敲桌子 + 评分 | 三栏工作台MVP + AI建议 + 快速回复 | AI前置筛选 + 双通道推送 |
| 阶段三 | 坐席辅助回复/判断 | H5 体验优化 | AI Wingman（草稿+摘要+知识+排查步骤） | 千问深度集成 |
| 阶段四 | 日志标准+知识库迭代 | H5 跨平台扩展 | 绩效看板 + AI知识库自动迭代 | AI知识库自学习闭环 |
| 阶段五 | 自动/辅助审核开单结单 | H5 一站式 | 待办面板 + AI填单 + AI审核 + AI结单 | AI流程自动化 |
| 优点 | 缺点 |
|------|------|
| H5 员工端可做丰富的交互UI（评分/摇人/AI标识） | 员工需进入H5页面，非原生聊天体验 |
| 消息路由完全可控，可强制AI前置筛选 | 依赖WebView加载，有网络延迟 |
| 自研坐席后台，全面解决痛点4-7 | H5 需OAuth2鉴权（多一步跳转） |
| 支持跨主体（H5可嵌入其他企微主体/平台） | 开发量最大（员工端+坐席端+后端） |
| 一次开发，可扩展到钉钉/飞书/浏览器 | 通知依赖H5页面是否打开（不如原生必达） |
| AI/人工身份清晰区分（UI可做丰富标识） | |
**H5 端实时消息推送方案**：
方式四的 H5 员工端存在一个关键体验问题——坐席回复消息后，H5 页面需要实时刷新才能显示新消息。当前已实现的消息到达机制如下：
| 机制 | 实现状态 | 体验 |
|------|---------|------|
| 企微应用消息推送（`/message/send`） | ✅ 已实现 | 坐席发消息 → 企微系统级通知弹窗/红点 → 员工**点击通知**回到 H5 → 页面拉取新消息 |
| H5 轮询（`/h5/conversations/current/messages/poll`） | ✅ 已实现 | 前端每 3-5 秒请求一次新消息，延迟明显 |
| H5 WebSocket 实时推送 | 🔲 待开发 | 坐席发消息 → 后端推送 → H5 聊天区**秒级自动刷新**，体验最佳 |
**双通道通知策略**（推荐上线方案）：
```
坐席发送消息
├── 通道1: 企微 /message/send → 系统级通知（保证必达）
│ → 员工未在 H5 页面时，收到企微通知弹窗
│ → 员工已关闭 H5 时，仍可通过通知回到对话
│
└── 通道2: WebSocket 推送 → H5 页面内实时更新（保证即时）
→ 员工在 H5 页面时，聊天区秒级刷新
→ 页面未打开时，WebSocket 断连，自动降级为通道1
```
**WebSocket 推送技术方案**：
| 项目 | 说明 |
|------|------|
| 后端 | 扩展现有 `ws_manager.py`（已管理坐席 WS 连接），新增 `employee` 类型连接注册 |
| WS 端点 | `GET /api/h5/ws?token={bearer_token}` — H5 前端通过 Bearer Token 鉴权连接 |
| 消息格式 | `{"type": "new_message", "data": {"id": "...", "content": "...", "sender_type": "agent"}}` |
| 断连降级 | WebSocket 断连时，前端自动切换为轮询（现有 `/messages/poll` 兜底） |
| 重连策略 | 指数退避重连（1s → 2s → 4s → 8s → 最大 30s），断连期间消息由通道1保证 |
| 前端 | `frontend-h5/` 新增 `composables/useWebSocket.ts`，监听推送事件自动追加消息 |
**与现有系统对比**：
| 维度 | 现有生产环境 | 方式四（H5 + 双通道推送） |
|------|------------|------------------------|
| AI→人工切换 | 关键字触发 → 推送链接 → 跳转新窗口 | H5 内同一对话流无缝切换 |
| 人工回复通知 | 企微员工服务自带通知（原生窗口） | 企微系统通知 + H5 WebSocket 双通道 |
| 回复即时性 | 原生1对1窗口，即时 | WebSocket 秒级推送（H5 页面内）/ 企微通知（H5 未打开时） |
| 消息存档 | 企微员工服务存档（需开通会话存档权限） | 全量经后端，天然存档，无额外权限 |
**关键企微 API**：
| API | 路径 | 用途 | 关键限制 |
|-----|------|------|---------|
| 发送应用消息 | `/cgi-bin/message/send` | 通知/提醒推送到企微 | ≤账号上限×200人次/天 |
| 接收消息回调 | 自建应用回调URL | 接收员工发给应用的消息 | 需公网HTTPS回调URL |
| 构造网页授权链接 | `/cgi-bin/oauth2/authorize` | H5页面识别员工身份 | 需配置可信域名 |
| 互联企业应用共享 | 企微管理后台 | 跨主体员工使用同一应用 | 需双方管理员审批 |
**结论**：✅ 当前推进方案 — 全面解决7项痛点，生态扩展性最强，分阶段演进风险可控。
#### 方式五：企微原生1对1 + 外援群聊（应急备选方案）
> **定位**：非主推方案。当方式四的AI服务（Dify/RAGFlow）出现故障不可用时，作为**应急预案**切换至方式五，利用企微原生1对1消息维持基本服务。若方式四整体故障（坐席工作台也不可用），则退回"企微-员工服务-桌面IT支持"仅有人工坐席最简方式。
**原理**：员工直接在企微原生聊天窗口与自建应用1对1对话，AI和坐席回复均通过 `/message/send` 推送到同一窗口。外援场景通过 `/appchat/create` 创建群聊。
```
┌──────────────────────────────────────────────────────────────┐
│ 员工端（企微原生聊天窗口） │
│ │
│ 员工 ←─1对1消息─→ 自建应用（IT智能助手） │
│ │ │
│ ├─ AI回复 → /message/send → 同一窗口 │
│ ├─ 坐席回复 → /message/send → 同一窗口 │
│ │ （员工无感知AI/人工切换） │
│ │ │
│ └─ 外援场景 → /appchat/create → 新群聊窗口 │
│ │
└──────────────────────────────────────────────────────────────┘
```
| 优点 | 缺点 |
|------|------|
| **应急价值高**：AI故障时可快速切换，员工仍可通过原生窗口获得人工服务 | 无法跨主体（仅同一企微主体内） |
| 员工端零开发量（原生聊天窗口） | AI/人工身份需消息前缀区分（如"[人工-张三]"） |
| 体验最优（与日常聊天无差异，通知必达） | 员工可直接1对1联系应用，绕过AI前置筛选 |
| 消息全量经后端API，天然存档 | 绑定企微生态，无法扩展到其他平台 |
| 外援走原生群聊，低频且轻量 | 满意度评分只能用模板卡片（体验不如H5评分组件） |
**关键企微 API**：
| API | 路径 | 用途 | 关键限制 |
|-----|------|------|---------|
| 发送应用消息 | `/cgi-bin/message/send` | AI/坐席向员工推送消息（主流程） | ≤账号上限×200人次/天，同一人≤30次/分 |
| 接收消息回调 | 自建应用回调URL | 接收员工发给应用的消息 | 需公网HTTPS回调URL |
| 创建群聊 | `/cgi-bin/appchat/create` | 外援场景：创建多方协作群 | ≤1000群/天，≤2000人/群 |
| 修改群聊 | `/cgi-bin/appchat/update` | 外援群管理（加人/改名） | ≤1000次/小时 |
| 获取群聊 | `/cgi-bin/appchat/get` | 查询群聊信息 | 仅本应用创建的群 |
| 推送群消息 | `/cgi-bin/appchat/send` | 群内推送消息（9种类型） | ≤2万人次/分 |
**方式四 vs 方式五详细对比**：
| 维度 | 方式四：H5 WebView（当前方案） | 方式五：原生1对1 + 外援群聊（应急备选） |
|------|-------------------------------|---------------------------------------|
| **员工入口** | 点击应用 → 进入 H5 页面 | 直接在企微与应用1对1聊天 |
| **对话体验** | H5 内部输入框，需切换上下文 | **原生聊天窗口，与日常聊天无差异** |
| **通知必达** | 依赖 H5 是否打开 | **企微原生推送，必达** |
| **富媒体支持** | H5 自定义 UI（需开发） | **原生支持6种输入+10种输出** |
| **前端开发量** | 大（Vue3+Vant4 H5 客户端） | **零（员工端无前端）** |
| **OAuth2 鉴权** | 必须（H5 需识别用户身份） | **不需要（回调自带 UserID）** |
| **跨平台移植** | **✅ H5 可挂载钉钉/飞书/浏览器等** | ❌ 绑定企微 |
| **跨主体企微支持** | **✅ 可，非静默登录时提供其他认证** | ❌ 仅同一企微主体内 |
| **AI/人工区分** | **✅ H5 可做丰富身份标识** | ⚠️ 需消息内容前缀区分（如"[人工-张三]"） |
| **转人工触发** | H5 内按钮（`ai_substantive_reply_count >= 3`） | 关键词"转人工" / 交互卡片按钮 |
| **满意度评分** | H5 内评分组件 | 模板卡片消息（按钮交互型） |
| **消息存档** | 全量经后端，天然存档 | **全量经后端（AI+坐席都走API），无需会话存档权限** |
| **外援/摇人** | 需额外设计 | **原生群聊(appchat)，新窗口** |
| **坐席工作台** | 保留 | 保留 |
**结论**：方式五体验最优但受限于企微主体内，定位为**应急备选方案**。当方式四的AI服务故障时切换使用，维持基本服务能力。
### 3.3 降级应急预案
当方式四（主方案）出现不同级别的故障时，按以下降级链路逐步回退：
```
方式四（正常）→ 方式五（AI故障，保留坐席工作台+原生1对1）→ 企微员工服务（仅人工坐席最简方式）
```
| 降级级别 | 触发条件 | 员工端变化 | 坐席端变化 | 恢复条件 |
|----------|---------|-----------|-----------|---------|
| **L0 正常** | 全部服务可用 | H5 完整体验 | 自研工作台全功能 | — |
| **L1 AI降级** | Dify/RAGFlow 不可用 | H5 内自动跳过AI，直接进入人工排队 | 工作台AI推荐/快速回复不可用，手动回复 | AI服务恢复 |
| **L2 方式五切换** | H5服务整体故障 | 切换至企微原生1对1消息（方式五） | 工作台仍可用，回复通过API推送到员工原生窗口 | H5服务恢复 |
| **L3 完全回退** | 坐席工作台也不可用 | 退回"企微-员工服务-桌面IT支持" | 使用企微员工服务后台手动处理 | 全部服务恢复 |
> **核心架构决策**: 彻底放弃企微"员工服务"模块，用自建应用消息API + 自研坐席服务台替代整个链路
> **消息路由**: 自建应用消息回调到自己服务器，所有消息先到路由层，可强制新会话默认进AI模式
> **跨企业**: 通过企微"互联企业"应用共享实现（方式四），或H5嵌入其他平台实现
---
## 4. 产品定义
### 4.1 产品目标
1. **提高AI首答率**: 通过消息路由层强制新会话先走AI，将AI筛选比例从当前低位提升至80%以上，降低人工坐席负载
2. **统一对话体验**: 员工从AI对话到人工服务在同一窗口无缝流转，消除跳转割裂感
3. **构建AI-人工协作闭环**: 建立坐席标注→知识库迭代的正向循环，持续提升AI解答质量
### 4.2 用户故事
| # | 角色 | 故事 | 验收标准 |
|---|------|------|---------|
| US-1 | 普通员工 | 我希望在企微应用中直接咨询IT问题，AI先回答，需要人工时无需切换窗口即可转接 | AI回复和人工回复在同一对话流中连续显示 |
| US-2 | 普通员工 | 我希望通过"摇人"一键呼叫IT坐席，不需要记住关键词 | 摇人按钮在输入框左侧，点击即触发转人工流程 |
| US-3 | IT坐席 | 我希望看到一个按紧急度排序的会话列表，优先处理最紧急的问题 | 会话列表按紧急→举手→需介入→活跃→AI处理中→已结单排序 |
| US-4 | IT坐席 | 我希望AI能在旁边给我建议回复和操作步骤，我可以采纳或修改 | AI建议条显示在对话区，支持采纳/编辑后采纳/忽略 |
| US-5 | IT主管 | 我希望坐席在日常工作中标注AI回复的准确性，系统能自动分析知识库缺陷 | 标注嵌入坐席工作流，千问自动分析生成优化建议 |
| US-6 | VIP员工 | 我希望我的问题能被优先处理 | VIP标记自动匹配，会话紧急度加成，列表优先展示 |
| US-7 | 跨企业员工 | 我希望在母公司的企微应用中也能使用IT服务 | 通过企微互联企业应用共享，跨主体员工可使用同一服务 |
---
### 4.4 竞品分析与差异化定位
> **新增日期**: 2026-06-14
#### 4.3.1 四大竞品对标
| 竞品 | 类型 | 核心能力 | 我们的差异化优势 |
|------|------|----------|------------------|
| **钉钉·智能客服** | 平台内置 | AI问答、工单、会话分析 | **私有化部署 + 企微深度集成** + 坐席工作台自定义 |
| **美团·IT服务台** | 自研 | 报修工单、资产盘点、BI看板 | **终端安全集成**（火绒+联软）+ 免费开源 |
| **飞书·IT运维** | 插件生态 | 审批流、资产、知识库 | **企业微信原生** + AI混合策略 |
| **Jira Service Management** | 商业SaaS | ITSM、资产管理、SLA | **本土化免费** + 国有大模型集成 |
#### 4.3.2 市场定位
> **一句话定位**: 融合服务台+资产+终端安全的**企业级ITSM**，基于企微生态的免费开源解决方案。
| 维度 | 定位说明 |
|------|----------|
| **目标客户** | 6000人左右的中大型企业，使用企微作为办公通讯 |
| **核心价值** | 免费开源 + 私有化部署 + 终端安全一体化 |
| **差异化标签** | AI驱动 · 多系统对接 · 一站式处理 |
| **定价策略** | 社区版免费，专业版定制收费 |
#### 4.3.3 竞争优势
| 优势 | 说明 |
|------|------|
| **企微深度集成** | 原生OAuth2、企业API、消息推送、通讯录同步 |
| **终端安全联动** | 火绒+联软API直连，威胁自动响应 |
| **免费开源** | MIT协议，社区支持，降低采购阻力 |
| **AI混合策略** | 流程图+AI生成+坐席标注+自动迭代 |
#### 4.3.4 风险与挑战
| 风险 | 等级 | 应对策略 |
|------|------|----------|
| 企微API限制 | 中 | 保持降级通道（企微员工服务） |
| 集成复杂度 | 高 | 分阶段交付，MVP先行 |
| 社区活跃度 | 低 | 先在内部打磨，文档完善后开源 |
---
### 4.5 身份认证与统一入口
> **更新日期**: 2026-07-06 | **核心变更**: 修正为各端独立入口，删除理想化统一入口设计
#### 4.5.1 设计原则
| 原则 | 说明 |
|------|------|
| **角色分离** | 用户/坐席/管理员三种角色，按角色分配访问权限 |
| **安全可控** | 坐席和管理员通过双因素认证（OTP）确保安全 |
| **入口独立** | 各端独立入口，互不依赖，避免单点故障 |
| **企微内嵌** | 用户端（H5）强制企微内嵌，保证安全性和用户体验 |
#### 4.5.2 实际实现架构
> **重要说明**: 初始设计期望使用 `/itportal/` 统一入口，但基于实际运营中的问题，已调整为**各端独立入口**方案。
**未采用统一入口的原因**：
1. **坐席必须在企微中登录** — 绑定企微自动登录后，坐席端强制依赖企微客户端
2. **企微登录验证故障频繁** — OAuth 回调不稳定，影响开发和运维效率
**当前实现**：各端独立入口，独立认证流程：
```mermaid
flowchart TB
subgraph 用户端
A1[企微工作台] --> A2[应用内嵌打开 /itdesk/]
A2 --> A3[OAuth2 静默授权]
A3 --> A4[进入工作台]
end
subgraph 坐席端
B1[浏览器直接打开 /itagent/] --> B2[智能检测企微登录状态]
B2 --> B3{企微已登录?}
B3 -->|是| B4[三种登录方式]
B3 -->|否| B5[默认登录页]
B4 --> B6[验证成功]
B5 --> B6
B6 --> B7[进入工作台]
end
subgraph 管理后台
C1[浏览器直接打开 /itadmin/] --> C2[智能检测企微登录状态]
C2 --> C3{企微已登录且有管理员角色?}
C3 -->|是| C4[免密直接进入]
C3 -->|否| C5[账号密码+OTP验证]
C4 --> C6[进入管理后台]
C5 --> C6
end
subgraph 统一入口
D1[已配置 /itportal/] -.-> D2[未实际使用
保留接口]
end
```
> **说明**：三个端独立运作，互不依赖。即使企微OAuth出现故障，坐席和管理员仍可通过账号密码+OTP方式正常登录。
#### 4.5.3 角色体系
| 角色 | 标识 | 说明 | 访问路径 | 登录方式 |
|------|------|------|----------|----------|
| 普通员工 | `user` | 提交IT问题、查看进度、评价满意度 | `/itdesk/` | OAuth2 静默授权（企微内嵌） |
| IT坐席 | `agent` | 处理会话、AI辅助、快速回复 | `/itagent/` | 智能检测 + 三种登录方式 |
| 管理员 | `admin` | 系统配置、坐席管理、数据看板 | `/itadmin/` | 智能检测 + 三种登录方式（与坐席相同） |
#### 4.5.4 坐席/管理员登录流程
> **更新日期**: 2026-07-06 | **核心变更**: 区分企微免密登录与传统登录，OTP验证时机调整
```mermaid
flowchart TD
Start([访问 /itagent/]) --> Detect[检测企微客户端登录状态]
Detect --> HasWecom{检测到企微登录账号?}
HasWecom -->|是| CheckRole{该账号具有坐席或管理员角色?}
CheckRole -->|是| Direct[免密直接进入工作台]
CheckRole -->|否| ShowOptions[显示登录选项]
HasWecom -->|否| ShowOptions
ShowOptions --> Options{选择登录方式}
Options -->|企微扫码| QRAuth[企微扫码授权]
QRAuth --> QROk{授权成功且有坐席或管理员角色?}
QROk -->|是| Direct
QROk -->|否| ShowOptions
Options -->|账号密码| PwdInput[输入账号密码]
PwdInput --> PwdVerify{账号密码验证}
PwdVerify -->|通过| OTPInput[弹出OTP填写框]
PwdVerify -->|失败| ShowOptions
OTPInput --> OTPVerify{OTP验证}
OTPVerify -->|通过| Direct
OTPVerify -->|失败| ShowOptions
Direct --> Token[发放Token]
Token --> Workbench([进入坐席工作台])
```
**流程说明**：
| 场景 | 条件 | 登录方式 | OTP验证 |
|------|------|----------|---------|
| **场景一** | 检测到企微登录账号 + 具有坐席或管理员角色 | 免密直接进入 | 无需OTP |
| **场景二** | 未检测到企微登录 **或** 企微账号无坐席角色 | 扫码/账号密码 | 账号密码后需OTP |
| **场景三** | 选择企微扫码登录 | 扫码授权 | 授权成功且有坐席或管理员角色则免OTP |
| **场景四** | 选择账号密码登录 | 账号+密码+OTP | 必须OTP验证通过 |
#### 4.5.5 登录方式详细说明
| 登录方式 | 适用场景 | 技术实现 | OTP验证 |
|----------|---------|---------|---------|
| **企微免密登录** | 检测到企微登录账号且具有坐席或管理员角色 | JS-SDK `wx.agentConfig` → 后端校验角色 | 无需（已验证企微身份） |
| **企微扫码登录** | 企微客户端未登录但有企微App | 显示企微OAuth二维码 → 用户扫码授权 | 授权成功后需OTP验证 |
| **账号密码+OTP** | 无企微环境或二维码失效 | 传统表单 + TOTP验证码 | 账号密码验证通过后，需填写OTP |
#### 4.5.6 企微客户端检测
| 检测方式 | 代码 | 说明 |
|----------|------|------|
| **企微内嵌检测** | `navigator.userAgent.includes('wxwork')` | 检测UA是否包含wxwork |
| **企微 JS-SDK** | `wx.agentConfig()` | 获取当前企微用户身份（需企业微信JS-SDK引入） |
| **企微协议跳转** | `wecom://` | 唤起企微客户端打开指定页面 |
> **注意**：
> - 用户端（`/itdesk/`）强制企微内嵌，非企微环境访问跳转拦截页
> - 坐席端智能检测为增强体验，检测失败时回退到默认登录页
#### 4.5.7 技术实现
| 组件 | 说明 |
|------|------|
| **H5 前端** | Vue3 + Vant4，路径 `/itdesk/` |
| **坐席前端** | Vue3 + Element Plus，路径 `/itagent/` |
| **管理后台** | Vue3 + Element Plus + Tailwind，路径 `/itadmin/` |
| **Portal 前端** | Vue3 + Element Plus（已配置但未使用），路径 `/itportal/` |
| **Portal API** | FastAPI `/api/portal/*`，角色查询、Token 发放（保留接口） |
| **数据库表** | `roles`（角色定义）、`user_roles`（用户角色关联） |
| **Token 机制** | Bearer Token，通过 URL 参数 `?token=xxx` 传递 |
| **OTP 绑定** | 首次登录引导绑定，支持 TOTP（Google Authenticator/微信扫码） |
| **OTP API** | `/api/mfa/*` 系列接口 |
#### 4.5.8 测试账号
| 角色 | 用户名 | 初始密码 | OTP | 说明 |
|------|--------|----------|-----|------|
| 坐席 | `sxn` | `admin123` | 需绑定 | IT 支持组组长 |
| 管理 | `sxn` | `admin123` | 需绑定 | 同上，具有 admin 权限 |
> **注意**：生产环境需修改默认密码；坐席/管理员需先绑定OTP才能登录（首次登录引导）
#### 4.5.9 管理后台登录页面设计
```
+------------------------------------------+
| IT智能服务台 |
| 管理后台登录 |
+------------------------------------------+
| |
| [企微免密登录] [企微扫码登录] [账号密码登录] |
| |
| +------------------------------------+ |
| | 用户名: [____________] | |
| +------------------------------------+ |
| | 密码: [____________] | |
| +------------------------------------+ |
| | OTP: [______] [发送验证码] | |
| +------------------------------------+ |
| | [ 登录 ] | |
| +------------------------------------+ |
| |
| 首次登录自动绑定OTP和企业微信 |
+------------------------------------------+
```
**说明**：
- 智能检测企微登录状态，根据检测结果动态显示登录入口
- 企微已登录且有管理员角色：显示"企微免密登录"入口
- 未检测到企微登录：默认显示"企微扫码登录"和"账号密码登录"
#### 4.5.10 技术实现要点
> **更新日期**: 2026-07-06 | **整合自管理后台登录方式扩展PRD**
**数据库扩展**：
```sql
-- 坐席/管理员表新增字段
ALTER TABLE agents ADD COLUMN password_hash VARCHAR(255);
ALTER TABLE agents ADD COLUMN mfa_enabled BOOLEAN DEFAULT FALSE;
ALTER TABLE agents ADD COLUMN mfa_secret VARCHAR(32);
ALTER TABLE agents ADD COLUMN mfa_bound_at TIMESTAMP;
```
**API 端点**：
| 方法 | 路径 | 描述 |
|------|------|------|
| POST | `/api/auth_wecom/jsdk-login` | 企微免密登录 |
| POST | `/api/auth_qrcode/create` | 企微扫码登录 |
| POST | `/api/agents/login` | 账号密码+OTP登录 |
| POST | `/api/mfa/bind/start` | MFA绑定 |
| POST | `/api/mfa/verify` | OTP验证 |
**技术约束**：
- 密码存储：bcrypt 哈希
- Session/Token：复用现有 Redis Token 机制
- 企微免密登录：企微JS-SDK获取userid → 验证角色 → 返回Token
---
### 4.6 功能优先级 (MoSCoW)
> **新增日期**: 2026-06-14
#### Must have (P0 - MVP必须)
| 功能 | 说明 | 阶段 |
|------|------|------|
| AI对话 | 员工在H5中咨询IT问题，AI回答 | 阶段1 |
| 转人工 | AI无法解决时一键转人工坐席 | 阶段1 |
| 坐席工作台 | 会话列表+聊天+快速回复 | 阶段1 |
| 消息推送 | 企微消息实时到达 | 阶段1 |
| 身份识别 | OAuth2企微登录 | 阶段1 |
#### Should have (P1 - 第一版应该有)
| 功能 | 说明 | 阶段 |
|------|------|------|
| 摇人按钮 | 输入框左侧一键呼叫坐席 | 阶段2 |
| 满意度评价 | 会话结束后评价 | 阶段2 |
| 排队系统 | 多会话时排队等待 | 阶段2 |
| 快速回复 | 坐席常用语管理 | 阶段2 |
| 知识库(基础) | FAQ手动维护 | 阶段2 |
#### Could have (P2 - 最好有)
| 功能 | 说明 | 阶段 |
|------|------|------|
| AI Wingman | AI建议回复 | 阶段3 |
| 会话标注 | 坐席标注AI回复准确性 | 阶段3 |
| 自动摘要 | 会话结束后AI摘要 | 阶段3 |
| 数据看板 | 基础统计 | 阶段4 |
| 知识库自动迭代 | AI分析+知识库更新 | 阶段4 |
#### Won't have (暂缓)
| 功能 | 说明 | 阶段 |
|------|------|------|
| 工单系统 | 开单/审批/结单 | 阶段5 |
| 资产联动 | 联软资产集成 | 阶段5 |
| 终端安全 | 火绒终端集成 | 阶段5 |
| 跨企业共享 | 企微互联 | 未来 |
---
### 4.9 推广计划
> **新增日期**: 2026-06-14
#### 5阶段推广节奏
| 阶段 | 时间 | 目标 | 策略 |
|------|------|------|------|
| **封闭内测** | 第1-2周 | 30人IT部门 | 邀请制，收集反馈，优化体验 |
| **全员试用** | 第3-4周 | 200人种子用户 | 企微群推广，管理员推动 |
| **正式上线** | 第5-6周 | 1000人 | 培训+推广材料 |
| **功能扩展** | 第7-12周 | 3000人 | 阶段2功能，推广摇人+评价 |
| **生态构建** | 第3-6月 | 6000人 | 阶段3-4，数据驱动优化 |
#### 推广关键指标 (KPI)
| 指标 | 目标值 | 说明 |
|------|--------|------|
| AI首答率 | ≥80% | AI直接解决的比例 |
| 人工平均响应 | ≤60s | 从提交到坐席响应的平均时间 |
| 会话满意度 | ≥4.5★ | 5分制评价 |
| 问题解决率 | ≥90% | AI+人工最终解决的比例 |
| 坐席人均处理 | ≤30/天 | 坐席日均处理会话数 |
> **指标体系补充说明 (2026-07-04)**: 完整的指标体系设计见下节「§4.7 指标体系详细设计」，包含北极星指标、驱动指标、健康指标的完整定义和测量方法。
#### 推广资源需求
| 资源 | 说明 |
|------|------|
| IT支持组 | 3人坐席值班 |
| 培训材料 | 5分钟入门视频+图文手册 |
| 推广文案 | 企微公告+海报 |
| 激励机制 | 满意度前10%奖励 |
---
### 4.7 指标体系详细设计
> **新增日期**: 2026-07-04 | **状态**: 方案设计阶段，待开发实施
#### 4.7.1 指标框架概览
| 指标类型 | 定义 | 测量方法 | 展示位置 |
|----------|------|---------|---------|
| **北极星指标** | 最终业务目标 | 会话结单时用户评价「问题已解决」的比例 | 管理后台首页 |
| **驱动指标** | 过程指标，直接影响北极星 | 各类过程数据埋点统计 | 数据看板 |
| **健康指标** | 系统健康状态 | 系统可用性、错误率监控 | 运维监控页 |
#### 4.7.2 北极星指标 (North Star)
| 指标 | 定义 | 目标值 | 测量方法 |
|------|------|--------|---------|
| **员工问题解决满意度** | 员工评价「问题已解决」的比例 | ≥90% | 满意度评价中选择「已解决」的会话数 / 总会话数 |
#### 4.7.3 驱动指标 (Driver Metrics)
| 指标 | 定义 | 目标值 | 测量方法 | 数据来源 |
|------|------|--------|---------|---------|
| **AI首答解决率** | AI直接回答并被评价为「已解决」的比例 | ≥60% | AI回复且结单评价「已解决」的会话 / AI回复总会话数 | conversations + feedback |
| **人工首次响应时间** | 从会话创建到坐席首次回复的平均时间 | ≤60s | AVG(first_response_time - conversation_created_at) | conversations |
| **会话解决率** | 最终被评价为「已解决」的会话比例 | ≥90% | 结单评价「已解决」的会话数 / 总会话数 | feedback |
| **自助服务率** | 员工不需人工介入解决问题的比例 | ≥40% | AI解决会话数 / 总会话数 | conversations |
#### 4.7.4 健康指标 (Health Metrics)
| 指标 | 定义 | 目标值 | 测量方法 |
|------|------|--------|---------|
| **坐席响应超时率** | 超过设定阈值的响应超时比例 | <5% | 超时会话数 / 总会话数 |
| **重复会话率** | 同一用户短期内重复发起会话的比例 | <10% | 重复会话数 / 总会话数 |
| **负面评价率** | 评价为1-2星的比例 | <3% | 1-2星评价数 / 总会话数 |
| **系统可用性** | 系统正常可用时间比例 | ≥99.9% | (总时间 - 故障时间) / 总时间 |
#### 4.7.5 行业基准对比
| 指标 | 行业基准 (ITSM) | 本产品目标 | 差距分析 |
|------|-----------------|-----------|---------|
| FRT (首次响应时间) | < 15分钟 | ≤60s | ✅ 目标更激进 |
| 自助服务率 | 40-60% | ≥40% | ✅ 目标对齐 |
| CSAT (满意度) | > 4.2/5 | ≥4.5★ | ✅ 目标合理 |
| 问题解决率 | > 85% | ≥90% | ✅ 目标合理 |
| SLA 达成率 | > 95% | 待定义 | 需补充 |
#### 4.7.6 数据采集设计
| 事件 | 采集时机 | 字段 |
|------|---------|------|
| 会话创建 | 用户发起新会话 | session_id, user_id, source, timestamp |
| AI回复 | AI返回回答 | session_id, ai_response_time, resolved |
| 坐席首次响应 | 坐席首次回复 | session_id, agent_id, first_response_time |
| 会话结单 | 坐席点击结单 | session_id, resolution_time, resolution_type |
| 满意度评价 | 用户提交评价 | session_id, rating (1-5), resolved (bool) |
#### 4.7.7 仪表盘设计
管理后台「数据看板」应展示：
1. **首页核心指标卡片**: 北极星指标 + 4个驱动指标 + 4个健康指标
2. **趋势折线图**: 按日/周/月展示指标变化趋势
3. **排行榜**: 坐席绩效排名、热点问题排行
4. **告警列表**: 指标低于阈值时的告警记录
---
## 5. 五阶段演进路径
> **演进原则**：每个阶段都基于现有生产环境（企微AI机器人 + RAGFlow + Dify + 千问）进行增量升级，不做大爆炸式替换。现有AI机器人持续运行直到新系统对应阶段稳定上线。
### 5.1 阶段总览
| 阶段 | 目标 | 核心变更 | 解决痛点 | 现有系统影响 |
|------|------|---------|---------|------------|
| **阶段一** | 转人工改H5+坐席工作台MVP | AI机器人转人工链接从"员工服务"改为H5自建应用，员工端解决登录和身份识别，坐席端交付自研工作台MVP（会话列表+聊天+快速回复），AI能力不变 | 痛点1（部分）、坐席摆脱员工服务限制 | AI转人工链接从员工服务改为H5，原有1对1窗口保留为降级通道 |
| **阶段二** | 迁移和集成面向员工的智能咨询功能 | H5员工端完整体验（AI对话+转人工+摇人+评分），双通道消息推送 | **痛点1** | 员工服务入口逐步迁移至H5 |
| **阶段三** | 面向坐席的辅助回复和辅助判断 | 坐席工作台 AI Wingman（草稿回复+自动摘要+知识推荐+排查步骤） | **痛点2** | 坐席从员工服务后台切换至自研工作台 |
| **阶段四** | 日志标准和AI知识库迭代 | 会话标注体系 + AI知识库自动迭代闭环 + 数据统计看板 | **痛点3~4** | AI知识库从人工维护升级为自动迭代 |
| **阶段五** | 自动/辅助审核、开单、结单 | 工单/审批/设备异常一站式处理 + AI辅助填单+自动结单 | 多系统切换效率问题 | 替代多系统切换，统一工作台闭环 |
### 5.2 各阶段详细规划
#### 阶段一：转人工改H5 + 坐席工作台MVP
> **本阶段解决痛点**：坐席摆脱企微员工服务限制（为阶段二解决痛点1打基础）。
>
> **关键前提**：企微AI机器人 + Dify + RAGFlow + 千问**已在生产环境运行**，本阶段不做任何AI引擎改动，仅改变转人工环节的链接指向和坐席端工具。
**目标**：现有AI机器人继续运行（不动），仅将转人工的链接从"企微员工服务"改为H5自建应用；员工端解决OAuth2登录和身份识别；坐席端交付自研工作台MVP（会话+快速回复），摆脱企微内置员工服务的限制。坐席端AI能力**暂不接入**。
**现状 → 目标对比**：
| 维度 | 现有生产环境 | 阶段一目标 |
|------|------------|----------|
| AI机器人 | 企微1对1对话，RAGFlow+Dify+千问（**不变**） | 企微1对1对话，RAGFlow+Dify+千问（**不变**） |
| 转人工 | 关键字触发 → 推送"企微员工服务"链接 → 跳转新窗口 | 关键字触发 → 推送H5自建应用链接 → 同一WebView内切换 |
| 员工端 | 无独立身份识别，员工服务窗口无登录 | H5 WebView（OAuth2静默授权 → 身份识别） |
| 坐席端 | 企微内置员工服务后台（功能受限） | 自研工作台MVP，摆脱员工服务限制 |
| 坐席快速回复 | 无（纯手动输入） | 三级导航快速回复面板（7大类28子类180条模板） |
| 坐席AI能力 | 无 | **暂不接入**（阶段三引入） |
**范围**：
**员工端（H5 WebView，Vue3 + Vant4）**：
- 自建应用创建 + H5页面基础框架
- OAuth2 静默授权 → 员工身份识别（核心）
- 接收坐席消息的展示（人工回复在H5页面显示）
- 企微应用消息推送（坐席回复通过 `/message/send` 推送企微通知）
**坐席端（自研工作台MVP，Vue3 + Element Plus）**：
- 会话列表（显示进行中的会话，按时间排序）
- 聊天窗口（显示完整对话记录，可回复）
- 发送消息（文本消息发送）
- 快速回复面板（三级渐进导航：7大类→28子类→180条模板，数字键快捷操作）
- **邀请功能**（坐席邀请其他员工/部门加入会话，详见§21）
- 摆脱企微员工服务限制，坐席使用独立工作台处理会话
- **不含AI能力**（AI建议、排查步骤等留到阶段三）
**后端变更**：
- AI机器人转人工链接配置：从"员工服务"改为H5自建应用URL
- 坐席WebSocket连接管理（复用现有 `ws_manager.py`）
- 消息路由：AI对话→关键字触发→创建人工会话→分配坐席
**完成标准**：员工在企微与AI机器人对话 → 关键字触发转人工 → 推送H5链接 → 员工点击进入H5页面（OAuth2自动登录） → 坐席在自研工作台收到会话 → 坐席使用快速回复或手动输入回复 → 员工在H5页面看到人工回复；坐席可邀请其他员工/部门加入会话协作 → 被邀请人收到企微通知 → 通过H5链接加入 → 多人同一会话协作
**开发周期**：6-8周
#### 阶段二：迁移和集成面向员工的智能咨询功能
> **本阶段解决痛点**：痛点1（员工入口体验差：可绕过AI、另开窗口、无法跨主体）。
**目标**：完善H5员工端全流程体验，实现AI→人工无缝切换，取代关键字触发跳转链接的转人工方式，并增强坐席工作台能力（仍不含AI）。
**现状 → 目标对比**：
| 维度 | 阶段一 | 阶段二目标 |
|------|--------|----------|
| 转人工方式 | 关键字触发 → 推送H5链接（同一WebView切换） | H5内"敲桌子"按钮/摇人 → 同一对话流切换 |
| 人工回复到达 | 坐席自研工作台回复 → 员工H5页面查看（轮询） | H5内WebSocket实时推送 + 企微通知双通道 |
| AI→人工切换 | 关键字触发，两个窗口（AI对话+人工H5） | 同一对话流，AI历史+人工回复连续显示 |
| 坐席端能力 | 基础MVP（会话列表+聊天+快速回复） | 用户信息栏 + 会话标记 + 排队显示（不含AI） |
| 满意度评分 | 无 | H5内评分组件，会话结束后弹出 |
| 排队系统 | 无 | 等待坐席接入的排队机制，含等待提示 |
**范围**：
**员工端（H5）**：
- H5 "敲桌子/摇人"按钮 + 转人工触发逻辑（AI实质性回复≥3轮）
- H5 WebSocket 实时推送（双通道通知策略）
- 满意度评分组件
- AI→人工同一对话流无缝切换
**坐席端（工作台增强，不含AI）**：
- 用户信息栏（员工基本信息、IT等级徽标）
- 会话标记系统（VIP/举手/需介入/情绪标记）
- 会话列表增强（按紧急度排序、标记显示）
- 排队信息展示
**后端**：
- 消息路由层优化：新会话→AI优先，AI判断/用户触发→坐席队列
- 排队系统 + 等待提示
- 会话状态增强（排队中/服务中/已结单 + 标记）
**完成标准**：员工H5内AI对话→敲桌子→坐席接入→人工回复→员工同一对话流看到→结单→评分
**开发周期**：5周
**开发计划**：
| 周 | 天数 | 内容 |
|----|------|------|
| 第1周 | D1-D5 | H5敲桌子/摇人 + 消息路由优化 + AI→人工切换 |
| 第2周 | D6-D10 | WebSocket推送 + 双通道通知策略 |
| 第3周 | D11-D15 | 坐席AI建议面板 + 用户信息栏 + 会话标记 |
| 第4周 | D16-D20 | 排队系统 + 满意度评分 |
| 第5周 | D21-D25 | 联调测试 + 现有系统切换 |
#### 阶段三：面向坐席的辅助回复和辅助判断
> **本阶段解决痛点**：痛点2（坐席能力不稳定：回复质量依赖个人能力、实习生成长慢）。
**目标**：坐席工作台引入AI Wingman（智能副驾驶），消灭重复劳动、增强认知能力。
**现状 → 目标对比**：
| 维度 | 阶段二 | 阶段三目标 |
|------|--------|----------|
| 坐席回复方式 | 纯手动输入 | AI草稿回复 + 快速回复模板 + 排查步骤 |
| 会话摘要 | 无 | AI自动生成结构化摘要（问题/原因/解决方案） |
| 知识获取 | 坐席自行搜索 | 基于对话上下文自动推送知识库文档 |
| 问题判断 | 依赖个人经验 | AI辅助判断 + 相似工单推荐 + SOP流程导航 |
| 新人上手 | 老带新，成长慢 | AI推荐回复降低认知负荷，上手周期缩短50% |
**范围**：
- AI Wingman 效率层：AI草稿回复（采纳/编辑/忽略）+ 自动摘要 + 自动标签
- AI Wingman 认知层：知识推荐 + SOP流程导航 + 相似工单 + 客户画像
- 排查步骤栏 + 决策树流程图
- 坐席端双区布局（内嵌区 + 侧栏区）
- 两个 Dify Agent（员工端AI + 坐席端Wingman）共用知识库
**完成标准**：坐席接会话→AI自动生成草稿→采纳/修改→发送；结单→自动摘要→确认存档
**开发周期**：4-6周
#### 阶段四：日志标准和AI知识库迭代
> **本阶段解决痛点**：痛点3（知识无法积累传承）+ 痛点4（管理缺乏数据支撑）。
**目标**：建立AI-人工协作闭环，坐席标注驱动AI知识库自动迭代，构建数据驱动的管理体系。
**现状 → 目标对比**：
| 维度 | 阶段三 | 阶段四目标 |
|------|--------|----------|
| AI回答质量保障 | 依赖坐席主观感受 | 坐席标注→AI自动分析→知识库自动优化 |
| 知识库维护 | 人工定期审查更新 | 千问自动分析标注数据，判断缺文档/信息过时 |
| 数据统计 | 无 | 坐席绩效看板 + AI回答质量看板 + 员工满意度统计 |
| 管理决策 | 凭感觉 | 数据支撑：响应时效/解决率/AI筛选率/知识库覆盖率 |
**范围**：
- 坐席标注AI回复正确/错误（嵌入日常工作流，不单独开标注页面）
- 千问自动分析待优化队列：缺文档→生成FAQ→推送RAGFlow；过时→标记→推送管理员审核
- 数据统计看板：坐席绩效/会话量/AI筛选率/员工满意度
- 日志标准：会话日志格式规范，支持后续审计和分析
- 跨企业共享（通过企微互联企业应用共享）
**完成标准**：坐席标注→千问分析→自动生成FAQ→推送RAGFlow→AI回答质量提升→闭环验证
**开发周期**：4-6周
#### 阶段五：自动/辅助审核、开单、结单
> **本阶段解决痛点**：多系统切换效率问题（延伸痛点4/5，进一步提升人效）。
**目标**：将工单/审批/设备异常等外部系统整合到坐席工作台，实现一站式闭环处理。
**现状 → 目标对比**：
| 维度 | 阶段四 | 阶段五目标 |
|------|--------|----------|
| 工单处理 | 坐席手动切到外部系统开单 | 坐席工作台内一键开单/结单 |
| 审批流程 | 坐席告知员工审批链接，员工自行操作 | 工作台内直接发起/审批 |
| 设备异常 | 坐席手动记录，另开系统处理 | 工作台内查看设备状态+派工+标记恢复 |
| 结单流程 | 坐席手动输入结单描述 | AI自动生成结单摘要→坐席确认→自动结单 |
| 审核机制 | 无 | AI辅助审核（检测遗漏步骤/不合规操作） |
**范围**：
- 待办事项面板（工单/审批/设备异常）
- 中间栏任务详情视图切换
- AI辅助填单（基于对话内容自动填写工单字段）
- AI辅助审核（检测遗漏步骤、不合规操作）
- AI辅助结单（自动生成结构化摘要）
- 外部系统API对接（ITSM/审批系统/设备管理）
**完成标准**：坐席接会话→AI辅助开单→处理→AI辅助审核→AI辅助结单→一站式闭环
**开发周期**：4-6周
### 5.3 阶段间降级兼容
> 每个阶段上线期间，现有生产环境必须保持可用，作为降级通道。
| 阶段 | 降级方案 | 触发条件 | 恢复条件 |
|------|---------|---------|---------|
| 阶段一 | 回退到原企微1对1AI机器人窗口 | H5页面无法访问 | H5服务恢复 |
| 阶段二 | 回退到关键字触发推送员工服务链接 | 坐席工作台故障 | 工作台恢复 |
| 阶段三 | 坐席关闭AI辅助，纯手动回复（功能降级，非切换） | Dify AI服务故障 | AI服务恢复 |
| 阶段四 | 数据统计暂时中断，坐席继续工作 | 分析服务故障 | 分析服务恢复 |
| 阶段五 | 回退到外部系统手动处理 | 工作台任务模块故障 | 模块恢复 |
---
## 6. 需求池 (Requirements Pool)
### P0 — Must Have（第一步必须交付）
| ID | 需求 | 说明 | 验收标准 |
|----|------|------|---------|
| P0-01 | 企微自建应用消息接收 | 通过企微回调URL接收员工消息 | 员工发送消息，服务器能收到并解析 |
| P0-02 | 企微自建应用消息发送 | 通过企微API向员工发送消息 | 服务器主动发消息，员工在企微应用中收到 |
| P0-03 | 消息路由层 | 所有消息先到路由层，按规则分发 | 新会话默认路由到坐席队列（第一步无AI） |
| P0-04 | 坐席会话列表 | 显示所有进行中的会话，含基本排序 | 按时间倒序，显示员工姓名、最后消息摘要 |
| P0-05 | 坐席对话区 | 显示选定会话的完整对话记录，可回复 | 消息实时显示，坐席可发送文本回复 |
| P0-06 | 员工同窗口体验 | 员工AI对话和人工服务在同一企微应用对话流 | 无需切换窗口，消息连续显示 |
| P0-07 | 会话状态管理 | 会话状态：排队中/服务中/已结单 | 数据库状态字段正确流转 |
| P0-08 | 测试环境隔离 | 在正式企微企业中测试可见范围隔离 | 测试用户可见，其他用户不可见 |
| P0-09 | 邀请功能-邀请发起 | 坐席在会话中可邀请其他员工/部门加入 | 坐席点击邀请→选人→确认→被邀请人收到企微通知 |
| P0-10 | 邀请功能-加入会话 | 被邀请人通过链接进入H5会话，可查看和回复 | 点击通知→H5加载→拉取历史→可发送消息 |
| P0-11 | 邀请功能-参与者管理 | 会话显示所有参与者，区分发起人/被邀请人 | 参与者列表可见，角色标识清晰 |
### P1 — Should Have（第一步应交付，第二步完善）
| ID | 需求 | 说明 | 验收标准 |
|----|------|------|---------|
| P1-01 | 会话标记系统 | VIP/举手/需介入/情绪标记 + 紧急度评分 | 标记在会话列表中正确显示，紧急度计算准确 |
| P1-02 | 会话列表排序 | 紧急→举手→需介入→活跃→AI处理中→已结单 | 排序规则生效，会话按紧急度排列 |
| P1-03 | VIP标记自动匹配 | 基于企微通讯录API规则匹配（总监及以上或关键部门） | 匹配规则可配置，VIP标记自动显示 |
| P1-04 | 举手标记 | 员工说"转人工"或关键词触发 | 关键词可配置，触发后自动举手 |
| P1-05 | 需介入标记 | 同一问题追问超过N轮(默认3轮)或AI判断需要人工 | N值可配置，自动触发标记 |
| P1-06 | 情绪标记（规则版） | 关键词规则匹配("急/紧急/马上/崩溃"等) | 关键词可配置，命中后自动标记 |
| P1-07 | 紧急度评分 | 公式：紧急度=基础分(关键词)+情绪加成+VIP加成+重复追问加成，1-5分映射 | 评分计算正确，映射为低/中/高/紧急/最高 |
| P1-08 | 置顶/代办 | 坐席手动操作，数据库加is_pinned和is_todo字段 | 操作后列表位置变化，数据持久化 |
| P1-09 | 坐席端AI助手面板 | AI建议回复/快速回复模板/操作步骤/风险提示/用户信息 | 5个模块在右栏显示，功能可用 |
| P1-10 | 用户端H5双栏 | 左侧对话区 + 右侧AI助手面板 | 企微应用内H5正确渲染双栏布局 |
| P1-11 | 摇人按钮 | 输入框左侧，橙色渐变铃铛图标，点击触发转人工 | 视觉交互符合设计稿，功能正确触发 |
| P1-12 | 趣味话术体系 | 存配置表，支持后台动态修改 | 6种场景话术正确触发，后台可修改 |
| P1-13 | 用户端AI助手面板 | 相似问题/审批流程/软件下载/知识库搜索 | 4个模块在右栏显示，未实现功能显示"即将上线"占位 |
| P1-20 | 邀请功能-历史消息共享 | 邀请时可选择共享历史消息模式（全部/最近10条/不共享） | 默认最近10条，被邀请人可查看共享的历史消息 |
| P1-21 | 邀请功能-部门批量邀请 | 可按部门批量邀请，勾选部门=邀请全部门成员 | 部门节点勾选后自动展开子成员，支持取消个别成员 |
| P1-22 | 邀请功能-系统消息广播 | 邀请成功/加入/退出时在会话中广播系统消息 | 所有参与者看到"XX邀请XX加入会话""XX已加入会话" |
| P1-23 | 文件上传 | 坐席/员工可发送文件附件（PDF/Word/Excel/压缩包等） | 文件可上传、存储、下载，大小限制可配置（默认20MB） |
| P1-24 | 满意度评价 | 会话结束后5星+表情评价，含文字反馈 | 评价弹窗正确弹出，数据正确存储，管理后台可查看统计 |
| P1-25 | 知识库基础 | FAQ手动维护，多级分类+关键词标签+搜索 | 管理后台可增删改查，RAGFlow检索可用，命中统计正确 |
### P2 — Nice to Have（第二步及之后交付）
| ID | 需求 | 说明 | 验收标准 |
|----|------|------|---------|
| P2-01 | AI前置筛选 | 新会话默认走AI，AI判断/用户触发转人工 | AI筛选率≥80% |
| P2-02 | 转人工触发配置 | 关键词/连续追问轮次/AI超时阈值写配置文件 | 配置文件修改后即时生效 |
| P2-03 | 排队系统 | 等待坐席接入的排队机制，含等待提示 | 排队人数/预计等待时间显示 |
| P2-04 | 对话日志标注 | 坐席标注AI回复正确/错误，嵌入日常工作流 | 标注操作在对话区内完成，不跳转页面 |
| P2-05 | AI知识库自动迭代 | 千问分析标注数据，判断缺文档/信息过时 | 自动生成FAQ推送RAGFlow，过时标记推送管理员 |
| P2-06 | 情绪标记（模型版） | 第二阶段迭代接入轻量模型替代关键词规则 | 模型推理准确率≥85% |
| P2-07 | 跨企业共享 | 通过企微"互联企业"应用共享 | 跨主体员工可使用同一服务 |
| P2-08 | AI建议回复动态生成 | 千问基于对话上下文+RAGFlow知识生成建议回复 | 建议回复采纳率≥30% |
| P2-09 | 操作步骤AI动态生成 | 替代静态配置，AI动态生成问题解决步骤 | 步骤可操作性强，坐席可直接转发 |
| P2-10 | 风险提示AI动态判断 | 替代已知故障匹配，AI动态风险判断 | 关键风险不遗漏 |
| P2-11 | 自动摘要 | 会话结束后AI自动生成摘要（问题描述+解决步骤+后续行动） | 摘要自动生成，内容准确完整，坐席可编辑 |
| P2-12 | 数据看板 | 整体概览+坐席绩效+问题分布+AI效果+趋势分析 | 看板正确显示指标，数据更新及时，支持导出 |
---
## 7. 并行协作模式
### 7.1 核心设计理念
传统"串行排队"改为"并行协作"——AI和人工并行，AI全程在场，人工随时介入。
### 7.2 坐席看板分区
| 区域 | 说明 | 坐席是否主动看 |
|------|------|---------------|
| AI自主处理区 | AI处理简单问题 | 折叠，默认不展开 |
| 举手等待区 | 员工明确要求人工或AI识别异常 | 核心关注区 |
| 人工处理区 | 当前坐席正在处理 | 我的会话 |
| 已结单区 | 会话已结束 | 灰色，折叠 |
### 7.3 会话标记系统详细设计
| 标记类型 | 图标颜色 | 触发条件 | 数据来源 |
|---------|---------|---------|---------|
| VIP标记 | 红色 | 企微通讯录API规则匹配（总监及以上或关键部门） | 企微通讯录 |
| 举手标记 | 黄色 | 员工说"转人工"或关键词触发 | 消息内容匹配 |
| 需介入标记 | 橙红色🔔 | 同一问题追问超过N轮(默认3轮)或AI判断需要人工 | 对话轮次计数 + AI判断 |
| 情绪标记 | 红色 | 第一阶段：关键词规则("急/紧急/马上/崩溃"等)；第二阶段：轻量模型 | 消息内容分析 |
### 7.4 紧急度评分公式
```
紧急度 = 基础分(关键词) + 情绪加成 + VIP加成 + 重复追问加成
```
- 评分范围: 1-5分
- 映射: 1=低, 2=中, 3=高, 4=紧急, 5=最高
### 7.5 会话列表排序规则
```
紧急 → 举手 → 需介入 → 活跃 → AI处理中 → 已结单
```
---
## 8. 界面设计
### 8.1 用户信息去重规则
| 区域 | 显示内容 | 不显示 |
|------|---------|--------|
| 左栏（会话列表） | 姓名头像 + 标签 + 最后消息摘要 | 办公地点 |
| 中栏（对话区） | 姓名 + 标签（VIP/举手/需介入） | 部门/岗位/等级 |
| 右栏（AI助手面板） | 部门/岗位/等级/完整信息 | — |
### 8.2 用户端界面
**布局**: 企微H5双栏
- **左侧**: 对话区
- AI回复和人工回复在同一对话流
- AI回复后附带3张推荐卡片（相似问题、下载入口、审批流程）
- 摇人按钮在输入框左侧
- 底部引导条："点击 摇人 = 一键呼叫 IT 坐席"
- **右侧**: AI助手面板
- 相似问题与做法（RAGFlow语义检索，异步加载）
- 审批流程链接（静态映射表，存数据库/配置文件）
- 软件下载快捷入口（分类到下载链接映射，显示版本号和平台）
- 知识库搜索（用户主动触发，加防抖300ms）
- **功能未实现前预留占位符+"即将上线"灰字提示**
### 8.3 坐席端界面
**布局**: 三栏
- **左栏**: 会话列表
- 排序 + 彩色标签 + 红点 + 未读消息数
- **中栏**: 对话区
- AI回复和坐席回复明确区分
- AI建议条
- 操作按钮
- **右栏**: AI助手面板（5个模块）
- AI建议回复（采纳/编辑后采纳/忽略）
- 快速回复模板（按问题分类，支持变量替换{员工姓名}等）
- 问题解决操作步骤
- 风险提示
- 用户特点和其他注意事项（基本信息+VIP标记+历史咨询模式+坐席备注）
---
## 9. 摇人功能设计
### 9.1 视觉设计
| 属性 | 值 |
|------|------|
| 位置 | 输入框左侧，和微信语音按钮同样的位置 |
| 图标 | 铃铛图标 |
| 颜色 | 橙色渐变(#FF6B35→#FF8F5E) |
| 右上角 | 红点 |
| 尺寸 | 44px圆形 |
| Hover | 放大110%弹性回弹 |
| 点击 | 0.6秒摇晃动画 |
### 9.2 趣味话术体系
| 触发场景 | 话术 | 语气 | 存储方式 |
|---------|------|------|---------|
| 点击摇人按钮 | 大哥，俺这就去摇人，稍等... | 亲切 | 配置表 |
| 关键词触发转人工 | 收到！这就帮您摇位大神来 | 稍正式 | 配置表 |
| 排队等待(30秒无人接单) | 人还在路上，别急别急～ | 安抚 | 配置表 |
| 坐席接入 | 人摇来了！IT坐席为您服务 | 明确交接 | 配置表 |
| 等待超时(2分钟) | 坐席都在忙，不过AI还在呢，要不先聊聊？我再继续摇 | 降级安抚 | 配置表 |
| VIP员工(自动切换) | 这就帮您安排专家，请稍候 | 正式 | 配置表 |
> **配置管理**: 话术存配置表，支持后台动态修改，无需发版。
---
## 10. 术语与图标规范
> **新增日期**: 2026-06-11
> **整合自**: `PRD-增量-人工按钮与术语统一.md`
### 10.1 核心概念定义
| 术语 | 定义 | 触发者 | 接收者 | 图标 | 使用范围 |
|------|------|--------|--------|------|----------|
| **人工** | 用户呼叫坐席，请求人工服务 | H5用户端员工 | IT坐席 | 传菜铃（桌面拍铃）SVG | 用户端H5 + 坐席端（状态指示） |
| **摇人** | 主责坐席呼叫其他坐席进入群聊协助 | IT坐席 | 其他IT坐席 | 👋 招手 | 仅坐席端 |
| ~~**举手**~~ | **已取消** | — | — | — | 全局移除 |
### 10.2 "人工"按钮需求
#### 10.2.1 产品定义
**"人工"** = 用户（员工）主动呼叫IT坐席，请求人工服务。
| 属性 | 定义 |
|------|------|
| 触发者 | H5用户端员工 |
| 接收者 | IT坐席（主责坐席或系统分配坐席） |
| 图标 | 传菜铃（桌面拍铃）—— 前台/厨房放在桌面、拍一下发出"叮"声的圆形金属铃铛 |
| 区别于 | "摇人" = 坐席呼叫其他坐席 |
> **图标说明：传菜铃 vs 摇铃**
> - ✅ **传菜铃**（正确）：圆形金属铃铛，放在桌面上，从上方拍打铃面发出"叮"声。代表"我已提出问题，请人工来看一下"。
> - ❌ **摇铃** 🔔（错误）：有把手的手摇铃，摇动发出声响。当前代码中使用的是此图标，需替换。
#### 10.2.2 按钮设计
**位置**：H5聊天界面标题栏右侧
**形态**：
```
┌────────────────────────────────────┐
│ 智能IT支持服务台 [🔔 人工] │ ← 启用状态（橙色）
│ [▓▓ 人工] │ ← 禁用状态（灰色）
└────────────────────────────────────┘
```
**图标规范**：
- 启用状态：传菜铃SVG图标 + 橙色系配色 `#FF9800`
- 禁用状态：传菜铃SVG图标 + 灰色 `#9E9E9E`，按钮整体 `opacity: 0.5; cursor: not-allowed`
#### 10.2.3 启用条件
按钮在以下任一条件满足时**启用**（橙色，可点击）：
| # | 条件 | 说明 |
|---|------|------|
| 1 | **问题已确定** | AI已识别问题类型（`problem_confirmed = true`） |
| 2 | **会话交互达3次** | 用户与AI的对话轮次 ≥ 3（不含：直接呼叫人工的消息、问候语如"你好""hi"） |
**禁用状态**（灰色，不可点击）：
- 以上条件均未满足时
- 显示 `title="请先描述您的问题，AI将为您匹配最佳坐席"`
#### 10.2.4 坐席端联动
坐席端对应位置的按钮/状态指示也使用**传菜铃**图标：
| 位置 | 当前状态 | 目标状态 |
|------|---------|---------|
| 会话列表 - 标签 | "举手"黄色标签 | "人工"橙色标签 + 传菜铃图标 |
| 会话列表 - 排序权重 | `hand_raise` 标记 | `human_requested` 标记 |
| 聊天区 - 系统消息 | "员工摇人请求人工" | "员工请求人工服务🔔" |
#### 10.2.5 坐席离线状态
当无坐席在线时：
- H5标题栏坐席状态显示：**灰色圆点 + "坐席离线"**
- "人工"按钮：保持可见但**禁用**（灰色），`title="当前无在线坐席，请稍后再试或继续与AI对话"`
### 10.3 "摇人"详细规范
**含义**：主责坐席在处理会话时，邀请其他坐席进入当前会话协助。
**触发方式**：
- 坐席点击聊天区"🤝 摇人"按钮 → 弹出 InviteDialog.vue
**与"人工"的区别**：
| 维度 | 人工 | 摇人 |
|------|------|------|
| 触发者 | 用户（员工） | 主责坐席 |
| 接收者 | IT坐席 | 其他IT坐席 |
| 目的 | 请求人工服务 | 协作处理复杂问题 |
| 图标 | 传菜铃 SVG | 👋 招手 |
| 对应代码 | `human_requested` | `collaborating_agent_ids` |
### 10.4 全局取消"举手"概念
**涉及范围**：
| 类别 | 涉及位置 | 改动说明 |
|------|---------|---------|
| **代码变量名** | `hand_raise`, `hand_raise_keywords` | 标记为 `@deprecated`，重构为 `human_requested` |
| **数据库字段** | `tags` JSON中的 `hand_raise: true` | 保持兼容，新增 `human_requested: true` |
| **前端状态** | `store.tags.hand_raise` | 改为 `store.tags.human_requested` |
| **UI文案** | "举手标签"、"举手标记" | 改为"人工标签"、"人工请求标记" |
### 10.5 图标汇总表
| 场景 | 图标 | 说明 |
|------|------|------|
| H5用户端 - "人工"按钮 | 传菜铃 SVG | 橙色，启用状态 |
| H5用户端 - "人工"按钮（禁用） | 传菜铃 SVG | 灰色，`opacity: 0.5` |
| 坐席端 - 会话列表"人工"标签 | 传菜铃 SVG + "人工"文字 | 橙色标签 |
| 坐席端 - "摇人"按钮 | 👋 | 招手emoji |
| 坐席离线状态 | ⚪ 灰色圆点 | CSS: `background-color: #9E9E9E` |
### 10.6 传菜铃SVG参考
```svg
```
### 10.7 改动清单摘要
| 类别 | 改动范围 |
|------|---------|
| 前端 | H5按钮文案+图标、坐席端标签、状态管理 |
| 后端 | 新增 `human_requested` 字段，标记 `hand_raise` 为 deprecated |
| 文档 | 全局替换"举手"为"人工" |
---
## 11. 技术约束
> **更新日期**: 2026-07-04 | **状态**: 部分约束已过时，需迭代更新
| 约束项 | 说明 | 当前状态 |
|--------|------|----------|
| 消息通道 | 企微自建应用消息API，禁止使用微信客服能力 | ✅ 约束中 |
| 前端框架 | Vue3 + ElementPlus | ✅ 已采用 |
| 后端框架 | FastAPI + Redis + PostgreSQL | ✅ 已采用 |
| 部署方式 | Docker 容器化部署（Docker Compose 一键启停） | ✅ 已采用 |
| 用户端渲染 | 企微H5（方式B：双栏布局，非对话卡片内方式A） | ✅ 已采用 |
| 坐席端通信 | 使用WebSocket实时推送（2026-07已实现） | ⚠️ 已变更 |
| AI接入 | 已接入Dify/RAGFlow/千问 | ⚠️ 已变更 |
| 排队系统 | 阶段二已实现 | ⚠️ 已实现 |
| 跨企业共享 | 阶段四规划中 | ⚠️ 规划中 |
| 开发者 | 宋献，IT支持组组长，开发零基础，通过学习+AI辅助完成开发 | ✅ 持续进行 |
| 企微设备管理 | 企微设备管理API | ❌ 付费功能，公司未购买 |
---
## 12. 数据模型核心设计
### 11.1 会话表 (conversations)
| 字段 | 类型 | 说明 |
|------|------|------|
| id | UUID | 会话ID |
| employee_id | String | 企微员工ID |
| employee_name | String | 员工姓名 |
| department | String | 部门 |
| position | String | 岗位 |
| level | String | 等级 |
| status | Enum | 会话状态: ai_handling / queued / serving / resolved |
| is_vip | Boolean | VIP标记 |
| is_pinned | Boolean | 置顶标记 |
| is_todo | Boolean | 代办标记 |
| urgency_score | Integer | 紧急度评分(1-5) |
| tags | JSON | 标签集合(举手/需介入/情绪等) |
| assigned_agent_id | String | 分配的坐席ID |
| created_at | DateTime | 创建时间 |
| updated_at | DateTime | 更新时间 |
### 11.2 消息表 (messages)
| 字段 | 类型 | 说明 |
|------|------|------|
| id | UUID | 消息ID |
| conversation_id | UUID | 所属会话ID |
| sender_type | Enum | 发送者: employee / agent / ai / system |
| sender_id | String | 发送者ID |
| content | Text | 消息内容 |
| msg_type | Enum | 消息类型: text / image / file |
| ai_suggestion | Boolean | 是否为AI建议(坐席端) |
| is_read | Boolean | 是否已读 |
| created_at | DateTime | 创建时间 |
### 11.3 坐席表 (agents)
| 字段 | 类型 | 说明 |
|------|------|------|
| id | UUID | 坐席ID |
| user_id | String | 企微用户ID |
| name | String | 坐席姓名 |
| status | Enum | 在线/离线/忙碌 |
| current_load | Integer | 当前服务会话数 |
| created_at | DateTime | 创建时间 |
---
## 13. 待确认问题 (Open Questions)
| # | 问题 | 影响范围 | 建议 |
|---|------|---------|------|
| OQ-01 | 坐席数量上限：第一步测试环境计划支持几个坐席同时在线？ | 服务器资源/轮询频率 | 建议3-5个坐席 |
| OQ-02 | 消息存储策略：会话记录保留多久？是否需要归档机制？ | 数据库容量/合规要求 | 建议6个月热数据+归档 |
| OQ-03 | 多媒体消息：M1支持文件上传，图片共享留到M2 | 企微API对接范围 | M1支持文本+文件上传，图片共享M2再评估 |
| OQ-04 | 坐席排班：是否需要坐席排班/轮班功能？ | 坐席管理模块 | 建议第二步考虑 |
| OQ-05 | 满意度评价：会话结束后是否需要员工评价？ | 用户端界面/数据收集 | 建议第二步增加 |
| OQ-06 | 企微应用命名：自建应用在企微中显示的名称？ | 用户感知 | 建议命名"IT服务台" |
| OQ-07 | 坐席端权限：是否区分坐席/组长/管理员角色？ | 权限系统设计 | 建议第一步简单区分，第二步完善 |
| OQ-08 | 企微互联企业应用共享范围：共享给哪些上下游企业？ | 跨企业功能边界 | 第三步确认 |
| OQ-09 | AI回复末尾提示语："以上为AI自动回复，如需人工帮助请回复'转人工'"——是否需要可配置？ | 第二步AI接入 | 建议存配置表 |
| OQ-10 | 转人工阈值：AI调用超时3秒是否需要可配置？ | 第二步AI接入 | 建议写配置文件 |
---
## 14. 里程碑与交付物
| 里程碑 | 预计周期 | 核心交付物 | 现有系统变化 |
|--------|---------|-----------|------------|
| 阶段一：转人工改H5+坐席工作台MVP | 6-8周 | H5登录+身份识别 + 转人工链接改H5 + 坐席工作台MVP（会话列表+聊天+快速回复+邀请功能，不含AI） | AI转人工链接从员工服务改为H5，坐席使用自研工作台 |
| 阶段二：智能咨询集成 | 5周 | H5全流程 + 敲桌子 + 双通道推送 + AI建议面板 + 排队 + 评分 | 员工服务入口逐步迁移至H5，坐席工作台增强 |
| 阶段三：坐席辅助回复/判断 | 4-6周 | AI Wingman（草稿+摘要+知识+排查步骤）+ 双区布局 | 坐席从员工服务后台切换至自研工作台 |
| 阶段四：日志标准+知识库迭代 | 4-6周 | 标注系统 + AI知识库自动优化 + 数据看板 + 跨企业共享 | AI知识库从人工维护升级为自动迭代 |
| 阶段五：自动/辅助审核开单结单 | 4-6周 | 待办面板 + AI填单/审核/结单 + 外部系统对接 | 替代多系统切换，统一工作台闭环 |
---
## 15. AI Wingman — 坐席智能辅助设计
> **设计日期**: 2026-06-04 | **设计者**: 宋献 | **状态**: 方案已确认，待开发
### 14.1 设计理念
传统IT服务台的设计重心偏向"员工端体验"——让员工更快获得答案。但**坐席人员的工作体验同样关键**。IT坐席每天面对大量重复性问题（密码重置、账号解锁、VPN连接），同时承受员工焦虑情绪传导带来的心理消耗。
**AI Wingman 的核心使命**：让AI不仅服务员工，更是坐席的"智能副驾驶"——消灭重复劳动、增强认知能力、守护情绪健康。
```
┌─────────────────────────────────────────────────────────────────────┐
│ AI Wingman 三层设计架构 │
│ │
│ ┌─────────────────────────────────────────────────────────────────┐│
│ │ 情感层 · 守护情绪健康 ││
│ │ 情绪识别预警 → 安抚话术推荐 → 语气润色 → 正向激励 → 疲劳检测 ││
│ │ 目标：减少坐席情绪耗竭 45%，降低职业倦怠风险 ││
│ └─────────────────────────────────────────────────────────────────┘│
│ ┌─────────────────────────────────────────────────────────────────┐│
│ │ 认知层 · 消除认知负荷 ││
│ │ 知识推荐 → SOP流程导航 → 相似工单推荐 → 下一步建议 → 客户画像 ││
│ │ 目标：降低坐席认知负荷 55%，新人上手周期缩短 50% ││
│ └─────────────────────────────────────────────────────────────────┘│
│ ┌─────────────────────────────────────────────────────────────────┐│
│ │ 效率层 · 消灭重复劳动 ││
│ │ AI草稿回复 → 会话自动摘要 → 智能填单 → 自动标签 → 快捷回复库 ││
│ │ 目标：坐席打字量减少 80%，单次会话处理时间缩短 60% ││
│ └─────────────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────────────┘
```
### 14.2 行业最佳实践验证
调研了 NiCE Copilot、Helpshift AI Copilot、Zendesk Agent Assist、天润融通、循环智能、合力亿捷等 7 家主流解决方案，提炼出关键数据：
| 行业基准数据 | 数值 | 来源 |
|-------------|------|------|
| AI草稿回复可减少坐席打字量 | 70%-80% | 天润融通、合力亿捷实测 |
| 自动填单节省时间 | 从1分钟降至10秒 | 天润融通实测 |
| 知识推荐缩短新人上手 | 50% | 循环智能实测 |
| 情绪识别预警准确率 | 85%+ | Helpshift 实测 |
| 自动摘要节省文书记录时间 | 70% | 合力亿捷实测 |
**5 大设计原则**（行业共识）：
1. **非侵入式** — AI 辅助不干扰坐席原生工作流
2. **坐席始终主导** — AI 只建议，不自动发送，坐席始终有最终决定权
3. **反馈闭环** — 采纳/编辑/忽略行为持续优化 AI 推荐质量
4. **上下文继承** — AI → 人工切换时完整上下文（对话历史、客户画像、AI诊断）无缝跟随
5. **渐进式赋能** — 每阶段独立可用，不依赖后续阶段
### 14.3 新增用户故事（坐席端）
| # | 角色 | 故事 | 验收标准 |
|---|------|------|---------|
| US-8 | IT坐席 | 当我接到一个会话时，AI 已经帮我生成了草稿回复，我只需审核后点击发送，不用从头打字 | 每条新员工消息自动生成 1 个 AI 草稿，[采纳]/[编辑]/[忽略] 三选一 |
| US-9 | IT坐席 | 当我完成一个会话时，系统自动生成结构化摘要（问题/原因/解决方案），我只需确认或微调 | 会话结单时自动弹出摘要确认框，坐席可编辑后确认，确认后存入 messages 表 |
| US-10 | IT坐席 | 在处理复杂问题时，右侧自动显示知识库中的相关文档和操作步骤，不用切屏搜索 | 基于当前对话上下文，自动检索知识库并推送 Top 3 相关文档 |
| US-11 | IT坐席 | 当员工情绪激动时，AI 提醒我注意语气，并推荐安抚话术，帮助我平和应对 | 情绪关键词触发预警图标，自动推荐 1-2 条安抚话术，支持一键发送 |
| US-12 | IT坐席 | 我希望看到"历史上类似问题是怎么解决的"，避免重复调查 | 基于当前问题自动搜索历史已结单会话，展示相似工单及解决方案 |
| US-13 | IT主管 | 我希望了解坐席团队的工作效率和情绪健康状态，及时发现职业倦怠信号 | 仪表盘展示响应时效、会话时长、情绪事件统计、坐席疲劳指数 |
### 14.4 Phase 1 实施方案：效率层（已确认）
**双区布局设计**：
- **内嵌区（对话流中）**：针对当前员工消息的 AI 草稿回复，以特殊气泡样式显示在对话流中，[采纳]/[编辑]/[忽略] 按钮内嵌
- **侧栏区（右侧面板）**：会话自动摘要、自动标签、快捷回复库、相关知识推荐
**内嵌区 vs 侧栏区的设计逻辑**：
| 功能 | 呈现位置 | 理由 |
|------|---------|------|
| AI草稿回复 | **内嵌**（对话流中） | 与当前对话上下文紧密相关，坐席需逐条审核 |
| 会话自动摘要 | **侧栏** | 会话结束后查看，不干扰实时对话 |
| 知识推荐 | **侧栏** | 参考性信息，按需查阅 |
| 快捷回复模板 | **侧栏** | 已有功能，保持一致性 |
| 自动标签 | **侧栏** | 批次操作，不打断对话流 |
**底层实现**：扩展现有 Dify —— 新增一个 `assistant` 类型的 Dify Agent，与员工端 AI 共用知识库，但 system prompt 侧重"辅助坐席回复"而非"直接回复员工"。
| Agent | 用途 | system prompt 侧重 |
|-------|------|-------------------|
| Agent 1 — 员工端 AI（已有） | 回答员工问题 | 友好、准确、引导自助 |
| Agent 2 — 坐席端 Wingman（新增） | 为坐席生成草稿/摘要/知识 | 专业、结构化、可操作 |
### 14.5 Phase 2+ 前置规划
| 阶段 | 功能 | 核心价值 | 预计周期 |
|------|------|---------|---------|
| Phase 1 效率层 | AI草稿 + 自动摘要 + 自动标签 | 消灭重复劳动 | 2-3 周 |
| Phase 2 认知层 | 知识推荐 + SOP导航 + 相似工单 + 客户画像 | 降低认知负荷 | 3-4 周 |
| Phase 3 情感层 | 情绪识别 + 安抚话术 + 语气润色 + 疲劳检测 | 减少情绪消耗 | 4-6 周 |
### 14.6 新增需求池
**P1 — Should Have（AI Wingman 效率层）**
| ID | 需求 | 说明 | 验收标准 |
|----|------|------|---------|
| P1-14 | AI草稿回复 | 每条新员工消息自动生成AI建议回复，坐席可采纳/编辑/忽略 | 草稿生成 <3秒，内嵌在对应的员工消息下方 |
| P1-15 | 会话自动摘要 | 会话结单时AI自动生成结构化摘要（问题/原因/解决方案） | 摘要包含 3 个结构化字段，坐席可编辑后确认 |
| P1-16 | 自动标签 | AI基于对话内容自动建议会话标签（如：账号问题/网络故障） | 标签建议在结单时弹出，支持添加自定义标签 |
| P1-17 | AI建议采纳追踪 | 记录坐席对AI建议的采纳/编辑/忽略行为 | 每个AI建议的操作记录到 messages 表 |
**P2 — Nice to Have（认知层 + 情感层）**
| ID | 需求 | 说明 | 验收标准 |
|----|------|------|---------|
| P2-11 | 知识推荐 | 基于对话自动检索知识库，推送 Top 3 相关文档 | 推荐刷新 <2秒，链接可点击跳转 |
| P2-12 | SOP流程导航 | 高频问题预置SOP步骤，引导标准流程 | SOP步骤可勾选完成，支持动态调整 |
| P2-13 | 相似工单推荐 | 搜索历史已结单会话，展示相似问题及解决方案 | 相似度排序，展示 Top 5 |
| P2-14 | 客户画像 | 展示员工历史咨询模式、技术偏好等 | 画像自动提取，支持坐席补充 |
| P2-15 | 情绪识别预警 | 检测员工消息情绪，坐席端预警图标 | 关键词+语气分析，准确率 ≥ 85% |
| P2-16 | 安抚话术推荐 | 检测到情绪波动时自动推荐安抚话术 | 话术可一键发送，支持自定义 |
| P2-17 | 语气润色 | 检查坐席即将发送的消息，提示语气问题 | 仅提示不拦截，坐席可选择忽略 |
| P2-18 | 正向激励 | 会话满意结单时向坐席发送正向反馈 | 激励信息以系统消息方式推送 |
| P2-19 | 坐席疲劳检测 | 统计连续工作时间、情绪事件次数，提醒休息 | 阈值可配置，温和提示 |
---
## 16. v5.3 坐席工作台增量需求
> 以下内容合并自 PRD-v53-incremental.md（2026-06-06），为 §16 v5.3 坐席工作台增量需求的子章节。
---
## 16.1 产品定义
### 16.1.1 产品目标
1. **提升坐席效率**：通过 AI 推荐回复（Ctrl+1/2/3 快捷填入）、键盘驱动的快速回复（Alt+1~5 + ↑↓ + Enter）、排查步骤流程图，将坐席平均响应时间降低 30%
2. **增强信息感知**：通过优先级图标体系（⛔阻断性/👥影响范围/⭐角色等级/🔁重复问题）、用户情绪状态芯片、IT 等级徽标，让坐席在 3 秒内掌握会话全貌
3. **统一工作闭环**：通过待办事项面板 + 中间栏视图切换，将工单/审批/设备异常等任务类型整合到同一工作台，消除多系统切换成本
### 16.1.2 用户故事
| # | 用户故事 |
|---|---------|
| US-1 | **As a** IT 坐席, **I want** 在会话列表每条会话上直接看到阻断性/影响范围/角色等级/重复问题等优先级图标, **so that** 我能快速判断哪些会话需要优先处理，不必逐一点开查看详情 |
| US-2 | **As a** IT 坐席, **I want** 在聊天区顶部常驻显示用户情绪、等待时长、IT 等级等信息芯片，点击展开 6 卡片详情, **so that** 我在对话过程中始终掌握用户画像，及时调整沟通策略 |
| US-3 | **As a** IT 坐席, **I want** 在聊天区内看到 1-3 条 AI 推荐回复并支持 Ctrl+1/2/3 快捷填入, **so that** 我能快速回复常见问题，减少手动输入时间 |
| US-4 | **As a** IT 坐席, **I want** 点击左侧待办事项时中间栏切换为任务类型专属页面（工单/审批/设备异常）, **so that** 我无需切换到其他系统即可一站式处理所有任务 |
| US-5 | **As a** IT 坐席, **I want** 在右栏通过 Alt+1~5 切换快速回复分类、↑↓ 导航、Enter 确认填入, **so that** 我可以在不离开键盘的情况下高效完成回复 |
---
## 16.2 需求池（P0/P1/P2）
### P0 — 必须完成（核心体验）
---
#### FE-01 主题系统
| 项目 | 说明 |
|------|------|
| **需求** | 浅色/深色主题切换 |
| **交互** | 顶部工具栏右侧添加 ☀️/🌙 切换开关（Track + Thumb 滑块样式），点击即切换 |
| **实现** | `data-theme="light\|dark"` 属性切换；CSS 变量驱动两套配色（`:root` 浅色 / `[data-theme="dark"]` 深色） |
| **持久化** | 切换后写入 `localStorage`，页面加载时读取恢复 |
| **约束** | 切换即时生效，过渡时长 ≤ 300ms（`transition: background 0.3s, color 0.3s`）；所有新增组件必须兼容双主题 |
| **设计规格** | 深色主题：主背景 `#0f1923`，次背景 `#151f2b`，三级背景 `#1a2736`，悬停 `#1e3044`，激活 `#243b52`；主文字 `#e8edf2`，次文字 `#8ba1b7`；强调色 `#4da6ff` |
| **变更范围** | `Workspace.vue` 顶部栏重构为独立 `TopBar.vue`；新增 `composables/useTheme.ts`；`global.css` 新增深色 CSS 变量 |
---
#### FE-02 左栏会话列表 — 三段折叠 + 搜索增强 + 优先级图标
| 项目 | 说明 |
|------|------|
| **三段折叠** | 替代原 6 区结构，改为 3 段：📌 我的会话（默认展开）/ 👥 同事会话（默认折叠）/ 🕐 历史会话（默认折叠） |
| **段头交互** | 段头背景 `var(--bg-tertiary)`，hover 变 `var(--bg-hover)`；显示条目数量（药丸徽标）+ 折叠箭头（▼ 旋转 -90° 收起）；点击整行切换折叠 |
| **搜索增强** | 搜索框 placeholder "搜索用户、关键词..."；下方增加快捷筛选标签：全部/待处理/进行中/已完成（药丸样式，active 态 `var(--accent-soft)` + `var(--accent)` 色） |
| **优先级图标** | 每条会话名称右侧显示：⛔ 阻断性（`is_blocking`，红底）、👥 影响范围（`impact_scope`，>5 人用高对比色）、⭐ 角色等级、🔁 重复问题。**不显示 IT 等级徽标** |
| **优先级图标规格** | 16×16px 圆角方块，8px 字体；`pi-blocked` 红底、`pi-impact` 黄底（high 变红底）、`pi-role` 紫底、`pi-repeat` 橙底 |
| **会话条目规格** | 条目间距 `margin: 1px 6px`，padding `8px 10px`；active 态 `var(--accent-soft)` + accent 边框；"待回复" 红色药丸标签 |
| **变更范围** | `ConversationList.vue` 重构分区逻辑 + 搜索标签；`ConversationItem.vue` 新增优先级图标渲染 |
---
#### FE-03 左栏底部 — 待办事项面板
| 项目 | 说明 |
|------|------|
| **位置** | 左栏底部，`border-top: 1px solid var(--border)`，`max-height: 220px`，内部滚动 |
| **标题** | "待办事项" + 紧急数量红色标记（如 "5 紧急"） |
| **条目** | 每条显示：优先级圆点（urgent 红 / high 黄）+ 文本 + 类型标签（工单/审批/设备）+ 时间 |
| **类型标签样式** | 工单：蓝底蓝字蓝边框；审批：紫底紫字紫边框；设备：橙底橙字橙边框（9px 字体） |
| **点击交互** | 点击条目 → 中间栏切换为对应任务类型详情视图 |
| **底部统计** | 在线/忙碌/离线坐席数（带状态圆点） |
| **变更范围** | `ConversationList.vue` 底部新增 `TodoPanel.vue` |
---
#### FE-04 中栏聊天区 — 用户信息栏
| 项目 | 说明 |
|------|------|
| **常驻区** | 替代原顶部标题栏，显示：头像（36px 圆形渐变）+ 姓名·部门岗位 + IT 等级徽标 + 信息 chips + 展开箭头 |
| **信息 chips** | 😟 情绪（黄底黄边）、⏱ 等待时长、💬 对话轮次、🔁 重复标记（红底红边）、📝 备注标记（紫底紫边）；默认态灰底 |
| **展开详情** | 点击整行展开/收起 6 卡片详情面板（3 列 grid 布局）：① 情绪状态 ② 会话详情 ③ 问题分析 ④ IT 技能等级 ⑤ 历史工单 ⑥ 其他备注 |
| **IT 等级徽标** | 7 级段位（见 §4.2），显示在用户名行 + 详情卡片 ④ 中 |
| **动画** | 展开箭头旋转 180°，详情面板 `max-height` 动画过渡 0.35s |
| **变更范围** | 新增 `UserInfoBar.vue` + `ItLevelBadge.vue`；`ChatArea.vue` 替换顶部栏 |
---
#### FE-05 中栏聊天区 — AI 推荐回复（内联）
| 项目 | 说明 |
|------|------|
| **位置** | 聊天消息流中，用户消息之后、坐席回复之前 |
| **触发条件** | 仅坐席未回复时显示；坐席发送回复后自动隐藏 |
| **样式** | 虚线边框（`1px dashed var(--accent)`）+ 浅蓝背景，全宽 |
| **内容** | "🤖 AI 推荐回复" 标签 + 1-3 个推荐选项卡片（横向排列，flex:1） |
| **快捷键** | Ctrl+1 / Ctrl+2 / Ctrl+3 快捷填入回复框 |
| **点击** | 点击卡片内容填入回复框并聚焦 |
| **变更范围** | 新增 `AiRecommendInline.vue`；修改 `ChatArea.vue` 消息渲染逻辑 |
---
#### FE-06 中栏聊天区 — 排查步骤栏
| 项目 | 说明 |
|------|------|
| **位置** | 聊天输入框下方，始终可见（不可整体收起） |
| **栏头** | "🔧 排查步骤" + "▶ 展开全流程图" 按钮（accent 色边框药丸） |
| **默认视图** | 最优路径横向方块：① 确认版本 → ② 清除缓存 → ③ 远程排查 → ...（可横向滚动） |
| **路径方块规格** | padding `7px 14px`，圆角方块；done 态绿底、current 态蓝底、默认灰底；hover 变 accent 边框 |
| **展开视图** | 点击 "展开全流程图" → 按钮文字变 "▼ 收起全流程图"，下方展开完整决策树 |
| **决策树规格** | 纵向步骤：圆点节点（22px）+ 连接线（2px）；判断节点（❓ 判断）黄底方块；分支用虚线左侧缩进；当前步骤蓝色节点，已完成绿色节点 |
| **动画** | 流程图区 `max-height` 过渡 0.35s；按钮箭头旋转 90° |
| **数据源** | 静态模板库（`TroubleshootingTemplate` 模型），P0 坐席手动选择模板 |
| **变更范围** | 新增 `TroubleshootBar.vue`；`ChatArea.vue` 底部挂载 |
---
#### FE-07 中栏 — 任务详情视图切换
| 项目 | 说明 |
|------|------|
| **触发** | 点击左栏待办事项条目 → 中间栏从聊天视图切换为任务详情视图 |
| **返回** | "← 返回会话" 按钮，切换回聊天视图 |
| **运维工单页** | 📋 工单描述卡片（标题/类型/优先级/上报人/时间/描述）+ 📍 处理进度卡片（状态/接单人/SLA）+ 操作按钮：📥 接单 / 🔧 开始处理 / ✅ 结单 / 🔄 转派 |
| **审批单页** | 📝 审批内容卡片 + ✏️ 审批意见输入区（textarea）+ 操作按钮：✅ 审批通过 / ❌ 拒绝审批 / 🔄 转交审批 |
| **设备异常页** | 🖥 设备状态网格（2×3 grid：名称/型号/在线状态/最后在线/IP/告警次数）+ 🔧 处理记录卡片 + 操作按钮：📝 一键开单 / 🚚 派工 / ✅ 标记恢复 / 📅 加入巡检 |
| **卡片规格** | 白底 + border + `radius-lg`(10px) + padding `14px 16px`；标签行 `tic-label`(70px) + `tic-value` |
| **状态色值** | 正常=success绿、告警=warning黄、异常=danger红 |
| **变更范围** | 新增 `TaskDetailView.vue`（含 3 种子视图）；`ChatArea.vue` 同级添加视图切换逻辑 |
---
#### FE-08 右栏 AI 助手面板重构
| 项目 | 说明 |
|------|------|
| **重构** | 移除现有 5 Tab 结构（`ElTabs`），改为上下两个区域 |
| **上方 ~1/3** | 🤖 AI 智能推荐区（`flex-shrink:0`，border-bottom 分隔）：标题栏（左侧蓝色竖线 3×12px + "🤖 AI 智能推荐"）+ 1-3 张推荐卡片 |
| **推荐卡片** | 灰底 + border，hover 变 accent 边框；卡片头：方案名称 + 置信度药丸（如 "92%"）；卡片文本：2 行截断；快捷键提示 `Ctrl+1/2/3` |
| **下方 ~2/3** | 快速回复区（`flex:1`，内部列布局）：搜索栏置顶 + 分类标签栏 + 回复条目列表 + 底部键盘指南 |
| **分类标签** | 横向排列，每个标签带 `Alt+N` 提示；active 态 `var(--accent-soft)` + accent 边框；如 "VPN/网络 Alt+1"、"邮箱/办公 Alt+2" 等 |
| **回复条目** | 左侧图标 + 文本 + 序号提示；selected 态蓝底蓝边框；hover 灰底 |
| **键盘导航** | Alt+1~5 切换分类；↑↓ 选中条目；Enter 确认填入；/ 聚焦搜索框 |
| **键盘指南** | 底部常驻：`Alt+1-5 切换` / `↑↓ 选择` / `Enter 填入` / `/ 搜索` |
| **移除** | 风险提示 Tab（`RiskAlert.vue` 废弃）、用户信息 Tab（`UserInfoPanel.vue` 废弃，功能已并入聊天区） |
| **变更范围** | `AiAssistantPanel.vue` 完全重写；`QuickReplyPanel.vue` 重写交互逻辑 |
---
#### FE-09 系统名称
| 项目 | 说明 |
|------|------|
| **顶部栏** | 左侧：logo 方块 "IT"（渐变紫蓝 26×26px）+ "智能IT支持服务台"（渐变文字）+ "· 坐席工作台 — AI驱动 · 多系统对接 · 一站式处理"（10px 灰色副标题，max-width 280px 溢出省略） |
| **变更范围** | `TopBar.vue`（从 `Workspace.vue` 顶部栏独立） |
---
#### BE-01 Employee 模型扩展
| 项目 | 说明 |
|------|------|
| **新增字段** | `it_level`: IT 等级枚举（bronze/silver/gold/platinum/diamond/star/king），默认 silver；`it_level_source`: 等级来源（system/manual），默认 system；`notes`: 备注 JSON |
| **API** | 新增 `PUT /api/employees/{id}/it-level` 坐席手动调整 IT 等级端点；修改 `GET /api/employees/{id}` 返回新字段 |
| **变更范围** | `models/employee.py` 新增 3 字段；`schemas/` 新增/修改；`api/` 新增端点 |
---
#### BE-02 Conversation 模型扩展
| 项目 | 说明 |
|------|------|
| **新增字段** | `impact_scope`: 影响范围（整数，受影响人数，默认 0）；`is_blocking`: 阻断性标记（布尔，默认 False）；`emotion_state`: 情绪状态（枚举 normal/anxious/angry/urgent，默认 normal） |
| **API** | 修改 `GET /api/conversations` 和 `GET /api/conversations/{id}` 响应包含新字段 |
| **变更范围** | `models/conversation.py` 新增 3 字段；`schemas/conversation.py` 修改；`api/conversations.py` 修改 |
---
#### BE-03 TodoItem 模型 + CRUD API
| 项目 | 说明 |
|------|------|
| **新增模型** | `TodoItem`：id(UUID), type(ticket/approval/device), title, priority(urgent/high/normal), description(JSON), status(pending/processing/resolved), assigned_agent_id(nullable), corp_id, created_at, updated_at |
| **API** | `GET /api/todo-items`（列表）、`GET /api/todo-items/{id}`（详情）、`PUT /api/todo-items/{id}/status`（更新状态）|
| **数据** | Mock 数据先行，预置 5-10 条示例待办 |
| **变更范围** | 新增 `models/todo_item.py` + `schemas/todo_item.py` + `api/todo_items.py` |
#### BE-03B 企微审批工单同步
> **新增日期**: 2026-07-04 | **优先级**: P1
| 项目 | 说明 |
|------|------|
| **需求** | 将企微审批工单同步到坐席待办事项 |
| **数据来源** | 企微审批中心 API |
| **同步内容** | 审批单标题、申请人、审批状态、创建时间 |
| **企微API** | `GET /cgi-bin/oa/approvallist` 获取审批列表 |
| **映射逻辑** | 企微审批状态 → TodoItem 状态（pending/processing/resolved）|
| **同步频率** | 定时任务，每5分钟拉取一次；或实时 Webhook 推送 |
| **变更范围** | 新增 `services/approval_sync.py` + 定时任务配置 |
> **技术说明**：企微审批 API 需要审批应用权限，需在企微管理后台创建审批应用并配置 API 授权。
---
#### BE-04 TroubleshootingTemplate 模型 + CRUD API
| 项目 | 说明 |
|------|------|
| **新增模型** | `TroubleshootingTemplate`：id(UUID), name, category(vpn/email/system/account), path_steps(JSON 最优路径), flowchart(JSON 完整决策树), is_active(布尔), created_at, updated_at |
| **API** | `GET /api/troubleshooting-templates`（列表）、`GET /api/troubleshooting-templates/{id}`（详情）、`POST/PUT/DELETE`（管理员增删改） |
| **数据** | 预置常见问题模板（VPN 连接失败、邮箱配置、系统登录、账号权限等 5-8 套） |
| **变更范围** | 新增 `models/troubleshooting_template.py` + `schemas/troubleshooting_template.py` + `api/troubleshooting_templates.py` |
---
### P1 — 应该完成（体验增强）
---
#### FE-10 快捷键系统完善
| 项目 | 说明 |
|------|------|
| **需求** | 全局快捷键注册与统一管理 |
| **快捷键列表** | Ctrl+1/2/3（AI 推荐填入）、Alt+1~5（快速回复分类切换）、↑↓（快速回复条目导航）、Enter（确认填入）、/（聚焦快速回复搜索框） |
| **约束** | 快捷键仅在未聚焦输入框时生效（避免与打字冲突）；需提供快捷键提示 UI（右栏底部键盘指南） |
| **变更范围** | 新增 `composables/useKeyboardShortcuts.ts` |
---
#### FE-11 IT 等级手动调整交互
| 项目 | 说明 |
|------|------|
| **需求** | 坐席可在用户信息详情卡片中手动调整用户 IT 等级 |
| **交互** | 在 IT 等级详情卡片旁提供「调整」按钮，弹出 7 级选择器（下拉/弹窗） |
| **约束** | 调整后需记录 `it_level_source=manual`；前端立即更新显示，后端异步保存 |
| **变更范围** | `UserInfoBar.vue` 详情面板中新增调整交互 |
---
#### FE-12 主题切换过渡动画
| 项目 | 说明 |
|------|------|
| **需求** | 主题切换时的平滑过渡效果 |
| **实现** | `body` 添加 `transition: background 0.3s, color 0.3s`；所有 CSS 变量驱动的属性自动跟随过渡 |
| **约束** | 过渡时长 ≤ 300ms，不影响交互流畅度 |
---
#### BE-05 IT 等级自动评分逻辑（框架）
| 项目 | 说明 |
|------|------|
| **需求** | 为后续迭代搭建自动评分框架 |
| **实现** | 定义评分维度和权重接口，当前仅返回默认值（silver）或手动值 |
| **约束** | 不在 P0 实现完整评分，仅搭建扩展点 |
---
### P2 — 锦上添花（远期优化）
---
#### FE-13 排查步骤进度同步
| 项目 | 说明 |
|------|------|
| **需求** | 排查步骤的当前步骤与对话内容自动同步 |
| **实现** | 根据消息内容关键词自动推进步骤状态（如坐席说"清除缓存"→ 步骤 ② 标记 done） |
#### FE-14 待办事项实时推送
| 项目 | 说明 |
|------|------|
| **需求** | 通过 WebSocket 实时推送新的待办事项 |
| **实现** | 扩展 WS 消息类型，新增 `todo_item_created` 事件 |
#### FE-15 IT 等级完整自动评分
| 项目 | 说明 |
|------|------|
| **需求** | 基于用户历史工单、自助解决率、操作复杂度等维度自动计算 IT 等级 |
| **实现** | 后台定时任务 + 评分服务 |
#### FE-16 排查步骤模板管理后台
| 项目 | 说明 |
|------|------|
| **需求** | 管理员可在后台增删改排查模板 |
| **实现** | 独立管理页面或嵌入现有管理后台 |
---
## 16.3 UI 设计草案
### 16.3.1 整体布局（三栏 + 顶栏）
```
┌─────────────────────────────────────────────────────────────────────┐
│ [IT] 智能IT支持服务台 · 坐席工作台 — AI驱动 · 多系统对接 · 一站式处理 │ ☀️/🌙 │ 坐席: 陈思远 │
├──────────┬──────────────────────────────────┬───────────────────────┤
│ │ 👤 张伟 · 研发一部 🥇黄金 │ 🤖 AI 智能推荐 │
│ 🔍 搜索 │ 😟焦虑 ⏱8分32秒 💬6轮 🔁重复 │ ┌─────────────────┐ │
│ 全部|待处 │ ▼ [6卡片详情展开区] │ │ 92% 远程协助方案 │ │
│ |进行|已完│──────────────────────────────────│ │ 85% 备用方案 │ │
│ │ │ └─────────────────┘ │
│ 📌我的会话│ [用户消息气泡] │───────────────────────│
│ ⛔👥👑🔁 │ [坐席消息气泡] │ 🔍 搜索快速回复 / │
│ 张伟 │ 🤖 AI推荐回复 │ Alt+1│Alt+2│... │
│ 👥👑 │ ┌────────────────────────────┐ │ ┌─────────────────┐ │
│ 陈芳 │ │①确认版本 → ②清除缓存 → ...│ │ │ VPN连接失败... │ │
│ │ └────────────────────────────┘ │ │ VPN证书过期... │ │
│ 👥同事会话│ 💬 [回复输入框] [发送] │ └─────────────────┘ │
│ (折叠) │──────────────────────────────────│ Alt+1~5 ↑↓ Enter / │
│ │ 🔧 排查步骤 [▶展开全流程图] │ │
│ 🕐历史会话│ ①确认版本→②清除缓存→③远程排查→.. │ │
│ (折叠) │ │ │
│──────────│ │ │
│ 📋待办事项│ │ │
│ 🔴工单 │ │ │
│ 🟣审批 │ │ │
│ 🟠设备 │ │ │
├──────────┤ │ │
│ 在线4 忙2│ │ │
└──────────┴──────────────────────────────────┴───────────────────────┘
```
### 16.3.2 IT 等级徽标设计
| 等级 | 标识 | 配色 | CSS 类名 | 说明 |
|------|------|------|---------|------|
| 青铜 | 🛡️ 青铜 Lv.1 | 棕色渐变 `#78350f→#92400e`，文字 `#fef3c7`，边框 `#b45309` | `.bronze` | 基础操作需指导 |
| 白银 | 🛡️ 白银 Lv.2 | 灰色渐变 `#374151→#6b7280`，文字 `#f3f4f6`，边框 `#9ca3af` | `.silver` | 能完成常规操作 |
| 黄金 | 🥇 黄金 Lv.3 | 金色渐变 `#92400e→#d97706`，文字 `#fffbeb`，边框 `#f59e0b` | `.gold` | 熟练使用，高级操作需指导 |
| 铂金 | 💎 铂金 Lv.4 | 青蓝渐变 `#164e63→#0e7490`，文字 `#cffafe`，边框 `#22d3ee` | `.platinum` | 独立解决大部分问题 |
| 钻石 | 💎 钻石 Lv.5 | 靛蓝渐变 `#312e81→#4338ca`，文字 `#e0e7ff`，边框 `#818cf8` | `.diamond` | 高级排障能力 |
| 星耀 | ⭐ 星耀 Lv.6 | 粉紫渐变 `#831843→#be185d`，文字 `#fce7f3`，边框 `#ec4899` | `.star` | 技术专家级 |
| 王者 | 👑 王者 Lv.7 | 橙红渐变 `#7c2d12→#c2410c`，文字 `#ffedd5`，边框 `#f97316` + **发光动画** | `.king` | IT 管理员级 |
> 王者徽标特有动画：`king-glow`，`box-shadow` 在 `0 0 4px` 和 `0 0 10px` 之间交替，2s 循环
### 16.3.3 待办事项 → 中间栏视图切换
```
点击左侧「工单」→ 中间栏切换为：
┌──────────────────────────────────────────────┐
│ ← 返回会话 工单 #20240606001 [运维工单] │
├──────────────────────────────────────────────┤
│ 📋 工单描述 │
│ 标题: CEO办公室 - 投屏设备故障 │
│ 优先级: 🔴 紧急 SLA: ⏰ 剩余 12 分钟 │
│ ...描述详情... │
│ │
│ 📍 处理进度 │
│ 状态: ⏳ 待接单 接单人: 未分配 │
├──────────────────────────────────────────────┤
│ [📥 接单] [🔧 开始处理] [✅ 结单] [🔄 转派] │
└──────────────────────────────────────────────┘
```
---
## 16.4 数据模型变更
### 16.4.1 Employee 模型新增字段
```python
# 新增字段（在 models/employee.py 中追加）
it_level: Mapped[str] = mapped_column(
String(20), nullable=False, default="silver",
comment="IT技能等级: bronze/silver/gold/platinum/diamond/star/king"
)
it_level_source: Mapped[str] = mapped_column(
String(20), nullable=False, default="system",
comment="等级来源: system(系统初评)/manual(坐席手动)"
)
notes: Mapped[dict] = mapped_column(
JSON, nullable=False, default=dict,
comment="坐席备注(JSON): {pregnancy, preferred_time, special_needs, ...}"
)
```
### 16.4.2 Conversation 模型新增字段
```python
# 新增字段（在 models/conversation.py 中追加）
impact_scope: Mapped[int] = mapped_column(
Integer, nullable=False, default=0,
comment="影响范围(受影响人数)"
)
is_blocking: Mapped[bool] = mapped_column(
Boolean, nullable=False, default=False,
comment="阻断性标记: 是否导致用户无法工作"
)
emotion_state: Mapped[str] = mapped_column(
String(20), nullable=False, default="normal",
comment="情绪状态: normal/anxious/angry/urgent"
)
```
### 16.4.3 新增 TodoItem 模型
```python
class TodoItem(Base):
__tablename__ = "todo_items"
id: Mapped[str] # UUID 主键
type: Mapped[str] # ticket/approval/device
title: Mapped[str] # 标题
priority: Mapped[str] # urgent/high/normal
description: Mapped[dict] # JSON，类型专属详情
status: Mapped[str] # pending/processing/resolved
assigned_agent_id: Mapped[str | None] # 分配坐席
corp_id: Mapped[str] # 企业ID
created_at: Mapped[datetime]
updated_at: Mapped[datetime]
```
### 16.4.4 新增 TroubleshootingTemplate 模型
```python
class TroubleshootingTemplate(Base):
__tablename__ = "troubleshooting_templates"
id: Mapped[str] # UUID 主键
name: Mapped[str] # 模板名称，如 "VPN连接失败"
category: Mapped[str] # 分类：vpn/email/system/account
path_steps: Mapped[list] # JSON，最优路径步骤 [{label, status}]
flowchart: Mapped[dict] # JSON，完整决策树（含判断节点、分支）
is_active: Mapped[bool] # 是否启用
created_at: Mapped[datetime]
updated_at: Mapped[datetime]
```
---
## 16.5 API 变更概要
### 16.5.1 新增端点
| 方法 | 路径 | 说明 |
|------|------|------|
| GET | `/api/todo-items` | 获取当前坐席待办列表 |
| GET | `/api/todo-items/{id}` | 获取待办详情 |
| PUT | `/api/todo-items/{id}/status` | 更新待办状态 |
| GET | `/api/troubleshooting-templates` | 获取排查模板列表 |
| GET | `/api/troubleshooting-templates/{id}` | 获取排查模板详情 |
| POST | `/api/troubleshooting-templates` | 新增排查模板（管理员） |
| PUT | `/api/troubleshooting-templates/{id}` | 修改排查模板（管理员） |
| DELETE | `/api/troubleshooting-templates/{id}` | 删除排查模板（管理员） |
| PUT | `/api/employees/{id}/it-level` | 坐席手动调整 IT 等级 |
### 16.5.2 修改端点
| 方法 | 路径 | 变更说明 |
|------|------|---------|
| GET | `/api/conversations` | 响应新增 `impact_scope`, `is_blocking`, `emotion_state` 字段 |
| GET | `/api/conversations/{id}` | 同上 |
| GET | `/api/employees/{id}` | 响应新增 `it_level`, `it_level_source`, `notes` 字段 |
---
## 16.6 组件变更矩阵
| 组件 | 变更类型 | 说明 |
|------|---------|------|
| `Workspace.vue` | **重构** | 顶部栏独立为 `TopBar.vue`；移除应急模式横幅到 TopBar；三栏布局微调 |
| `ConversationList.vue` | **重构** | 三段折叠替代原六段；搜索区增加筛选标签；底部新增待办事项面板 |
| `ConversationItem.vue` | **修改** | 新增优先级图标渲染（⛔👥⭐🔁）；移除 IT 等级徽标 |
| `ChatArea.vue` | **重构** | 顶部栏替换为 `UserInfoBar.vue`；底部新增 `TroubleshootBar.vue`；新增视图切换逻辑（聊天/任务详情） |
| `AiAssistantPanel.vue` | **完全重写** | 移除 5 Tab，改为上下两区（AI 推荐 ~1/3 + 快速回复 ~2/3） |
| `QuickReplyPanel.vue` | **重写** | 搜索栏置顶 + Alt 分类切换 + ↑↓ 键盘导航 + Enter 确认填入 + 底部键盘指南 |
| `RiskAlert.vue` | **废弃** | 功能移除 |
| `UserInfoPanel.vue` | **废弃** | 功能并入 `UserInfoBar.vue` |
| `AiSuggestReply.vue` | **修改** | 移至右栏上方 AI 推荐区；增加置信度显示 + Ctrl 快捷键 |
| `TopBar.vue` | **新增** | 独立顶栏组件（系统名称 + 主题切换 + 坐席信息 + 应急模式） |
| `UserInfoBar.vue` | **新增** | 聊天区顶部用户信息栏（chips + 展开详情 6 卡片） |
| `AiRecommendInline.vue` | **新增** | 聊天区内 AI 推荐回复（Ctrl+1/2/3 快捷填入） |
| `TroubleshootBar.vue` | **新增** | 排查步骤栏（路径视图 + 可展开流程图） |
| `TodoPanel.vue` | **新增** | 左栏底部待办事项面板 |
| `TaskDetailView.vue` | **新增** | 中间栏任务详情视图（工单/审批/设备三种子视图） |
| `ItLevelBadge.vue` | **新增** | IT 等级徽标组件（7 级段位 + 渐变配色 + 王者发光动画） |
| `useKeyboardShortcuts.ts` | **新增** | 全局快捷键管理 composable |
| `useTheme.ts` | **新增** | 主题切换 composable（CSS 变量 + localStorage 持久化） |
| `stores/todo.ts` | **新增** | 待办事项 Pinia Store |
| `stores/theme.ts` | **新增** | 主题 Pinia Store |
| `api/todo.ts` | **新增** | 待办事项 API |
| `api/troubleshooting.ts` | **新增** | 排查模板 API |
---
## 16.7 待确认问题
| # | 问题 | 影响范围 | 建议 |
|---|------|---------|------|
| 1 | **情绪状态识别方式**：由 AI 自动分析消息内容识别，还是由坐席手动标记？ | BE-02, FE-04 | 建议先 AI 自动识别 + 坐席可手动修正 |
| 2 | **影响范围数据来源**：是员工自行填写、系统自动判断（如根据部门人数），还是坐席标记？ | BE-02 | 建议坐席手动标记为主，后续迭代增加 AI 辅助判断 |
| 3 | **排查模板与问题分类的关联**：排查模板如何匹配到当前会话？是按标签自动匹配还是坐席手动选择？ | BE-04, FE-06 | 建议 P0 坐席手动选择模板，P2 再做自动匹配 |
| 4 | **待办事项与外部系统对接时机**：工单/审批/设备的真实系统 API 何时对接？ | BE-03 | 已确认 Mock 先行，前端 UI 做完整交互 |
| 5 | **IT 等级在用户端显示方式**：用户端看到的 IT 等级是完整徽标还是简化文本？ | FE-04, BE-01 | 需与用户端（H5）产品确认 |
| 6 | **同事会话区的数据筛选**：「同事会话」是显示所有其他坐席的进行中会话，还是仅显示同组/同部门坐席的？ | FE-02 | 建议先显示同组坐席，后续可配置 |
| 7 | **排查步骤栏的高度**：排查步骤栏始终可见会占用聊天区空间，是否需要设置最小/最大高度？ | FE-06 | 参考原型：默认路径视图 ~44px，展开流程图最大 300px |
| 8 | **AI 推荐回复的触发时机**：是每条用户消息后都触发，还是有条件触发？ | FE-05 | 已确认仅坐席未回复时显示 |
| 9 | **原 6 区到 3 段的数据映射**：原"待接单"区并入"我的会话"还是独立显示？原"协作会话"区并入哪个段？ | FE-02 | 需确认分区数据映射规则 |
---
## 16.8 关键决策记录
| # | 决策 | 依据 |
|---|------|------|
| 1 | 外部系统对接 Mock 先行，前端 UI 做完整交互 | 避免被外部系统 API 阻塞前端开发进度 |
| 2 | IT 等级采用混合模式（系统初评 + 坐席手动调整） | 系统自动评分不够准确，需坐席校准 |
| 3 | 排查步骤数据源为静态模板库 | 预置常见问题模板即可满足 MVP，后续可扩展为动态生成 |
| 4 | 右栏移除 5 Tab 结构，改为上下两区 | 原型验证：坐席主要使用 AI 推荐和快速回复，其他功能使用频率低 |
| 5 | 会话列表不显示 IT 等级徽标 | 避免信息过载，IT 等级在聊天区详情展示更合适 |
| 6 | 排查步骤栏整体不可收起 | 确保坐席始终能看到排查进度，避免遗漏步骤 |
| 7 | 原型样式已锁定（v5.3 版），调整样式前必须与用户确认 | 保证开发产出与设计稿一致 |
---
## 16.9 里程碑建议
| 阶段 | 范围 | 预估周期 |
|------|------|---------|
| **Phase 1 — 基础框架** | FE-01 主题系统 + FE-09 系统名称 + BE-01/02 模型扩展 + 数据库迁移 | 2-3 天 |
| **Phase 2 — 左栏改造** | FE-02 三段折叠 + 优先级图标 + FE-03 待办面板 + BE-03 TodoItem API | 2-3 天 |
| **Phase 3 — 中栏改造** | FE-04 用户信息栏 + FE-05 AI 推荐内联 + FE-06 排查步骤栏 | 3-4 天 |
| **Phase 4 — 右栏改造** | FE-08 AI 助手面板重构 + BE-04 排查模板 API | 2-3 天 |
| **Phase 5 — 任务视图** | FE-07 视图切换 + 工单/审批/设备 3 种子页面 | 2-3 天 |
| **Phase 6 — 增强打磨** | FE-10 快捷键 + FE-11 IT 等级调整 + FE-12 过渡动画 + 联调测试 | 2-3 天 |
---
### 16.2.1 密码管理需求
| ID | 需求 | 说明 | 验收标准 |
|----|------|------|----------|
| P0-10 | 修改密码API | POST /api/agents/password，支持旧密码验证+新密码修改 | 旧密码验证成功后更新，bcrypt 哈希存储 |
| P0-11 | 修改密码UI | 个人中心/设置页面提供"修改密码"入口，弹窗表单 | 弹窗包含旧密码、新密码、确认密码字段，验证后提交 |
---
## 17. 管理后台远景规划
> **决策状态**: 已确认（2026-06-08）
> **决策依据**: 本平台未来产品、开发、维护人员并非专业岗位人员，所有模块功能需尽可能解耦，产品开发阶段和功能模块颗粒度需符合零基础岗位人员特点。
### 17.1 产品定位
管理后台是 IT 智能服务台的**第三端产品**（与员工端 H5、坐席工作台并列），面向**坐席组长**，提供系统配置、人员管理、内容运营、数据监控等能力。
**核心原则**：
- 运维人员能通过管理后台配置一切，代码修改仍需开发
- 代码修改由零开发基础员工逐步成长，但要合理控制代码开发变更颗粒度和影响范围
- 单功能单模块，每个菜单项可独立启用/禁用
- 配置优于代码，导入导出标准格式统一用 JSON/CSV
- 变更可回滚，每次配置变更记录版本
### 17.2 功能模块清单
| # | 模块 | 功能描述 | 优先级 | 上线阶段 | 备注 |
|---|------|---------|--------|---------|------|
| 1 | **功能开关/参数** | 按阶段控制功能开放，运行时切换无需改代码 | P0 | 阶段一 | 阶段一仅开核心功能，后续阶段解锁排队/评分等 |
| 2 | **坐席人员管理** | 在线/离线状态、技能标签（参考快速回复7大类）、权限分级（角色→权限组） | P0 | 阶段一 | 技能标签与快速回复分类对齐：电脑/软件/外设/网络/安全/资产/其他 |
| 3 | **消息分配模式** | 阶段一仅手动接单，后续按坐席规模扩展自动分配 | P1 | 阶段一(手动) → 阶段二+(自动) | 当前1人足够，手动接单完全满足；6种模式为远景规划，详见 §18.3 |
| 4 | **快速回复管理** | 分类管理 + 版本历史 + 审核发布流程 | P1 | 阶段一 | 审核通过前不影响提交人自己使用（提交人可用待审核版本） |
| 5 | **主题模板管理** | 三层管理（全局默认→坐席端→H5端），支持节日/活动主题 | P2 | 阶段二 | 三层统一一个主题体系，未来可加入节日和活动主题 |
| 6 | **会话监控** | 实时查看坐席工作状态、会话队列、异常告警（超时未响应等） | P1 | 阶段二 | 先出 Demo |
| 7 | **数据看板** | 坐席绩效（响应时间/结单率/AI采纳率）、满意度趋势、热点问题排行 | P1 | 阶段四 | 先出 Demo |
| 8 | **排查流程图管理** | JSON 导入导出 + 预览 + 版本管理 | P1 | 阶段三 | 后续升级为可视化拖拽编辑 |
| 9 | **知识库管理** | 标注→知识条目→迭代闭环 | P2 | 阶段四 | 与 RAGFlow 集成，详见 §19 |
| 10 | **外部系统集成** | Dify/RAGFlow/数据平台连接管理 + 同步日志 | P0~P2 | 阶段二起 | 详见 §19 |
### 17.3 消息分配模式
> **现状校准（2026-06-08）**：当前人工咨询量和坐席人员数量 1 人足以承担，引入多坐席主要是 AB 角色设置和冗余考虑。因此阶段一只需手动接单，自动分配模式为远景规划，按坐席规模增长渐次启用。
| # | 模式 | 描述 | 适用场景 | 启用时机 | 优先级 |
|---|------|------|---------|---------|--------|
| 1 | **手动接单** | 坐席在待办列表中自行选择接单 | 当前唯一模式：1人足以承担，AB角冗余 | ✅ 阶段一 | P0 |
| 2 | **轮询分配** | 按坐席列表顺序依次分配，循环往复 | 坐席≥3人且能力均匀 | 坐席≥3人时 | P2 |
| 3 | **最少活跃优先** | 自动分配给当前活跃会话数最少的坐席 | 坐席处理速度有差异 | 坐席≥3人时 | P2 |
| 4 | **加权比例分配** | 按坐席权重分配（如高级权重2、初级权重1） | 坐席能力分层明显 | 坐席≥5人时 | P3 |
| 5 | **技能匹配分配** | 根据问题类别匹配坐席技能标签 | 专业化分工 | 坐席≥5人+技能标签体系成熟时 | P3 |
| 6 | **优先队列** | 紧急/阻断性问题优先路由到高级坐席/组长 | 需要快速响应高优问题 | 坐席≥5人+紧急度评分上线时 | P3 |
**设计原则**：
- 阶段一管理后台分配模式设置页仅显示「手动接单」一项，界面简洁
- 后续模式按坐席规模自动解锁（如坐席<3人时自动分配选项灰显并提示"坐席人数不足3人，暂不需要"）
- 所有模式均支持热切换，不需重启服务
### 17.4 快速回复管理 — 审核流程
```
坐席提交模板 → 状态: 待审核（仅提交人可用）
↓
坐席组长审核 → 通过: 全员可见 / 驳回: 返回修改
↓
版本历史保留，支持回滚到任意版本
```
### 17.5 主题模板管理 — 三层架构
```
全局默认主题 ──→ 坐席端主题覆盖 ──→ H5端主题覆盖
│ │ │
└─ 基础色板 └─ 坐席工作台专属 └─ 员工端专属
└─ 字体/圆角 └─ 优先级高于全局 └─ 优先级高于全局
特殊主题：节日/活动主题 → 临时覆盖三层，到期自动恢复
```
---
## 18. 系统生态与集成规划
> **决策状态**: 已确认（2026-06-08）
> **核心策略**: 管理后台先建 + 集成渐次接入
### 18.1 五系统生态架构
| 系统 | 职责 | 部署位置 | 当前集成度 |
|------|------|---------|-----------|
| **智能IT支持服务台** | 员工端H5 + 坐席工作台 + 管理后台 | 公司内网服务器 | — |
| **Dify** | AI对话引擎（Agent1 员工自助 + Agent2 坐席辅助） | 公司内网 | 100%（dify2openai 集成） |
| **RAGFlow** | 知识库检索（Dify 通过 RAGFlow 获取知识） | 公司内网 | 0%（Dify 间接调用） |
| **智能IT助手数据处理平台** | 会话数据分析、报表、运营指标 | 公司内网 | 0%（物理隔离） |
| **企业微信** | 消息通道、身份认证、组织架构 | 企微云 | 100%（回调+API） |
### 18.2 Dify 管理边界
| 管理后台管的 | 仍在 Dify 网页管的 |
|------------|-----------------|
| Agent Key/URL 配置 | Workflow 逻辑设计 |
| System Prompt 参数 | 知识库与 Agent 绑定 |
| 转人工关键字列表 | 对话日志查看 |
| AI 命中阈值参数 | dify2openai 桥接配置 |
**设计原则**：管理后台管「配置和参数」，Dify 网页管「Workflow 逻辑」，两者边界明确。
### 18.3 RAGFlow 集成 — 知识库迭代闭环
**同步触发方式**: 阈值触发自动推送，管理员仅审核
```
坐席标注 → 同类问题超过 N 次 → 管理后台自动推荐「加入知识库」
↓
管理员确认 → 管理后台生成 FAQ 条目 → RAGFlow API 推送 → 知识库更新
↓
下次同类问题 → L1 流程图命中（不走 AI）→ 成本下降
```
**标注粒度**: 标注 + 坐席实际回复内容（不只是「有效/无效」，还记录坐席实际发了什么）
### 18.4 数据处理平台集成
**策略**: 短期 B+C，长期 A
| 阶段 | 方式 | 描述 |
|------|------|------|
| **短期** | B. 数据库只读 | 数据平台直连新系统 PostgreSQL（只读视图），获取全量会话/消息/评分数据 |
| **短期** | C. 看板嵌入 | 数据平台看板 URL 嵌入管理后台 iframe，体验统一 |
| **长期** | A. API 推送 | 会话结单时管理后台推送标签/评分到数据平台 API |
**数据同步内容**:
| 数据 | 同步方向 | 时机 |
|------|---------|------|
| 会话标签 | 服务台 → 数据平台 | 会话结单时 |
| 满意度评分 | 服务台 → 数据平台 | 员工评分后 |
| 坐席绩效 | 服务台 → 数据平台 | 每日汇总 |
| 运营报表 | 数据平台 → 管理后台 | iframe 嵌入实时查看 |
### 18.5 外部系统集成模块
| 子模块 | 功能 | 优先级 |
|--------|------|--------|
| Dify 连接管理 | API URL/Key 配置、连接测试、Agent 状态查看 | P0 |
| RAGFlow 连接管理 | API URL/Key 配置、知识库列表查看、同步状态 | P1 |
| 数据平台连接管理 | 数据库连接配置、看板 URL 嵌入、同步状态 | P1 |
| 同步日志 | 所有外部系统的推送/拉取记录、成功/失败统计 | P1 |
| 流程图→Dify 导出 | L1 流程图导出为 Dify 变量/知识条目 | P2 |
### 18.6 AI 混合策略 — 四层架构
> **决策状态**: 已确认（2026-06-08）
> **核心原则**: 不过度依赖 AI 实时能力，采用「固定流程图 + AI 动态能力 + 标注 + 迭代」混合模式，在响应速度、算力成本、管理可控、迭代循环实现最佳实践。
| 层级 | 名称 | 机制 | 成本 | 响应速度 | 可控性 |
|------|------|------|------|---------|--------|
| **L1** | 固定流程图 | 确定性分支树，关键词/规则匹配 | 零 | 毫秒级 | 100% |
| **L2** | AI 动态能力 | Dify Agent 调用（RAGFlow 检索增强） | 高 | 2-5秒 | 中 |
| **L3** | 人工标注 | 坐席对 AI 建议标注「有效/无效/部分有效」+ 实际回复内容 | 低 | 即时 | 高 |
| **L4** | 迭代闭环 | 高频问题→流程图补充，AI 命中率低→知识库补充 | 低 | 批量 | 高 |
**迭代目标**: 不断将 L2 的问题「降级」到 L1，提升系统确定性和响应速度，降低 AI 算力成本。
**L1 流程图编辑方式**:
- 阶段三: JSON 导入导出 + 预览（实现快、零基础人员可用）
- 后续升级: 可视化拖拽编辑
**迭代触发机制**: 阈值自动推荐（超过 N 次同类问题 → 管理后台弹推荐），管理员确认后执行
**关键设计原则**: AI 的 system prompt 中应注入当前流程图的结构摘要，让 AI 在已有流程图覆盖的领域内回答时与流程图保持一致。
### 18.7 排查流程图与 Dify 结合 — 实现路径
> **决策状态**: 已确认（2026-06-08），接收推荐的分阶段实现路径
#### 可行性矩阵
| 结合点 | 可行性 | 实现方式 |
|--------|--------|---------|
| 流程图→Dify System Prompt 注入 | ✅ 完全可行 | 导出为结构化文本→注入 Agent system prompt 变量 |
| 流程图→Dify 知识条目 | ✅ 完全可行 | 每个分支导出为 FAQ 对→推送 RAGFlow→Dify 通过 RAGFlow 检索 |
| 流程图→Dify Workflow 节点 | ⚠️ 有限可行 | Dify 不开放 Workflow 编辑 API，但可通过 HTTP 请求节点回调管理后台获取流程图分支 |
| Dify 对话结果→流程图标注 | ✅ 完全可行 | AI 回复后自动记录命中/未命中流程图，统计覆盖率 |
#### 分阶段实现路径
| 阶段 | 实现内容 | 对应子阶段 | 交付物 |
|------|---------|-----------|--------|
| **Step 1** | JSON 导入导出 + 预览 | 3B | 管理后台可管理流程图 JSON，坐席端展示流程图 |
| **Step 2** | 流程图导出为 Dify 变量/知识条目 | 4A | 管理后台一键导出→Dify system prompt 注入/RAGFlow 推送 |
| **Step 3** | Dify HTTP 请求节点回调流程图分支 | 4C | Dify Agent 可实时查询流程图分支，动态决策 |
| **Step 4** | 可视化拖拽编辑 | 远景 | 管理后台可视化编辑流程图，替代 JSON 手写 |
**Step 1→2 的关键价值**：流程图从「仅坐席可见的参考」升级为「AI 也遵循的规则」，实现 L1+L2 一致性。
---
## 19. 阶段细化与并行推进策略
> **决策状态**: 已确认（2026-06-08）
> **核心策略**: 资源审批期间并行推进不受阻断影响的需求，避免停工等待
### 19.1 阶段细化（子阶段划分）
每个子阶段独立可交付，不受其他子阶段阻断：
#### 阶段一：转人工改H5 + 坐席MVP + 管理后台骨架
| 子阶段 | 范围 | 独立可交付物 | 外部依赖 |
|--------|------|-------------|---------|
| **1A** | H5 Mock登录 + 坐席MVP + 邀请功能 | 员工手动登录→坐席可接单回复→坐席可邀请员工/部门加入会话 | 无 |
| **1B** | 管理后台骨架 | 功能开关 + 坐席管理 + 快速回复管理 | 无 |
| **1C** | 端到端验证 | 完整链路跑通 + 修复缺陷 | 需完整环境 |
#### 阶段二：H5全流程 + 实时推送 + 排队
| 子阶段 | 范围 | 独立可交付物 | 外部依赖 |
|--------|------|-------------|---------|
| **2A** | WebSocket推送 | 员工端实时消息 | 无 |
| **2B** | 排队分配 | 手动接单（已满足当前1人需求），自动分配按坐席规模渐次解锁 | 无 |
| **2C** | 满意度评分 | H5评分 + 后端存储 | 无 |
| **2D** | OAuth2切换 | 公司域名就绪后一键切回 | 公司备案域名 |
#### 阶段三：AI Wingman + 排查流程图
| 子阶段 | 范围 | 独立可交付物 | 外部依赖 |
|--------|------|-------------|---------|
| **3A** | AI Wingman验证 | Agent2 Key填入 + 草稿/摘要验证 | Dify Agent2 创建 |
| **3B** | 排查流程图+AI混合 | L1流程图管理(JSON) + L2 AI兜底 + 管理后台流程图模块 | 无 |
| **3C** | 标注体系 | 坐席标注 + 数据沉淀 + 阈值推荐 | 无 |
#### 阶段四：迭代闭环 + 数据看板
| 子阶段 | 范围 | 独立可交付物 | 外部依赖 |
|--------|------|-------------|---------|
| **4A** | 迭代闭环 | 高频问题→流程图补充 + RAGFlow 知识库推送 | RAGFlow API 联调 |
| **4B** | 数据看板 | 绩效/满意度/热点 + 数据平台集成 | 数据平台联调 |
| **4C** | 知识库管理 | 标注→知识条目→迭代闭环 | 无 |
### 19.2 并行推进策略
**核心原则**: P0 阻断项依赖外部资源审批，不等审批完成，并行推进不受阻断影响的需求。
| 外部依赖 | 阻断的子阶段 | 可并行推进的子阶段 |
|---------|------------|-----------------|
| 公司备案域名 | 2D（OAuth2切换） | 1A/1B/1C/2A/2B/2C/3A/3B/3C/4A/4B/4C |
| Dify Agent2 创建 | 3A（Wingman验证） | 1A/1B/1C/2A/2B/2C/3B/3C/4A/4B/4C |
| RAGFlow API 联调 | 4A（迭代闭环-知识推送） | 1A/1B/1C/2A/2B/2C/3A/3B/3C/4B/4C |
| 数据平台联调 | 4B（数据看板-平台集成） | 1A/1B/1C/2A/2B/2C/3A/3B/3C/4A/4C |
### 19.3 资源审批期间推荐推进事项
在 OAuth2 公司域名审批期间，优先推进以下**零外部依赖**的工作：
| 优先级 | 工作内容 | 所属子阶段 |
|--------|---------|-----------|
| 🔴 最高 | 管理后台骨架（功能开关+坐席管理+快速回复管理） | 1B |
| 🔴 最高 | 端到端测试验证 | 1C |
| 🟡 高 | H5 WebSocket 推送实现 | 2A |
| 🟡 高 | 手动接单优化（当前1人足够，AB角冗余场景） | 2B |
| 🟢 中 | 满意度评分组件 | 2C |
| 🟢 中 | 排查流程图 JSON 导入导出 + 预览 | 3B |
---
> **文档结束** — 本PRD涵盖企微智能IT支持服务台全部已确认设计决策和约束，作为后续架构设计和开发实施的基准文档。
> - v1.0 新增管理后台远景规划、系统生态与集成规划、阶段细化与并行推进策略
> - v1.1 新增邀请功能设计（§21）
> - v1.2 文档合并优化：归档冗余 PRD，保留唯一权威版本
---
## 20. 邀请功能设计 — 多人会话协作
> **设计日期**: 2026-06-10 | **设计者**: 宋献 | **状态**: 方案已确认，纳入M1 MVP
> **原型文件**: `docs/prototypes/invite-flow-v1.html`
> **技术方案**: `docs/邀请功能-技术方案.md`
### 20.1 背景与动机
**问题场景**：IT坐席在处理会话时，经常需要拉入其他同事协助（如网络问题需要网络组同事确认、软件授权需要资产管理同事查证）。当前只有1对1模式，坐席只能手动告知对方会话内容，效率极低。
**方案选型**（2026-06-10 确认）：
| 方案 | 核心思路 | 可行性 | 结论 |
|------|---------|--------|------|
| 方案一：一对一+邀请 | 在现有会话上扩展参与者，企微应用消息通知 | ✅ 完全可行 | 备选 |
| 方案二：应用群聊 | 企微appchat创建群，群内沟通 | ❌ 应用无法接收群内消息回调 | 不可行 |
| **方案三：WebSocket+应用消息双通道** | **在现有架构上扩展，后端维护参与者列表** | ✅ **完全可行，零新增基础设施** | **当前方案** |
**方案二不可行的原因**：企微appchat是「应用推送消息群」，群成员在群内的发言**不会回调给应用**。应用只能单向推送消息到群，无法看到用户回复，坐席工作台无法获取群内对话。
### 20.2 核心设计理念
**邀请 ≠ 群聊**。邀请是在现有1对1会话基础上，将新参与者加入同一会话的协作模式：
```
原始：员工 ←→ 坐席（1对1）
邀请后：员工 ←→ 坐席 + 被邀请人A + 被邀请人B（多人同一会话）
```
- 所有参与者在同一会话中看到完整对话
- 坐席始终是会话的"主控者"（创建/结单/转接权限）
- 被邀请人是"协作者"（可查看和回复，不可结单/邀请他人）
### 20.3 用户故事
| # | 角色 | 故事 | 验收标准 |
|---|------|------|---------|
| US-14 | IT坐席 | 处理网络问题时，我想邀请网络组的同事直接进入当前会话查看情况并回复，不用我手动转发聊天记录 | 坐席点击邀请→选择人员→对方收到通知→加入会话→可看到历史消息并发送回复 |
| US-15 | IT坐席 | 邀请同事时，我想选择共享多少历史消息，避免对方被大量无关信息淹没 | 邀请时可选择共享模式（全部/最近10条/不共享），默认最近10条 |
| US-16 | IT坐席 | 我需要邀请整个部门参与，比如让安全组的同学一起排查 | 可按部门批量邀请，勾选部门=邀请全部门成员 |
| US-17 | 被邀请员工 | 收到邀请通知后，我希望一键加入会话，看到之前的问题上下文 | 点击企微通知→H5加载→看到共享历史→可发送消息 |
| US-18 | 被邀请员工 | 我协助完成后，想退出这个会话，不再收到消息 | 被邀请人可主动退出，退出后会话列表中不再显示 |
### 20.4 功能规格
#### 20.4.1 邀请发起（坐席端）
| 功能点 | 规格 |
|--------|------|
| 入口 | 会话详情头部工具栏「+ 邀请」按钮 |
| 选人方式 | ①搜索姓名/工号 ②组织架构树浏览 ③按部门批量勾选 |
| 组织架构数据 | 后端调用企微通讯录API，前端渲染部门树 |
| 历史消息共享 | 三选一：全部 / **最近10条**（默认）/ 不共享 |
| 邀请确认 | 显示已选人员列表 + 共享模式，确认后调用后端接口 |
| 人数提醒 | >10人时弹窗提醒"建议优先邀请关键人员"，不设硬上限 |
#### 20.4.2 通知与加入（被邀请人端）
| 功能点 | 规格 |
|--------|------|
| 通知方式 | 企微应用消息（template_card 卡片消息） |
| 卡片内容 | 邀请人姓名 + 发起人姓名 + 问题摘要（最近1条消息截取50字） + 「加入会话」按钮 |
| 加入方式 | 点击按钮→H5页面→自动加载会话（Mock登录或OAuth2） |
| 历史消息 | 根据邀请时的共享模式，加载对应历史消息 |
| 加入广播 | 加入后自动在会话中发送系统消息「XX已加入会话」 |
#### 20.4.3 多人会话（所有参与者）
| 角色 | 查看消息 | 发送消息 | 邀请他人 | 结单/转接 | 退出 |
|------|---------|---------|---------|----------|------|
| 原始员工 | ✅ | ✅ | ❌ | ❌ | 关闭页面即退出 |
| 主责坐席 | ✅ | ✅ | ✅ | ✅ | ❌（主责不可退） |
| 被邀请人 | ✅ | ✅ | ❌ | ❌ | ✅ |
#### 20.4.4 参与者管理
| 功能点 | 规格 |
|--------|------|
| 参与者显示 | 会话详情头部显示参与者头像+姓名，hover显示角色标签 |
| 系统消息 | 邀请/加入/退出均广播系统消息，所有参与者可见 |
| 退出机制 | 被邀请人点击「退出会话」→ 确认 → 从participants移除 → 广播系统消息 |
| 坐席视角 | 坐席工作台可查看参与者列表，可移除被邀请人 |
### 20.5 与「摇人」的关系
| 维度 | 摇人（§9） | 邀请功能（§21） |
|------|-----------|---------------|
| 邀请对象 | 坐席 → 坐席 | 坐席 → 任意员工/部门 |
| 通信通道 | WebSocket（坐席内部） | WebSocket + 企微应用消息（跨端） |
| 被邀请人入口 | 坐席工作台内弹窗通知 | 企微应用消息→H5页面 |
| 典型场景 | 坐席A请坐席B协助同一问题 | 坐席请网络组同事确认现场情况 |
| 数据字段 | `collaborating_agent_ids` | `participants` |
| 权限 | 协作坐席可邀请其他坐席 | 只有主责坐席可邀请员工 |
> **两套机制独立但互补**：摇人解决坐席间协作，邀请解决跨部门/跨角色协作。
### 20.6 非目标（Non-goals）
| 不做什么 | 原因 |
|---------|------|
| 不做企微群聊同步 | appchat API无法接收群内消息，技术上不可行 |
| 不做被邀请人二次邀请 | 防止邀请链失控，只有主责坐席能发起邀请 |
| 不做邀请审批流程 | 邀请是即时协作需求，加审批会破坏时效性 |
| 不做音视频通话 | 当前只做文字协作，音视频是独立功能 |
| 不做跨企业邀请 | 阶段一仅限内部员工，互联企业是阶段四的P2需求 |
| 不做文件/图片共享 | 阶段一支持文本+文件上传，图片粘贴共享留到阶段二 |
### 20.7 交互原型
详见 `docs/prototypes/invite-flow-v1.html`，包含9步完整交互流程：
1. 架构概览（SVG流程图）
2. 一对一会话中 → 点击邀请
3. 选人弹窗（组织架构树+已选列表+历史共享设置）
4. 批量选部门
5. 历史消息共享模式选择
6. 确认邀请（后端6步时序）
7. 企微通知卡片样式
8. 加入会话流程
9. 多人会话双视角对照
### 20.8 依赖与前提
| 依赖 | 状态 | 说明 |
|------|------|------|
| 企微通讯录API | ✅ 已有 | 读取部门/员工列表，OAuth2授权后可调用 |
| 企微应用消息推送 | ✅ 已有 | `/message/send` 推送邀请通知 |
| WebSocket通道 | ✅ 已有 | 坐席端和H5端均已实现 |
| H5 Mock登录 | ✅ 已有 | 被邀请人通过H5加入，Mock模式下手动登录 |
| template_card消息 | 🔧 需开发 | 邀请卡片消息类型，当前仅支持text消息 |
---
## 21. 应急降级页设计 — BC/DR 业务连续性保障
> **需求提出**: 2026-06-15（经多次澄清，核心场景为 BC/DR）
> **需求方**: Simon
> **状态**: 方案已确认，待实施
> **关联规则**: §3.3 降级应急预案
### 21.1 背景与业务目标
**核心场景**：🔴 **业务连续性（BC/DR）** — 系统故障时切换至企微原生服务，坐席保留关键功能
当本系统出现**特殊情况**（故障 / 不可用 / 合规要求 / 流量过载）时：
1. **员工侧**：切换至企微**原生员工服务**（群聊/单聊兜底）
2. **坐席侧**：通过企微"员工服务 → 服务窗口"链接，使用本系统应急页
3. **目标**：即使主系统挂掉，**核心 IT 服务不中断**
### 21.2 入口架构（1 URL + 企微 JS-SDK）
```
┌────────────────────────────────────────┐
│ 企微"员工服务"应用(企业已建) │
│ └─ "服务窗口" tab(只能配 1 个 URL) │
│ └─ https://itsupport.servyou.com.cn/emergency
└────────────────────────────────────────┘
↓
┌────────────────────────────────────────┐
│ /emergency 页面(身份检测) │
│ 1. 加载企微 JS-SDK(不依赖本后端) │
│ 2. agentConfig 拿当前 userid │
│ 3. 调企微通讯录 API 查 user 详情 │
│ 4. 判断身份:是"IT支持-咨询坐席"标签成员 │
│ ├─ 是 → router.push('/agent/preview')│
│ └─ 否 → router.push('/h5/preview') │
└────────────────────────────────────────┘
```
**关键设计原则**：
- 身份检测**不依赖本系统后端**（主系统挂时仍可用）
- 应急页 2 套（h5 + agent），通过 router.push 切换
- 企微通讯录 API 走企微 access_token，跟主系统无关
### 21.3 保留功能（4 件套 + 动态联系人）
| # | 功能 | 描述 | 数据源 |
|---|---|---|---|
| 1 | 🔍 **快速回复模板** | 100+ 条按关键词搜索 | mock JSON → localStorage |
| 2 | 🔍 **排障流程模板** | vpn/邮箱/系统/账号 4 大类 | mock JSON → localStorage |
| 3 | 📋 **资源/审批链接** | 12 个常用入口 | mock JSON → localStorage |
| 4 | 👥 **应急联系人** | 企微标签"IT支持-咨询坐席"成员 | 企微 API → 单独 localStorage |
| **合计** | | | **~750KB + 联系人列表** |
#### 21.3.1 应急联系人（动态，非固定）
**数据源**：企微通讯录标签"IT支持-咨询坐席"
**预同步**：
- 主系统正常时，每 30 分钟调企微通讯录 API 查该标签成员
- 存到**独立 localStorage key** `emergency_contacts`：
```json
{
"synced_at": "2026-06-15T10:00:00",
"tag_id": "TAG_xxx",
"members": [
{"userid": "zhangsan", "name": "张三", "avatar": "...", "online": true},
...
]
}
```
**应急展示**：
- 列出标签下所有成员
- 在线/离线状态（企微 status 接口）
- 点击 → 打开企微单聊
- 数据 > 1 小时未更新时标红，提示"联系人可能不准，建议手动搜索标签组"
### 21.4 "特殊情况" 触发与降级
| 类型 | 触发条件 | 降级动作 |
|---|---|---|
| 🔴 主系统完全不可用 | API 5xx / 网络断开 | 切企微原生 + 服务窗口 |
| 🟡 部分功能故障 | 消息发送失败 / 排队堵死 | 切企微原生 + 工具走应急页 |
| 🟠 合规要求 | 必须用企微审计 | 切企微原生 + 应急页工单 |
| 🟢 流量过载 | 服务降级中 | 部分功能走应急页 |
### 21.5 功能范围
| 项 | H5 应急页 | Agent 应急页 |
|---|---|---|
| URL | `/h5/preview` | `/agent/preview` |
| 统一入口 | `/emergency` | `/emergency` |
| 显示组件 | `RightPanel.vue`（3 段式） | `AiAssistantPanel.vue`（4 件套） |
| 去除功能 | `ChatPanel`（聊天走企微原生） | `ConversationList` + `ChatArea` + `TopBar` |
| 数据源 | **预同步到 localStorage** | **预同步到 localStorage** |
| 后端调用 | **无**（主系统可能挂） | **无**（主系统可能挂） |
| 用户登录 | **跳过**（应急场景免登） | **跳过**（应急场景免登） |
### 21.6 数据预同步机制（2 个独立 localStorage）
#### localStorage #1: `emergency_data`（静态工具数据）
**正常态**：
```
主后端 /api/emergency-data
→ 前端每 30 分钟拉取
→ 存到 localStorage("emergency_data")
```
**应急态**：
```
localStorage("emergency_data") → 应急页直接渲染
```
**内容**：快速回复 / 排障 / 资源（~750KB）
#### localStorage #2: `emergency_contacts`（动态联系人）
**正常态**：
```
企微通讯录 API 查"IT支持-咨询坐席"标签
→ 前端每 30 分钟拉取
→ 存到 localStorage("emergency_contacts")
```
**应急态**：
```
localStorage("emergency_contacts") → 应急页渲染联系人列表
```
**内容**：标签成员列表（动态，可能多人）
### 21.7 页面要求（应急场景）
#### 21.7.1 `/emergency`（身份检测入口，约 50 行）
- 加载企微 JS-SDK（wx.config + wx.agentConfig）
- 拿当前 userid
- 调企微通讯录 API 查 user 详情 + 标签
- 判断是否含"IT支持-咨询坐席"标签
- 是坐席 → push /agent/preview，否则 → push /h5/preview
- 检测失败 → 显示"请选择身份"2 个大按钮兜底
#### 21.7.2 H5 应急页（`/h5/preview`）
- 顶部：项目名 + **"🆘 应急模式"** 红色徽章 + 数据更新时间
- 主体：`RightPanel` 全宽，3 段式（AI 推送 / 资源 / 趣味问答）
- 底部：固定"主系统异常？此页面帮您继续获得服务"
- 移动端：强制显示（覆盖 `isMobile` 判断）
#### 21.7.3 Agent 应急页（`/agent/preview`）
- 顶栏：简化版 TopBar + 🆘 徽章
- 主体：`AiAssistantPanel` 全宽，4 件套
- 联系人：标签组成员 + 在线状态
- 底部：固定"主系统异常"提示
### 21.8 文件改动清单
#### H5 端（frontend-h5/）
| 操作 | 路径 | 说明 |
|---|---|---|
| 新建 | `src/views/EmergencyEntry.vue` | 身份检测入口（约 50 行） |
| 新建 | `src/views/H5PreviewView.vue` | 应急主页 |
| 新建 | `src/mock/emergency-data.json` | 应急静态数据 |
| 新建 | `src/utils/emergency-sync.ts` | 同步工具（2 个 localStorage） |
| 改 | `src/router/index.ts` | 加 `/emergency` + `/h5/preview` |
| **复用** | `src/components/assistant/RightPanel.vue` | import 共享 |
#### Agent 端（frontend-agent/）
| 操作 | 路径 | 说明 |
|---|---|---|
| 新建 | `src/views/AgentPreviewView.vue` | 应急主页 |
| 改 | `src/router/index.ts` | 加 `/agent/preview` |
| **复用** | `src/components/assistant/AiAssistantPanel.vue` | import 共享 |
**注**：联系人 API 调用放 `emergency-sync.ts` 共用模块，h5 + agent 都用
### 21.9 验收标准
#### 功能验收
- [ ] **断网测试**：拔网线/关后端 → 应急页仍能打开
- [ ] **身份自动路由**：员工点开 → /h5/preview，坐席点开 → /agent/preview
- [ ] **联系人动态**：标签组加新人，预同步后能显示
- [ ] **数据新鲜度**：顶部"数据 X 分钟前更新"，> 1h 标红
- [ ] **2 个 localStorage 独立工作**：删 emergency_data 不影响 emergency_contacts
#### 灾备演练（非工作时间，本月必做）
- [ ] 选择非工作时间（晚上 / 周末）
- [ ] 模拟主系统挂掉 → 切企微原生服务 → 坐席用应急页
- [ ] 演练时长 / 解决率 / 痛点记录
- 详见 `docs/SOPs/SOP-005-应急降级演练.md`
### 21.10 排期
| 时间 | 任务 |
|---|---|
| 2026-06-16（周一） | WB 接单，1 入口 + 2 页面 + 1 mock + 1 同步工具 + 2 路由 |
| 2026-06-16（周一） | 本地 `npm run build` 验证 |
| 2026-06-17（周二） | 部署 + **断网演练**（非工作时间，如周二晚 20:00） |
| 2026-06-18（周三） | 收集问题，迭代 |
| 2026-06-19（周四） | 二次演练确认 |
| 2026-06-20（周五） | 正式版上线 + 应急页同步上线 |
### 21.11 应急场景的额外考虑
1. **入口要醒目**：企微"员工服务 → 服务窗口"配置清晰描述
2. **不依赖登录**：应急时坐席可能密码都改不了，免登
3. **非工作时间演练**：降低对业务影响
4. **联系人降级**：实在没预同步数据，提示"请手动搜索 IT支持-咨询坐席 标签"
5. **保留升级路径**：主系统恢复后，应急页要有提示"主系统已恢复，建议返回"
### 21.12 关联文档
- **双端同步规则**：`[[preview-pages-sync-rule]]`
- **锁定决策**：`[[locked-decisions]] § 应急降级`
- **演练 SOP**：`docs/SOPs/SOP-005-应急降级演练.md`
- **需求演进**：v1 灰度（误）→ v2 BC/DR（理解）→ v3 服务窗口（1 URL）→ v4 标签联系人（动态）
---
## 22. 阶段5 自动化闭环需求
> **新增日期**: 2026-07-06 | **状态**: 已合并（原独立文档 `docs/02-需求分析/阶段5-自动化闭环-PRD.md` 已归档删除）| **定位**: 在阶段1-4（MVP→完整流程→AI Wingman辅助→知识库/看板）基础上，将「AI辅助」与「知识库/看板」闭环为「自动处置 + 自动关单」。外部系统集成见主文档 §18（火绒/HMAC-SHA1、联软 LV7000、Dify、RAGFlow、aTrust/HMAC-SHA256待密钥、eHR）。
### 22.1 产品目标
**要解决的核心问题**：阶段3 是「AI 辅助坐席」、阶段4 是「知识库 + 看板」，但常见 IT 请求（密码重置、软件自助安装、病毒自动处置、终端定位、网络故障自助、权限申请）仍需人工接待与处置，导致人工成本高、响应慢。
**成功标准（可量化，验收口径见 §22.5 Q7）**：
| # | 目标 | 指标 / 量化标准 |
| --- | --- | --- |
| G1 | 提升自动化闭环率 | 上线首季 ≥ 30%、稳态 ≥ 50%（无需人工介入即从受理到关单的会话占比） |
| G2 | 降低人工介入 | 同类请求坐席工时较阶段4 下降 ≥ 40% |
| G3 | 缩短响应时延 | 机器人首响应时间 ≤ 5 秒（WebSocket 实时推送） |
| G4 | 提升自动关单率 | 处置成功且无需转人工的会话中，自动关单占比 ≥ 90% |
| G5 | 覆盖满意度采集 | 自动关单后自动推送评价，满意度收集覆盖率 ≥ 95% |
| G6 | 保障安全合规 | 高危/写操作 100% 审计留痕，0 安全事故（处置需可审批、可回滚） |
### 22.2 用户故事
**员工（H5 端）**
- 作为员工，我希望描述问题后系统能自动给出解决方案或自动处理，以便我无需等待坐席即可快速恢复工作。
- 作为员工，我希望能实时看到自动化处置进度与结果，以便了解我的请求状态，必要时主动转人工。
**坐席（agent 端）**
- 作为坐席，我希望系统自动处置常见请求、仅把疑难/异常/高危转给我，以便我专注高价值问题。
- 作为坐席，我希望能一键查看、审核或接管自动化动作，以便在安全兜底的同时减少重复操作。
**管理员（admin 端）**
- 作为管理员，我希望能配置自动化场景的触发条件与动作、审核写操作审批策略，以便安全可控地运营自动化。
- 作为管理员，我希望在看板中查看自动化闭环率/介入率/响应时长等指标，以便持续优化场景。
### 22.3 需求池（P0/P1/P2）
> 优先级：P0=Must have（本期必须）；P1=Should have（重要可分批）；P2=Nice to have（可选/后续）。依赖外部系统：火绒 / 联软 LV7000 / Dify / RAGFlow / aTrust / eHR；映射策略 联软(主) > aTrust(VPN辅) > eHR(静态)。
**P0（Must have）**
| 编号 | 名称 | 描述 | 优先级 | 角色 | 依赖 |
| --- | --- | --- | --- | --- | --- |
| P0-01 | 意图识别与场景路由 | 基于 Dify 识别员工自然语言意图，结合 RAGFlow 知识库，将请求路由到对应自动化场景（自助应答 / 处置执行 / 转人工） | P0 | user/agent | Dify、RAGFlow、§18 知识库 |
| P0-02 | 员工↔终端映射解析 | 复用联软 LV7000 `strusername` 字段建立员工↔终端映射，作为自动化处置定位终端的依据；映射策略：联软(主) > aTrust(VPN辅) > eHR(静态) | P0 | user/agent | 联软 LV7000、aTrust(待密钥)、eHR |
| P0-03 | 知识库自助应答 | 复用 RAGFlow 检索知识库，向员工返回自助解决指引（图文/步骤），支持「已解决/未解决」反馈 | P0 | user | RAGFlow、§18 知识库 |
| P0-04 | 自动化处置执行引擎 | 核心执行层，分级执行（见 §22.5 Q2）：只读/低风险动作自动执行；写操作/高危动作默认需审批或员工 H5 二次确认。调用火绒/联软/aTrust 等 | P0 | user/agent | 火绒、联软 LV7000、aTrust(待密钥)、P0-05 |
| P0-05 | 自动化动作审批与审计 | 对写操作/高危动作提供审批与 100% 审计留痕（操作人、对象、参数、结果、时间） | P0 | admin/agent | P0-04、OAuth2、会话审计 |
| P0-06 | 转人工兜底与阈值 | 定义自动应答/处置必须转人工的触发条件（见 §22.5 Q3）：置信度<0.6 / 超时60s / 高危必转 / 员工主动转 / 连续未解决≥2次 | P0 | user/agent | P0-01 |
| P0-07 | 自动关单 + 满意度自动收集 | 处置成功且员工未异议后静默 10 分钟自动关单（见 §22.5 Q4），并自动推送满意度评价 | P0 | user | 满意度、数据看板 |
| P0-08 | 管理后台自动化配置 | 管理后台简易配置（见 §22.5 Q5）：自动化场景开关、触发条件与动作配置、审批策略配置 | P0 | admin | §17 功能开关、集成配置 |
| P0-09 | 自动化实时进度推送 | 经 WebSocket 向 H5 与坐席端实时推送处置进度/状态/结果，复用 WebSocket 与本地消息缓存 | P0 | user/agent | WebSocket、本地消息缓存 |
| P0-10 | 自动化指标看板 | 在数据看板基础上扩展：自动化闭环率、人工介入率、首响应时长、场景分布、自动关单率 | P0 | admin | 数据看板 |
**P1（Should have）**
| 编号 | 名称 | 描述 | 优先级 | 角色 | 依赖 |
| --- | --- | --- | --- | --- | --- |
| P1-01 | 处置失败回滚/补偿 | 写操作失败时提供回滚或补偿机制，保证终端/VPN 状态可恢复 | P1 | agent/admin | P0-04、P0-05 |
| P1-02 | 异常处理与自动转人工通知 | 处置失败/超时/异常时自动转人工并通知坐席（经 WebSocket） | P1 | agent | P0-06、P0-09 |
| P1-03 | 规则版本管理与灰度 | 自动化场景配置支持版本快照与灰度发布（小比例流量验证后再全量） | P1 | admin | P0-08 |
| P1-04 | 高危操作员工侧二次确认 | 影响员工终端/账号的高危动作，执行前需在 H5 端二次确认 | P1 | user | P0-04、P0-05 |
**P2（Nice to have）**
| 编号 | 名称 | 描述 | 优先级 | 角色 | 依赖 |
| --- | --- | --- | --- | --- | --- |
| P2-01 | 可视化工作流编排引擎 | 可视化配置「触发条件→动作链」（拖拽式）。本期用管理后台简易配置（Q5），引擎列入 P2 后续迭代 | P2 | admin | P0-08 |
| P2-02 | 自学习场景优化 | 基于满意度/转人工数据，自动建议或优化场景路由与方案 | P2 | admin | P0-10 |
| P2-03 | 权限申请自动化 | 联动 eHR/审批流，自动发起并跟踪权限申请（涉及审批流，范围较大） | P2 | user/admin | eHR、P0-04 |
| P2-04 | aTrust VPN 自动化接入 | 基于 aTrust(HMAC-SHA256) 自动处理 VPN 接入/策略。**aTrust 密钥未到则后置**（见 §22.5 Q6） | P2 | user | aTrust(待密钥) |
### 22.4 UI 设计稿
> 风格：沿用现有 Vue3 三端风格——浅色扁平、主色 accent = `#07C160`。
**端到端自动化闭环流程**
```mermaid
flowchart TD
A[员工 H5 提交请求] --> B{意图识别/场景路由
Dify + RAGFlow}
B -->|高置信-自助类| C[知识库自助应答
RAGFlow]
B -->|处置类| D{是否写操作/高危?}
D -->|否/只读| E[自动化处置执行引擎]
D -->|是| F{需审批/确认?}
F -->|是| G[审批流/坐席审核/员工二次确认]
F -->|否| E
G --> E
E --> H{处置成功?}
H -->|是| I[自动关单 + 满意度自动收集]
H -->|否| J[自动转人工 坐席接管]
B -->|低置信/异常/超时| J
C -->|已解决| I
C -->|未解决| J
I --> K[看板:闭环率/介入率/响应时长]
J --> K
```
**H5 员工端 · 自动化会话页（线框）**
```
┌─────────────────────────────┐
│ ← IT 智能服务台 │
├─────────────────────────────┤
│ [输入/语音] 描述你的问题… │
├─────────────────────────────┤
│ 🤖 智能助手（实时进度条） │
│ ▸ 已识别：密码重置 │
│ ▸ 正在检索知识库… │
│ ▸ 已生成自助方案 / 处置中… │
├─────────────────────────────┤
│ 方案卡片：步骤1/2/3… │
│ [已解决] [仍未解决] │
├─────────────────────────────┤
│ [转人工] [查看进度] │
└─────────────────────────────┘
```
**H5 状态流转**
```mermaid
stateDiagram-v2
[*] --> 提交请求
提交请求 --> 识别中: WebSocket 推送
识别中 --> 自助应答: 高置信
识别中 --> 自动处置: 处置类
识别中 --> 转人工: 低置信/异常
自助应答 --> 已解决: 员工点[已解决]
自助应答 --> 转人工: 员工点[未解决]
自动处置 --> 待确认: 高危/写操作需确认
待确认 --> 处置中: 员工确认
自动处置 --> 处置中: 免确认
处置中 --> 已解决: 成功
处置中 --> 转人工: 失败/超时
已解决 --> 自动关单: 静默10分钟/默认关单
自动关单 --> 满意度评价
转人工 --> 坐席处理
```
**坐席端 · 自动化处置监控 / 接管页（线框）**
```
┌──────────────────────────────────────┐
│ 自动化工作台 │
├──────────────────────────────────────┤
│ 进行中自动化会话 (实时列表) │
│ • 员工A · 病毒处置 · 处置中 · [接管] │
│ • 员工B · 软件安装 · 待确认 · [审核] │
├──────────────────────────────────────┤
│ 选中会话详情： │
│ 意图/场景 · 映射终端 · 计划动作链 │
│ [一键接管] [批准执行] [驳回转人工] │
├──────────────────────────────────────┤
│ 异常/超时队列（自动转人工） │
└──────────────────────────────────────┘
```
```mermaid
flowchart LR
M[坐席监控列表] -->|查看| N[会话详情]
N -->|一键接管| O[坐席接管处理]
N -->|批准执行| P[执行引擎继续]
N -->|驳回/高危| Q[转人工处理]
P --> R[自动关单/异常]
```
**管理后台 · 自动化配置 + 看板（线框）**
```
┌──────────────────────────────────────┐
│ 管理后台 / 自动化 (OTP 已验证) │
├──────────────┬───────────────────────┤
│ 场景开关 │ 自动化指标看板 │
│ ☑ 密码重置指引 │ 闭环率 32% ▲ │
│ ☑ 软件自助安装 │ 介入率 ↓ 41% │
│ ☑ 病毒自动处置 │ 首响应 3.2s │
│ ☑ 终端定位 │ 场景分布(饼) │
│ ☐ 权限申请 │ │
├──────────────┼───────────────────────┤
│ 触发条件/动作 │ 审批策略 │
│ 意图=密码重置 │ 写操作: ☑需审批 │
│ → 动作=推送指引│ 高危: ☑员工二次确认 │
│ [保存] [版本] │ [保存] │
└──────────────┴───────────────────────┘
```
### 22.5 待确认问题与确认结论
> 以下原 PRD 待确认项均已由产品负责人与业务方确认（2026-07-06），结论如下，相应需求条目已在 §22.3 同步标注。
| 编号 | 原问题 | 确认结论 | 状态 |
| --- | --- | --- | --- |
| Q1 | 优先覆盖场景 | 首期聚焦 **①④②③** 四类：①密码重置指引 ②软件自助安装 ③病毒自动处置（火绒）④终端定位（联软映射）；网络故障自助、权限申请后置 | ✅ 已确认 |
| Q2 | 执行模式与安全设计 | **分级执行**：只读/低风险动作自动执行；写操作/高危动作默认需审批或员工 H5 二次确认；审计留痕、可回滚（P1-01） | ✅ 已确认 |
| Q3 | AI 兜底与人工接管阈值 | **可配置默认值**：意图置信度 < 0.6、处置超时 60s、命中高危必转、员工主动转人工、连续未解决 ≥ 2 次 | ✅ 已确认 |
| Q4 | 自动关单与满意度触发 | **静默 10 分钟**自动关单（员工无异议）；关单后自动推送满意度评价 | ✅ 已确认 |
| Q5 | 是否需要可视化编排引擎 | 本期用**管理后台简易配置**（P0-08 开关+条件+动作）；可视化编排引擎列 P2（P2-01）后续迭代 | ✅ 已确认 |
| Q6 | aTrust 密钥与 VPN 自动化排期 | aTrust 密钥未到，则 **VPN 自动化（P2-04）后置**，不影响首期交付 | ✅ 已确认 |
| Q7 | 量化目标值拍板 | G1 闭环率首季30%/稳态50%、G2 人工介入下降40% 等**暂定作验收口径**，后续按实际数据校准 | ✅ 已确认 |
---
## 附录 A: 术语表
| 术语 | 说明 |
|------|------|
| 企微 | 企业微信 |
| 员工服务 | 企微内置的客服模块，本方案将放弃使用 |
| 自建应用 | 企微中由企业自行开发的应用 |
| 互联企业 | 企微跨主体企业互联功能 |
| RAGFlow | 检索增强生成引擎，用于知识库语义检索 |
| Dify | AI应用开发平台 |
| 千问 | 阿里云通义千问大模型 |
| 摇人 | 一键呼叫IT坐席的趣味化交互设计 |
| 并行协作 | AI和人工同时在线，人工可随时介入的创新服务模式 |
## 附录 B: 企微API关键接口
| 接口 | 用途 | 文档 |
|------|------|------|
| 接收消息 | 通过回调URL接收员工发送的消息 | 企微自建应用消息回调 |
| 发送消息 | 主动向员工发送消息 | 企微应用消息发送API |
| 通讯录读取 | 获取员工信息（VIP判断） | 企微通讯录API |
| 互联企业应用共享 | 跨主体共享应用 | 企微互联企业API |
| OAuth2静默授权 | H5页面身份认证 | 企微网页授权API |
## 附录 C: TeliChat 技术分析 — 产品设计借鉴
> **分析日期**: 2026-07-03 | **来源**: TeliChat 官网 (telichat.io) | **目的**: 借鉴 TeliChat 架构理念，优化复杂对话场景设计
### C.1 核心理念
TeliChat 提出 **"让代码负责业务逻辑，让模型负责语言理解"** 的分工模式：
| 问题 | 传统 ReAct Agent | TeliChat 方案 |
|------|-----------------|---------------|
| 幻觉 | 模型自由推理导致越权 | 代码硬编码业务流程，100% 确定 |
| 延迟 | 每步都调用大模型推理 | 仅意图识别用模型，执行由 Python 完成 |
| 状态 | 长对话上下文丢失 | 独立结构化状态空间，持久化存储 |
### C.2 三大核心组件
| 组件 | 职责 | 在 IT 服务台中的对应 |
|------|------|---------------------|
| **对话树** | 基于 DAG 表达交互逻辑和状态流转 | Neo4j 知识图谱（可复用） |
| **大语言模型** | 意图识别，信息抽取，自然语言生成 | Dify / 千问 |
| **Python 代码** | 业务逻辑、权限校验、API 调用 | FastAPI 后端服务 |
### C.3 信息项状态管理
借鉴 TeliChat 的信息项概念，设计结构化的用户信息状态：
| 修饰 | 交互策略 | 在 IT 服务台的应用 |
|------|---------|-------------------|
| `固定` | 不再询问，通过系统获取 | 操作系统版本、用户名 |
| `增量` | 允许补充，不覆盖旧值 | 故障描述、错误信息 |
| `明确` | 必须明确回答 | 紧急程度确认 |
| `隐含` | 可从上下文推断 | AI 推断的问题类型 |
| `复述` | 要求用户确认 | 关键操作确认 |
| `必需` | 缺失则强制补全 | 必填的故障信息 |
### C.4 三重约束抑制幻觉
1. **拓扑结构限制** — 限制对话可以走到哪里
2. **信息状态约束** — 决定当前已经知道什么
3. **Python 代码约束** — 负责真正的业务判断
### C.5 与 Dify 工作流的对比
| 维度 | Dify 工作流 | TeliChat 风格 | 适用场景 |
|------|------------|--------------|---------|
| 流程表达 | 线性节点图 | DAG 对话树 | Dify 适合固定流程，TeliChat 适合多分支 |
| 状态管理 | 单一节点状态 | 组合信息项 | TeliChat 更适合复杂长对话 |
| 用户灵活性 | 路径固定 | 允许乱序输入 | TeliChat 更适合自然对话 |
### C.6 落地建议
**短期（1-2周）**:
- 信息项模型设计：在 Conversation 模型中增加 `information_items` JSON 字段
- 全局意图识别：在 Dify 中新增意图识别 Agent
**中期（1个月）**:
- 开发独立的对话状态管理服务
- Neo4j 融合：将知识图谱作为对话树的入口路由
**长期（季度目标）**:
- 白盒调试能力：实现对话轨迹全链路追踪
- 性能优化：简单场景跳过 Dify，直接 Python 处理