ACM校赛全流程复盘：从出题到输入输出避坑指南

2026年3月21日上午九点，东北林大ACM实验室第一次面向全校的校赛准时开打。我坐在实验室角落盯着判题大屏，从第一份提交进来开始，心跳就没降下来——办赛人和参赛选手最大的区别大概就在这里，前者在开赛前就已经把题做吐了，可真正开赛那一刻，最紧张的反而成了自己。

如果你也是某个学校ACM实验室的成员，或者正打算组织一场类似的新人校赛，这篇文章可以帮你避开不少坑。我会把这场校赛从定位、出题、现场运维到赛后复盘完整写下来，还会把新手在算法竞赛里最容易卡住的输入输出问题单独拎出来聊透。说白了，对刚接触竞赛的人来说，看十篇别人的题解，不如跟着一场真实校赛走一遍全流程，这种经验的密度是完全不一样的。

1. 为什么把这场比赛放在春季开学第四周

1.1 这个时间节点背后的盘算

办一场校赛，时间点选得对不对，直接影响能来多少人、能筛出什么结果。最开始我们讨论过两个方案：一是寒假放假前办，借着学期末的热度收一波人；二是春季开学初办，给寒假训练一个交代。后来我们选了后者，而且特意压在开学第四周的周六。

原因很简单。寒假之前实验室刚完成一轮招新，很多大一成员其实才接触编程几个月，连一次完整比赛都没打过。学期末办赛，看起来热闹，实际上全是“裸考”，既打击信心，也测不出什么有效水平。而经过了寒假一个多月的自主训练，加上开学前三周每周一次的常规训练，这批新人对语言、OJ提交、基本算法都有了初步感知，这时候来一场正式比赛，正好检验寒假训练成果。

另外还有一个比较现实的因素：ACM实验室的纳新通常集中在秋季，但很多同学秋季因为课程冲突没有参与，春季开学后实验室的门槛反而会低一些，不少有兴趣的新人会自己找过来。这时候办一场面向全校的校赛，是低成本吸纳潜在选手的好机会，题目难度也照顾到这些“半路入场”的人。

1.2 实际到场的参赛盘面

这场校赛最终以个人赛形式进行，报名人数152人，最终到场签到并产生提交记录的共137人。看起来流失率不高，但注意一个细节：很多人是抱着“看一看”的心态报名的，如果没有赛前的多轮提醒，实际到场可能连100人都不到。我们在比赛前三天、前一天分别发过两次群公告，把比赛平台、账号、注意事项讲清楚，还开放了一个小时的在线答疑窗口，到场率才被拉起来。

人员构成上，大一新生占了大头，109人；大二及以上和研究生只有28人。这个比例其实有点失衡，但对第一次办赛来说是可以接受的——大一选手本来就是我们要摸底的主要对象。新生里有相当一部分人连正式比赛都没打过，更不理解“ACM模式”是什么意思，后面种种现场事故，不少都和这份经验缺失有关。

我在赛前做了一张参数表，现在看仍然值得存档：

为什么不用组队赛？我们内部争论过。组队赛更接近ICPC/CCPC的真实场景，能锻炼协作；但第一次校赛的核心任务是摸清每个成员的个体水平，组队会让一部分人“搭便车”，强弱混在一起，问题被掩盖了。个人赛虽然残酷，但数据和反馈最干净，适合作为赛季初的摸底测试。

1.3 为什么“第一次”要强调

很多高校的ACM实验室办校赛，一上来就把难度对标省赛区域赛，结果就是一片红，榜单上几十个人挂零，赛后留下一堆挫败感。这不是办赛，这是劝退。

这次既然是实验室成立后的第一场校赛，我一开始就定了基调：让大多数认真准备过的人能AC三分之一以上的题，让少数能打的人有题可钻研，让完全零基础的人至少能看懂签到题并拿到分。后来最终榜单也证明了这套思路是对的——137人中有115人至少过了一题，这个比例在个人赛里算相当健康。

2. 一张11题的题单是怎么搭出来的

2.1 难度曲线不是“从易到难”这么简单

