简介面向信息学奥林匹克竞赛选手及编程学习者的指南手册围绕全国青少年信息学奥林匹克评测系统、竞赛专用操作系统和文本编辑器等核心工具提供从环境准备到代码提交的完整指引。资源为单个PDF文件压缩包仅253KB便于离线查阅和快速定位知识点。现有超过一千五百人学习适合正处于备赛阶段的编程竞赛选手、初学者以及希望转向竞赛系统环境进行算法开发的学习者。内容系统梳理了评测系统的代码提交流程、自动测试执行机制以及运行时间、内存消耗等指标含义同时介绍竞赛操作系统中内置的编译器、调试器、编辑器等工具链并针对文本编辑器展开讲解多种模式切换、宏录制、行跳转、文本检索等高频操作。结合竞赛常用的标准模板库、内存管理及调试技巧这份资料能帮助读者缩短环境磨合时间更专注于算法设计与代码实现是一本密度集中的竞赛工具入门手册。1. 为什么 NOI 选手最需要这份「评测系统 NOI Linux 2.0 Vim」三合一指北一个训练了一年 C 的选手在 Windows 上用 VS Code 敲代码跑得飞起第一次参加 NOI 系列赛的机房赛环节面对 NOI Linux 2.0 的桌面找不到编译器入口连 Vim 怎么退出都不知道更别说评测系统那一套 .in/.out 文件规则。这不是段子是每年赛前模拟都会出现的事。标题这份指北解决的就是这个问题把评测系统在测什么、NOI Linux 2.0 怎么装怎么配、Vim 怎么调到顺手这三个问题揉成一份能照着做的实操笔记。适合三类人——正在备赛的选手、带竞赛队的教练、以及第一次负责搭竞赛机房的电教老师。读完之后你至少能本地跑通一次模拟评测并在 Vim 里完成编辑、编译、看错误的完整循环。2. NOI Linux 2.0 装好并调成竞赛状态镜像、分区和三个必做配置2.1 为什么竞赛指定 NOI Linux 2.0 而不是你熟悉的系统NOI Linux 2.0 是 CCF 在 NOI 系列竞赛里指定的操作系统底层是 Ubuntu 20.04 LTS 64 位官方把竞赛需要的编译器、编辑器、调试器和评测工具都集成在镜像里。竞赛指定它的直接原因不是它功能多而是统一评测环境所有选手的代码必须在同一套系统、同一套编译参数下跑出结果否则你在 Windows 上通过、在评测机上失败的场景会变成常态。NOI Linux 2.0 预装的 g、Vim、GVim、GDB 等工具覆盖了「写代码→编译→调试→自测」的完整链路选手不需要额外安装任何软件。很多选手的第一反应是「我在 Xcode 或 VS Code 里写得挺好为什么非要换到 Vim 和命令行」。原因很现实评测环境里没有这些 IDE。你在本机用 C17 甚至更新标准写的代码到了按旧标准编译的评测机上可能直接 CE。平时可以继续用习惯的 IDE 做算法训练但临近比赛一定要切到 NOI Linux 2.0 里走完整流程至少在提交前知道自己的代码在考场环境里能不能编译。另外一个容易被忽视的点是NOI Linux 2.0 是 64 位系统对现代笔记本的 UEFI 启动和硬件支持比早期版本完整得多这也让它在真实机房部署时更省心。2.2 虚拟机还是双系统怎么选分区留多大训练机装 NOI Linux 2.0 主要有两条路选择标准取决于你离比赛多远。虚拟机VirtualBox 或 VMware适合还处于刷题阶段的选手Windows 保持可用NOI Linux 跑在虚拟机窗口里分配 2 核 CPU、4GB 内存、40GB 磁盘就足够跑 Vim、g 和自测脚本。虚拟机的好处是快照可以当后悔药系统改坏了五分钟恢复缺点是图形界面性能和计时精度有损耗不适合做最后的全真模拟。双系统适合赛前一到两个月的封闭训练把机器直接装成 NOI Linux 2.0评测计时更接近考场也能逼自己完全离开 Windows 的舒适区。磁盘上给 Linux 留 80120GB 即可代码和本地评测数据占不了多少空间主要是系统和编译缓存。安装步骤不复杂从官方网站下载 NOI Linux 2.0 的 iso 镜像用 Rufus 或 balenaEtcher 写入 U 盘做启动盘虚拟机则直接新建虚拟机挂载 iso。安装器界面是标准 Ubuntu 风格语言建议选 English避免部分命令行工具在中文 locale 下出现乱码和编码问题。双系统注意先装 Windows 后装 Linux 的顺序引导交给 GRUB 接管装反了会多花不少时间修引导。2.3 系统装完先做三件事换源、装编译器、确认 Vim新装好的 NOI Linux 2.0 第一件事不是打开 Vim 练手而是把软件源换到国内镜像。系统自带的 apt 源在部分网络环境下更新时间很长直接用apt install vim很可能报「package vim is not available, but is referred to by another package. This may mean that the package is missing, has been obsoleted, or is only available from another source.」。第一眼会以为是软件包问题其实根源是软件源索引没更新或镜像地址不可达。把/etc/apt/sources.list里的地址替换成国内镜像再apt update这条报错基本就消失了。# 备份原始源文件改坏了还能恢复 sudo cp /etc/apt/sources.list /etc/apt/sources.list.bak # 把源地址替换为清华镜像NOI Linux 2.0 基于 Ubuntu 20.04代号 focal # 顺手把 security.ubuntu.com 也替换掉否则安全源还是走海外 sudo sed -i s/archive.ubuntu.com/mirrors.tuna.tsinghua.edu.cn/g /etc/apt/sources.list sudo sed -i s/security.ubuntu.com/mirrors.tuna.tsinghua.edu.cn/g /etc/apt/sources.list # 更新索引后安装竞赛基础工具 sudo apt update sudo apt install build-essential vim gdb -ysources.list里常见两个域名archive.ubuntu.com管主源security.ubuntu.com管安全更新后者不换的话apt update还是会卡在慢速源上。build-essential这个元包会带来 g 和 makegdb留给后面对拍和查段错误用。装完分别敲g --version和vim --version看到版本号输出而不是 command not found这一步才算结束。NOI Linux 2.0 预装或装好的 Vim 是 8.x对竞赛写代码完全够用不要花时间去源码编译新版 Vim。提示如果只是备赛不要在新系统上折腾中文输入法和桌面美化。评测和写代码完全用不到输入法桌面环境够用就行花在这些地方的时间都会变成你练题时间的机会成本。3. Vim 用对那十几个命令就够竞赛用一份可抄的 .vimrc 与操作流3.1 竞赛场景为什么绕不开 Vim在 NOI Linux 2.0 上官方提供的编辑器里 Vim/GVim 是最可靠、启动最快、任何配置机器上都存在的选择。评测系统的判定过程对你不可见这决定了编辑器也必须极端可靠——你不想在赛场上赌某个 IDE 的插件会不会崩。Vim 的另一个优势是操作效率从读题到写代码到编译到回跳错误行全程手不离键盘这在时间紧张的赛场上非常值钱。相比平时在 Xcode 或 VS Code 里用鼠标点按钮的节奏Vim 的学习曲线确实陡但竞赛需要的能力子集很小打开文件、插入、删除、保存、跳转、编译、快速回到出错行——大约十几个命令就够用。不少选手问过要不要在 NOI Linux 里装 VS Code比赛规则和机房条件通常不允许而且 Vim 已经预装在每一台机器上不存在环境不一致的问题。我的建议是不要试图把 Vim 学成日常主力编辑器只把它当成考场里那个「不会出错、足够快」的工具。把高频命令练成肌肉记忆比研究花哨插件有用得多。3.2 竞赛向 .vimrc一份直接复制到 ~/.vimrc 的配置下面这份配置我会放到每个备赛环境的~/.vimrc里核心思路是缩进对齐 g 的常见风格、显示行号、用键盘完成编译运行。你可以在考场机器的 Vim 里临时输入这些命令会比你手动敲命令快很多。 显示绝对行号和相对行号方便跳转和标记 set number set relativenumber 语法高亮代码在终端下更易读 syntax on colorscheme desert 统一用 4 空格代替 Tab避免不同机器上 Tab 宽度不一致 set tabstop4 set shiftwidth4 set expandtab 搜索时实时高亮排查大代码里很实用 set hlsearch set incsearch 按文件类型加载缩进规则 filetype on filetype plugin on filetype indent on 统一 UTF-8防止题目样例里的中文注释乱码 set encodingutf-8 set fileencodingsutf-8,gbk,latin1 F8 只编译不运行编译告警可以快速定位语法错误 map F8 :wCR:!g % -o % -O2 -WallCR F9 编译并运行适合不需要重定向的本地小测试 map F9 :wCR:!g % -o % -O2 ./%CR代码里的%在 Vim 中代表当前文件名%是去掉扩展名的文件名所以g % -o %会把a.cpp编译成可执行文件a。-Wall打开常见编译告警很多本来是 WA 的隐藏错误在编译阶段就会被提示。这套配置里没有写set paste因为竞赛中鼠标粘贴的场景不多需要时手动:set paste即可平时保持expandtab反而更安全不会因为混用 Tab 和空格导致评测环境里的缩进解析异常。3.3 高频 vim 命令从打开到改完的完整操作流竞赛场景里最值得练的是一条完整的操作链路而不是零散命令打开文件vim /path/to/a.cpp需要对比两个文件时用vim a.cpp b.cpp:next和:prev切换。进入插入光标移到目标位置按i改完按Esc回到普通模式。删除整行用dd复制当前行用yy粘贴用p。保存退出:w保存:wq保存并退出q!不保存强制退出。比赛结束前离开机房前记得把工作目录里所有改动过的文件都:w一遍。回跳错误行编译报错会给出a.cpp:12:5这样的信息输入:12回车直接到第 12 行。这是 Vim 在竞赛里最值钱的一个命令。全局格式化ggG一键自动缩进整个文件提交前跑一下能让代码可读性提升一大截也避免因为缩进风格被人工复查环节误读。把「改代码 → 按 F9 看运行结果 → 按报错信息回跳」练成肌肉记忆比记住几十个命令更重要。Vim 不像 IDE 那样给你点按钮的余地但它把你和编译器之间的距离压缩到了最短。4. NOI2.0 评测系统的判定逻辑从黑匣子到本地可复现的最小评测脚本4.1 评测系统到底在测什么编译、跑数据、比输出NOI 2.0 评测系统也就是 NOI 系列赛采用的竞赛评测环境本质上是一个批量裁判它用题目规定的编译命令把你的源码编译成可执行文件然后把每个测试点的输入文件喂给程序捕获程序写出的输出文件再与参考答案文件比对。这个过程对你不可见你只能拿到一个最终判定所以它看起来像黑匣子。但黑匣子也有确定的行为逻辑编译失败就是 CE运行崩溃就是 RE超时就是 TLE输出不一致就是 WA全部通过才是 AC。理解这个流程的意义在于评测系统不会因为你的思路巧妙给分它只认输出文件。很多选手在本地用 IDE 的「运行」按钮测试看到黑窗口里的结果就以为没问题实际上评测机根本不看黑窗口——它读取的是.out文件。这就是为什么文件读写规范比代码本身更优先。4.2 代码必须遵守的输入输出规则freopen 与 return 0竞赛代码与平时开发最大的区别是它不读终端标准输入而是直接读写题目指定的文件。每道题会说明输入文件叫什么、输出文件叫什么代码里要用freopen重定向否则评测机找不到你的输出直接判 WA。这是新手翻车频率最高的一条而且翻车时间通常在赛场上代价很大。// NOI 风格的文件读写模板每个程序开篇必写 #include cstdio #include iostream using namespace std; int main() { // 文件名必须和题目要求完全一致大小写敏感 // 输入文件 a.in输出文件 a.out评测机只认这两个名字 freopen(a.in, r, stdin); // 从题目数据文件读入 freopen(a.out, w, stdout); // 把结果写到评测机要找的文件 // 主逻辑从这里开始 // 结束时一定要 return 0否则部分旧评测环境判 RE return 0; }.in用r模式只读.out用w模式覆盖写评测机只检查.out是否存在且内容匹配。return 0不是规范洁癖在某类评测系统里缺失会触发非零退出码进而被误判为 RE。另外a.out这个名字不要改成a.txt或在前面加路径评测机的工作目录就是数据文件所在目录路径写多了反而出错。4.3 本地最小自测脚本把评测判定搬到桌面不需要搭建完整的评测服务一个 shell 脚本就能复现「编译 → 跑数据 → 比对 → 报结果」的流程。这一步的价值在于提交前就发现 CE 和 WA而不是等评测结果出来再改。#!/bin/bash # 模拟 NOI 评测编译 a.cpp对 data 目录下多个 .in 跑一遍并 diff # 用法: ./judge.sh /path/to/a.cpp data/ CPP${1:?请传入源码路径} DATA_DIR${2:?请传入数据目录} SRC_NAME$(basename $CPP .cpp) # 用接近评测机的参数编译不开本地默认的最新标准避免本地过、评测 CE g $CPP -o $SRC_NAME -O2 -stdc11 -Wall || { echo CE: 编译失败请检查语法 exit 1 } # 逐个测试点比对输出ac/wa/tle/re 一目了然 total0 pass0 for infile in $DATA_DIR/*.in; do total$((total 1)) base$(basename $infile .in) ansfile${DATA_DIR}/${base}.ans timeout 1s ./$SRC_NAME $infile /tmp/out.txt if [ $? -ne 0 ]; then echo $base: RE/TLE elif diff -q /tmp/out.txt $ansfile /dev/null; then echo $base: AC pass$((pass 1)) else echo $base: WA fi done echo 通过 $pass/$total 个测试点参数选择说明-stdc11是往届评测中常见的编译标准如果你的目标赛事明确用 C14把这个参数换成 c14 即可timeout 1s模拟单点时间限制防止死循环拖垮整台机器diff -q只报告是否有差异不打印全量输出省时间也省眼睛。跑出 WA 时用diff /tmp/out.txt $ansfile看具体差异在哪一行定位精度比盲改高得多。有了这个脚本训练流程就变成写完代码 → 跑 judge.sh → 按 AC/WA/RE 调整 → 再跑。评测系统不再是黑匣子而是一个本地就能复现的确定性流程。5. NOI Linux 环境与评测常见问题5 条踩坑记录5.1 apt 装 Vim 报「package vim is not available」现象在 NOI Linux 2.0 上执行sudo apt install vim返回package vim is not available, but is referred to by another package. This may mean that the package is missing, has been obsoleted, or is only available from another source安装失败。原因绝大多数情况是没执行sudo apt update软件源索引还停留在系统刻录时的状态包列表里没有 vim 的元数据。另一种常见原因是/etc/apt/sources.list里的镜像地址不可达系统联网失败导致索引为空。解决先执行sudo apt update如果 update 时报连接错误按 2.3 节换成国内镜像源再重试。这条报错本身不是 Vim 的问题是源的问题。被它迷惑去手工下载 deb 包纯属绕远路而且容易引入和系统不兼容的版本。5.2 Windows 上写的代码拿到评测机 CE现象代码在 Windows 上用 VS Code 编译运行一切正常提交到评测系统返回 CECompile Error。原因首要是编译器版本差异——本地默认用了 C17 甚至 C20 的语法而评测系统按 C11/C14 编译其次是文件名问题Windows 文件系统不区分大小写评测机区分AB.cpp和ab.cpp是两个不同文件评测机按题目要求找ab.cpp时找不到。解决从训练第一天起就用 judge.sh 跑本地评测脚本里把标准锁死为-stdc11文件命名严格按题目要求全部用小写字母加数字命名。换行符 CRLF 一般不会导致 CE但会让字符串处理类的题出现诡异的 WA在 Vim 里保存时用:set ffunix转一下更稳。5.3 Vim 里粘贴代码缩进全乱现象在终端 Vim 里用鼠标粘贴一段代码行首缩进一层套一层原有格式面目全非。原因vim 配置里的autoindent和smartindent在插入模式下会对每行自动缩进粘贴文本时这些机制被当成手工输入触发原有缩进上又叠了一层新缩进。解决粘贴前先:set paste粘贴完:set nopaste恢复。更省事的做法是用p从系统剪贴板粘贴绕开终端鼠标的模拟输入。还有一个有效但被很多人忽略的习惯粘贴后立刻ggG全文件重排比肉眼修缩进快得多。5.4 本地脚本全过评测系统 WA现象同样的代码本地 judge.sh 所有点都是 AC提交到评测系统返回 WA 甚至 RE。原因本地脚本和官方评测在数据目录、文件读取方式上有细微差别。最常见的是代码里写死了/home/user/data/a.in这种绝对路径评测机的工作目录不同程序直接找不到输入文件也有代码用了system(pause)、getch()这类非标准交互函数评测环境没有终端可交互。解决代码里的文件读写只写文件名不写路径让程序工作目录与数据目录一致移除所有交互类函数。本地验证时把 judge.sh 的输入输出路径也改成相对路径确保换一个目录也能跑通。5.5 栈溢出被判 RE 而不是 MLE现象程序在本机跑大数据量正常评测系统报 RE错误信息指向段错误segmentation fault。原因评测系统对栈的限制往往小于本机。Linux 默认栈大小约 8MB而部分评测环境可能更低深度递归或大数组在栈上分配就会崩。这类错误在 Windows 上很难复现因为 Windows 的默认栈空间通常大得多。解决把大数组改成全局变量或加static修饰全局区不受栈大小限制递归改成显式栈或迭代。代码写完后额外用一个极限数据在 NOI Linux 虚拟机里跑一遍确认退出码是 0。这是我对所有提交代码的最后一道自检已经帮我拦下过不少次赛场 RE。6. 把 Vim 与评测脚本串起来一键本地评测与数据对拍6.1 一个按键完成保存、编译、评测4.3 的 judge.sh 写好后不要每次手动切到终端去跑直接在~/.vimrc里把 F5 重新映射让评测成为写代码流程的一部分 F5 一键完整评测保存当前文件并调用 judge.sh map F5 :wCR:!./judge.sh % ~/oi/dataCR%会被替换成当前文件路径~/oi/data是存放测试数据和.ans答案文件的固定目录。执行后 Vim 会切到终端显示每个数据点的判定结果按回车返回编辑区。这套映射的意义在于缩短「改代码→看结果」的循环你每调一处逻辑都能立刻知道有没有引入新错误。我在备赛的最后两周每天只按 F5不再手动敲编译命令。6.2 没有标准答案时写个生成器做数据对拍遇到自己出的练习题或回忆题没有.ans文件时 judge.sh 的 diff 环节就无米下锅。常见做法是写对拍器一个数据生成器产生随机小数据两个程序你的解法和一个暴力验证程序分别运行输出逐行比对一旦不一致就说明某一方有错。# 对拍循环生成随机数据分别运行 sol 和 brute输出不同则停下 for i in $(seq 1 1000); do python3 gen.py /tmp/input.txt ./sol /tmp/input.txt /tmp/out_sol.txt ./brute /tmp/input.txt /tmp/out_brute.txt if ! diff -q /tmp/out_sol.txt /tmp/out_brute.txt /dev/null; then echo 第 $i 轮发现差异输入在 /tmp/input.txt break fi donegen.py生成随机小数据要做的是覆盖边界而不是卡时间sol是要测的正解brute是正确性有保障的暴力程序两者必须独立编写避免复制同一个错误。发现差异后保留/tmp/input.txt这一份输入就是调试反例把它喂给两个程序逐步跟踪就能定位问题。我的个人习惯比赛前一周每天只在 NOI Linux 2.0 里练所有代码编译标准锁死 C11每题必跑完整 judge 脚本睡前用数据对拍把所有不确定的题扫一遍。别小看这个习惯它让我在赛场上没有一次因为编辑器操作浪费时间。评测系统仍然是那个看不见的黑匣子但你已经用本地的确定性流程把它所有的脾气摸清楚了。希望帮到你。本文还有配套的精品资源点击获取