八年把赛事记录做成能并排比较的档案

01 / 起点与主张

先解决赛前那几分钟的麻烦

2016年，我们盯上的是一个很具体的麻烦：开赛前几小时，伤停名单散在发布会记录、出场名单和赛后统计里，翻完一遍费时间，看完还记不住谁缺阵、谁回归。看台于是决定把这件事做小做实——一条一条记下来，标清时间和来源类型，再放进同一张表里并排看。

方向定下来之后就没再变过。球队从几十支加到1480支，联赛扩展到32个，记录从桌面表格搬到电脑端和移动端，目标还是那一个：让您花几分钟就能看清两队的人员变化与射门走向，而不是在十几个页面之间来回跳。

优先级也一直没动过：伤停与出勤先站得住，对比要能并排摆开，历史记录要能往回翻十二个月。

02 / 三道校验

一条记录要过三道手才会上线

看台的记录不是一个人写完就发。每条伤停从进入系统到出现在页面上，要经过标注、复核、发布三道环节，三种岗位各自做一种判断，谁的活谁负责。

1. 01 / 标注录入

   9名标注员把球员、位置、缺阵原因与预计回归时间填进记录，单条平均约3分钟。

   这一步会记下什么

   • 参考公开赛事名单、赛前发布会与赛后统计公告整理，来源类型随记录一起保存。
   • 同一名球员的连续变化挂在同一条档案下，方便顺着时间看走势。
   • 信息互相矛盾时先挂待确认标记，不直接写入页面。

2. 02 / 审校复核

   6名审校对着参考来源逐项复核，单条平均约2分钟，发现不一致就退回上一步重新确认。

   这一步会看哪些地方

   • 球员姓名与所属球队是否对得上，会不会是同一个人的两次不同译名。
   • 缺阵原因与预计回归时间有没有前后冲突，会不会出现刚复出又缺阵的矛盾。
   • 复核完成后，记录才被推进到发布队列，等待编辑确认。

3. 03 / 编辑发布

   2名栏目编辑确认表述与分类没问题，才会让这条记录出现在页面上。

   这一步会做哪些判断

   • 检查标题、标签与所属联赛是否匹配，避免挂错到别的赛事下。
   • 判断这条记录进不进当期的赛事专题，需不需要配一张热区图。
   • 发布之后记录进入十二个月的可回看区间，能按赛季与轮次检索。

03 / 版本节点

能力是一版一版加上去的

每一次版本升级背后都是同一个问题：用起来还够不够顺手。下面这几个节点，串起看台从最早期到现在的推进节奏。

04 / 团队分工

24个人围着同一张表

团队一共24人，分成五块，每块负责一段不同的工作。人数最多的不是写代码的人，而是把记录一条条整理出来的标注与审校。

• 9

  赛事数据标注员

  一线录入伤停、出勤与射门记录，把球员、时间与来源类型填齐，是整条链条的第一道入口。

• 6

  审校

  对照参考来源逐项复核，处理译名冲突与时间矛盾，决定一条记录能不能往下走。

• 4

  前端工程师

  负责电脑端的对比表、排序筛选与左侧固定栏，让18项指标摆在一屏里也看得清。

• 3

  移动端工程师

  打磨 iOS 版栏目的横向滑动卡片，把小屏上的阅读节奏和手势操作调顺。

• 2

  栏目编辑

  负责专栏选题、专题组织与发布前的表述确认，也对接合作方提出的内容需求。

05 / 合作生态

120家内容伙伴与36个自媒体团队

到目前，有120家内容合作方与36个自媒体团队在用看台的记录做赛前节目、图文与短视频。协作方式跟着对方的内容节奏走，常见的是三类。

每个赛季的约12期大型赛事专题里，有一部分会与合作伙伴联合策划，从选题到成稿一起确认；栏目按月归档后，合作方可以直接引用其中的对照结论与图表。