企业官网建设流程全解析

简介：Cena评测软件0.8.2是一款面向C、C++、Pascal编程语言的代码评测工具，适用于编程学习、教学批改与算法竞赛场景。该版本压缩包共包含446个文件，包括头文件（h）、静态库（a）、可执行程序（exe）、Pascal源文件（pas）、目标文件（o）以及配置文件（xml）等，整体体积约10.68MB，可满足本地化离线评测需求。软件内置多语言编译与标准样例比对机制，能够精准定位语法错误、逻辑缺陷，并通过预设规范检查编码风格。目前已有433人学习使用，尤其适合需要高频提交作业、模拟竞赛评测环境的用户。借助这套打包好的评测环境，用户可以快速搭建OJ评测流程，减少环境配置成本，更专注练习和排错。

1. CENA评测软件0.8.2是什么：一场评测从半小时到两分钟

做过校内模拟赛或者NOIP赛前训练的人，大概率都经历过那种痛苦：选手交上来几十份代码，你手工一个测试点一个测试点地跑，比对输出，记录分数，再汇总排名。运气好半小时，运气不好一晚上搭进去。CENA评测软件0.8.2就是用来解决这件事的——它是一个跑在Linux下的评测内核，负责把选手程序编译好、逐测试点运行、和标准答案比对、给出得分。它不是一个带网页界面的在线评测平台，更像一个老老实实的批处理引擎：你给它题目数据、标准输出和选手源码，它把分数还给你。适合学校机房的模拟赛、个人刷题的自测脚本，以及那些不想为了一个评测功能就去搭整套OJ的人。

2. 把CENA 0.8.2装进Linux评测机：最小依赖与第一个自测用例

2.1 CENA这类评测程序的工作原理：不是OJ，是评测内核

先要把概念对齐。我们平时说的OJ平台，是“前端提交页面+后端判题队列+沙箱执行器+数据库”一整条链路；而CENA评测软件0.8.2这类的定位要低一层，它只做判题这件事里最关键的那一段：编译选手程序、在受限环境里运行、比对输出、换算分数。

它的工作方式非常朴素：

1. 读取题目目录下的配置信息，知道有哪些测试点、每个测试点对应哪个输入文件、分数权重是多少。
2. 编译选手提交的源码，得到可执行文件。
3. 对每个测试点，用该测试点的输入数据去运行选手程序，同时启动计时和内存监控。
4. 把程序输出和该测试点的标准答案做文本比对，一致就给分，不一致或超时超内存就按规则扣分。
5. 汇总所有测试点分数，写进评测结果文件。

所以你会看到，用CENA这套思路搭评测，真正要处理的只有三样东西：题目数据目录、选手代码、结果读取方式。没有数据库，没有队列，没有用户系统。也正因为轻，它非常适合在局域网机房、单台教师机甚至自己的笔记本上快速铺起来。

我一般不建议第一次用的人直接去改它的源码，而是先把它当成一个黑匣子，摸清楚输入输出约定，用起来就顺了。

2.2 最小安装步骤：configure、make与目录规划

CENA 0.8.2是源码包发行，拿到手之后先看目录里有没有configure脚本。有的话，标准三步走基本就能装上。以下是我在Ubuntu和Debian系系统上常用的最小流程：

# 安装基础编译依赖 sudo apt-get install -y build-essential g++ make # 进入源码目录，生成Makefile ./configure --prefix=/opt/cena # 编译并安装到/opt/cena make sudo make install # 验证可执行文件是否生成 ls -l /opt/cena/bin/cena /opt/cena/bin/cena --version

逻辑说明：configure的--prefix参数决定安装位置，我习惯装到/opt/cena，这样和后面题目数据、评测结果目录放在一起，路径干净。make做编译，如果系统缺依赖，这里会报错，最常见的是缺libpcre或者zlib，装上开发包再重跑就行。

参数说明：--prefix不写的话默认落在/usr/local，也能用，但升级和清理都不方便。我建议固定一个目录，方便后面写评测脚本的时候引用绝对路径。

装完以后，需要规划一个工作根目录。常见做法是建三个目录，各管一摊：

mkdir -p /opt/cena/problems # 每道题的目录放这里 mkdir -p /opt/cena/submissions # 选手提交的源码放这里 mkdir -p /opt/cena/results # 评测结果输出到这里

