CSP 等信息学考试第二轮防“暴 0”全攻略：文件命名、自测环境与心态指南

适用范围：CSP-J/S 第二轮、NOIP 提高组、各类 OI/省选模拟机试等。

目标：哪怕遇到超纲难题，也要通过良好的习惯和稳定的代码，尽量拿到能跑的部分分，避免整场“暴 0”。

一句话核心：不要求你每题都会做，但一定要让每一题“能编译、能跑、能拿分”。

一、什么是“暴 0”，为什么会发生？

很多同学第二轮“暴 0”，并不是因为完全不会做，而是因为：

• 代码无法编译（CE）；

• 一提交就运行错误（RE）或输出格式错误（PE）；

• 输入输出写错位置，评测系统读不到/写不到数据；

• 写到一半没来得及提交，或者交错题、交错文件。

结果就是：明明有思路、有实力，却在成绩上被记成“0 分”。因此，防暴 0 的重点不是“会多少算法”，而是：在考场上稳定写出能通过样例、能完整跑完的程序。

二、考前准备：环境 + 模板，少踩坑

1. 熟悉评测环境

• 尽量在与 CSP/NOI 接近的环境上练题（例如 NOI Linux 镜像、本地 g++ 编译 + 命令行运行）。

• 掌握命令行编译方式，了解常用参数，例如：

g++ -std=c++17 -O2 -pipe -static -s main.cpp -o main

同时，提前搞清楚本次考试是标准输入输出，还是要读写指定的 xxx.in / xxx.out 文件。

2. 准备一份“安全模板”

建议考前整理一份自己熟悉的 C++ 模板，内容包括：

• 固定头文件（如比赛环境允许，可使用 #include <bits/stdc++.h>）；

• 常用别名：using ll = long long; 等；

• 常用函数封装（如快速读写、常见数据结构模板等）。

3. 刻意练习“只拿部分分”

平时刷历年题时，不要只追求“AC 满分”，要刻意练习：

• 先写一个暴力/枚举版本，保证在小数据上能跑、能拿 20～60 分；

• 再考虑如何优化到更高分，而不是一上来就写复杂优化、最后“编译不过/跑不完”。

三、考场操作习惯：避免“物理性暴 0”

1. 文件命名清晰，一题一个文件

• 建议按题号命名：t1.cpp、t2.cpp、t3.cpp、t4.cpp，或 a.cpp、b.cpp、c.cpp、d.cpp。

• 如果考场要求指定文件名（例如 game.cpp、tree.cpp），必须与题面完全一致，不要随意改名。

• 建议在电脑上给每一题单独建一个文件，不要把所有题都写在同一个 main.cpp 里，以免交卷时搞错题目或覆盖掉代码。

2. 提交要求与“最后版本”意识

不同考试的提交方式略有区别，但通常有以下几种形式：

• 现场机房 + 本地评测系统：在考试系统中为每一题选择对应的源文件（如 t1.cpp），点击“提交”并等待评测结果。

• 统一打包提交：按要求将 t1.cpp～t4.cpp 放在同一目录，由监考老师或系统统一打包收取。

无论采用哪种方式，都要牢记：

• 确认每一题都至少提交过一次可运行的版本，不要忘记提交某一题。

• 提交前看清题号：T1 就交 T1 的文件，避免把 T3 的代码交到 T2。

• 若系统支持多次提交，最后一次提交才是真正计分的版本，不要在最后几分钟随便改一行就提交，导致“改坏了”。

3. 弄清楚输入输出方式

• 标准输入输出题：只使用 cin / cout 或 scanf / printf，不要乱用 freopen；

• 文件输入输出题：按照题目要求精确写文件名，例如：

freopen("game.in", "r", stdin);
freopen("game.out", "w", stdout);

注意：文件名、大小写、后缀必须和题目保持完全一致，否则评测系统可能读不到/写不到。

4. 写代码前先“抄格式”

在纸上或代码顶部简要记下：

• 输入格式：是否多组数据？第一行是否有 T？是否 0 结束？

• 输出格式：每行输出什么？是否需要前缀文字（如 Case #x: ）？

• 数据范围：n、m 多大？是否需要 long long？时间复杂度大致要求？

四、防暴 0 的关键代码细节

1. 优先考虑 long long

当题目出现如下关键词时，优先使用 long long：

• 元素值范围到 1e9 或更大；

• 有大量累加、乘法、前缀和等操作；

• 涉及组合数、路径数、权值和等。

2. 数组开大一点 + 初始化

• 若题目给 n ≤ 2e5，数组可考虑开到 200000 + 5 或 2 * 200000 + 5；

• 必要时在开局加 memset 清零，避免读到未定义的“垃圾值”。

3. 避免常见 RE（运行错误）

• 数组越界：注意 i±1、j±1、队列/栈的 push/pop 等场景；

• 除 0：任何除法前都先判断分母是否为 0；

• 递归过深：深度 DFS 时考虑改用循环或手动栈。