很多人以为出题就是按难度从1到11线性排列，其实不对。真正的比赛题单需要考虑不同水平选手的“体验曲线”。

我习惯把题目分成四层：签到层、热身层、区分层、压轴层。签到题要让所有会基本输出的人都能做，通常放在A题；热身层要筛出能写循环、能处理数组的人，大概占三到四题；区分层拼的是对常见算法的理解，这道坎决定最终名次的含金量；压轴题则必须保证不会被人乱搞AC，至少得卡住95%以上的人。

这次11道题的知识点分布和预期通过率如下：

看起来挺规整，但这里有一个很容易踩的误区：预期通过率不是按“我会不会做”来估计的，而是按“目标人群的水平区间”来估的。出题人自己觉得再简单的题，放到第一次接触竞赛的选手眼里也可能无比困难。所以我们做预判时参考了寒假训练小测验的数据，把“大家已经熟练掌握”的内容定义为签到，把“只练习过一次”的内容定义为区分题，这样难度才不会飘。

2.2 造数据时最容易被忽视的边界问题

题面写完、标程写完，只是出题的一半。另一半是造数据，而且造数据绝对是这场校赛筹备过程中最折磨人的环节。

以B题“买水果”为例，题目要求计算若干种水果的总价，看上去很简单。但数据范围写的是水果单价和购买数量都在1到1e9之间，N最多1e5。如果不注意，用int去存总价，溢出几乎是必然的。这题的考察点根本不是“你会不会乘法”，而是“你知不知道1e5乘以1e9意味着什么”。正确答案必须用long long。

类似的坑在F题“食堂排队”里也出现过。题目要求在一个升序序列里找最后一个小于等于目标值的位置，标准的二分查找模板能过。但我们故意在数据里塞了个用例，目标值小于序列第一个元素，此时正确答案是0表示不存在。很多选手二分边界处理不好，就会在这个用例上WA（答案错误），我们赛前测数据时专门保留了这类边界。

造数据最容易翻车的还不是题目的边界，而是“猜答案错误的方向”。为了保证判题数据没有歧义，我们写了一个小型的测试脚本：先用一份最朴素的暴力算法跑出答案，再用标程跑一遍，然后把输出逐字节diff。两边一致的数据才敢放进正式题库。这个过程我们称之为“对拍”，是所有认真出题的人必备的手段。

2.3 赛前测试一定要找没做过题的人来试做

这里有一个很多人不信但真实的规律：出题人自己测自己的题，永远测不出问题来。因为你的大脑已经被题解影响，样例怎么读都觉得合理，标程怎么跑都觉得顺。但新手不是这么想的，他们会在你完全没注意的地方卡住。

这次A题“你好，参赛选手”要求输出一段含有多行文本的文字，我们在热身赛时找了一位大一新生来试做。他第一反应是：“OJ上输出要不要带引号？输出里的\n要转义吗？”这种问题出题人永远不会遇到，但赛场上一定会有人问。我们干脆把热身赛的答疑记录整理成一份FAQ放在赛前通知里，效果很好，正式比赛当天类似问题几乎消失。

所以我现在给所有准备办赛的人一个建议：出完题后，不要只让实验室内部的人测试，务必找一个还没形成“出题人心智”的普通选手来做一遍，记录他在哪里卡住、问了什么问题、提交时犯了什么错。这个人体验到的才是赛场上大多数人的真实体验。

3. 赛后复盘：值得展开说的四道题

3.1 全场提交的统计数字

赛后我导出了整场提交记录，总提交次数759次，AC提交302次，AC率大约是39.8%。这个数字比我们预想的低了将近10个百分点，主要原因是编译错误和格式错误占比太高——这个问题后面专门说。

各题的实际通过人数如下：

整体通过率全面低于预期，尤其A题只有82.5%，这其实就是新手第一次打ACM比赛的典型特征——不是不会写，而是还搞不明白“ACM模式”下的输出规范和提交逻辑。下面挑四道有代表性的题复盘。

3.2 A题：最简单的题为什么还有人卡住