这样做的原因是CENA的评测流程只认路径不认“项目”，目录规整了，后面批量评测和成绩汇总才能用脚本扫目录完成。

2.3 自测：用一道Hello题验证评测链路通不通

装完环境第一件事，不是急着配比赛题，而是先用最简单的一道题验证整条链路。我通常会临时建一个hello目录，放一组只有1个测试点的数据。

# 创建hello题目目录，data目录存测试数据 mkdir -p /opt/cena/problems/hello/data # 写一个标准输入程序：读一个整数，输出它的两倍 cat > /opt/cena/problems/hello/solution.cpp << 'EOF' #include <iostream> int main() { int x; std::cin >> x; std::cout << x * 2 << std::endl; return 0; } EOF # 生成测试数据：输入文件1.in，标准输出1.out echo "21" > /opt/cena/problems/hello/data/1.in echo "42" > /opt/cena/problems/hello/data/1.out

逻辑说明：题目目录下建data子目录放测试数据，这是CENA约定的数据组织方式。solution.cpp是这个阶段手工写的参考解法，用于验证评测端到端能不能跑通。1.in和1.out的命名和后续配置文件里的映射一致。

参数说明：测试点的编号从1开始，输入输出成对出现。这里故意用21和42，方便肉眼确认评测结果确实读到了数据并在运行选手程序，而不是空跑一场。跑通这个hello题，才说明编译、运行、比对三个环节都正常；这步过了，才有资格谈后面配难题。

3. 配好一套题的料：题目目录、testdata.ini与逐项参数

3.1 题目目录的标准布局：数据、配置、答案各归其位

一套能被CENA 0.8.2正常识别的题目，目录结构是有讲究的。我见过不少新手把输入输出文件散落在各种地方，导致评测时找不到测试点。按下面的布局来做，基本不会出问题：

/opt/cena/problems/p1001/ ├── data/ │ ├── 1.in │ ├── 1.out │ ├── 2.in │ ├── 2.out │ ├── 3.in │ └── 3.out └── testdata.ini

说明一下这个布局里的约定：data目录只放测试数据，输入文件后缀.in，输出文件后缀.out，同一测试点编号统一。testdata.ini放在题目根目录，是整个题目的配置文件。CENA在评测一道题时，会根据这个ini文件去data目录逐个找对应文件，如果文件缺失，这个测试点会直接判为无法评测，而不是跳过。

一个我踩过很多次的细节：数据文件的编号一定要连续。比如你有1.in、2.in、4.in，中间断了3.in，评测系统处理到异常编号时的行为五花八门，有的直接停止这题评测。所以我的习惯是，生成数据后先跑一个脚本检查编号连续性，再开始配置。

3.2 testdata.ini逐项拆解：分数、时限、内存与文件映射

testdata.ini是CENA这套评测体系的灵魂。它决定了一道题有多少个测试点、每个测试点多少分、程序运行时间限制多长、内存限制多大。下面给一份完整的示例，以3个测试点的题目为例：

[problem] name=p1001 time=1000 memory=256 score=100 checker=none [test1] input=1.in output=1.out score=30 time=1000 [test2] input=2.in output=2.out score=30 time=1000 [test3] input=3.in output=3.out score=40 time=2000

逻辑说明：[problem]段的name是题目标识；time是默认时间限制，单位毫秒；memory是默认内存限制，单位MB；score是本题总分。[test1]到[test3]每个段描述一个测试点，input和output指定文件在data目录里的名字，score是当前测试点分值，time可以单独覆盖默认时间限制。

参数说明：所有score加起来必须等于[problem]段的总分，否则汇总时可能出现总分对不上的情况。time按毫秒给，1000就是1秒。memory单位是MB，这里的256代表256MB。这个单位很多人看字面以为是字节，后面专门讲，这是最坑的地方之一。

关于checker参数，不配的时候默认做全文本比对。如果想用特判（比如输出浮点数、只比对答案的一部分），这里填spj，同时在题目目录放一个特判程序。对绝大多数标准答案固定的题，checker=none就够用。

3.3 Special Judge的接入方式：什么时候需要、怎么约定

