chore: initial baseline with P0-safety .gitignore
This commit is contained in:
@@ -0,0 +1,127 @@
|
||||
# H5用户端右侧栏动态推送评估
|
||||
|
||||
评估日期:2026-06-11
|
||||
|
||||
## 评估对象
|
||||
|
||||
用户端右侧栏不再提供静态标签导航和资源列表,而是基于会话上下文和第三方集成数据触发阈值,动态推送相关问题答疑、流程审批、软件下载等资源卡片。
|
||||
|
||||
本质:从"人找资源"到"资源找人"的范式转换。
|
||||
|
||||
---
|
||||
|
||||
## 一、正面价值
|
||||
|
||||
### 1. 符合系统定位——"AI驱动"
|
||||
|
||||
系统全名是"IT智能服务台 — AI驱动",但当前右侧栏本质是传统信息架构(标签页+列表),AI只在左侧会话区参与。动态推送让右侧也变成AI能力的延伸,整个产品才能名副其实。
|
||||
|
||||
### 2. 降低用户认知负荷
|
||||
|
||||
传统模式下,用户遇到VPN问题,需要自己点"常用资源"→翻到VPN分类→找对应文档。动态推送模式下,系统识别到会话提到VPN,右侧自动出现VPN连接指南、aTrust下载链接——用户零步触达。
|
||||
|
||||
### 3. 提升首问解决率
|
||||
|
||||
很多IT支持请求本质是"信息差"——用户不知道流程怎么走、软件去哪下、密码怎么改。主动推送填补信息差,用户可能都不需要和坐席对话就解决了。
|
||||
|
||||
### 4. 数据闭环价值
|
||||
|
||||
推送了什么、用户点了什么、是否解决问题——这些行为数据反过来可以优化推送准确度和知识库质量,形成"推送→反馈→优化"的飞轮。
|
||||
|
||||
### 5. 与第三方集成天然契合
|
||||
|
||||
联软查到某员工终端有高危漏洞→右侧推送修复指南;aTrust检测到VPN异常→右侧推送重连步骤。这种场景下,动态推送比静态列表的体验差距是量级性的。
|
||||
|
||||
---
|
||||
|
||||
## 二、风险与挑战
|
||||
|
||||
### 1. 冷启动问题——首条消息前,右侧是空的
|
||||
|
||||
用户刚进入会话,还没说话,系统没有任何上下文。此时右侧要么空白(体验差),要么需要兜底策略(猜用户可能需要什么)。静态列表没有这个问题,任何时候都有内容可看。
|
||||
|
||||
### 2. 准确性依赖——推错了比不推更糟
|
||||
|
||||
用户问"VPN连不上",系统推了aTrust下载链接,但实际是密码过期问题——错误推送不仅没帮到忙,还可能误导用户走弯路,增加后续排查成本。传统列表虽然效率低,但至少不会误导。
|
||||
|
||||
### 3. 可发现性丧失——用户无法主动探索
|
||||
|
||||
有些资源用户不知道存在,只有浏览列表时才会发现"原来还有这个工具"。动态推送只推系统认为相关的,存在"你不知道你不知道"的信息茧房风险。
|
||||
|
||||
### 4. 技术实现成本高
|
||||
|
||||
需要:意图识别引擎→规则引擎/阈值系统→第三方数据实时对接→推送排序算法→用户反馈收集。这套体系远比静态列表复杂,且需要持续调优。
|
||||
|
||||
### 5. 用户信任建立周期长
|
||||
|
||||
如果早期推送不准,用户会养成"忽略右侧栏"的习惯,一旦习惯形成,后续推送再准也没用了。第一印象决定成败。
|
||||
|
||||
### 6. 多意图场景处理难
|
||||
|
||||
"我VPN连不上,另外帮我看看电脑上有没有装火绒"——一个会话包含两个问题,右侧推什么?两套资源都推会显得杂乱,推一套又遗漏另一个。
|
||||
|
||||
---
|
||||
|
||||
## 三、对比分析
|
||||
|
||||
| 维度 | 静态列表(当前方案) | 动态推送(提议方案) |
|
||||
|------|-------------------|-------------------|
|
||||
| 认知负荷 | 高(需自行查找) | 低(自动呈现) |
|
||||
| 准确性 | 无(用户自己判断) | 依赖AI准确度 |
|
||||
| 冷启动 | 有内容 | 需兜底策略 |
|
||||
| 可发现性 | 好(可浏览) | 差(只能看推的) |
|
||||
| 实现成本 | 低 | 高 |
|
||||
| 与第三方集成契合度 | 低(无法感知外部数据) | 高(实时响应) |
|
||||
| 用户信任 | 高(所见即所得) | 需积累 |
|
||||
| 个性化程度 | 无 | 高 |
|
||||
|
||||
---
|
||||
|
||||
## 四、专业建议:混合架构
|
||||
|
||||
两条路线单独走都有明显短板。建议采用"动态为主、静态兜底"的混合模式。
|
||||
|
||||
### 具体方案
|
||||
|
||||
右侧栏分两个区域,上下排列:
|
||||
|
||||
上方(占70%):AI动态推送区
|
||||
- 基于会话上下文+第三方数据触发,显示资源卡片
|
||||
- 卡片类型:问题答疑卡、流程指引卡、软件下载卡、状态通知卡
|
||||
- 有推送时显示,没有推送时不占空间
|
||||
- 用户可点"不相关"反馈,用于优化推送
|
||||
|
||||
下方(占30%):常用资源兜底区
|
||||
- 收起式面板,默认折叠,点击展开
|
||||
- 保留最常用的3-5个入口(密码重置、软件下载、VPN指南、IT制度)
|
||||
- 满足冷启动和主动探索需求
|
||||
|
||||
### 分阶段实施路径
|
||||
|
||||
| 阶段 | 右侧栏形态 | 说明 |
|
||||
|------|-----------|------|
|
||||
| 阶段一(当前) | 静态列表 + 少量AI提示 | 低成本上线,右侧保留3个标签页,AI推送区仅做关键词匹配 |
|
||||
| 阶段二 | 混合模式 | 上方AI推送区基于规则引擎+第三方数据触发,下方常用资源折叠 |
|
||||
| 阶段三 | AI为主、静态兜底 | 引入意图识别,推送准确度达标后,动态推送成主体,静态降级为兜底 |
|
||||
|
||||
### 关键验证指标
|
||||
|
||||
动态推送是否值得扩大投入,看两个数据:
|
||||
|
||||
1. 点击率——推送卡片的点击/曝光比,>15%说明推送有价值
|
||||
2. 自助解决率——用户点了推送资源后未发起坐席对话的比例,>10%说明推送有效减少了人工负担
|
||||
|
||||
两个指标不达标,就别急着扩大动态推送的比例。
|
||||
|
||||
---
|
||||
|
||||
## 五、结论
|
||||
|
||||
| 维度 | 判断 |
|
||||
|------|------|
|
||||
| 方向 | 正确,符合AI驱动定位和用户期望 |
|
||||
| 时机 | 阶段一不急,阶段二再实质性投入 |
|
||||
| 风险 | 全盘替代有冷启动和准确性风险 |
|
||||
| 建议 | 混合架构,数据验证后再扩大动态推送占比 |
|
||||
|
||||
核心观点:想法是对的,但别一步到位。先让静态列表跑起来,用数据证明动态推送真的比用户自己找更高效,再逐步替代。
|
||||
Reference in New Issue
Block a user