Simon
44e77dcb0e
**重构前**（旧编号 02-11）： - docs/02-产品需求/ → 00 产品规划/PRD - docs/03-技术架构/ → 01-05 子目录散落 - docs/04-原型设计/ → 01-02 产品设计（HTML 原型） - docs/05-原型设计/ → screens/ - docs/06-测试素材/ → 02-E2E / 03-功能 / 04-版本测试 - docs/07-项目管理/ → 任务说明书/日报/计划 - docs/08-安全审计/ → 审计报告 - docs/09-堡垒运维/ → toolbox / deploy - docs/10-项目管理/ → 任务说明书（重复） - docs/11-历史归档/ → deploy-nas-archived **重构后**（新编号 00-07，语义化）： - docs/00-产品开发流程与文档管理规范.md - docs/00-版本迭代总览.md - docs/01-产品文档/ （PRD/原型/认证/会话/AI 服务/坐席/集成） - docs/02-技术文档/ （技术方案/架构图/重构记录/前端改造/实现配置） - docs/03-测试文档/ （E2E/功能用例/版本报告/缺陷单） - docs/04-运维文档/ （部署运维/运维指南） - docs/05-运营文档/ （品牌推广/用户手册） - docs/06-安全审计/ （审计报告） - docs/07-项目管理/ （任务说明书/日报/计划/看板） **净收益**： - 目录编号与产品文档管理规范对齐（按文档阶段 01-07 编号） - 消除 02-产品需求 与 10-项目管理 的编号重叠 - 子目录按文档类型分组（如 01-产品文档/00-产品规划、01-产品文档/01-认证与登录） - 把运维/安全/项目管理从 0X 散落改为 04/06/07 合计 494 文件 + 78495 行 / - 14076 行
5.7 KiB
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为主、静态兜底 | 引入意图识别，推送准确度达标后，动态推送成主体，静态降级为兜底 |
关键验证指标
动态推送是否值得扩大投入，看两个数据：
- 点击率——推送卡片的点击/曝光比，>15%说明推送有价值
- 自助解决率——用户点了推送资源后未发起坐席对话的比例，>10%说明推送有效减少了人工负担
两个指标不达标，就别急着扩大动态推送的比例。
五、结论
| 维度 | 判断 |
|---|---|
| 方向 | 正确，符合AI驱动定位和用户期望 |
| 时机 | 阶段一不急，阶段二再实质性投入 |
| 风险 | 全盘替代有冷启动和准确性风险 |
| 建议 | 混合架构，数据验证后再扩大动态推送占比 |
核心观点：想法是对的，但别一步到位。先让静态列表跑起来，用数据证明动态推送真的比用户自己找更高效，再逐步替代。