十八人小组 · 六个赛季
开赛前该确认的事，由十八个人盯住
必一游艺运营 BSPORTS 中文专区，六个赛季下来只做一件事：让你在开赛前把该确认的信息一次看清楚。这一页讲的是谁在做、为什么做成现在这样、凭什么做得准，以及接下来往哪走。
- 连续运行的完整赛季
- 6
- 内容小组成员
- 18
- 常驻赛事
- 12
- 阵容档案覆盖球员
- 460
入口只剩两个，是我们主动砍出来的
站点刚上线时，赛程、阵容、伤停各在各的页面里。想看一场比赛，得先找赛事，再翻日期，再确认谁上不了——一趟走下来，比赛都快开始了。
现在首屏只留两个入口：核对赛程，翻伤病档案。其余全部退到后面去。理由很直接：赛前十分钟打开手机，你要的是这场几点开、谁缺阵，而不是一份完整目录。点球回看、版本问题、跨端故障都有各自的固定去处，但它们不该挡在第一步前面。
能两步走完的事，不做第三步。
赛前 3 小时全量过一遍，赛前 30 分钟只看改动
这一条从第三个赛季沿用至今：每轮开赛前 3 小时完成一次全量赛程校对，开赛前 30 分钟再复核一次变更。全量校对负责把基础信息摆平，30 分钟那次只盯改动，改完就停手，不再新增内容。
-
赛事
12 项常驻赛事逐项过，含 4 项主赛与 8 项杯赛、洲际赛。不同赛事的开赛规则不一样，不能套用同一张表。
-
日期
每周要核对的场次在 40–60 场之间，赛季密集期能到 72 场。先按日期排一遍，再回头看跨日的连场会不会撞。
-
队伍
阵容与伤停在队伍这一维合流。460 名球员按位置、伤停周期与复出节点分组，这场确定缺席的、刚进入观察的，分别标出来。
十八个人，分四件事做
小组一共 18 人。人数不多，所以每个人负责的范围写得很死，交接点也只有一个：校对改了什么，编辑立刻知道。点开下面任意一类，看他们一天在做什么。
6 名数据校对，一天大概是这样
- 上午先看上一轮遗留的变更，把没闭环的挑出来单独挂着。
- 赛前 3 小时做全量比对，赛事、日期、队伍三个维度逐条过，一处对不上就退回去重查。
- 赛前 30 分钟只确认改动，改完就停，不再往表里加新东西。
5 名赛事编辑，一天大概是这样
- 各自盯住负责的赛事，赛程一动就同步改写描述，不让旧说法留在页面上。
- 伤停与复出按每周二、周五两次更新，突发情况当天补上。
- 把点球结果写成能直接转述的一句话，罚球顺序与关键轮次一起保留。
4 名产品与客户端，一天大概是这样
- 收拢一周约 200 条端侧反馈，逐条归到具体版本和具体页面。
- 判断哪些能进下一个版本，这部分大约占三成，剩下的排进后续批次。
- 盯着页脚那个苹果端反馈入口是否始终可用，别让提问题的人找不到门。
3 名客服，一天大概是这样
- 工作日 9:30–18:30 在线，回答赛程核对与阵容信息上的具体问题。
- 碰到 iOS 端问题直接转进反馈通道，不让人自己在页面里绕。
- 把一周里反复出现的同类问题汇总给校对和产品，下个周期优先处理。
六个赛季，一步步走到现在
-
第 1–2 赛季
把赛程核对的赛事、日期、队伍三个维度定下来。赛前 3 小时全量校对从那时起就是固定动作，没有例外。
-
第 3 赛季
赛前核对与阵容追踪合并成一条路径，首屏只留两个入口，中间的跳转页全部拿掉。这一步之后，平均 90 秒就能完成一次赛程核对。
-
第 4–5 赛季
点球结果开始按华人赛事单独整理，罚球顺序、命中结果与关键轮次三项一起留下。这部分现在是榜单速览里的一条，每周更新一次，赛季密集期每周两次。
-
第 6 赛季
版本走到 V3.2.1，首页直达专区。版本号与苹果端反馈入口长期挂在页脚，随时能找到。
-
V3.0
赛程、阵容与伤停收进同一套页面结构，为后来的两步路径腾出位置。
-
V3.1.4
调整列表密度与移动端阅读，赛季密集期的长列表不再挤成一片。
-
V3.2.1
路径缩短，首页直达；反馈入口做成页脚固定锚点，滚动时始终可见。
对不上的数字，宁可删掉
站内每一组规模数字只说一套。赛季数、赛事数、场次范围、小组人数，页面与页面之间不允许出现第二个说法。
口径以赛季为周期统一复核一次，最近一次在 V3.2.1 发布时完成。复核的方式很笨：把每个数字在页面上的出现位置逐条列出来，对不齐的就改到对齐为止；改不动的，就从页面上撤掉，不留一个含糊的数字在那里。
数字对不上，比没有数字更难办。