# 飞书前门 go-live 试点方案 v1

## 1. 文档目的
本文件用于定义人才盘点自动化系统"飞书前门"的第一阶段 go-live 试点方案。
目标不是一次性全量上线，而是先通过小范围、低风险、可复盘的方式验证：
- 飞书入口是否可用
- Runtime Portal 是否适合作为默认首页
- 业务用户是否愿意通过飞书进入系统
- 下载、查看、当前版本识别等核心体验是否顺畅
- 后续是否值得继续推进免登、通讯录、通知、审批流等能力

## 2. 当前阶段判断
当前系统已经具备：
- Runtime Portal
- 推荐下载
- 最新交付包
- current_release
- release_history
- HTML / PDF / PPT / ZIP 正式交付物
- run_full_release 一键发布
- release_manifest / artifact_index / audit_log

因此，飞书前门的第一阶段试点不再是概念验证，而是把现有产品原型真正接到业务实际使用入口里。

一句话判断：
当前试点的重点不是"能不能做飞书前门"，而是"业务方是否愿意通过飞书把它当成正式入口使用"。

## 3. 试点目标
本次飞书前门试点建议聚焦以下五个目标：

1. 业务方能在飞书中稳定打开系统首页
2. Runtime Portal 作为默认首页的产品感是否足够
3. 当前正式版本、推荐下载、最新交付包是否足够直观
4. 试点用户是否能完成核心路径操作
5. 能否快速收集第一轮产品反馈并反推后续优化优先级

## 4. 试点范围
建议第一阶段采用：

### 4.1 试点范围
- 小范围验证
- 白名单放行
- 核心内部用户优先

### 4.2 第一批建议用户
建议优先开放给以下角色：
- system_admin
- hrbp
- business_manager
- 核心 reviewer

### 4.3 暂不建议第一阶段开放给
- 全量业务用户
- 无关围观用户
- 无真实使用场景的普通 viewer

一句话判断：
飞书前门第一阶段应该追求"高质量试点"，而不是"大面积铺开"。

## 5. 白名单建议
第一阶段建议采用白名单方式推进。

建议白名单至少包含：
1. 产品负责人
2. 系统维护人
3. HRBP 试点用户
4. 业务负责人 / 核心管理者
5. 一到两位真实使用者作为反馈样本

原因：
- 控制风险
- 便于快速迭代
- 便于问题定位
- 便于验证真实使用路径

## 6. 默认首页建议
第一阶段建议明确：

### 6.1 默认首页
- Runtime Portal

### 6.2 选择原因
因为 Runtime Portal 已经具备：
- 当前运行状态
- current_release
- 推荐下载
- 最新交付包入口
- 历史发布版本
- 趋势分析摘要
- 权限模型摘要
- 最近审计事件

一句话判断：
当前 Runtime Portal 已经不是简单页面，而是最适合作为飞书前门首页的产品壳。

## 7. 试点用户核心使用路径
第一阶段建议重点验证以下路径：

### 路径 A：进入首页
- 用户从飞书进入应用
- 打开 Runtime Portal
- 看到当前项目 / 当前期次 / 当前正式版本

### 路径 B：获取正式交付物
- 查看推荐下载
- 查看最新交付包
- 下载 PPT / PDF / ZIP

### 路径 C：理解当前发布状态
- 查看 current_release
- 查看 release_note
- 查看历史发布版本

### 路径 D：理解组织与趋势
- 查看趋势分析摘要
- 理解当前版本和历史版本关系
- 查看多期对比正式交付物

## 8. go-live 前检查项

### 8.1 飞书入口检查
- 桌面端首页可打开
- 移动端首页可打开
- H5 页面兼容正常
- trusted domain 配置正确
- 菜单入口可点击

### 8.2 产品首页检查
- Runtime Portal 加载正常
- current_release 展示正常
- 推荐下载可点击
- 最新交付包可下载
- 历史发布版本可展示

### 8.3 正式交付检查
- PPT v2 可下载
- 团队汇总 PDF 可下载
- 组织分析 PDF 可下载
- 多期对比 PDF 可下载
- latest_release_bundle.zip 可下载

### 8.4 治理检查
- release_manifest_latest 可用
- release_history_latest 可用
- audit_log_latest 可用

## 9. 反馈收集
第一阶段必须同步设计反馈收集方式，否则试点价值会大打折扣。

### 9.1 建议收集的反馈维度
- 是否容易进入
- 首页是否看得懂
- 推荐下载是否够直观
- 哪些内容最有价值
- 哪些内容信息密度过高
- 哪些操作还不够顺
- 是否愿意继续通过飞书使用

### 9.2 建议反馈方式
- 白名单试点群
- 定向访谈
- 使用后快速问卷
- 核心用户定性反馈

### 9.3 反馈收集重点
第一阶段不要一上来收太多细节，而要优先回答：
1. 入口是否顺
2. 首页是否有产品感
3. 交付物是否足够有用
4. 用户是否愿意继续用

## 10. 成功标准
建议把 go-live 成功标准定义为以下几类：

### 10.1 技术成功标准
- 飞书内可稳定打开首页
- 页面无明显崩溃或白屏
- 主要下载链接有效
- current_release 展示正确

### 10.2 产品成功标准
- 试点用户能看懂首页结构
- 推荐下载和最新交付包有明显使用价值
- 历史发布版本展示不会造成困惑

### 10.3 业务成功标准
- 至少有一批试点用户愿意持续从飞书进入
- 至少有一轮真实管理讨论使用到这些交付物
- 能形成清晰的下一轮优化需求清单

一句话判断：
go-live 不是"能打开页面"就算成功，而是"业务方愿意把它当成入口使用"。

## 11. 试点推进节奏
建议按以下顺序推进：

### T-3 ~ T-1
- 完成飞书应用配置
- 完成 Runtime Portal 当前版本上线
- 完成小范围白名单确认
- 完成下载链路检查

### Day 1
- 小范围验证
- 核心用户进入飞书应用
- 检查首页、bundle、推荐下载、current_release

### Week 1
- 收集第一轮反馈
- 记录主要问题
- 判断首页与下载中心是否要微调

### Week 2
- 形成试点结论
- 判断是否扩大范围
- 判断是否进入免登 / 通讯录 / 通知阶段

## 12. 风险与回退
第一阶段建议明确风险控制与回退方式：

### 12.1 主要风险
- 首页打开不稳定
- 下载链路不顺
- 入口产品感不足
- 用户看不懂首页层级
- 版本展示造成困惑

### 12.2 回退策略
- 保留现有 Web 直链作为备用入口
- 白名单缩小
- 先只开放 Runtime Portal，不开放更多入口
- 先修 Portal 体验，再扩大范围

## 13. open_questions
当前仍需后续明确的问题包括：
1. 第一批白名单具体包含哪些人
2. 移动端是否需要独立体验优化
3. 试点阶段是否直接启用最新交付包下载
4. current_release 是否需要首页更突出显示
5. 是否需要单独做一页"飞书首页轻首页"
6. 试点成功后先接免登，还是先接通知

## 14. 一句话总结
飞书前门 go-live 试点的意义，不是把一个链接搬进飞书，而是验证 Talent Review OS 是否能真正进入业务工作入口、被真实用户持续使用。
