线上运行 / 持续迭代

RivalHub

项目负责人 / 独立开发者·2026.05–至今

面向高校 CS 赛事的运营平台,从报名、资格、队伍到比赛和赛后数据都在同一套系统里持续运行。起于 2026 NJU Rivals,目前正在承载 2026 NJU Major。

平台现状

截至 2026-09-24
  • 303
    有效账号
  • 225
    高校认证用户
  • 272
    近 30 日活跃用户
  • 30 支
    当前有效队伍

当前正在运行

2026 NJU Major 报名期首页
2026 NJU Major 报名期。截图时已有 25 支队伍通过审核,176 名选手进入公开赛事名单。

从腾讯文档到 RivalHub

2023 年第一次办 24 支队伍的 NJU Major 时,赛前用腾讯文档收参赛意愿、玩家实力、基本资料和联系方式;比赛推进后的排期、资格检查、BP 和结果也主要靠群聊、表格和人工确认完成。

连续几届赛事让我反复遇到同一类问题:同一份信息每届重新收、比赛时间要临时协调、身份和首发资格靠人工核对、比赛数据最后集中到主办者手里补录。2026 Spring NJU Rivals 又采用个人报名、审核、队长投票和蛇形选秀,原来的表格和群聊开始很难继续维护这些关系,RivalHub 从这里开始开发。

一次完整赛事验证

56 人参赛者
8 支队伍
42 场正式比赛
59 张比赛地图

第一届 NJU Rivals 完整跑完报名、队长投票、选秀、排位赛和正赛,最终完成 42 场比赛和 59 张地图;赛事页面记录了首页状态、投票结果和最终选人名单。

几个反复出现的赛务问题

这些问题在几届比赛里反复出现,后来逐步做进了 RivalHub。

01 · 参赛资料与运营

一次性问卷变成长期资料

2023 年的问卷会一次收齐实力、联系方式和参赛意愿。每届比赛都要重新整理,主办者也很难持续看清玩家池、队伍结构和活跃情况。

现在

用户长期维护昵称、QQ、Steam64、竞技档案和教育身份;报名时直接复用这些资料,并保存本届参赛信息。管理员可以直接查看 24 小时 / 7 日 / 30 日活跃、认证覆盖、玩家池和队伍人数分布,并通过操作日志追踪关键操作。

02 · 比赛排期

从“问卷提交”变成具体的一场比赛

早期会给不同时间段分别建腾讯问卷,每个问卷最多收两份,对应最多两场比赛。队长本应先和对手商量再由一方提交;如果同一场比赛的两个队长同时提交,两份响应会直接占满这个时段,实际上只排进了一场。

现在

双方现在直接围绕同一场比赛提议、接受或拒绝时间;超时可以自动确定,管理员也可以处理特殊情况。下一步会把有官方解说的时间段直接放进排期流程:赛委会可以设置每个时段最多覆盖几场比赛,队长选择时先临时占住一个名额,双方确认后再正式锁定;如果名额已满,可以改选其它官方时段,也可以自由约定没有官方解说的比赛时间。

时间协商已上线;官方解说时段的名额占用与确认机制已完成设计,待后续落地。

03 · 身份、名单与资格

把赛前人工检查变成系统校验

过去由队长一次替全队填个人信息;新生暂时拿不到学信网材料时,录取通知书要私聊发给主办者。规则里的本校成员数量和外校实力限制,也长期依赖赛前人工检查和赛后举报。

现在

教育认证有学校邮箱、学信网材料和新生录取通知书三条路径;报名和单场首发会直接读取认证与竞技资料,系统会检查身份、名单和实力限制,并明确提示不符合规则的原因。

225 / 303有效用户已认证
74.3%认证覆盖率
43 所高校

首次通过认证:学信网 150 人(66.7%)、学校邮箱 69 人(30.7%)、新生录取通知书 6 人(2.7%)。认证身份中,在读 198 人、已毕业 27 人。

RivalHub 教育认证概览,展示认证人数、学校分布和学籍身份分布
2026 年 9 月 24 日生产后台截图:225 / 303 名有效平台注册用户已认证,覆盖 43 所高校;认证身份中 198 人在读、27 人已毕业。
04 · BP、比分与比赛数据

让比赛数据尽量在发生时进入系统

Spring Rivals 期间,赛后截图 OCR、BP、比分和统计主要由我集中补录;同时处理其它赛务时,数据更新会自然产生延迟。

现在

RivalHub 已经统一保存比赛、BP、比分、赛果和后续更正;OCR 与 DAK 继续补充赛后证据和统计。下一步会让双方队长直接在网站完成 BP;RivalHub Broadcast 接入后,再把现场能够可靠获取的基础比赛数据同步回来。

队长在线 BP 已完成设计,待后续落地;RivalHub Broadcast 的数据回传属于下一阶段联动。

从 Rivals 到 Major

Rivals 跑完以后,2026 NJU Major 又提出了一套不同的问题:长期队伍、整队报名、高校资格、名单变更、审核和更复杂的赛制,都要继续放进同一个系统。

到 Major,RivalHub 才真正从“一届 Rivals 的工具”变成需要长期维护队伍、身份、参赛记录和历史事实的平台。

2026 NJU Major 赛前运营工作台
2026 NJU Major 赛前运营工作台。截图时共有 28 条报名记录、25 支队伍已批准;正式参赛名单和比赛仍处于赛前生成阶段。

一次赛后处理

Rivals 结束后,一名队员自己在群里发出的截图里出现了玩家轮廓和烟雾倒计时。我们继续核对他的解释,也找人去相关网吧测试,并反复要求他提供可以核验的自证材料。后续他停止配合调查,赛事侧最终按作弊处理。

我当时既是赛事主办者,也是这支队的队长和参赛选手。调查结束后,我决定撤销自己队伍的冠军和名次。

这次复盘让我更明确两块问题:关键参赛资格需要可核验材料,赛后争议也需要提前约定证据留存和处罚流程。后续赛事里,南京大学在读生可以通过学校邮箱完成认证,其他在读 / 毕业身份可以提交学信网在线验证材料;规则也逐步明确 POV、Demo、账号记录和聊天记录等可用材料。这次事件是后续加强身份核验和证据治理的重要经验之一。

我负责什么

产品定义、赛事流程建模、优先级和 Issue 拆解、实现 Review、测试验收、数据库迁移、版本发布与线上问题收尾。

开发中长期使用 Coding Agent;关键需求、取舍、Review 和最终验收由我负责。

一个决定

长期队伍和某一届赛事的参赛记录分开

一支队伍会跨多届比赛存在,也会改名、换人;但某一届当时是谁参赛、用什么名单,是已经发生的历史事实。比赛不能永远读取队伍“现在的成员”,所以长期队伍和单届参赛记录分开保存。

当时也考虑过
  • 每届赛事都复制一支新的队伍
  • 比赛时直接读取队伍当前成员

原始赛事材料

2026 NJU Rivals 是 RivalHub 的直接开发触发和第一场完整赛事验证。这里保留当时的赛事海报、规则速览和原始规则文件。

2026 NJU Rivals 赛事海报
2026 NJU Rivals 海报
2026 NJU Rivals 规则速览图
2026 NJU Rivals 规则速览

技术

Next.jsTypeScriptPostgreSQLSupabaseDrizzle ORMCI/CD