2016 01
一块看台是怎么来的
多宝平台赛事从 2016 年做到今天。起点很朴素：那时候我们自己就是追比赛的人，一场球的准确开赛时间要在好几个页面之间来回翻，一层浮层关掉了还有下一层。
于是这块看台从一个很笨的念头开始——打开页面就是赛程，别的东西往后让。到今天，站点提供的内容仍然收拢在四类上：赛程、球队库、伤停信息，还有一条告诉你此刻能不能正常打开的访问状态。
足球与篮球两大主项各占一块地盘，联赛和杯赛排在同一张按比赛日推进的表里。你不用先判断比赛属于哪种赛制，再决定去哪个入口。
2018 02
十八个人怎么排班
维护这块看台的团队一共 18 人，办公地点在重庆，分成四个组，各自盯一段。
四个组，十八个人
18人
- 数据整理7
- 前端与体验5
- 内容编辑4
- 客服与反馈2
一个比赛日，四个组按顺序接力。赛前 48 小时，数据整理组先出第一版伤停；内容编辑把每条消息的来源时间标上去，来源说不清的先挂着，确认了再放出来。开赛前那几个小时，前端与体验组盯的是页面在流量高峰能不能秒开——PC 端在本季完成适配升级后，首屏渲染从原来的 3.4 秒压到了 1.2 秒以内，版本走到 3.2。
比赛结束后轮到客服与反馈组。每个月大约 460 条修正建议从各种渠道进来，其中伤停和赛程字段相关的问题占了七成，这些意见会直接排进下一轮整理清单。
2020 03
伤停字段为什么必须补齐
早几年最容易出问题的就是这块。体育伤停信息页面显示不全的时候，你点开只看到半行字，或者名单比比赛还旧，等于白点。补齐之后，一条伤停记录固定包含五类信息，缺任何一项都不算完成。
- 球员
- 位置
- 伤停原因
- 预计缺阵场次
- 信息来源时间
更新按比赛日分三轮推进，节奏跟着开赛时间走。
- 赛前 48 小时第一版名单上线，先把确定缺阵的人放进去
- 赛前 6 小时补上临场变化与最新消息，标注来源时间
- 赛前 30 分钟最后一轮核对，把名单与阵容对齐
名单按联赛分组呈现，同一联赛的几支球队挨在一起，方便你一眼扫完一轮里谁缺人、缺在哪。
开赛前三十分钟，伤停要能看清；开赛前三十秒，页面要能打开。
2022 04
球队库搬进赛程中心的那一季
球队资料原本是一个独立入口。收藏夹里存了旧地址的人，隔一段时间再点，打不开，又不知道新入口在哪——这类反馈攒到一定量之后，我们做了决定：赛季开始前，把球队库整体迁进赛程中心，旧入口从迁移完成后不再维护。
现在找一支球队有四条路可走：按联赛、按比赛日、按球队、按伤停。进了球队页面，常规阵容、主客场战绩与赛季走势依次排开，不用翻到第二屏再找一遍。功能与赛程页把这些入口的走法写得更细一些。
2024 05
二十六万条赛程是怎么攒起来的
从 2016 年到现在，站点的赛程条目累计超过 26 万条。这个体量不是一个人一条一条录出来的。
我们与 9 家数据服务方建立了赛程与伤停字段的交叉校对关系：同一场比赛的开赛时间和伤停名单，至少要有两个来源对得上，才会进入正式表。对不上的先搁在待核区，宁可晚一点，也不放一条含糊的记录上去。
另一部分是专题。按赛季阶段组织内容，最近三个赛季平均每季发布 24 期，把同一轮次的看点、阵容变化和伤停集中在一处。这些专题的更新节奏和版本迭代记录都放在内容观察里。
本季 06
把广告位留空之后
页面上的广告位数量是 0。没有弹窗，也没有插屏。打开就是赛程表，往下滚就是伤停名单。
这件事听上去只是清爽，真正的影响在比赛日：开赛前那几分钟，同一时间有多少人在刷页面，页面还能不能稳住，才是关键。站点按月做访问巡检，最近 12 个月的可用率保持在 99.6% 以上，日常固定访问不会今天快明天慢。
如果你正好遇到打不开的情况，帮助中心把常见的处理顺序列了出来，照着走一遍通常就能回到赛程中心。