2016
先把主要联赛的开赛时间稳定下来
平台在第一年上线,第一批内容是按日期排列的赛程表。当时只有网页一条通道,编辑组一边用手工录入,一边接通数据供应方,目标很单纯:把国内外主要联赛每天几点开打这件事,做到打开就能看清。
- 网页端赛程表
- 手工录入起步
当季赛季 · 更新中 本周 41 场待开赛
下载赛程 App
01 / 从第一个赛季到现在
从只有网页的赛程表,到现在网页、App、日历订阅三条路并排走,中间的几个节点基本都是被读者的使用习惯推着来的。
2016
平台在第一年上线,第一批内容是按日期排列的赛程表。当时只有网页一条通道,编辑组一边用手工录入,一边接通数据供应方,目标很单纯:把国内外主要联赛每天几点开打这件事,做到打开就能看清。
2019
赛程解决的是什么时候看,战报解决的是看完了想复盘。频道开通后,比分、关键节点和阶段性数据摘要开始成篇发布,赛季累计量逐年往上走,到现在累计已超过 4.2 万篇。
2022
移动 App 在这一年推出,赛事收藏、开赛提醒、离线赛程与战报推送一起上线。iOS 与 Android 双端同步发布,通勤路上不用再靠记忆去猜某场比赛几点开始,提醒会在开赛前替你把人叫回来。
2024
这一年赛程中心做了整体重做,页面结构、加载路径和移动端适配都换了新的一套。改完之后,App 首屏加载稳定在 1.2 秒上下,浏览器版约 1.8 秒;同年 App 也进入 4.x 版本线,当前主版本为 4.6。
02 / 内容生产
从信息进门到你屏幕上出现开赛时间,中间要走完五步。最花时间的不是录入,是核对——时间、队伍、场地三项只要有一项对不上,这条赛程就会被退回源头重新确认。
赛事数据供应方、场馆与媒体渠道的原始信息先进池子,按项目与联赛归拢。
录入组把对阵双方、开赛时间与举办场地逐项落位,项目名与队伍名统一成大陆读者习惯的叫法。
时间、队伍、场地各过一遍,任何一项与来源不一致,就先退回确认,不做猜测性填写。
两名编辑分别核对同一份赛程,两人都通过之后,条目才进入待发布队列。
上线不是终点。延期、改期与场地调整会在赛季期间持续同步进赛程表和订阅文件。
03 / 团队
内容团队分成四组:录入与校对、战报编辑、产品与技术、运营。赛季期间整条线是满负荷的,平均每天更新赛程条目 600 条以上,同步产出战报与数据摘要约 60 篇。
赛季之外,节奏会缓下来。这一段时间主要用来整理项目与联赛名称、复核历史条目、准备下一赛季的收录范围,产品侧则把用户反馈集中的问题排进版本计划。
负责把原始赛程信息落成可读条目,并完成时间、队伍、场地三项交叉校对。赛季期间他们是最先上班、最后收工的一组,比赛临时改期往往在夜里发生,需要有人守着把变更推到线上。
负责比赛结束后的回顾与数据摘要。每个赛季产出约 5,600 篇,写法上偏重结果与过程节点,不编造赛场内外的人物言行,只讲比分、时间与场地这些能被查证的内容。
负责网页端与 App 的结构、加载性能和数据通道。App 保持每两周一次小版本更新、每季度一次功能版本的节奏;网页端的赛程筛选与日历订阅文件也由这一组维护。
负责读者反馈的归集、合作渠道的对接和客服邮件的分发。赛季期工作日的来信平均 6 小时内会有人回复,非赛季期一般在 24 小时内处理完。
04 / 覆盖与体量
你关注的可能只是某一个联赛,但后台要同时照顾到很多条线。目前收录 42 个体育项目、约 1,860 项赛季赛事,举办地覆盖国内 26 个省份以及海外 14 个国家和地区。这些条目全部精确到具体开赛时间,而不是只标一个日期。
战报频道每个赛季发布约 5,600 篇赛事回顾与数据摘要,累计发布量已经超过 4.2 万篇。长期使用收藏与提醒功能的读者,平均每周回访 4 次以上。
05 / 运营与联系
赛程录入、战报编辑和客服都集中在天津办公,工作时间为工作日 9:00–18:00。写邮件之前可以先看一眼常见问题排查,入口确认、赛程显示、收藏与提醒、App 安装这几类问题在那份清单里大多能自己走通。
06 / 合作与内容来源
平台与 30 余家赛事数据供应方及场馆、媒体渠道保持内容合作。不同渠道各管一段:供应方带来开赛时间与临场变更,场馆和媒体渠道补上场地信息与赛程调整通知,我们负责把这几路信息合并成一条读得懂的赛程。
对阵关系、预计开赛时间、赛制阶段,以及比赛临近时的临时变更。这类信息时效性最强,也是校对时最先被核对的项。
举办场地的准确名称、可容纳规模、入场安排,以及赛程调整通知。场地名写错会直接影响读者找场馆,这一项不允许含糊。
把几路信息合并、统一命名、完成三项校对与双人复核,再发布到网页、App 与日历订阅文件上,让不同入口看到的是同一份时间。