主线一
数据源协作线
解决的是“表里到底有没有这一场”。对阵清单、BP 顺序、选手对局时长、英雄登场率与夺冠概率，都从这条线进来。取数范围、字段含义和更新频率在对接时就写清楚，避免同一指标在不同地方出现两个答案。
- 当日对阵按比赛日推送，开赛时间误差直接反馈给数据组
- BP 与胜率同批次发布，赛后完成校准
- 版本更新后 48 小时内同步英雄登场率基线
生态体系 · 协作与边界
谁把数据送到你眼前
雷火电竞每个比赛日的一屏对阵，背后是三条各自跑、又互相供料的协作线：数据源线把原始对阵与 BP 取回来，内容线把它切成能用得上的东西，赛事执行线让进度跟真实场面保持一致。下面这条时间线记录了它们怎样一步步长成现在的样子。
- 10 个阶段节点
- 4 类协作
- 3 条协作主线
- 14 项赛事覆盖
三条主线
数据进来，内容出去，赛事落地
三条线不是三套互不相干的流程。数据源线交出的是原始对阵与 BP 序列，内容线负责把它变成观众看得懂、创作者引用得动的形态，赛事执行线则保证页面上的进度和场馆里的真实节奏对得上。
主线二
内容与分发协作线
解决的是“数据怎么到观众手上”。回放切片、解说脚本素材、赛程提醒都从这里走出去。分发出去的每一份内容都带着校准时间与口径说明，协作方可以叠加自己的解说层，但不改动底层数字。
- 回放保留 BP 面板与关键节点时间戳
- 预测类指标必须与统计推演说明一同引用
- 移动端赛程提醒是打开频次最高的入口
主线三
赛事执行与技术协作线
解决的是“进度跟不跟得上”。分组抽签结果、小组排名、淘汰赛对阵关系与总决赛日程，都按赛事阶段独立维护。执行端关心的是哪一场该开、哪一场延后，技术端关心的是这些变化怎样稳定地落到观众端。
- 抽签结束后当天同步分组结构
- 淘汰赛对阵进度标注状态与依赖关系
- 大屏观赛模式单独提供精简数据格式
阶段推进
十个节点，三次换挡
从一份手写的对阵表开始，到三条线并行运转。每个节点记的是当时碰到的问题、用了哪种协作方式、以及现在是什么状态。点开任意一个节点可以看完整的协作方式与变化。
-
先解决“今天到底有哪几场”
最早只有一份人工誊写的对阵表，跨赛区开赛时间经常看错，观众问得最多的一句话就是“几点打”。
协作方式与变化
- 协作方式
- 与赛程提供方约定按比赛日推送对阵清单，只保留赛区、双方、开赛时间与赛制四项字段，回传时间固定在同一时段。
- 带来的变化
- 当日对阵从人工誊写变成自动落表，开赛时间看错的反馈基本消失，数据组把省下的时间挪去核对 BP。
-
给每一场对局配上 BP 面板
对阵有了，但观众看不懂这局为什么先禁这两个英雄，解说也只能凭印象讲。
协作方式与变化
- 协作方式
- 以接口对接方式取回完整 BP 顺序，英雄名称与位置统一换成中文口径，赛后与对局结果同批次发布。
- 带来的变化
- 解说与创作者不必再自己截图对照，BP 复盘的时间从赛后提前到开赛前，赛前准备有了抓手。
-
把选手对局时长纳入同一套表
选手的对局时长散落在不同来源里，取数范围不一致，横向比较没有意义。
协作方式与变化
- 协作方式
- 数据组按赛区轮值校对，记录 320 位选手的对局时长与出场分布，每条数字旁标注取数范围。
- 带来的变化
- 教练组能直接看到同一名选手在不同版本的时长走势，赛前准备的参照从单场扩大到赛季。
-
让回放切片带上关键节点
回放只有完整一场，创作者找一次关键团战要反复拖进度条，剪出来的时间点也各不相同。
协作方式与变化
- 协作方式
- 以内容互换方式取得回放使用权，单场切成 8 至 15 段，每段保留 BP 面板与关键节点时间戳。
- 带来的变化
- 一场对局变成可引用的碎片，图文与短视频用同一套时间戳，跨形式的复盘能对得上。
-
把数据送到通勤路上
数据都在站内，观众在上下班路上看不到，错过开赛之后才想起要查。
协作方式与变化
- 协作方式
- 把赛程与胜率数据以只读形式分发给协作渠道，走内容互换，底层口径与站内保持完全一致。
- 带来的变化
- 移动端访问占到全部访问的约六成，赛程提醒成为打开频次最高的入口。
-
夺冠概率怎么讲才不误导
概率数字一散出去就容易被当成结果，评论区反复争论“这到底是不是预测”。
协作方式与变化
- 协作方式
- 与内容合作方约定，任何引用都要带上校准时间与统计推演说明，改动数字前先同步口径。
- 带来的变化
- 转载页面开始保留口径注释，读者对指标性质的理解趋于一致，口径说明随数据一起交付。
-
分组抽签结果不再迟到
抽签结束到赛程更新之间常有一段空档，观众看到的还是上一轮的对阵。
协作方式与变化
- 协作方式
- 与赛事执行方约定抽签结束后回传分组结构，按赛道与小组两条线分别落表，两边互为校验。
- 带来的变化
- 小组排名与淘汰赛对阵关系呈现在同一张图上，观众不用在多个页面之间来回切换。
-
场馆侧看的是执行进度
主办方关心哪一场该开、哪一场延后，胜率曲线对他们帮助有限。
协作方式与变化
- 协作方式
- 提供淘汰赛对阵进度视图，标注每场的状态与下一场的依赖关系，总决赛日程单独维护一版。
- 带来的变化
- 赛程临时调整时，观众端与执行端看到的是同一份进度，沟通成本明显下降。
-
把数据搬上大屏
大屏观赛模式下字号与配色跟网页完全不同，直接投屏常常看不清关键数字。
协作方式与变化
- 协作方式
- 以接口对接方式提供大屏专用数据格式，只保留对阵、比分与关键指标三类信息。
- 带来的变化
- 场馆与观赛空间可以在同一份数据上叠加自己的解说层，不必重新采集一遍赛程。
-
版本换挡后的 48 小时
版本一更新，英雄登场率基线就得重算，慢一天，版本前后的结论就错一天。
协作方式与变化
- 协作方式
- 建立版本更新后的同步流程：英雄登场率基线在 48 小时内换挡，旧版本数据保留对照，两个版本的样本量分别注明。
- 带来的变化
- 版本前后的两套数据可以并排看，热度变化从模糊印象变成可追溯的曲线，当前三个赛季的版本对照都能查到。
协作方式与边界
三种做法，事先写在约定里
协作听起来抽象，落到纸面上其实就是三件事：怎么接、接多少、改了谁通知谁。我们把它们按对接形式分成三类，每一类都有对应的准备要求和变更流程。
字段口径先对齐，数据再流动
适合需要把赛程、BP 或胜率接进自有系统的场景。对接前双方确认字段含义、更新频率、异常值处理方式与回滚方案，接口只读取，不改写底层数据。
- 字段含义与取数范围逐项书面确认
- 更新频率与延迟上限提前约定
- 接口异常时保留上一批次可用数据
各自的发布节奏，各自保留
适合媒体、创作者与分发渠道。双方各自保留自己的发布节奏与编排方式，引用数据时保留校准时间与来源说明，转载页面不删改口径注释。
- 引用必须带校准时间，不单独摘取数字
- 预测类指标需与统计推演说明一并出现
- 发现口径偏差时双方同步更正
动到进度和节奏的，先签字
涉及赛事执行进度、淘汰赛对阵关系与场馆侧视图的调整，改动前需要双方书面确认，确认内容包含改动范围、生效时点与回退方式。
- 改动范围与生效时点写明
- 保留一版可回退的旧进度
- 观众端与执行端同批次切换
三条主线目前覆盖 LPL、KPL 与 Major 级别合计 14 项赛事，时间跨度从 2024 赛季延续至今。协作类型只对外说明形式与边界，不涉及任何具体机构名称。想了解团队怎么分工，可以看品牌档案；想把数据用起来，先对照数据方案档位。
对接入口
想接哪条线，先说清这四件事
-
一
协作类型
是接口对接、内容互换，还是赛事执行与场馆侧的进度同步。
-
二
用在哪
数据或内容最终出现在什么场景里，是自有系统、解说脚本，还是观赛现场。
-
三
对准哪个赛区
LPL、KPL 还是 Major，以及是否需要区分分组抽签、小组排名或淘汰赛阶段。
-
四
谁来对接
留一个能拍板字段与口径的对接人，后续往返会快很多。