Special Judge（特判）在CENA 0.8.2里不是一个内置功能，而是通过约定接口实现。当一道题的答案不唯一，或者只要求“包含指定内容”时，就需要用特判。典型场景比如输出两个可行解、精度误差允许在1e-6以内的浮点数答案。

接入方式我一般是三件套准备：

1. 测试点输出文件里不再放完整答案，而是放判题所需的参考数据。
2. 写好特判程序，编译成可执行文件，按约定读取选手输出和测试点信息。
3. 在testdata.ini中把checker设为spj。

常见的特判程序约定是这样的：

#include <iostream> #include <fstream> #include <cmath> using namespace std; int main(int argc, char* argv[]) { // argv[1]是选手输出文件，argv[2]是标准输出文件 ifstream user(argv[1]); ifstream answer(argv[2]); double a, b; user >> a; answer >> b; if (fabs(a - b) < 1e-6) { return 0; // 判为正确 } else { return 1; // 判为错误 } }

逻辑说明：特判程序通过命令行参数拿到两个文件路径，一个是选手的输出，一个是标准答案。程序内部的判断逻辑完全自定义：返回值0表示通过，非0表示不通过。这个约定简洁，也方便移植到其他评测环境。

参数说明：1e-6是浮点比较的容忍误差，具体数值得看题目要求。很多几何题要求1e-8，你如果写成1e-6，部分精度要求高的数据就会误判。建议建题时把精度要求写进题面，避免争议。

接入特判时有个容易翻车的细节：标准输出文件1.out在特判模式下可能不再是最终答案，而是参考起点，特判程序需要自己处理“哪些内容该读、哪些内容不该读”。如果特判程序写挂了，所有测试点都会变成RE，而且是评测端RE，选手那边完全复现不了那种。

4. 从选手源码到分数：一条完整的CENA 0.8.2评测流水线

4.1 编译选手代码：参数选择与常见失败信号

评测第一步永远是编译。这一步做不好，后面全是空中楼阁。选手交上来的代码格式五花八门，有些人是.cpp，有些人命名是main.cpp，有些还有文件读写残留。我一般会先按题目要求统一重命名，再执行编译：

# 进入选手提交目录 cd /opt/cena/submissions/player1 # 用-O2优化编译，默认C++17标准 g++ -O2 -std=c++17 -o program main.cpp -lm

逻辑说明：-O2是竞赛标配的优化级别，能保证程序运行速度接近真实比赛环境。-std=c++17是当前比较通用的标准，如果题目年代较早，老代码可能用到C++98的语法，随后需要换成-std=c++98再编译一次。-o program指定生成的可执行文件名称，评测阶段统一用这个名字。

参数说明：-lm是链接数学库，用了<cmath>的程序经常需要它；如果编译命令里漏了，本地跑没问题，评测机上可能爆出一堆undefined reference to 'sqrt'。这种报错给选手的提示往往很隐晦，你作为评测管理端要第一时间判断出来是编译命令的问题，而不是选手代码的问题。

编译失败时，日志要留档。我会把编译错误输出重定向到文件，这样给选手反馈时能精确指出是哪一行语法错误：

g++ -O2 -std=c++17 -o program main.cpp 2> compile_error.log # 检查日志文件是否为空，非空即编译失败 if [ -s compile_error.log ]; then echo "Compile Error" fi

这里-s compile_error.log的-s是判断文件非空的测试条件，非空代表编译过程产生了错误信息。把编译错误输出流和正常输出流分开，是避免把错误信息混进评测日志的关键。

4.2 逐测试点执行与比对：一条评测循环的核心逻辑

编译通过之后，真正的评测循环才是重头戏。CENA评测软件0.8.2的核心执行逻辑可以用下面这条bash脚本概括。这里以刚刚配置好的p1001为例：

