简介面向信息学奥赛NOI/CSP选手和教练的速查型PDF手册围绕NOI2.0评测系统、NOI Linux 2.0与Vim编辑器三条主线汇总了从虚拟机安装、系统启动、Arbiter/LemonLime测评操作到代码提交、文件输入输出与常见避坑点等内容适合备赛冲刺或赛前环境自查使用。资源为1个PDF文件压缩包大小253KB内容以精选视频教程、图文指南和工具说明的索引形式呈现目录按评测系统、系统环境、编辑器、C竞赛要求等模块组织便于快速定位所需环节。已有1507人学习下载。手册不仅整理B站实操视频和CSDN保姆级教程还补充了Vim的插入/命令/可视化模式切换、宏录制与播放、跳转指定行等核心操作要点同时覆盖Linux终端常用命令、C内存管理与STL应用等竞赛高频能力能帮助选手减少环境问题干扰把更多精力集中在算法设计与代码实现本身。1. NOI2.0、NOI Linux 2.0、Vim一条评测链路三个闸门NOI2.0评测系统、NOI Linux 2.0、Vim表面看是三份材料实际是同一根链路的三个环节你在 Vim 里写代码在 NOI Linux 2.0 里编译运行最后由评测系统决定你拿多少分。很多选手把精力全压在算法上到了机房却卡在编辑器保存乱码、文件命名不对、评测目录不熟这些小问题上一道明明会做的题直接零分。这份指南要解决的正是从敲下第一行代码到提交评测之间那段没人细讲的路。适合正在备赛的信息学选手、带队的教练以及要搭机房评测环境的运维同学。下面按评测环境、Vim 使用、评测系统操作和踩坑排查的顺序展开每段都给出能直接落地的命令和参数。2. NOI Linux 2.0 评测环境为什么分数只认这一套系统2.1 评测系统的判定逻辑黑盒之外环境一致才是关键NOI Linux 2.0 是信息学竞赛指定的操作系统它基于 Ubuntu 20.04 LTS自带标准 C/C 编译工具链。这套系统看起来只是把 Ubuntu 换了个皮肤但真正值钱的是它把竞赛要用的那一套工具固定在了一个版本上g 编译器、标准头文件、动态库路径、default 的编译标准全部锁死。评测机读的是源码但源码是在一套特定系统里编译成可执行文件的如果选手自己在别的系统上调通到评测机上换个编译器版本行为就可能完全不同。评测系统的判定逻辑本身是黑匣子你把源码交上去系统在受控环境里编译、运行然后用标准输出和标准答案比对。传统题比对的是 stdout交互题比对的是交互过程提交答案题直接比对输出文件。这套流程倒不复杂复杂的是受控环境四个字。NOI 系列比赛明确要求选手在 NOI Linux 2.0 下开发就是要把变量压到最小编译器一致、头文件一致、浮点舍入一致、文件路径规则一致。我的经验是平时训练必须至少在虚拟机里保留一套和评测机同版本的 NOI Linux 2.0写完代码先拿它编译一遍再谈对错。环境差异不是玄学是可复现的事故。我自己就见过在 macOS 上用 Xcode 调得好好的 BFS拿到 Linux 评测机上 MLE也见过用 Windows 记事本存代码交上去编译报stray \357 in program。这些东西和算法水平无关却能把分数直接清零。下面几个环境项赛前要一条条核对。环境项NOI Linux 2.0 常见形态平时自测要做的操作系统Ubuntu 20.04 LTS64 位虚拟机里跑同一版本 ISO编译器g 9.x 系列用 g 而不是 clang编译标准默认 gnu14可显式指定更高标准命令里写-stdc17输入文件题目指定的 .in/.out 文件名自己写 freopen 时逐一核对数据目录评测系统按题目分别隔离本地自测建统一目录2.2 Windows 装 NOI Linux 2.0虚拟机与双系统怎么选很多人的第一台电脑是 Windows装上 NOI Linux 2.0 有两条路虚拟机或者双系统。如果只是平时刷题和复现评测虚拟机一般够用。用 VirtualBox 或 VMware 建一台 Ubuntu 20.04 的虚拟机分配 4GB 内存、60GB 以上动态磁盘安装时选中文简体装完再挂载共享文件夹用来和 Windows 交换源码。虚拟机的缺点是绕了一层硬件CPU 频率和内存带宽跟真机有差距所以它适合验证编译能不能过、语法对不对不适合估算极限数据下的运行时间。双系统是更接近比赛环境的做法Windows 下想装 NOI Linux 2.0 双系统套路并不复杂先给硬盘分出一个空闲分区用 ISO 做启动 U 盘进 BIOS 把启动顺序改到 U 盘然后按安装向导走。两个地方容易出问题一是分区时手滑把 Windows 分区删了没有后悔药二是装完双系统后 Windows 和 Linux 的硬件时钟机制不一样时间会差 8 个小时。前者靠备份数据规避后者装完后在 Linux 里执行timedatectl set-local-rtc 0或者直接在 Windows 里关闭自动同步时间就能消掉。我个人的建议是打算认真打竞赛的选手直接用双系统当主力环境早一天把编辑器、编译命令、文件管理都搬到 Linux 上比赛时少一层手忙脚乱。注意下载 ISO 后先用md5sum或sha256sum校验一遍再装网上源五花八门校验值对不上要么是下载损坏要么是文件被改过。机房批量部署时直接做一份装好的磁盘镜像分发到同配置机器比每台现场安装节省大量时间。2.3 g、C 标准与 Xcode/Vim 的编译差异同一个班有人用 Vim有人用 Xcode平时都能写题但到评测机上结果可能完全不同。Xcode 带的是 clang 编译器NOI Linux 2.0 里用的是 g两者对 C 标准的实现有差异。最典型的例子是pow的重载行为和整型提升规则在 clang 下编译通过的代码换 g 可能报出多个候选函数的模糊重载错误。另一个常见案例是__int128这个是 g 的扩展用 clang 编译时有可能直接报__int128未声明还有#include bits/stdc.h这个万能头在 NOI 环境里存在但依赖的路径和实现跟特定编译器版本绑定换个环境要么没有这个头文件要么内部宏定义不一致。我的建议是日常写题用什么编辑器都可以但赛前一两周必须把主力环境切到 NOI Linux 2.0 或同等版本的虚拟机里用同一条编译命令跑。编译命令尽量固定成一种我一般用g -stdc17 -O2 -Wall -o a.out main.cpp这条命令里-stdc17指定语言标准NOI Linux 2.0 自带的 g 9.x 完整支持 C17-O2是评测常用的优化级别不开 O2 和开了 O2 的程序运行时间差距可能超过一倍最影响比赛的是递归、浮点和编译器自动向量化行为-Wall开启基础警告能提前暴露未初始化变量等问题。-o a.out固定输出名字下面讲 Vim 快捷键和评测脚本时都用这个约定省得到处找二进制文件。3. 用 Vim 写第一份能上评测机的代码从新建文件到跑通样例3.1 一份面向评测的 .vimrc语法、缩进、编码三个方向Vim 默认配置对竞赛不算友好没有行号Tab 宽度是 8语法高亮要手动开最坑的是处理从 Windows 拷过来的 GBK 编码文件时直接显示乱码。这些问题都不影响算法但都会在赛场上消耗你的耐心。我的做法是把一份 .vimrc 固定下来复制到每一台自己用到的机器上下面的配置是我这几年用得顺手的最小集合。 面向 NOI Linux 2.0 的 .vimrc 最小配置 set nocompatible syntax on set number set ruler set tabstop4 set shiftwidth4 set softtabstop4 set expandtab set autoindent set hlsearch set incsearch set encodingutf-8 set fileencodingsutf-8,gbk,latin1 set fileformatsunix,dos set mousea这个文件里每一项都有明确的用途。set tabstop4和set shiftwidth4把 Tab 和缩进都变成 4 个空格这是竞赛代码最常见的缩进宽度也避免不同编辑器里 Tab 显示不一致set softtabstop4让 Backspace 一次删掉 4 个空格而不是只能删一个set expandtab表示按 Tab 键时插入空格而不是真实 Tab 字符防止评测机上的编译器对制表符位置敏感。encodingutf-8配合fileencodingsutf-8,gbk,latin1是让 Vim 能正确打开机房机器上常见的 GBK 源码不至于打开就是一片乱码挽救过不少从 Windows 共享文件夹直接拖过来的文件。set mousea启用鼠标争议比较大有人觉得比赛禁用鼠标有人觉得点选比键盘快。我的态度是键盘流有门槛新手用鼠标能减少误操作先把题做出来最重要。真正上考场如果赛场禁鼠标再临时改成set mouse-a也不迟。3.2 用一条编译命令对齐评测选项g -stdc17 -O2写代码不是问题编译命令才是评测的第一道坎。建议不要在 Vim 里频繁敲完整的 g 命令而是把常用的编译动作映射到快捷键上。上面那节说过-o a.out约定配合 Vim 的nnoremap可以做成一键编译。 一键编译运行F5 编译F6 编译并运行F7 只运行 nnoremap F5 :wCR:!g -stdc17 -O2 -Wall -o a.out %CR nnoremap F6 :wCR:!g -stdc17 -O2 -Wall -o a.out % ./a.outCR nnoremap F7 :!./a.outCR这三行的执行逻辑是先保存当前文件然后调用 shell 执行 g%在 Vim 命令里代表当前文件名所以g -stdc17 -O2 -Wall -o a.out %编译的就是你正在编辑的这份源码。F6 在编译成功后直接用串起./a.out运行这样写是因为只要编译失败就不用浪费时间跑一个不存在的程序。注意这里是 shell 的短路逻辑前面的 g 返回非零退出码后面的命令就不会执行。有个细节值得说明-o a.out固定输出名。很多新手喜欢写成-o 题目名手动敲键盘时没问题但一旦做成 F5 快捷键二进制文件名字会随文件名变化脚本里、对拍里都要跟着改非常容易出错。固定成a.out之后测试命令永远是./a.out评测脚本也只用管一个名字。运行程序前要确认已经编译成功不然跑的是上一次的旧二进制这种翻车最憋屈。3.3 用 Vim 的编译错误跳转和分屏做小样例测试Vim 还有一个常用组合把 g 集成进 Vim 的makeprg编译出错之后直接在错误列表里跳转不用肉眼在滚动输出里找行号。配置如下 把 makeprg 指向 g用 :make 编译 set makeprgg\ -stdc17\ -O2\ -Wall\ -o\ a.out\ % 编译后自动打开错误列表 nmap F5 :wCR:makeCR:copenCR这里makeprg里的\用来转义空格因为 Vim 把整行当成一个字符串传给 shell不转义会在g那里断开。执行:make时 Vim 会解析编译器输出并填进 quickfix 列表:copen打开那个列表光标选中错误条目回车就能跳到对应代码行。对一个几百行的 C 文件来说这个跳转节省的时间非常可观。分屏也是调小样例的利器。我习惯一个屏幕开三块源代码、输入文件、终端。按:split左右分屏:vsplit上下分屏:terminal打开内置终端。Vim 8.2 在 NOI Linux 2.0 里支持终端模拟器不需要切出编辑器就能跑./a.out sample.in。小样例出错时直接在旁边打开输入文件和代码肉眼对照数据找 bug比反复切窗口效率高很多。等代码稳定了再回到单一编辑界面写正题。4. NOI2.0 评测系统使用目录约定、自测脚本和评测参数4.1 评测目录和数据文件怎么组织评测系统接收的是源码文件和题目信息但本地自测时目录乱成一团程序跑起来连输入文件都找不到。这里给出一套能在评测机上落地的目录约定它不是某个官方标准但足够通用也方便和评测脚本对接/home/noi/judge/ ├── data/ │ ├── task1.in │ ├── task1.out │ ├── task2.in │ └── task2.out ├── submissions/ │ ├── player_a/ │ │ └── task1.cpp │ ├── player_a/ │ │ └── task2.cpp │ └── player_b/ └── scripts/ ├── judge.sh └── gen.pydata目录里放题目测试数据命名规则是题号.in对应题号.out成对出现。submissions按选手分目录每个选手目录下放各个题的源码。这样组织有一个好处评测的时候只需要遍历submissions下每个子目录里的task1.cpp配上data/task1.in就能形成完整的评测单元不管手动测还是写脚本都很直接。目录结构定了代码里 freopen 的路径就要围绕当前工作目录设计我一般不看相对路径直接让程序从 stdin/stdout 读写用 shell 重定向喂数据最干净。gen.py是数据生成器比赛前用来造小随机数据测边界用下面会用到。4.2 写一个 judge.sh把每个测试点跑一遍并比对评测系统的核心动作就是编译、运行、比对用 bash 脚本完全可以模拟一版适合赛前在 NOI Linux 2.0 里自测。下面的脚本接受两个参数测试数据目录和选手源码路径然后逐个跑完每个测试点输出 AC/WA/TLE。#!/usr/bin/env bash # 用法: ./judge.sh 数据目录 源码文件 DATA_DIR$1 SRC$2 BIN./a.out TLE2 # 单测试点超时阈值单位秒 rm -f $BIN g -stdc17 -O2 -o $BIN $SRC || { echo 编译失败; exit 1; } for inf in $DATA_DIR/*.in; do base$(basename $inf .in) out_file$(mktemp) timeout $TLE $BIN $inf $out_file 2/dev/null rc$? if [ $rc -eq 124 ]; then echo $base: TLE elif cmp -s $out_file $DATA_DIR/$base.out; then echo $base: AC else echo $base: WA fi rm -f $out_file done脚本逻辑分三块。第一块是编译g -stdc17 -O2 -o $BIN $SRC和前面第 3 章的命令保持一致源码编译失败就整体退出因为数据再全跑一个不能编译的程序毫无意义。第二块是循环for inf in $DATA_DIR/*.in遍历数据目录下所有.in文件basename $inf .in取出不带后缀的文件名比如task1.in会得到task1这样能精确找到同名的task1.out标准答案。第三块是运行和比对timeout $TLE $BIN $inf $out_file限制运行时间超过 TLE 阈值时timeout会杀掉进程并返回退出码 124所以紧接着的[ $rc -eq 124 ]就能判定超时没超时则用cmp -s比对输出文件和标准答案相同判 AC不同判 WA。这里要强调两个替换逻辑。第一cmp -s是严格字节比对评测系统通常会对行尾空白做一定容忍但本地自测严格一点没坏处能逼你把输出格式写精准。第二TLE2只是自测用的保守值正式比赛的时间限制以题目说明为准通常 1 秒到 2 秒如果你本地都要跑 1.5 秒换到评测机同配置上就相当危险。4.3 时间、内存、SPJ、交互题评测参数的四个边界评测系统并不只是跑一遍看输出它还会守着几个资源边界时间、内存、输出文件大小、是否启用 Special Judge。这四个参数在题目里都会写明但很多人只记住了时间限制忽略另外几个导致比赛现场一脸懵。参数常见限制调试时的对照时间限制1s / 2s用time ./a.out data.in测真实耗时内存限制512MB / 1GB用/usr/bin/time -v看 Maximum resident set size输出文件大小通常 50MB 以内用wc -c out.txt看是否异常膨胀SPJ有 / 无有 SPJ 时不能拿cmp当判据要跑评测方脚本时间限制前面已经讲过timeout可以直接兜底。内存限制经常被人忽略递归深、开大数组的程序很容易 MLE。自测时我用/usr/bin/time -v ./a.out in.txt看Maximum resident set size那一行如果接近题目内存上限就得想办法改算法而不是祈祷评测机宽限。输出文件大小是隐藏陷阱有时候代码死循环里疯狂printf在超时之前先输出几个 GB评测系统会直接判输出超限本地看到的是磁盘被写满。自测时用wc -c检查输出文件的字节数一条命令的事。SPJ 和交互题是另一套逻辑。SPJ 题目的评测程序会读你的输出和标准答案然后按自定义规则打分这时候用cmp -s对比文本文件完全是自欺欺人要对齐评测行为就得写一个等效的 SPJ 脚本。交互题更特殊你的程序和评测程序同时运行通过管道或文件互相收发信息除了代码逻辑还要关注刷新输出缓冲区、读入超时这些时序问题。对交互题我的建议是直接用题目提供的 grader 源码在本地编译调试不要自己发明模拟器因为真实评测交互时序很难完全模拟。5. NOI Linux 2.0 评测避坑与常见问题排查5.1 三个直接判零的坑编码、文件名、freopen现象在 Windows 上用记事本或 Dev-C 写好源码拷到 NOI Linux 2.0 里用 g 编译报错一片常见的有stray \357 in program和missing terminating character。原因Windows 文本文件默认带 UTF-8 BOM 头文件开头多了三个不可见字节更普遍的是行尾是 CRLF而 Linux 下编译器只认 LF。BOM 会把第一个#前面的字节当终端字符CRLF 则会让编译器在行尾看到一个\r。这是最典型的跨平台编译翻车。解决在 NOI Linux 2.0 里批量转换两条命令二选一。# 去掉行尾的 \r 并去除 BOM sed -i s/\r$// a.cpp sed -i 1s/^\xEF\xBB\xBF// a.cpp # 或者直接用 dos2unix如果系统有 dos2unix a.cppsed -i是原地修改第一条把行尾\r全部删掉第二条删除文件第一行开头的 UTF-8 BOM 三字节。用 dos2unix 更省事但 NOI Linux 2.0 不一定预装装不了就用 sed 版本。赛前把源码在 Linux 环境里编译一遍就不会遇到这种低级问题。现象明明写了freopen(task.in, r, stdin)程序跑起来却打开失败或者读出来是空的。原因Linux 是严格区分大小写的文件系统题目要求task.in你手上文件名是Task.in或TASK.IN直接打不开还有一种情况是程序的工作目录和输入文件不在同一目录freopen用的是相对路径依赖当前工作目录评测系统切到别的目录执行路径就失效。解决先ls确认文件名精确匹配再在评测脚本或运行命令里用cd切到数据所在目录。最省心的做法是程序不写死路径全部走 stdin/stdout由 shell 重定向输入输出评测脚本里 task.in task.out路径问题就交给了脚本而不是代码。现象程序本地运行一个测试点输出正确交到评测系统 0 分。原因只写了cin.tie(nullptr)忘了freopen样例是从终端手动输入的实际评测时没有终端输入程序直接停在等待输入。解决把样例读取写进文件重定向每道题开头固定加 freopen 模板。#include bits/stdc.h using namespace std; int main() { // 按题目要求改名字评测机用 stdin/stdout 也可以不写 freopen freopen(task.in, r, stdin); freopen(task.out, w, stdout); // 主逻辑 return 0; }5.2 两个跑分不对的坑栈、编译器差异现象递归深度稍微大一点程序秒变 Segmentation Fault小样例正常大样例全挂。原因Linux 默认线程栈大小通常只有 8MB评测系统不会为你的程序提高栈上限。递归深度超过几万层每层栈帧占用会累计到直接踩爆栈空间这不是算法复杂度问题是环境设置在物理层面把你拦住了。解决把深递归改成显式栈做 BFS/DFS或者改成迭代式动态规划。有些编译器扩展能提高栈大小但评测机不一定认所以不要赌。我一般直接把递归深度超过 10 万的代码全部改成非递归写起来稍麻烦但换一个不受限的踏实。现象本地 NOI Linux 2.0 跑通过限时评测机上同数据超时或者输出错位。原因两个常见来源一是评测机 CPU 型号和你的虚拟机不一样二是编译优化差异。NOI Linux 2.0 里自测是虚拟机CPU 虚拟化会损失一部分性能如果本地用 Xcode 或 clang 编译过更是增加一层差异。解决把自测和评测拉到同一个编译选项-stdc17 -O2是保底组合时间余量至少留 50%本地跑 0.6 秒的数据评测机上很容易接近 1 秒。真到临界线时用/usr/bin/time -v看真实耗时再回头优化常数而不是反复重试同一份代码。评测系统的黑匣子只能看到最终分数看不到中间日志你能做的就是把变量管住。6. 赛前最后一天把 Vim 调成竞赛级编辑器赛前当天不适合再学新命令适合做三件确定性的事。第一把 .vimrc 复制到比赛机的~/.vimrc位置然后打开一个模板文件按 F5确认 g 编译路径可用。比赛环境如果锁了主目录权限就手动把需要的配置写进命令行比如vim -c set nu -c syntax on保证基础体验不丢。第二练一次完整的救场流程模拟一个文件意外出现E325: ATTENTION交换文件冲突的场景学会用q退出后用rm .文件名.swp清理这个操作看着简单出问题时手忙脚乱很容易点错。第三记住几个救命命令u是后悔药撤销最近修改:%s/旧/新/g是全局替换改变量名时比手动删改快十倍:cq在编译报错连环时强制退出不保存避免误改代码。我自己的比赛习惯是再配一个对拍脚本用来验证高复杂度算法和暴力解是否一致。把gen.py、brute.cpp、main.cpp放在同一个目录运行下面的循环while true; do python3 gen.py in.txt ./brute in.txt ans.txt ./main in.txt out.txt if ! diff -q ans.txt out.txt /dev/null; then echo 找到了反例见 in.txt break fi done这个脚本的思路是无限生成随机小数据把暴力程序和参赛程序同时跑一遍输出不一致就停下来保存输入数据。注意brute和main都要先编译成可执行文件gen.py负责生成随机但合法的测试数据。调试时先在in.txt上缩小数据规模把反例降到一个能手工推演的大小然后用 Vim 分屏对照代码逐行走查。最后一天还要做一次环境自检用 NOI Linux 2.0 重启一遍确认 Vim 配置还在g 能编译./a.out能运行。有多少人是在考场上第一次发现编辑器打开是黑白的、编译选项不对、文件名带了额外后缀这都不是能力问题是习惯问题。希望这份从 Vim 到评测系统的流程能帮你把变量减到最少把真实的算法水平兑现成分数。本文还有配套的精品资源点击获取 NOI Linux 2.0与Vim评测全指南：从编译环境到避坑细节
简介面向信息学奥赛NOI/CSP选手和教练的速查型PDF手册围绕NOI2.0评测系统、NOI Linux 2.0与Vim编辑器三条主线汇总了从虚拟机安装、系统启动、Arbiter/LemonLime测评操作到代码提交、文件输入输出与常见避坑点等内容适合备赛冲刺或赛前环境自查使用。资源为1个PDF文件压缩包大小253KB内容以精选视频教程、图文指南和工具说明的索引形式呈现目录按评测系统、系统环境、编辑器、C竞赛要求等模块组织便于快速定位所需环节。已有1507人学习下载。手册不仅整理B站实操视频和CSDN保姆级教程还补充了Vim的插入/命令/可视化模式切换、宏录制与播放、跳转指定行等核心操作要点同时覆盖Linux终端常用命令、C内存管理与STL应用等竞赛高频能力能帮助选手减少环境问题干扰把更多精力集中在算法设计与代码实现本身。1. NOI2.0、NOI Linux 2.0、Vim一条评测链路三个闸门NOI2.0评测系统、NOI Linux 2.0、Vim表面看是三份材料实际是同一根链路的三个环节你在 Vim 里写代码在 NOI Linux 2.0 里编译运行最后由评测系统决定你拿多少分。很多选手把精力全压在算法上到了机房却卡在编辑器保存乱码、文件命名不对、评测目录不熟这些小问题上一道明明会做的题直接零分。这份指南要解决的正是从敲下第一行代码到提交评测之间那段没人细讲的路。适合正在备赛的信息学选手、带队的教练以及要搭机房评测环境的运维同学。下面按评测环境、Vim 使用、评测系统操作和踩坑排查的顺序展开每段都给出能直接落地的命令和参数。2. NOI Linux 2.0 评测环境为什么分数只认这一套系统2.1 评测系统的判定逻辑黑盒之外环境一致才是关键NOI Linux 2.0 是信息学竞赛指定的操作系统它基于 Ubuntu 20.04 LTS自带标准 C/C 编译工具链。这套系统看起来只是把 Ubuntu 换了个皮肤但真正值钱的是它把竞赛要用的那一套工具固定在了一个版本上g 编译器、标准头文件、动态库路径、default 的编译标准全部锁死。评测机读的是源码但源码是在一套特定系统里编译成可执行文件的如果选手自己在别的系统上调通到评测机上换个编译器版本行为就可能完全不同。评测系统的判定逻辑本身是黑匣子你把源码交上去系统在受控环境里编译、运行然后用标准输出和标准答案比对。传统题比对的是 stdout交互题比对的是交互过程提交答案题直接比对输出文件。这套流程倒不复杂复杂的是受控环境四个字。NOI 系列比赛明确要求选手在 NOI Linux 2.0 下开发就是要把变量压到最小编译器一致、头文件一致、浮点舍入一致、文件路径规则一致。我的经验是平时训练必须至少在虚拟机里保留一套和评测机同版本的 NOI Linux 2.0写完代码先拿它编译一遍再谈对错。环境差异不是玄学是可复现的事故。我自己就见过在 macOS 上用 Xcode 调得好好的 BFS拿到 Linux 评测机上 MLE也见过用 Windows 记事本存代码交上去编译报stray \357 in program。这些东西和算法水平无关却能把分数直接清零。下面几个环境项赛前要一条条核对。环境项NOI Linux 2.0 常见形态平时自测要做的操作系统Ubuntu 20.04 LTS64 位虚拟机里跑同一版本 ISO编译器g 9.x 系列用 g 而不是 clang编译标准默认 gnu14可显式指定更高标准命令里写-stdc17输入文件题目指定的 .in/.out 文件名自己写 freopen 时逐一核对数据目录评测系统按题目分别隔离本地自测建统一目录2.2 Windows 装 NOI Linux 2.0虚拟机与双系统怎么选很多人的第一台电脑是 Windows装上 NOI Linux 2.0 有两条路虚拟机或者双系统。如果只是平时刷题和复现评测虚拟机一般够用。用 VirtualBox 或 VMware 建一台 Ubuntu 20.04 的虚拟机分配 4GB 内存、60GB 以上动态磁盘安装时选中文简体装完再挂载共享文件夹用来和 Windows 交换源码。虚拟机的缺点是绕了一层硬件CPU 频率和内存带宽跟真机有差距所以它适合验证编译能不能过、语法对不对不适合估算极限数据下的运行时间。双系统是更接近比赛环境的做法Windows 下想装 NOI Linux 2.0 双系统套路并不复杂先给硬盘分出一个空闲分区用 ISO 做启动 U 盘进 BIOS 把启动顺序改到 U 盘然后按安装向导走。两个地方容易出问题一是分区时手滑把 Windows 分区删了没有后悔药二是装完双系统后 Windows 和 Linux 的硬件时钟机制不一样时间会差 8 个小时。前者靠备份数据规避后者装完后在 Linux 里执行timedatectl set-local-rtc 0或者直接在 Windows 里关闭自动同步时间就能消掉。我个人的建议是打算认真打竞赛的选手直接用双系统当主力环境早一天把编辑器、编译命令、文件管理都搬到 Linux 上比赛时少一层手忙脚乱。注意下载 ISO 后先用md5sum或sha256sum校验一遍再装网上源五花八门校验值对不上要么是下载损坏要么是文件被改过。机房批量部署时直接做一份装好的磁盘镜像分发到同配置机器比每台现场安装节省大量时间。2.3 g、C 标准与 Xcode/Vim 的编译差异同一个班有人用 Vim有人用 Xcode平时都能写题但到评测机上结果可能完全不同。Xcode 带的是 clang 编译器NOI Linux 2.0 里用的是 g两者对 C 标准的实现有差异。最典型的例子是pow的重载行为和整型提升规则在 clang 下编译通过的代码换 g 可能报出多个候选函数的模糊重载错误。另一个常见案例是__int128这个是 g 的扩展用 clang 编译时有可能直接报__int128未声明还有#include bits/stdc.h这个万能头在 NOI 环境里存在但依赖的路径和实现跟特定编译器版本绑定换个环境要么没有这个头文件要么内部宏定义不一致。我的建议是日常写题用什么编辑器都可以但赛前一两周必须把主力环境切到 NOI Linux 2.0 或同等版本的虚拟机里用同一条编译命令跑。编译命令尽量固定成一种我一般用g -stdc17 -O2 -Wall -o a.out main.cpp这条命令里-stdc17指定语言标准NOI Linux 2.0 自带的 g 9.x 完整支持 C17-O2是评测常用的优化级别不开 O2 和开了 O2 的程序运行时间差距可能超过一倍最影响比赛的是递归、浮点和编译器自动向量化行为-Wall开启基础警告能提前暴露未初始化变量等问题。-o a.out固定输出名字下面讲 Vim 快捷键和评测脚本时都用这个约定省得到处找二进制文件。3. 用 Vim 写第一份能上评测机的代码从新建文件到跑通样例3.1 一份面向评测的 .vimrc语法、缩进、编码三个方向Vim 默认配置对竞赛不算友好没有行号Tab 宽度是 8语法高亮要手动开最坑的是处理从 Windows 拷过来的 GBK 编码文件时直接显示乱码。这些问题都不影响算法但都会在赛场上消耗你的耐心。我的做法是把一份 .vimrc 固定下来复制到每一台自己用到的机器上下面的配置是我这几年用得顺手的最小集合。 面向 NOI Linux 2.0 的 .vimrc 最小配置 set nocompatible syntax on set number set ruler set tabstop4 set shiftwidth4 set softtabstop4 set expandtab set autoindent set hlsearch set incsearch set encodingutf-8 set fileencodingsutf-8,gbk,latin1 set fileformatsunix,dos set mousea这个文件里每一项都有明确的用途。set tabstop4和set shiftwidth4把 Tab 和缩进都变成 4 个空格这是竞赛代码最常见的缩进宽度也避免不同编辑器里 Tab 显示不一致set softtabstop4让 Backspace 一次删掉 4 个空格而不是只能删一个set expandtab表示按 Tab 键时插入空格而不是真实 Tab 字符防止评测机上的编译器对制表符位置敏感。encodingutf-8配合fileencodingsutf-8,gbk,latin1是让 Vim 能正确打开机房机器上常见的 GBK 源码不至于打开就是一片乱码挽救过不少从 Windows 共享文件夹直接拖过来的文件。set mousea启用鼠标争议比较大有人觉得比赛禁用鼠标有人觉得点选比键盘快。我的态度是键盘流有门槛新手用鼠标能减少误操作先把题做出来最重要。真正上考场如果赛场禁鼠标再临时改成set mouse-a也不迟。3.2 用一条编译命令对齐评测选项g -stdc17 -O2写代码不是问题编译命令才是评测的第一道坎。建议不要在 Vim 里频繁敲完整的 g 命令而是把常用的编译动作映射到快捷键上。上面那节说过-o a.out约定配合 Vim 的nnoremap可以做成一键编译。 一键编译运行F5 编译F6 编译并运行F7 只运行 nnoremap F5 :wCR:!g -stdc17 -O2 -Wall -o a.out %CR nnoremap F6 :wCR:!g -stdc17 -O2 -Wall -o a.out % ./a.outCR nnoremap F7 :!./a.outCR这三行的执行逻辑是先保存当前文件然后调用 shell 执行 g%在 Vim 命令里代表当前文件名所以g -stdc17 -O2 -Wall -o a.out %编译的就是你正在编辑的这份源码。F6 在编译成功后直接用串起./a.out运行这样写是因为只要编译失败就不用浪费时间跑一个不存在的程序。注意这里是 shell 的短路逻辑前面的 g 返回非零退出码后面的命令就不会执行。有个细节值得说明-o a.out固定输出名。很多新手喜欢写成-o 题目名手动敲键盘时没问题但一旦做成 F5 快捷键二进制文件名字会随文件名变化脚本里、对拍里都要跟着改非常容易出错。固定成a.out之后测试命令永远是./a.out评测脚本也只用管一个名字。运行程序前要确认已经编译成功不然跑的是上一次的旧二进制这种翻车最憋屈。3.3 用 Vim 的编译错误跳转和分屏做小样例测试Vim 还有一个常用组合把 g 集成进 Vim 的makeprg编译出错之后直接在错误列表里跳转不用肉眼在滚动输出里找行号。配置如下 把 makeprg 指向 g用 :make 编译 set makeprgg\ -stdc17\ -O2\ -Wall\ -o\ a.out\ % 编译后自动打开错误列表 nmap F5 :wCR:makeCR:copenCR这里makeprg里的\用来转义空格因为 Vim 把整行当成一个字符串传给 shell不转义会在g那里断开。执行:make时 Vim 会解析编译器输出并填进 quickfix 列表:copen打开那个列表光标选中错误条目回车就能跳到对应代码行。对一个几百行的 C 文件来说这个跳转节省的时间非常可观。分屏也是调小样例的利器。我习惯一个屏幕开三块源代码、输入文件、终端。按:split左右分屏:vsplit上下分屏:terminal打开内置终端。Vim 8.2 在 NOI Linux 2.0 里支持终端模拟器不需要切出编辑器就能跑./a.out sample.in。小样例出错时直接在旁边打开输入文件和代码肉眼对照数据找 bug比反复切窗口效率高很多。等代码稳定了再回到单一编辑界面写正题。4. NOI2.0 评测系统使用目录约定、自测脚本和评测参数4.1 评测目录和数据文件怎么组织评测系统接收的是源码文件和题目信息但本地自测时目录乱成一团程序跑起来连输入文件都找不到。这里给出一套能在评测机上落地的目录约定它不是某个官方标准但足够通用也方便和评测脚本对接/home/noi/judge/ ├── data/ │ ├── task1.in │ ├── task1.out │ ├── task2.in │ └── task2.out ├── submissions/ │ ├── player_a/ │ │ └── task1.cpp │ ├── player_a/ │ │ └── task2.cpp │ └── player_b/ └── scripts/ ├── judge.sh └── gen.pydata目录里放题目测试数据命名规则是题号.in对应题号.out成对出现。submissions按选手分目录每个选手目录下放各个题的源码。这样组织有一个好处评测的时候只需要遍历submissions下每个子目录里的task1.cpp配上data/task1.in就能形成完整的评测单元不管手动测还是写脚本都很直接。目录结构定了代码里 freopen 的路径就要围绕当前工作目录设计我一般不看相对路径直接让程序从 stdin/stdout 读写用 shell 重定向喂数据最干净。gen.py是数据生成器比赛前用来造小随机数据测边界用下面会用到。4.2 写一个 judge.sh把每个测试点跑一遍并比对评测系统的核心动作就是编译、运行、比对用 bash 脚本完全可以模拟一版适合赛前在 NOI Linux 2.0 里自测。下面的脚本接受两个参数测试数据目录和选手源码路径然后逐个跑完每个测试点输出 AC/WA/TLE。#!/usr/bin/env bash # 用法: ./judge.sh 数据目录 源码文件 DATA_DIR$1 SRC$2 BIN./a.out TLE2 # 单测试点超时阈值单位秒 rm -f $BIN g -stdc17 -O2 -o $BIN $SRC || { echo 编译失败; exit 1; } for inf in $DATA_DIR/*.in; do base$(basename $inf .in) out_file$(mktemp) timeout $TLE $BIN $inf $out_file 2/dev/null rc$? if [ $rc -eq 124 ]; then echo $base: TLE elif cmp -s $out_file $DATA_DIR/$base.out; then echo $base: AC else echo $base: WA fi rm -f $out_file done脚本逻辑分三块。第一块是编译g -stdc17 -O2 -o $BIN $SRC和前面第 3 章的命令保持一致源码编译失败就整体退出因为数据再全跑一个不能编译的程序毫无意义。第二块是循环for inf in $DATA_DIR/*.in遍历数据目录下所有.in文件basename $inf .in取出不带后缀的文件名比如task1.in会得到task1这样能精确找到同名的task1.out标准答案。第三块是运行和比对timeout $TLE $BIN $inf $out_file限制运行时间超过 TLE 阈值时timeout会杀掉进程并返回退出码 124所以紧接着的[ $rc -eq 124 ]就能判定超时没超时则用cmp -s比对输出文件和标准答案相同判 AC不同判 WA。这里要强调两个替换逻辑。第一cmp -s是严格字节比对评测系统通常会对行尾空白做一定容忍但本地自测严格一点没坏处能逼你把输出格式写精准。第二TLE2只是自测用的保守值正式比赛的时间限制以题目说明为准通常 1 秒到 2 秒如果你本地都要跑 1.5 秒换到评测机同配置上就相当危险。4.3 时间、内存、SPJ、交互题评测参数的四个边界评测系统并不只是跑一遍看输出它还会守着几个资源边界时间、内存、输出文件大小、是否启用 Special Judge。这四个参数在题目里都会写明但很多人只记住了时间限制忽略另外几个导致比赛现场一脸懵。参数常见限制调试时的对照时间限制1s / 2s用time ./a.out data.in测真实耗时内存限制512MB / 1GB用/usr/bin/time -v看 Maximum resident set size输出文件大小通常 50MB 以内用wc -c out.txt看是否异常膨胀SPJ有 / 无有 SPJ 时不能拿cmp当判据要跑评测方脚本时间限制前面已经讲过timeout可以直接兜底。内存限制经常被人忽略递归深、开大数组的程序很容易 MLE。自测时我用/usr/bin/time -v ./a.out in.txt看Maximum resident set size那一行如果接近题目内存上限就得想办法改算法而不是祈祷评测机宽限。输出文件大小是隐藏陷阱有时候代码死循环里疯狂printf在超时之前先输出几个 GB评测系统会直接判输出超限本地看到的是磁盘被写满。自测时用wc -c检查输出文件的字节数一条命令的事。SPJ 和交互题是另一套逻辑。SPJ 题目的评测程序会读你的输出和标准答案然后按自定义规则打分这时候用cmp -s对比文本文件完全是自欺欺人要对齐评测行为就得写一个等效的 SPJ 脚本。交互题更特殊你的程序和评测程序同时运行通过管道或文件互相收发信息除了代码逻辑还要关注刷新输出缓冲区、读入超时这些时序问题。对交互题我的建议是直接用题目提供的 grader 源码在本地编译调试不要自己发明模拟器因为真实评测交互时序很难完全模拟。5. NOI Linux 2.0 评测避坑与常见问题排查5.1 三个直接判零的坑编码、文件名、freopen现象在 Windows 上用记事本或 Dev-C 写好源码拷到 NOI Linux 2.0 里用 g 编译报错一片常见的有stray \357 in program和missing terminating character。原因Windows 文本文件默认带 UTF-8 BOM 头文件开头多了三个不可见字节更普遍的是行尾是 CRLF而 Linux 下编译器只认 LF。BOM 会把第一个#前面的字节当终端字符CRLF 则会让编译器在行尾看到一个\r。这是最典型的跨平台编译翻车。解决在 NOI Linux 2.0 里批量转换两条命令二选一。# 去掉行尾的 \r 并去除 BOM sed -i s/\r$// a.cpp sed -i 1s/^\xEF\xBB\xBF// a.cpp # 或者直接用 dos2unix如果系统有 dos2unix a.cppsed -i是原地修改第一条把行尾\r全部删掉第二条删除文件第一行开头的 UTF-8 BOM 三字节。用 dos2unix 更省事但 NOI Linux 2.0 不一定预装装不了就用 sed 版本。赛前把源码在 Linux 环境里编译一遍就不会遇到这种低级问题。现象明明写了freopen(task.in, r, stdin)程序跑起来却打开失败或者读出来是空的。原因Linux 是严格区分大小写的文件系统题目要求task.in你手上文件名是Task.in或TASK.IN直接打不开还有一种情况是程序的工作目录和输入文件不在同一目录freopen用的是相对路径依赖当前工作目录评测系统切到别的目录执行路径就失效。解决先ls确认文件名精确匹配再在评测脚本或运行命令里用cd切到数据所在目录。最省心的做法是程序不写死路径全部走 stdin/stdout由 shell 重定向输入输出评测脚本里 task.in task.out路径问题就交给了脚本而不是代码。现象程序本地运行一个测试点输出正确交到评测系统 0 分。原因只写了cin.tie(nullptr)忘了freopen样例是从终端手动输入的实际评测时没有终端输入程序直接停在等待输入。解决把样例读取写进文件重定向每道题开头固定加 freopen 模板。#include bits/stdc.h using namespace std; int main() { // 按题目要求改名字评测机用 stdin/stdout 也可以不写 freopen freopen(task.in, r, stdin); freopen(task.out, w, stdout); // 主逻辑 return 0; }5.2 两个跑分不对的坑栈、编译器差异现象递归深度稍微大一点程序秒变 Segmentation Fault小样例正常大样例全挂。原因Linux 默认线程栈大小通常只有 8MB评测系统不会为你的程序提高栈上限。递归深度超过几万层每层栈帧占用会累计到直接踩爆栈空间这不是算法复杂度问题是环境设置在物理层面把你拦住了。解决把深递归改成显式栈做 BFS/DFS或者改成迭代式动态规划。有些编译器扩展能提高栈大小但评测机不一定认所以不要赌。我一般直接把递归深度超过 10 万的代码全部改成非递归写起来稍麻烦但换一个不受限的踏实。现象本地 NOI Linux 2.0 跑通过限时评测机上同数据超时或者输出错位。原因两个常见来源一是评测机 CPU 型号和你的虚拟机不一样二是编译优化差异。NOI Linux 2.0 里自测是虚拟机CPU 虚拟化会损失一部分性能如果本地用 Xcode 或 clang 编译过更是增加一层差异。解决把自测和评测拉到同一个编译选项-stdc17 -O2是保底组合时间余量至少留 50%本地跑 0.6 秒的数据评测机上很容易接近 1 秒。真到临界线时用/usr/bin/time -v看真实耗时再回头优化常数而不是反复重试同一份代码。评测系统的黑匣子只能看到最终分数看不到中间日志你能做的就是把变量管住。6. 赛前最后一天把 Vim 调成竞赛级编辑器赛前当天不适合再学新命令适合做三件确定性的事。第一把 .vimrc 复制到比赛机的~/.vimrc位置然后打开一个模板文件按 F5确认 g 编译路径可用。比赛环境如果锁了主目录权限就手动把需要的配置写进命令行比如vim -c set nu -c syntax on保证基础体验不丢。第二练一次完整的救场流程模拟一个文件意外出现E325: ATTENTION交换文件冲突的场景学会用q退出后用rm .文件名.swp清理这个操作看着简单出问题时手忙脚乱很容易点错。第三记住几个救命命令u是后悔药撤销最近修改:%s/旧/新/g是全局替换改变量名时比手动删改快十倍:cq在编译报错连环时强制退出不保存避免误改代码。我自己的比赛习惯是再配一个对拍脚本用来验证高复杂度算法和暴力解是否一致。把gen.py、brute.cpp、main.cpp放在同一个目录运行下面的循环while true; do python3 gen.py in.txt ./brute in.txt ans.txt ./main in.txt out.txt if ! diff -q ans.txt out.txt /dev/null; then echo 找到了反例见 in.txt break fi done这个脚本的思路是无限生成随机小数据把暴力程序和参赛程序同时跑一遍输出不一致就停下来保存输入数据。注意brute和main都要先编译成可执行文件gen.py负责生成随机但合法的测试数据。调试时先在in.txt上缩小数据规模把反例降到一个能手工推演的大小然后用 Vim 分屏对照代码逐行走查。最后一天还要做一次环境自检用 NOI Linux 2.0 重启一遍确认 Vim 配置还在g 能编译./a.out能运行。有多少人是在考场上第一次发现编辑器打开是黑白的、编译选项不对、文件名带了额外后缀这都不是能力问题是习惯问题。希望这份从 Vim 到评测系统的流程能帮你把变量减到最少把真实的算法水平兑现成分数。本文还有配套的精品资源点击获取