从重庆出发的赛事数据编辑室

最早的问题很具体：中文用户要在一条水平线上同时看到两队的名词、球员与计价依据， 而不是在几个标签页之间来回切。版面骨架因此被定成横向网格——一条数据带承载一场赛事， 宽度留给数字，高度压到一眼能扫完。作为官方直营赛事数据台，我们保留了这条视觉线索： 从首页的费用查询入口，到产品总览的赛事价格比较，都沿用同一套横向排布。

中文赛事数据编辑这个定位同样是在这一版面上定下来的。中文不是翻译层，而是第一层： 队伍名、伤停部位、费用标准编号一律以中文口径为准，再向外对应原始数据。这样做的代价是 编辑量翻倍，好处是同一个说法在站内可以一直复用下去。

1. 阶段 01

   草创期：把信息摆成一条边线

   这一阶段只解决一件事——让横向数据带立得住。每一场赛事占一条，左侧写对阵， 右侧留给数字，注释贴在外沿。版面从一张打印稿的尺寸起步，纸张叠层的硬投影与描边也是 那时候留下来的：一页翻过去，下一层还在。

   同期定下的还有一条不成文的规矩：任何费用数字后面都要跟单位与口径依据， 不允许只写一个数。这条规矩后来变成了全站的写法。

   版面骨架

   横向数据带 1 条 / 场

   内容形态

   打印稿 → 网页

2. 阶段 02

   栏目成型期：节奏开始固定下来

   栏目开始按固定节奏更新之后，「一条赛事一条记录」的写法被推广到观察与问答： 先写依据，再写结论；涉及费用时，先写口径编号，再写数字。读者因此可以只挑自己关心的 那一段读，而不必从头看到尾。

   也是在这一阶段，两个终端开始共用同一份赛事数据源。常规刷新间隔定在 30 秒， 同一场比赛在两个终端上读到的是同一个版本，不存在哪一端先更新。

   常规刷新

   30 秒

   数据源

   双端同源 1 份

3. 阶段 03

   数据台成型期：把同一份数据摊开

   电脑端KAIYUN在这一阶段不再被当作放大版手机页面，而是当成一张摊开的工作台： 横向能并排的内容就并排，能一次比对的两队价格就不分两次点。移动端同时跟进， 两端的字段结构与状态标签保持同一套写法。

   伤病档案也是这时候补齐字段的：伤停部位、预计回归窗口，以及红黄绿三色状态标签， 颜色旁边永远配一句文字说明。关注列表单账号最多可添加 200 个关注对象， 可划分 12 个分组，分组名称由用户自己写。费用标准则采用 CN-主版本.次版本 编号，每个赛季在赛季前与赛季中期各复核一次，全年 2 次例行更新。

   周末双赛刷新

   15 秒

   关注对象上限

   200 个 / 12 组

   标准复核

   全年 2 次

日常排班按赛事密度而不是按工作日安排。周末双赛时段排班整体前移，校对队列的交接以半小时为单位， 保证第二场比赛的伤停信息不必等第一场的版面全部收尾。需要核对费用该怎么准备材料， 可以看问答中心；需要提交材料或询问细节， 找到我们写明了受理时段与材料清单。

站点与 20 余家场馆媒体和数据供应方保持内容合作，用于交叉校验赛程与伤停信息。 同一条伤停记录至少要有两条来源对得上，才会进入对外呈现的候选队列；来源之间出现分歧时， 记录停在队列里，不先写结论。

这套机制直接决定了伤病档案的呈现时效：状态变更后先进入校对队列，再对外呈现， 所以偶尔会比现场慢一步。我们选择保留这一步——晚几分钟的准确， 比早几分钟的猜测更有用。校验带来的另一项好处是费用说明的稳定：口径编号一经复核， 同一赛季内不再改动，方便老用户把历史账单与当前套餐放在一起对照。

• 费用

  不把费用数字单独抛出来。任何数字都与口径编号、单位一同出现，具体以查询页面显示结果为准。

• 状态

  不用红黄绿颜色单独表达伤病状态。三色标签旁边永远有一句文字说明，两者缺一不发。

• 效力

  不替代第三方结算单据。站内费用结果是整理与展示口径，不具备结算凭据效力。

• 观察

  不给比赛结果下判断。赛事观察只写可回溯的过程与方法，不写承诺性结论。

• 时效

  不在校对队列之前放出伤停信息。内容先过校对，再对外呈现，顺序不因赛事热度调整。