4. 提交前清理调试代码

• 删掉所有 cerr、printf("debug")、system("pause") 等；

• 如一定要保留，用宏判断包裹，提交前改成空实现。

五、得分策略：先“有分”，再想“高分”

1. 第一遍选题：先做最稳的

• 快速浏览所有题目，给自己打标记：“必做 / 可做 / 暂缓”；

• 先做最有把握的一题，确保有一个100% 能 AC 或高分的题目落袋为安。

2. 不会做的题也要留一个“能跑的版本”

对难题，可以先写：

• 简单暴力枚举（适用于小数据部分分）；

• 朴素 BFS/DFS、简单贪心等有一定正确性的方案。

很多题会特意给“小数据 / 特殊数据”的部分分，只要程序能正确跑完，就不至于 0 分。

3. 考试最后 10 分钟，禁止“大改重构”

最后阶段的主要任务是：

• 检查输入输出格式；

• 补边界特判（如 n=0、n=1、全相等、全为极值等）；

• 再跑一遍样例和自己构造的极端数据。

此时不建议推倒重写整题算法，一旦新版本来不及调试，连原来的部分分也可能丢掉。

六、在家搭建简单自测环境

1. 安装并确认 g++ 可用

• 在 Windows 上：可通过 MinGW、WSL 或官方镜像等方式安装 g++，安装后在命令行输入 g++ --version，确认输出版本信息。

• 在 Linux/macOS 上：一般系统自带或通过包管理器安装，安装后同样用 g++ --version 检查。

2. 建立“题目专用文件夹”

• 为每场模拟测试单独建一个文件夹，例如 csp_mock_2026_1。

• 在文件夹内按题号准备源文件和测试数据，例如：t1.cpp、t1_sample1.in、t1_sample1.ans 等。

3. 用命令行编译并运行

以第一题为例，可以在命令行中执行：

g++ -std=c++17 -O2 -pipe -static -s t1.cpp -o t1
./t1 < t1_sample1.in > t1_sample1.out

然后用文本对比的方式，将 t1_sample1.out 与标准答案 t1_sample1.ans 进行比对，检查是否完全一致（包括空格和换行）。

4. 自制“小评测脚本”（可选）

如果熟悉脚本语言，可以写一个简单脚本批量测试多组数据，例如用 shell：

for i in 1 2 3 4 5; do
  ./t1 < t1_sample${i}.in > t1_sample${i}.out
  diff -q t1_sample${i}.out t1_sample${i}.ans || echo "样例 $i 不通过"
done

这样就能在本地快速发现格式错误、边界问题等，考前尽量在“接近真实环境”的条件下完成几套模拟，能有效减少正式考试时的意外失误。

七、考试心态与时间分配建议

1. 整体时间规划

• 开考前 3～5 分钟：快速扫一遍所有题目，判断大概难度和熟悉度。

• 前 1/3 时间：优先保证至少 1～2 道题的稳定得分（尽量做到能 AC 的题先 AC）。

• 中间 1/3 时间：在有把握的基础上，尝试第三、第四题的暴力解或部分分做法。

• 最后 20～30 分钟：回头检查输入输出、边界情况，整理并提交最终版本。

2. 遇到卡壳时怎么做

• 在一道题上连续卡住 30 分钟以上、思路完全不清晰时，可以先暂停，转去处理其他题目的稳妥部分分。

• 给自己设“止损点”：比如一道题最多花 40 分钟，到了时间就先提交当前能跑的版本，然后再考虑是否回来优化。

• 实在推不出完整解法，就退回到更简单的子问题，拼出一个“至少能得部分分”的方案。

3. 心态：防止因一题失误带崩全场

• 把每道题当作“独立战场”：某一题失误或写炸了，不要立刻推翻全部代码，更不要影响后面几题。

• 暴露的问题当场“标记 + 记一条经验”，不要陷入自责，把精力用在“接下来还能拿多少分”上。

• 记住：CSP/NOIP 等考试是按总分排位，只要能稳稳拿到属于自己的那一部分分数，就已经超过大量因为暴 0 而崩盘的同学。

八、提交前“防暴 0 清单”（Checklist）

提交前，用 1～2 分钟快速自查：

• 我读的输入格式和题目描述完全一致吗？（是否多组、是否有 T、是否 0 结尾？）

• 输出格式是否多输出/少输出了空格或空行？是否缺少要求的前缀文字？

• 所有可能爆 int 的地方，都换成了 long long 吗？

• 数组、下标和队列/栈访问有没有可能越界？

• 有没有残留调试输出、system("pause") 等？

• 代码在本地至少完整跑过：官方样例 + 自己造的极端数据（全 0、全最大值、最小 n、最大 n）。

• 提交的文件名和题号匹配吗？没有把 T1 的代码交到 T2？

• 
  

坚持以上习惯，可以大大降低因为“技术性失误”造成的暴 0 风险。真正决定分数高低的，除了算法实力，更是这些细小但关键的基本功、自测能力和考场习惯。