chore(docs): docs/ 目录全面重新编号 + 重组

**重构前**（旧编号 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 行

docs/08-历史归档/H5用户端右侧栏动态推送评估-archived-20260704.md

@@ -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驱动定位和用户期望 |
+| 时机 | 阶段一不急，阶段二再实质性投入 |
+| 风险 | 全盘替代有冷启动和准确性风险 |
+| 建议 | 混合架构，数据验证后再扩大动态推送占比 |
+
+核心观点：想法是对的，但别一步到位。先让静态列表跑起来，用数据证明动态推送真的比用户自己找更高效，再逐步替代。