一次性问卷变成长期资料
2023 年的问卷会一次收齐实力、联系方式和参赛意愿。每届比赛都要重新整理,主办者也很难持续看清玩家池、队伍结构和活跃情况。
用户长期维护昵称、QQ、Steam64、竞技档案和教育身份;报名时直接复用这些资料,并保存本届参赛信息。管理员可以直接查看 24 小时 / 7 日 / 30 日活跃、认证覆盖、玩家池和队伍人数分布,并通过操作日志追踪关键操作。
面向高校 CS 赛事的运营平台,从报名、资格、队伍到比赛和赛后数据都在同一套系统里持续运行。起于 2026 NJU Rivals,目前正在承载 2026 NJU Major。

2023 年第一次办 24 支队伍的 NJU Major 时,赛前用腾讯文档收参赛意愿、玩家实力、基本资料和联系方式;比赛推进后的排期、资格检查、BP 和结果也主要靠群聊、表格和人工确认完成。
连续几届赛事让我反复遇到同一类问题:同一份信息每届重新收、比赛时间要临时协调、身份和首发资格靠人工核对、比赛数据最后集中到主办者手里补录。2026 Spring NJU Rivals 又采用个人报名、审核、队长投票和蛇形选秀,原来的表格和群聊开始很难继续维护这些关系,RivalHub 从这里开始开发。
从赛事首页、队长投票到选秀完成,保留上一届赛事在 RivalHub 中实际运行的页面。
第一届 NJU Rivals 完整跑完报名、队长投票、选秀、排位赛和正赛,最终完成 42 场比赛和 59 张地图;赛事页面记录了首页状态、投票结果和最终选人名单。
这些问题在几届比赛里反复出现,后来逐步做进了 RivalHub。
2023 年的问卷会一次收齐实力、联系方式和参赛意愿。每届比赛都要重新整理,主办者也很难持续看清玩家池、队伍结构和活跃情况。
用户长期维护昵称、QQ、Steam64、竞技档案和教育身份;报名时直接复用这些资料,并保存本届参赛信息。管理员可以直接查看 24 小时 / 7 日 / 30 日活跃、认证覆盖、玩家池和队伍人数分布,并通过操作日志追踪关键操作。
早期会给不同时间段分别建腾讯问卷,每个问卷最多收两份,对应最多两场比赛。队长本应先和对手商量再由一方提交;如果同一场比赛的两个队长同时提交,两份响应会直接占满这个时段,实际上只排进了一场。
双方现在直接围绕同一场比赛提议、接受或拒绝时间;超时可以自动确定,管理员也可以处理特殊情况。下一步会把有官方解说的时间段直接放进排期流程:赛委会可以设置每个时段最多覆盖几场比赛,队长选择时先临时占住一个名额,双方确认后再正式锁定;如果名额已满,可以改选其它官方时段,也可以自由约定没有官方解说的比赛时间。
时间协商已上线;官方解说时段的名额占用与确认机制已完成设计,待后续落地。
过去由队长一次替全队填个人信息;新生暂时拿不到学信网材料时,录取通知书要私聊发给主办者。规则里的本校成员数量和外校实力限制,也长期依赖赛前人工检查和赛后举报。
教育认证有学校邮箱、学信网材料和新生录取通知书三条路径;报名和单场首发会直接读取认证与竞技资料,系统会检查身份、名单和实力限制,并明确提示不符合规则的原因。
首次通过认证:学信网 150 人(66.7%)、学校邮箱 69 人(30.7%)、新生录取通知书 6 人(2.7%)。认证身份中,在读 198 人、已毕业 27 人。

Spring Rivals 期间,赛后截图 OCR、BP、比分和统计主要由我集中补录;同时处理其它赛务时,数据更新会自然产生延迟。
RivalHub 已经统一保存比赛、BP、比分、赛果和后续更正;OCR 与 DAK 继续补充赛后证据和统计。下一步会让双方队长直接在网站完成 BP;RivalHub Broadcast 接入后,再把现场能够可靠获取的基础比赛数据同步回来。
队长在线 BP 已完成设计,待后续落地;RivalHub Broadcast 的数据回传属于下一阶段联动。
Rivals 跑完以后,2026 NJU Major 又提出了一套不同的问题:长期队伍、整队报名、高校资格、名单变更、审核和更复杂的赛制,都要继续放进同一个系统。
到 Major,RivalHub 才真正从“一届 Rivals 的工具”变成需要长期维护队伍、身份、参赛记录和历史事实的平台。

Rivals 结束后,一名队员自己在群里发出的截图里出现了玩家轮廓和烟雾倒计时。我们继续核对他的解释,也找人去相关网吧测试,并反复要求他提供可以核验的自证材料。后续他停止配合调查,赛事侧最终按作弊处理。
我当时既是赛事主办者,也是这支队的队长和参赛选手。调查结束后,我决定撤销自己队伍的冠军和名次。
这次复盘让我更明确两块问题:关键参赛资格需要可核验材料,赛后争议也需要提前约定证据留存和处罚流程。后续赛事里,南京大学在读生可以通过学校邮箱完成认证,其他在读 / 毕业身份可以提交学信网在线验证材料;规则也逐步明确 POV、Demo、账号记录和聊天记录等可用材料。这次事件是后续加强身份核验和证据治理的重要经验之一。
产品定义、赛事流程建模、优先级和 Issue 拆解、实现 Review、测试验收、数据库迁移、版本发布与线上问题收尾。
开发中长期使用 Coding Agent;关键需求、取舍、Review 和最终验收由我负责。
一支队伍会跨多届比赛存在,也会改名、换人;但某一届当时是谁参赛、用什么名单,是已经发生的历史事实。比赛不能永远读取队伍“现在的成员”,所以长期队伍和单届参赛记录分开保存。
2026 NJU Rivals 是 RivalHub 的直接开发触发和第一场完整赛事验证。这里保留当时的赛事海报、规则速览和原始规则文件。