A题题目很简短：请输出三行文字，第一行是“Hello NEFU!”，第二行是“Welcome to ACM Lab.”，第三行是当前年份。这是一道纯签到题，任何人都应该写得出来。

但通过率只有82.5%，意味着137人里有24个人在这题上栽了跟头。赛后我查了他们的提交记录，发现错误基本集中在几类：第一类是根本没有理解题目要求的格式，输出多了空格或者少了个感叹号；第二类是代码里写了中文标点，编译器直接报错；第三类最可惜，代码完全正确，但因为全角字符问题导致页面上的引号被复制进编辑器后变成了非法字符。

这道题给新人的启发比给老手更多：ACM模式下的输出不是“看起来对了就行”，判题程序拿你的输出和标准答案逐字节比对，一个多余的空格都会导致WA。所以写输出程序时，最稳妥的办法就是严格复制题目给出的字符串，而不是自己重新打一遍。这个习惯养成后，以后做任何模拟题都会少吃很多亏。

还有一类提交是Presentation Error，也就是格式错误，多在输出内容的行末多了空格或结尾空行。这种提示在多数OJ上会被当成错误，虽然在人眼看来毫无区别。我在赛前FAQ里专门强调过这一点，仍然有人犯，说明这种经验必须通过自己踩坑才能真正记住。

3.3 D题：结构体排序与comp函数

D题背景是运动会排名：给定N支队伍的编号、解题数和罚时，要求先按解题数降序、再按罚时升序、最后按编号升序排列。N最大1e5，所有数据都是正整数。本质上是一道经典的结构体排序题。

这题通过率19%，比预期低了6个百分点，问题出在哪里？一是很多人不熟悉结构体排序怎么写，C++里要么写cmp函数，要么重载运算符；二是很多人对奖牌排序模型的理解停留在“按总分排”这种线性思维，没有意识到排序往往需要多级关键字。

我贴一段赛标程的核心写法，供初学者对比：

cpp复制#include <bits/stdc++.h>
using namespace std;

struct Team {
    int id;
    int solved;
    int penalty;
};

bool cmp(const Team &a, const Team &b) {
    if (a.solved != b.solved) return a.solved > b.solved;
    if (a.penalty != b.penalty) return a.penalty < b.penalty;
    return a.id < b.id;
}

int main() {
    ios::sync_with_stdio(false);
    cin.tie(nullptr);
    int n;
    cin >> n;
    vector<Team> t(n);
    for (int i = 0; i < n; i++) {
        cin >> t[i].id >> t[i].solved >> t[i].penalty;
    }
    sort(t.begin(), t.end(), cmp);
    for (auto &x : t) {
        cout << x.id << "\n";
    }
    return 0;
}

为什么第三关键字必须是“编号升序”？因为sort不是稳定排序。有些同学天真地以为相同成绩的队会按输入顺序输出，其实标准库的sort并不保证这一点。比赛中排名规则如果包含“同分按编号升序”，就必须手动写进比较函数，而不是依赖STL默认行为。知道这个原理后，以后再遇到“字典序最小”“编号最小”这类附加条件，你就有明确的处理方向了。

3.4 E题：前缀和这道“一眼题”为什么成为分水岭

E题的题意是：给一个长度为n的整数序列，接下来有q次询问，每次输入l和r，输出区间[l, r]的和。n和q都在1e5级别，所有数的大小在-1e9到1e9之间。赛前我们判断这道题很多人应该能看出是前缀和，但实际通过率只有9.5%。

现场的真实情况是：很多人用暴力求和去写，结果自然是TLE（超时），而且反复提交多次都不想优化。还有人虽然想到前缀和，但没注意负数，前缀和数组的初始化和累加类型仍然用int，导致溢出和WA。

暴力算区间和的复杂度是O(qn)，最坏情况下1e5乘1e5等于1e10次操作，现代CPU每秒钟能执行的简单运算量级大约在1e8左右，也就是说暴力最坏情况需要跑几十秒。而前缀和只需要O(n + q)的时间，两者差距是数量级的。这个例子很适合新手理解一件事：算法优化的本质，是用预计算来换查询时间，而不是把同一件事反复做多遍。