#!/bin/bash # 评测循环：逐测试点运行选手程序并比对 PROG=/opt/cena/submissions/player1/program DATA_DIR=/opt/cena/problems/p1001/data RESULT_DIR=/opt/cena/results/player1 mkdir -p $RESULT_DIR # 从testdata.ini里提取测试点总数，这里手工指定为3 for i in 1 2 3; do INPUT=$DATA_DIR/$i.in OUTPUT=$DATA_DIR/$i.out USER_OUT=$RESULT_DIR/$i.out # 限制运行时间2秒，输出文件写入用户目录 timeout 2 $PROG < $INPUT > $USER_OUT 2> $RESULT_DIR/$i.err # 根据退出码判断运行结果 EXIT_CODE=$? if [ $EXIT_CODE -eq 124 ]; then echo "test $i: Time Limit Exceeded" continue fi # 比对输出文件和标准答案，忽略行尾空白和末尾空行差异 if diff -Bb $USER_OUT $OUTPUT > /dev/null 2>&1; then echo "test $i: Accepted" else echo "test $i: Wrong Answer" fi done

逻辑说明：这个循环做五件事——构造输入输出路径、限制运行时间、执行选手程序、判断是否超时、比对输出。timeout 2表示最多运行2秒，退出码124是timeout命令特有的超时标记。diff -Bb中-B忽略末尾空行差异，-b忽略行尾空白差异，这样选手输出就算多一个空格或少一个空行，也不会被判错。

参数说明：timeout的时间单位是秒，而testdata.ini里的time单位是毫秒，转写脚本时别混。2秒在ini里要写作2000。-Bb这个参数组合是NOI系列评测的通用宽容策略，但如果你就是想严格判空格差异，删掉-b即可。

4.3 读懂评测结果：AC/WA/TLE/MLE/RE的行话与排查方向

评测结果的标准缩写，新手项目管理者和选手都要门儿清。这些缩写不是CENA独有，而是整个竞赛评测体系通用的语言，搞清楚它们，才能快速定位问题。

我评判一道题的配置是否合格，不是看题目本身难不难，而是看这几种结果在评测时能不能被稳定复现。如果一个选手代码在评测机上RE，在自己机器上正常，优先怀疑评测运行环境（比如栈空间限制、内存限制）和本地环境不一致。

RE在CENA这类评测系统里有一个特别常见的来源：程序试图写超出内存限制的数据，比如申请了一个超大数组后访问越界，被系统杀掉了，表现就是RE而不是WA。排查时不能只看输出对不对，还要看程序退出时的信号类型，这就是$RESULT_DIR/$i.err这个文件派用场的地方。

5. CENA 0.8.2避坑清单：五个让评测结果失真/翻车的常见坑

5.1 换行符的坑：CRLF让你全题零分

现象：选手在Windows本地写代码，输出正常，交到评测机上全题WA，一分没有。选手在评测机上重新编译一次，还是WA。

原因：Windows下编辑的源文件和输出文件用的是CRLF换行（\r\n），而Linux评测环境用的是LF换行（\n）。当选手程序里直接吃入了带\r的数据，或者输出了带\r的内容，diff比对时字符串后面多出的那个\r字符就会导致比对失败。

解决：评测前统一用dos2unix处理选手代码文件：

dos2unix /opt/cena/submissions/player1/main.cpp

这个坑最讨厌的地方在于，它不在编译报错里体现，也不在运行报错里体现，只有比对阶段默默失败。处理完换行符最好再跑一遍评测，确认分数变化。

5.2 内存限制的单位：MB还是字节，差了128倍

现象：一道题内存限制256MB，选手开了一个200MB的数组，按理说完全在限定内，但评测结果出现MLE。本地运行内存占用也就230MB，怎么测都不超。

原因：CENA评测软件0.8.2的testdata.ini里，memory参数默认以MB为单位，256即256MB。但如果某个版本的评测模块在内部转换时按字节处理，比如把数值当作字节数直接传给系统接口，那么256字节的程序根本跑不起来，表现就是全MLE。

解决：看清自己所用版本的约定。我自己的习惯是在配置里写256，然后用一个故意申请300MB内存的程序做基准测试，观察评测系统给不给MLE，用实测倒推单位。这比翻源码、找文档可靠得多。

5.3 数据文件名角标错位：1.in对上了2.out

现象：某道题前两个测试点AC，第三个测试点开始全WA，叹号数据也过不了，但手动拿3.in跑选手程序，输出分明和3.out一致。

原因：testdata.ini里第三个测试点的input或output写错了名字，比如input=3.in写成了input=2.in，选手程序跑的是第2个数据，比对的却是第3个答案，逻辑错位，结果当然错乱。手动跑的时候你是拿对的同名文件测，自然复现不了。

