问题、目标用户与方案
业务问题
直播数据分散在不同表格和复盘记录里，团队难以快速找到异常、定位场次并跟进任务。
目标用户
需要管理直播场次、复盘记录与跟进任务的直播运营人员。
产品方案
以飞书 Base 为业务数据源，构建直播总览、场次详情、上传、分析结果、复盘、历史和任务页面。
我在项目中的参与
将公开资料中的角色描述拆成可交接的工作面，方便继续核对源码、数据和运行条件。
- 产品架构
- 前端实现
- 数据建模
三步典型使用场景
以下路径是基于公开资料对业务对象和页面关系的整理，不是线上操作记录。
01 · 找到需要复盘的场次
运营人员从直播总览进入场次详情，按时间、指标和异常信号定位需要继续看的场次。
02 · 形成场次复盘
在分析结果和历史查询之间对照场次信息，整理复盘记录；页面范围支持复盘阅读，不声称已保留线上记录。
03 · 把结论交给任务
将复盘结论转成跟进任务，明确下一步负责人和状态，形成从场次到协同的操作路径。
两项具体设计取舍
这是根据已有问题、方案、功能和迁移字段整理出的判断，供接手者复核。
用场次作为主要业务对象
总览、详情、分析、历史与任务围绕同一场次展开，比把直播数据拆成孤立图表更容易回到运营动作。
把一个 Base 合同当作边界
资料只记录一个精确 Base 合同绑定，因此迁移时先恢复字段与读取关系，再补独立写入和身份服务。
完整功能与参与工作
关键能力
- 直播总览与场次详情
- 复盘记录和任务追踪
- 分析结果与历史查询
- 前端源码可继续迁移
参与工作
- 产品架构
- 前端实现
- 数据建模
架构示意
根据现有资料整理；结构示意，待与线上实现核对。
场次与复盘前端
React、TypeScript与ECharts组织直播总览、详情、分析、历史和任务页面。
Base业务数据
公开资料记录1个精确Base合同绑定，作为直播运营的业务数据来源。
独立业务服务
已有资料以可迁移前端为主；独立后端、身份与写入服务仍需补充。
客户端集成边界
普通网页需要替换飞书JSAPI，不能只复制前端就称为完整独立系统。
交付证据与状态
公开资料中的证据
- 开发态源码 113 个文件
- 1 个精确 Base 合同绑定
ARCHIVED_NOT_REVALIDATEDNOT_VERIFIED交付证据与构建状态为资料内历史验证记录，本轮未重新验证这些业务应用。
迁移限制与素材状态
源码与前端页面可重建；需要补独立后端、身份、写入服务并替换飞书 JSAPI。
历史页面截图与完整业务运行演示尚未全部接入。本页主要展示项目资料，新增界面展示单独标注来源与示例数据，不提供原业务系统的在线服务。
三步接手与迁移顺序
这些是基于当前资料整理的下一步工作，不是已经验收完成的交付。
- 01
复核场次字段
把总览、详情、复盘与任务页面使用的字段逐一对照数据合同，确认缺失字段和状态含义。
- 02
补独立服务入口
替换飞书 JSAPI、身份和写入层，为场次读取、复盘保存与任务更新建立可测试接口。
- 03
验证一条完整路径
从新建或导入场次到分析、复盘、任务跟进逐步验证，保留失败状态而不是用静态数据掩盖问题。