E题还有一个隐藏考点是数组下标从1开始。很多人习惯从0开始存数组，但题目问的l和r是1-based的。如果没处理好转换，就会造成差一错误。这类错误最坑的是用例小的时候测不出来，一旦数据变大就会连续WA。

3.5 I题：那一份唯一AC的提交值得单独表扬

整场比赛中I题“走楼梯III”只有1个人AC了，恰好是一位大二成员。这题在普通斐波那契爬楼梯的基础上加了限制——某些编号的台阶不能踩，且允许一次跨1级或2级。表面上只是加了个障碍，但这道题的真正意思是：如果台阶数很大，必须用矩阵快速幂优化；如果加上不能踩的条件，状态转移怎么写又考验基本功。

唯一AC的这位同学用的是“分段矩阵快速幂”：把不能踩的台阶之间分成若干段，每一段用矩阵算好，再合并到总状态上。这个思路本身不复杂，但也说明他对快速幂理解得比较透，知道它能处理的是递推关系，而不是具体数值。赛后我们把他拉来给大一做了一次线下分享，效果比老师讲还好——因为学长和学弟之间没有知识落差，他解释“矩阵快速幂为什么能加速递推”的方式非常接地气。

4. 先跨过那道叫“输入输出”的坎：ACM模式下的四种语言写法

4.1 为什么单独讲这个，因为它是第一道真正的门槛

ACM模式，简单说就是程序从标准输入读数据，计算结果写到标准输出，判题系统完全根据标准输出的内容判断对错。这跟很多人平时在力扣这类平台上写习惯了的核心函数模式不一样，后者只需要把函数体写好，输入输出的活平台全干了。到了真比赛里，很多新手明明算法写对了，却栽在读不到数据或输出格式不匹配上，非常可惜。

这次校赛里，第一小时提交的错误类型统计中，编译错误占32%，运行错误占11%，答案错误占40%。编译错误里相当一部分就是因为不理解输入输出格式，比如多组输入的终止条件没写对，代码逻辑不完整导致编译不过。因此，写下你的第一个正式模板，对每个参赛者来说都是必修课。

4.2 C/C++：最通用也最容易在细节上翻车

C++ 是竞赛中最主流的语言，它的输入输出有两种流派：scanf/printf和cin/cout。我个人的建议是：想减少心智负担，就用cin/cout并关闭同步；想追求极致速度又不喜欢写太长，就用scanf/printf。不过现代竞赛环境下，正确处理同步问题的cin/cout已经足够快。

cpp复制#include <bits/stdc++.h>
using namespace std;

int main() {
    ios::sync_with_stdio(false);
    cin.tie(nullptr);

    int n;
    while (cin >> n) {
        long long sum = 0;
        for (int i = 0; i < n; i++) {
            long long x;
            cin >> x;
            sum += x;
        }
        cout << sum << "\n";
    }
    return 0;
}

上面这段代码处理的是“多组测试，每组先给一个n，如果n为0则结束”的常见格式。这里有两个必须养成的习惯：第一，while (cin >> n) 处理到文件结尾是非常标准的写法，比依赖某个结束标记更稳；第二，ios::sync_with_stdio(false); cin.tie(nullptr); 这两行几乎是所有C++竞赛代码的标配，没有它，大量输入时cin可能比scanf慢一个数量级。

另一个容易踩的坑是 #include <bits/stdc++.h>。这个万能头文件在GCC环境下可用，大部分OJ都支持，但有极少数平台不支持，或会因为包含太多头文件导致编译慢。校赛环境我们预装了GCC，所以没问题，比赛时新手不必纠结这个头文件到底包含什么，只要知道它是GCC的扩展而非C++标准即可。

4.3 Java：主类名定生死，缓冲输入是底线

Java选手在校赛中遇到的第一道坎永远是类名：主类必须叫Main，否则判题系统无法运行。这次比赛就有两位同学因为类名写成了自己的昵称，编译直接失败。Java主类名这个问题没有任何商量余地，你在本地跑的时候叫什么都可以，交到OJ上主类一律写成Main。

java复制import java.io.*;
import java.util.*;