解决：写一个轻量检查脚本，逐测试点读取ini中的映射，确认每个input、output配置都能在data目录下找到对应文件：

# 检查data目录中文件是否存在 awk -F= '/input|output/ {print $2}' testdata.ini | while read f; do if [ ! -f "data/$f" ]; then echo "MISSING: $f" fi done

这个坑常见于题目数据量大、手工维护testdata.ini的时候，复制粘贴把上一行的文件名带了过来。花钱花时间造的数据，毁在一个文件名上，很不值。

5.4 全过样例却全WA：选手把文件读写写死在程序里

现象：选手报告本地所有样例都通过，评测结果却全WA，连最简单的一个测试点都不给过。把评测端生成的1.out拿给选手看，里面是空的。

原因：选手代码里写了freopen("input.txt", "r", stdin)或ifstream in("data.in")，程序运行时要到当前目录找文件，评测环境下当前目录是选手工作目录，没有这个文件，程序直接读失败，输出空文件，或输出异常内容。

解决：评测时不要假设选手会遵循“标准输入输出”约定，在评测打包脚本里先扫描一下源码，发现文件读写就往当前目录丢一个空壳文件兜底，或者直接判定为不合规。实战中，竞赛题面明确写了“标准输入输出”，但总有人不读，或者从旧代码模板里带了出来。

让评测系统快速暴露这类问题的方法很简单：第一个测试点就放最弱的数据，断言程序有有效输出。如果第一个测试点就全WA且输出为空，优先查文件读写。

5.5 行尾空格与多余空行：diff策略没对齐

现象：选手程序输出结果在视觉上和标准答案完全一致，但评测判WA。你手动用cat看两边输出，看不出任何区别，一对字节才发现差异。

原因：评测端的比对策略不同。diff -Bb宽容处理行尾空格和末尾空行，但有些配置或特判程序用的是逐字节比对，那么一个末尾空格就足以让整题翻车。

解决：确认配置文件用的是否是保持-Bb宽大策略。如果题面没有刻意要求严格模式，我强烈建议宽容。因为对于大多数竞赛题，行尾空格和空行差异不是选手算法问题，不应该扣分。题面写上“以评测系统判定为准”这句话，胜过后面对着一堆WA反复解释。

6. 验证新题配置的最后一公里：随机对拍与批量校对

一道新题配完，最危险的不是数据弱，而是配置本身有坑。我吃过一次大亏：自己配的新题，数据生成脚本写错了边界，导致第一版标准答案本身就是错的，比赛当天四十多人全在WA，后来查出来是标准程序的问题。从那以后，我每配一道题，都会做一轮随机对拍。

做法很简单：写一个暴力但逻辑简单的验证程序和一个随机数据生成器，然后生成大量小数据，跑一遍CENA评测，同时把暴力程序的结果拿来和标准答案比对：

# 随机生成测试数据并交给CENA评测 for i in $(seq 1 10); do python3 gen.py > /opt/cena/problems/p1001/data/test.in # 用暴力程序生成标准输出 ./brute_force < test.in > /opt/cena/problems/p1001/data/test.out # 跑一次评测，确认标准程序得分 ./run_judge.sh p1001 test.in test.out done

逻辑说明：这个脚本的核心思想是让“标准答案”本身先经过暴力程序校验。如果标准程序和暴力结果在小数据上不一致，说明标准程序有问题，评测下一百遍都没意义。用随机数据反复确认一致后，题目的正确性才有保障。

参数说明：gen.py是随机数据生成器，数据规模要小，这样暴力程序跑得快，才能在短时间内完成几十上百组交叉验证。数据规模一大，暴力程序先超时，验证就卡壳。

我还给自己加了一道保险：所有新题正式使用前，拿一台不联网的机器做一次全流程模拟赛，让一个不参与出题的人当“小白鼠”选手，提交一份参考解法，全程观察评测日志。这一步能暴露出权限问题、路径问题、数据遗漏等各种配置阶段发现不了的细节。CENA这类评测软件本身不复杂，配置链路才是一场比赛成功与否的关键。希望这些从实战里淌出来的习惯，能帮你少走几趟夜路。

本文还有配套的精品资源，点击获取