从青海的看台出发，把转会与跑动整理成可查的资料

为什么起点在一座高原城市的看台上

这份资料库的起点在青海。这里的观赛时段被时差和气候重新切过一遍：欧洲联赛的开球常常落在本地的深夜 与清晨，高原冬季的低气压又会让同一名球员在主场的跑动数据看起来比平原球场更吃力。几轮赛季看下来， 直觉和数字经常对不上，而对不上的原因往往不在球员身上，在于读的人手里缺一份能对照的口径。

最初的需求很具体——做一张对得上时区的赛程表，把开赛时段、轮次和场地类型放在同一处。做着做着才发现， 真正缺的不是赛程本身，是赛程、转会与跑动这三类信息之间对不上的口径：一条转会条目没有时间戳， 一份跑动数字没有样本量，两者放在一起就无法互相解释。

所以站点的做法是把区域观赛节奏与全球赛事时段并排摆出来。同一份赛事日历里，既能看到轮次与场地类型， 也能看到它在本地属于哪个时段、适合哪一种观赛安排。这是一份面向全球赛事的资料库， 只是把本地视角写进了说明，而不是把它当成一个地方站点的标签。

九个赛季里，资料库的边界被推了四次

站点上线以来连续运营 9 个赛季。资料库不是一次搭好的，每两到三个赛季往外推一段， 每次扩张都要先解决字段口径，再谈收录范围。

• 第 1 至第 2 赛季 单一联赛的赛程条目

  只做足球范畴，记录轮次、开赛时间与场地类型，字段少但要求每条都能对得上官方赛程表。

• 第 3 至第 4 赛季 杯赛与友谊赛并入同一份日历

  补入杯赛轮次；友谊赛按季前、赛季中、赛季末三段归档，目前累计 460 条条目。

• 第 5 至第 7 赛季 跑动记录字段化

  把跑动拆成场均跑动距离、高强度跑动占比、冲刺次数与热区坐标四个字段，跨赛季可比。

• 第 8 至第 9 赛季 电竞分组与赔率面板独立上线

  电子竞技资料按英雄登场率整理成独立分组；夺冠赔率面板接入 27 家公开来源，只做横向对比与历史回溯。

当前覆盖 42 项联赛与杯赛，其中足球联赛与杯赛 24 项、篮球赛事 10 项、电子竞技赛事 8 项；球员与选手档案 18,600 名， 跑动样本 62,800 条，覆盖近 11 个赛季；转会条目 5,240 条；赛事日历条目 3,100 条。

有四件事，这份资料库明确不做

边界不是免责声明，而是资料库能被长期引用的前提。下面四条从第一个赛季就在执行，没有因为流量或需求放松过。

• NO.01

  不判断比赛结果

  赔率面板呈现的是区间与历史变化，不是结论。站点不提供任何下注入口，也不做相关导流。

• NO.02

  不写预测性表述

  转会条目只呈现信源等级、时间戳与信源数量。涉及去向时一律使用区间与条件语，不给单一答案。

• NO.03

  不收集读者信息

  站点不使用表单，所有交互都是本地的筛选、折叠与锚点跳转；联系只通过公开邮箱与电话。

• NO.04

  不删除旧赛季数据

  旧赛季条目只做更正。修订过程留痕可查，读者能看出某条信息在什么时候被改过。

28 个人分成四组，各自盯住流程的一段

团队共 28 人。分组不是按职能名称划的，而是按一条信息从原始记录走到可引用条目所需要经过的环节划的， 每一组只对自己那一段负责。

三条口径，决定一条信息能不能上线

内容生产遵循三条口径：数字先于观点、信源先于结论、修订可见。它们不是挂在墙上的标语， 而是每次发布前要按顺序走一遍的判断流程。

按赛季归档，旧内容只更正不清理

资料库按赛季分层存放。每一条转会、每一次队伍变更、每一份跑动均值都挂在具体赛季之下， 而不是漂在一个不标时间的总表里。这样做检索会慢一点，但任何一条数字都能被放回它原本的情境中。

旧赛季的数据不会被清理。它们可能已经不是最新的，但读者在追一段队伍变更记录或者做一份跨赛季跑动对比时， 需要看到的是完整的时间链，而不是一份被修剪过的当前快照。

全站数据每日更新 3 次，分上午、下午与夜间三个批次。新条目进入当前赛季，历史条目留在原处， 只接受更正。这是这份资料库能连续运营 9 个赛季的原因之一，也是它敢把结论交给读者的原因。