public class Main {
    public static void main(String[] args) throws IOException {
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        String line;
        while ((line = br.readLine()) != null) {
            if (line.isEmpty()) continue;
            StringTokenizer st = new StringTokenizer(line);
            int n = Integer.parseInt(st.nextToken());
            long[] a = new long[n];
            st = new StringTokenizer(br.readLine());
            for (int i = 0; i < n; i++) {
                a[i] = Long.parseLong(st.nextToken());
            }
            // 业务逻辑...
        }
    }
}

用Scanner当然也能做，但在数据量大到1e5以上时，Scanner会因为正则解析慢得让人怀疑人生。BufferedReader加StringTokenizer是Java竞赛选手必须掌握的“基础装备”，不要嫌麻烦。题量小无所谓，一旦TLE，检查一下自己的IO是不是拖了后腿。

另外强烈建议Java选手在意输入可能跨多行的情况：不要假设每个整数都在同一行，有老杨树一样长的题面数据时，按行读然后逐字解析是最稳的。

4.4 Python：代码最短，但TLE风险也最高

Python的简洁吸引了很多新手，但它在竞赛环境里的运行速度是天然的短板。能写出正确算法只是第一步，同样的O(n log n)复杂度，C++也许100ms跑完，Python可能要花到500ms甚至更多。因此Python选手需要更注重读入效率。

python复制import sys

def main():
    data = sys.stdin.buffer.read().split()
    idx = 0
    n = int(data[idx])
    idx += 1
    a = list(map(int, data[idx:idx+n]))
    # 业务逻辑...

if __name__ == "__main__":
    main()

注意 sys.stdin.buffer.read().split() 是一次性把整个输入读进内存再切分，比反复调用input()快得多。很多Python新手习惯用 for _ in range(int(input())) 一行行读，这对小数据没问题，但数据量一上来，input()内部的缓冲机制就会拖慢速度。

Python另一个新手高发问题是递归深度。你用DFS跑一张1e5个点的图，递归深度很容易超过默认的1000层限制，直接RecursionError。要么手动 sys.setrecursionlimit(1000000)，要么干脆用栈模拟递归。总之用Python参赛，不仅要写对算法，还要时刻考虑“这个写法在Python里面会不会因为效率或递归深度挂掉”。

4.5 Go：语法简洁，但别忽略fmt.Scan的性能隐患

Go在算法竞赛圈子里属于小众选择，但确实有同学在用。Go的问题和Java类似，fmt包的Scan系列函数虽然好用，但性能不太稳定，遇到大规模数据时建议换成bufio。

go复制package main

import (
    "bufio"
    "fmt"
    "os"
    "strconv"
    "strings"
)

func main() {
    scanner := bufio.NewScanner(os.Stdin)
    scanner.Scan()
    n, _ := strconv.Atoi(scanner.Text())
    scanner.Scan()
    parts := strings.Fields(scanner.Text())
    a := make([]int64, n)
    for i := 0; i < n; i++ {
        a[i], _ = strconv.ParseInt(parts[i], 10, 64)
    }
    fmt.Println("done")
}

这里只展示了读取一行的方式。要注意bufio.Scanner默认的缓冲区大小有限制，如果在单行里塞了特别大的数据，可能会触发bufio.Scanner的token过长错误。解决办法是初始化时调大缓冲：scanner.Buffer(make([]byte, 1024*1024), 1024*1024)。Go选手少，参考资料难找，提前踩过这些坑的人才能在赛场上从容。

5. 现场运维实录：那些没有写进公告的混乱

5.1 开赛一小时后评测队列堵成了一条直线

比赛进行到十点左右，也就是开赛一小时后，评测系统突然开始堆积提交，等待队列肉眼可见地增长。我当时第一反应是评测机崩了，跑到机器前面一看，CPU已经跑满，但队列里明显有大量编译任务在排队。

原因很快定位到了：很多人把A题这种签到题也提交了多次，每提交一次就要编译；更麻烦的是有人写了死循环，程序跑起来不结束，把CPU长时间占住。一台四核的评测机根本扛不住这种并发。

