先把入口收进一个页面
比分、榜单和赛程第一次站到了同一屏上，看完结果不用再回头去找排名。
起点
从七个标签页开始
最开始我们也是普通球迷。想知道一场比赛谁进的球，得先开比分页面，再跳到榜单页面，最后去论坛翻伤停帖。一个下午过去，记住的只有浏览器的样子。
后来索性把这件事反过来做：不管你要看的是比分、射手排名还是伤停名单，都从同一个入口进去，一条路径走到底。这个念头九年没变，变的只是路径一年比一年短。
当时定下的三条
-
01
结果要第一眼看到
比分放在最显眼的位置，不往二级页面里藏。
-
02
榜单和伤停挨着放
想对照的时候，眼睛不用在几个页面之间来回跑。
-
03
能带走的就让人带走
表格导出成 CSV 或图片，贴进稿子里就能用。
版本历程
版本是一条一条推出来的
38 次迭代，每一次都是被具体的麻烦逼出来的：哪里慢、哪里乱、哪里第一次打开看不懂。下面这几站，是路径最短的几次跳跃。
手机上打开是完整的页面
不是缩小的桌面版，单手能翻，通勤路上看两眼球赛不用点两次放大。
最常看的两个栏目钉在首屏
射手榜和伤停回看固定到首屏可达的位置，往下滑也不会跑丢。
把三块数据放进同一块面板
比分、榜单和伤停并排呈现，切一下标签就能对照，读起来像盯着一块真的记分牌。
第一次打开的人知道先点哪
赛事层、数据层、工具层三层结构写成 9 条要点，照着走就能从选赛事走到拿数据。
不只看一场，看最近五轮的走势
按最近 5 轮区间取数，12 个维度指标一起呈现，一段时间的状态一眼能看出来。
团队
24 个人，三组接力
一条战报从数据接入到出现在你手机上，中间是四个环节，每个环节都有人接着上一棒。
- 编辑 8 战报成稿、专题与版本公告
- 数据标注 9 赛事数据核对与字段标注
- 工程 7 数据接入、接口与客户端迭代
-
01
接入
工程组把赛事与球员数据接进系统，按 30 秒级推送，页面每 60 秒自动对齐一次。
-
02
标注
标注组按轮次排班，逐场核对射手脚、伤情类型和预计回归轮次。
-
03
成稿
编辑组把一场比赛写成能在地铁两站之间读完的战报，每赛季约 1,200 篇。
-
04
上线
发布后进入监看，同一字段被反向改动就立刻回退重走前两步。
数据流程
一条射手统计，要过三道手
同一场比赛在不同栏目里出现的比分必须对得上，靠的是下面这三步，顺序不能颠倒。
-
01
多源比对
同一场比赛的比分与射手脚，会同时接进 6 家数据服务机构的回传。字段之间出现差异，这一场就自动挂起，不往下走。
-
02
人工复核
挂起的场次由标注组按赛事分工接手，逐个比对原始记录，重点确认伤情类型、预计回归轮次这类最容易记错的字段。
-
03
异常回滚
上线之后如果同一字段被反向修改，直接退回上一个确认版本，再重新走一遍比对和复核，不让错误的数字留在页面上超过一轮刷新。
射手榜覆盖 42 项赛事的前 50 名射手，每 15 分钟刷新一次；伤停信息可回溯最近 10 轮，含伤情类型与预计回归轮次。
看赛场观察我们在意什么
三条一直没改的做事原则
入口要短
从打开首页到看见任何一个数字，最多两次点击。多出来的一次跳转，就意味着有人会放弃。
数字要对得上
同一场比赛的比分，在比分面板、射手榜和战报里永远是同一个数。对不上就回滚，不解释。
导出要能直接用
CSV 打开就是整齐的列，PNG 贴进稿子里不用再裁。历史交锋覆盖 20 个赛季，两种格式都支持。
接下来
从一个入口开始用
装了安卓版，射手榜和伤停回看就在首屏；想追一支球队的走势，去赛场观察翻最近五轮的专题；规则看不明白，答疑中心里按步骤写着。
用户覆盖 31 个省级地区，移动端访问占比约 76%。通勤时段 18:00-19:30 是访问高峰，占全天流量的 27%。