数据编辑与校验
盯着采集端进来的每一条记录，处理异常值、核对字段与球队归属，是三道流程里最后一道闸门。赛季密集时，这个组的工作节奏会跟着赛程走。
阶段刻度
一条不断调整的路线
每一次调整都对应一个具体麻烦：等比赛等得心里没底、翻赛事表翻到眼花、查一个球员要看四五个页面。
-
V1.0
先解决“什么时候开球”
最早的产品只有一件事：把你在意的球队开赛时间推到手机上。当时球迷最常遇到的麻烦是要在好几个页面之间来回切换才能确认一场比赛的准确时间，我们把这个动作压缩成一次提醒。
-
V4–V9
关注的东西开始成堆
当一个人同时追三支球队、七八名球员，提醒就变成了噪音。我们把提醒改成可管理的订阅清单：单账号最多能存 200 条关注项，按联赛、球队、球员三个维度分组，重复关注同一支球队会自动合并成一条，置顶和取消都在同一处完成。
-
V12–V17
赛事表按天排，不再按联赛堆
移动端用户很少一次看完一整轮赛事。我们把赛程改成以自然日为最小单位，覆盖前一天到未来 14 天共 16 天的滚动窗口，未开赛、进行中与已结束用不同色阶区分，看得懂进度条的人就能一眼找到今天还剩几场。
-
V20–V2.3
把球员数据摆到伸手可及的地方
写稿的编辑和带队的教练要的不是长篇分析，而是可比的数字。我们建起覆盖中超全部 16 支球队一线队、520 余名球员的档案库，每人 32 项字段，并把查询入口做成常驻悬浮胶囊，在任何页面都能一键调起，单次最多并排对比 4 名球员。
从第一版到今天，累计发布 23 个公开版本。旧版本的资料和当前版本通过同一个归档入口查看，任何一次调整都能往回追溯。
数据来源
数据是怎么进来的
一份球员数据从赛场边到出现在你的手机上，要走过三道环节：采集、交叉校验、编辑复核。采集端记录的是原始事件，交叉校验负责比对不同来源之间的差异，最后由编辑逐项复核异常值，单轮校验的抽样比例不低于 10%。
白天到深夜，数据按每日三次的节奏刷新，分别是上午 10:00、下午 16:00 与晚间 22:00。遇到重大轮次结束，我们会在常规节奏之外追加一次校验更新，因为那一晚的跑动和传球数据最容易出现口径摇摆。
对写稿的人来说，这意味着截稿前拿到的是已经过复核的版本，而不是一小时后还会变动的半成品。
团队分工
谁在做这件事
六十余人的团队分成三块，各管各的活儿，但每周都要碰一次头。
产品与前端
负责订阅清单、按天赛程表与球员查询入口的实现。移动端是主战场，页面加载速度和单手操作路径是他们最在意的两件事。
客服与运营
对接俱乐部与数据合作方，处理订阅与账号问题。工作日 9:00 到 18:00 是他们的值守时间，赛事数据与订阅相关的来信会被优先处理。
与注册俱乐部、数据合作方的日常协作，大多围绕字段口径和交付时间展开。46 家合作方里既有职业俱乐部，也有城市业余联赛的组织方。
覆盖范围
覆盖到哪里
服务已经触达 31 个省级行政区。移动端访问占比约 78%，大部分人是在通勤路上或临睡前打开来看一眼。
- 31 省级行政区 从一线城市到地市级赛区都有活跃用户
- 78% 移动端访问占比 小屏赛事表与悬浮查询入口为主要使用场景
- 46 注册俱乐部与数据合作方 覆盖中超、中甲与部分城市业余联赛
- 16 天滚动窗口 赛程表的时间跨度为前一天至未来 14 天
里程碑
路上拿到的认可
这些节点来自合作伙伴与同行的反馈，也来自我们自己回头看时的判断依据。
-
产品
订阅清单前置到首页第一栏，成为打开应用后第一眼看到的内容。这个调整来自大量用户反复点开设置页的路径记录。
-
栏目合作
多家体育内容团队把球员数据查询入口纳入日常写稿流程，按姓名、球队、位置或号码检索，再并排对比两到四名球员的状态变化。
-
数据协作
与注册俱乐部、数据合作方的协作逐步稳定在一套字段约定上，促成了 7 天与 30 天两种对比窗口的上线，方便观察球员状态的连续变化。
-
版本节奏
自 V1.0 以来累计发布 23 个公开版本，平均每两周产出一篇版本说明或数据专题，把每一次改动的原因也一并留下来。