我们当即暂停了新提交的自动评测，等CPU降下来后手动清理了卡死的进程，然后限制同一时间最多同时评测两个任务，才把局面稳住。这件事给我们的教训很直接：下次比赛前必须做一次评测机的压测，脚本同时提交50份甚至100份不同代码，模拟开赛峰值，不然根本不知道自己服务器的极限在哪里。

5.2 一道题的数据在比赛途中被订正了

C题“大小写都一样”原意是给定一个由大小写字母组成的字符串，统计每种“不区分大小写的字母”出现次数。但初始题面里没有明确说明“不区分大小写”，导致一批选手按严格区分大小写的思路写了代码，前几个样例能过，后面被隐藏数据卡住，产生大量WA。

这道题在上午十点半左右集中涌入答疑群。我们经过讨论后，判定是题面表述不清，于是紧急发布公告澄清规则，并且把这题的所有提交标记为等待重判。公布之后我们做的第一件事是暂停这题的新提交，避免选手基于错误理解继续浪费时间；然后重新生成一份包含大小写混合字符串的数据，更新题库；最后等到比赛结束后执行了一次全量重判，把被规则误伤的提交重新给出正确判定。

这种“中途改数据”的骚操作能不做尽量不做，因为它会让人对榜单公平性产生怀疑。但真发生了也不要慌，处理顺序必须是：公告澄清优先级最高，先暂停该题评测，再改数据，最后重判。重判后榜单可能剧烈波动，一定要提前写好说明，防止选手误以为系统出错。

5.3 封榜策略救了很多新手的心态

ACM赛制支持实时滚榜，但实时榜单也会带来巨大的心理压力。我们这次选择了在比赛最后一小时封榜，即14:00结束的比赛，从13:00开始，选手无法再看到其他人的实时排名，只能看到自己的提交反馈。

封榜的决定来自我个人的一次惨痛经历。大一第一次参加校赛时，我在最后一小时刷新榜单，看到自己从十几名掉到三十几名，心态瞬间崩了，后面连续几道题都静不下心思考，白白浪费了时间。

封榜表面上是隐藏信息，实际上是保护选手：既然最后一小时看不到排名变化，那唯一的策略就是专注解题，盯着自己剩下的题目思考，别被外部信息干扰。赛后滚榜环节我们做了个简单的榜单回放，颁奖之前先放一段提交动画，把从第11名到第1名的排名变化过程展示出来，现场气氛很热烈，很多大一新生第一次感受到竞赛的魅力。

6. 赛后统计暴露出的三个训练缺口

6.1 编译错误率第一：基础语法还不够扎实

整场759次提交中，编译错误有221次，占比29.1%，比答案错误还高。也就是说近三成的提交连程序都没跑起来。

我统计了编译错误的具体类型，发现很有规律：C++选手集中在漏写头文件、变量名拼写错误、结构体定义少了分号；Java选手集中在类名不叫Main、忘记导入包、在static方法里调用了非static方法；Python选手的“编译错误”则主要是缩进混乱和语法错误。这些都不是算法层面的问题，纯粹是代码写得少、编译器报错信息看得少。

我的建议非常朴素：正式比赛之前，每人至少完整写完50道水题，每天只练输入输出和基础语法，不碰算法。当你能闭着眼写出C++的快读模板、Java的Main外壳、Python的sys.stdin.buffer读取流程时，编译错误自然就会消失。

6.2 数据范围意识薄弱，int溢出和暴力超时是最常见死因

查看运行错误和答案错误的提交记录，我发现一个高频场景：选手想到了正确做法，但因为没用long long而溢出，最终答案比标准答案大很多，反复WA也不知道为什么。比如B题里总价上限是1e14，明显超出int范围，仍然有接近20人在被提示WA后才尝试改成long long。

这暴露了一个训练缺口：大家刷题时往往只关注“这个题用什么算法”，却很少问“这个题的数据范围决定我用什么类型、什么复杂度”。我建议每个新手在读完题面后，先条件反射式地做两件事——看数据范围，算极端情况下的值域；看时间限制，估算最坏情况下算法能否在1秒内跑完。这两个习惯比会背十个算法都重要，因为算法选错了是知识问题，类型开小了是习惯问题，后者在比赛中更致命。

6.3 样例过了就交：缺少自测和对拍的意识

还有一个数据很能说明问题：这场比赛中，平均每道AC题对应的提交次数是2.5次。也就是说，绝大多数人不是一次写对的，而是反复WA才改对。有些人的第一次AC甚至出现在第五次、第六次提交之后。

原因很简单：大家习惯把样例复制进本地跑一遍，结果一致就直接交上去。但样例只能证明你的代码能处理最一般的情况，覆盖不了边界和隐藏条件。更健康的自测方式是：每次写完代码后，自己构造几个边界用例——最大值、最小值、数组空、只有一个元素、元素全部相同。把这些都跑过再交，一次AC的概率会大幅提升。

对拍是更专业的做法。写一个纯暴力但一定正确的版本，再写一个你正在优化的版本，然后写一个随机数据生成器，不断循环比较两份程序的输出，遇到不一致就说明优化版有bug。这个方法看似费时间，实际是找隐藏错误最快的路径，没有之一。赛后我把D、E、F三题的原题和数据生成脚本放到了训练仓库里，就是希望下一次周赛前，大家能照着这个流程练起来。

6.4 从周末训练方案看如何填补缺口

发现问题后，我们调整了实验室的春季训练计划：每周三固定一次“基础语法刷题夜”，每人必须完成20道水题，以消除编译错误和输入输出短板；每周日上午进行一场小型计时赛，题目从这次校赛的未AC题中抽取，强制要求现场补题；另外把“数据范围九宫格”贴在了实验室墙上——int上限2e9、long long上限9e18、1s大约1e8次运算、Python大约1e7次运算。这些看似基础的东西，恰恰是需要不断强调的。

7. 下次再办校赛，我一定会改的五件事

第一，评测机压测必须提前做。这次开赛一小时的评测队列拥堵是完全可以避免的，只要赛前用脚本模拟50人同时提交的峰值场景，就能提前发现性能瓶颈。

第二，热身赛时间要拉长。这次热身赛我们只安排了一个小时，很多人甚至没来得及测试自己电脑上编译器与OJ的兼容性，正式赛就开始了。下次至少在赛前一天开放全天热身赛，并且强制要求参赛者完成一次提交流程，尽量减少正式赛的低级错误。

第三，题目数据的“肉眼审查”要多一个环节。C题的表述不清问题其实在定稿前已经有人觉得可能产生歧义，但当时觉得“一看就懂”便放过去了。以后再出字符串类题目，至少要让两个人独立读完题面且不看标程，然后复述题意，确保他们的理解与出题人一致。

第四，答疑渠道要分优先级。这次我们建了一个比赛答疑群，但消息太多，重要公告容易被淹没。下次准备单独使用一个只由管理员发言的公告频道，普通讨论和答疑另开一个群。保证规则变更能被所有人看到。

第五，赛后两小时内必须发布题解和补题入口。比赛结束后的兴奋期是补题的最佳时间窗口，等热度过了再发题解，大多数人就不会去看了。这次我们当晚就整理好了全部题解和一份A到K的难度标签，第二天的浏览量比前十天的训练记录还高，说明趁热打铁的效果确实猛。

办完这场校赛的当天晚上，我坐在实验室里重新翻了一遍所有提交记录，看到一个有意思的现象：J题虽然零通过，但有一位大一新生提交了5次。他最后的提交里已经写出了正确的DFS框架，只是base case的返回值写反了。这道题按他当时的水平其实不应该有思路，可能是盯着榜单上J题的通过数为0之后，反而激起了他“试一试”的念头。

说真的，这种零通过题末尾的执着提交，比看榜单前列那些漂亮数据更让我高兴。他们愿意反复提交一个5次、8次都过不了的题，说明对竞赛的兴趣已经扎根了。一场校赛的价值，从来不只在于选出几个能打省赛的人，而在于让更多人知道，一道看似不可能做出来的题，通过拆解和尝试，也可能一点一点接近答案。这算是这次办赛下来，我最大的感受。