OJ判题规则与卡分排查指南：评测机工作原理与丢分原因定位

前几天有个朋友甩给我一张截图，问：一道基础计算题卡在 分，本地试了十组数据全对，交上去就是上不去，判题规则是不是有问题？我看了眼他的提交记录，第一反应就是——这又来了。这个问题我在各个刷题群里见了不下几十次，每次都要从头解释一遍评测机的工作原理。今天干脆把这类"卡分"问题的排查思路完整写一篇，从判题规则的基本逻辑讲起，到具体怎么定位丢分原因，再到我自己的踩坑复盘。不管你是刚接触 OJ 的新手，还是被某道题卡到怀疑人生想骂评测系统的老刷题人，这篇都能给你一个相对完整的排查框架。

先给结论：判题规则本身出 bug 的概率极低，你卡在某个分数上，几乎一定是你的程序在某些测试点上没过，而不是评测机"看你不顺眼"。但这个结论背后的逻辑链挺长的，我们一点点拆。

1. 卡分的第一反应：大多数人都把"判题规则"当成了替罪羊

1.1 评测机的打分本质：不是"大体对"，而是"每个测试点都对"

很多人对在线评测的理解停留在"对就是对，错就是错"，这种二分思维在一些交互题或简单平台上成立，但在绝大多数 OJ 上，更准确的说法是：你的程序必须在评测机预设的若干个测试点上全部输出正确结果，才能拿到满分。

举个例子：一道题总分 100 分，评测数据分成 10 个测试点，每个测试点 10 分。你提交后如果只过了前 3 个点，得分就是 30 分。你本地随便造了几组数据跑一遍，全对，于是你觉得"程序没问题，是判题规则有问题"——但问题在于，你造的那几组数据，大概率覆盖的只是第 1 个或第 2 个测试点能覆盖的场景。

样例全过只能说明你拿到了"送分点"，后面那些测试点里的边界情况、大数据量、特殊输入，才是真正决定你能不能 AC 的关键。所以第一个要建立的认知是：评测机不会因为你"思路大体正确"就给你分，它只看每个测试点的输出是否与标准答案完全一致。

1.2 部分分的真正来源：数据点加权、子任务结算与 Special Judge

那"部分分"到底从哪来的？主要有三种机制。

第一种是数据点加权。每个测试点分值可能不同，简单的样例点可能只占 5 分或者 10 分，坑爹的数据点可能值 20 分甚至 30 分。你卡在某个分数，可能就是其中一个分值较高的测试点挂了。

第二种是子任务结算。这种在竞赛类平台非常常见：数据按数据范围分成几档，比如 1~3 号测试点 n ≤ 100，暴力就能过；4~6 号测试点 n ≤ 10^5，需要优化算法；7~10 号测试点 n ≤ 10^9，必须用数学公式 O(1) 出答案。你如果只写了暴力版本，那么恭喜你，你就是那个"卡在三十分"的人。这是基础计算题卡分最常见的原因之一，不是判题规则搞你，是题目设计者故意把数据分档，考察你能否根据数据范围选对做法。

第三种是 Special Judge。这类题型的判题规则比较特殊，不要求输出与标准答案逐字符一致，而是由一个特判程序检查你的输出是否在误差范围内。比如答案允许误差 1e-6，你的程序输出 3.1415926，标答是 3.1415927，也算对。但要注意，SPJ 通常只出现在浮点数精度题、构造题或方案验证题里，一道普通整数计算题大概率不会启用 SPJ，所以别指望它能救你。

2. 基础计算题里的隐藏杀手：越简单的题目，边界越要命

2.1 数据范围不是写着玩的：int 溢出、长整型与取模时机

我见过太多人死在"看起来很简单"的计算题上，原因不是算法不会，而是从头到尾没把数据范围当回事。

比如一道题告诉你 a 和 b 的范围都是 [-10^9, 10^9]，让你输出 a + b。你信心满满写了：

cpp复制#include <iostream>
using namespace std;
int main() {
    int a, b;
    cin >> a >> b;
    cout << a + b << endl;
    return 0;
}

本地测试 1 + 2、3 + 5 全对，交上去却卡分。为什么？因为 int 的最大值是 2147483647，而 a + b 的最大值是 2000000000，看着没超？但如果题目范围是 [-10^9, 10^9]，两个数相加最大正好是 2000000000，确实不超 int。可如果范围是 [-10^9, 10^9] 的乘法呢？乘积最大是 10^18，远超 int，甚至超了 32 位。这种题你要是用 int 存中间结果，评测数据里只要出现一个大数测试点，直接 WA。

所以看到数据范围的第一步，就是判断每个变量、每个中间计算应该用什么类型。C++ 里该用 long long 就用 long long，Java 里该用 long 就用 long，Python 虽然没有溢出问题，但涉及浮点数时又会有另一套麻烦。

还有一个常见坑是取模。题目说"输出答案对 10^9+7 取模"，有些人在计算过程中先把两个 int 相乘，乘完才发现溢出，这时候才转 long long 已经来不及了。正确做法是每一步计算都转成 long long，或者在乘法前先强转。这是基础计算题里最经典的"中间值溢出"问题。

2.2 浮点数的"魔鬼精度"：为什么你的答案和标答一模一样却是 WA

如果是浮点数计算题，那坑就更多了。

首先是输出格式。有的题要求"保留两位小数"，你用 cout 默认输出了一长串小数，哪怕数值是对的，评测机按字符串比对直接判你 WA。反过来，如果标答输出的是 3.14，你输出 3.140，在非 SPJ 模式下也可能被判定为格式错误。所以做题前一定看清输出要求：保留几位小数、是否四舍五入、要不要带空格。

其次是浮点数本身的计算误差。比如 1.0 / 3 * 3 的结果在很多语言里不是 1，而是 0.9999999999999999。如果你把浮点数用 == 直接比较，或者在输出时没有做任何容差处理，在某些测试点上就可能因为最后一位小数差异被判 WA。这个问题在 Python、C++、Java 里都会出现，只是程度不同。

如果是 SPJ 题目，判题规则会允许一定误差，一般 eps 是 1e-6 或者 1e-9。这时候你的输出只要在标答附近就能过。但如果不是 SPJ，你输出的每一个字符都得和标答一致，多一个空格都不行。这也是为什么有些题你本地跑出来"看起来很对"，交上去却卡分。

2.3 多组输入与 EOF 处理：一道题卡半分的最高频原因

"多组输入"这四个字，坑了无数人。

有些基础计算题的题目描述是"输入包含多组测试数据，每组占一行，处理到文件结束"。结果很多新手只写了一次读入逻辑，程序跑完一组就退出。样例只有一组数据，所以样例过了，但评测机一跑后续的数据，程序直接结束没输出，后面几个测试点全挂。

C++ 写法应该是：

cpp复制int a, b;
while (cin >> a >> b) {
    cout << a + b << endl;
}

C 语言则是：

c复制while (scanf("%d%d", &a, &b) != EOF) {
    printf("%d\n", a + b);
}

还有一种固定结束标记的多组输入，比如"输入 0 0 时结束"。很多人忘了在处理循环里判断这个结束条件，结果评测机在读到 0 0 时你还在傻乎乎地输出一个 0，于是最后一个特殊测试点挂掉，卡掉你 10 分。这类问题低调但致命，我见过太多人卡在"差一点满分"上。

3. 动手模拟一次判题：在本地复现评测机的完整检查流程

3.1 先过"样例三件套"：复制粘贴、肉眼比对、diff 定生死

当你怀疑判题规则有问题的时候，不要急着骂评测机，先把自己当成评测机跑一遍完整流程。

第一步，把题目给的样例输入原样复制到一个文件里，然后跑你的程序。注意是"原样复制"，不要手敲，因为你很可能在某个不可见字符上出错——比如样例里有个制表符，你手敲成了空格，结果你的程序读进来的数据就不对了。这种错误肉眼几乎看不出来，但程序行为会变。

第二步，把你的输出和标准输出放在一起，用肉眼逐字符比对。重点看这些地方：最后一行的末尾有没有换行？数字之间是空格分隔还是换行分隔？有没有多余的输出（比如调试 printf 没删干净）？这些看似无关紧要的差异，在评测机眼里就是非 AC 的唯一理由。

第三步，如果输出文件比较大，直接用 diff 命令对比你本地的输出和下载下来的样例输出。Linux 和 macOS 用户直接用终端，Windows 用户可以用 PowerShell 的 Compare-Object 或者干脆装个 Git Bash。diff 会精确列出每一处不同，省去你肉眼盯屏的折磨。

3.2 暴力对拍：让笨办法帮你找出所有边界差异

如果样例过了但仍然卡分，那就需要上"对拍"了。对拍是目前刷题圈里最朴实也最有效的查错手段，尤其适合你有一个"暴力但保证正确"的写法和一个"高效但可能存在边界问题"的写法时。

具体流程是：

1. 写一个绝对正确的暴力版本（哪怕复杂度是 O(n^3)，只要 n 小的时候结果对就行），命名为 brute.cpp。
2. 写一个你要提交的版本，命名为 solve.cpp。
3. 写一个随机数据生成器，生成覆盖各种边界的小数据，命名为 gen.py。
4. 写一个循环脚本，每次生成一批随机数据，分别跑两个程序，然后比对输出。

一个最简单的 bash 对拍循环长这样：

bash复制for i in $(seq 1 10000); do
    python3 gen.py > input.txt
    ./brute < input.txt > output_brute.txt
    ./solve < input.txt > output_solve.txt
    if ! diff -q output_brute.txt output_solve.txt > /dev/null; then
        echo "Found difference at round $i"
        cat input.txt
        break
    fi
done

如果你的提交版本和暴力版本在某个随机数据上输出不一致，恭喜你，你找到了那个让评测机给你扣分的测试点。接下来就是对着这个反例，去 debug 你的边界处理。

对拍特别适合找"看似正确但某个特殊情况处理错误"的逻辑 bug。当然，如果题目本身没有"暴力可行"的解法，或者数据生成器很难写，那对拍就不太适用了，但对基础计算题来说，对拍几乎是万能武器。

3.3 特殊输入自测：0、负数、最大值、空数据一个都不能少

除了随机对拍，还要把边界值一个个手工测一遍。我总结过一个必测清单：

• 最小规模：n = 0、n = 1、n = 2。很多题目在 n = 0 或只有一行数据时，程序会走到意想不到的分支。
• 负数：负数参与加减乘除时，你有没有考虑整除的舍入方向？C++ 里 -5 / 2 的结果是 -2，而有些题目想让你向零取整，这就有得说了。
• 数据类型边界：int 的最小值 -2147483648，最大值 2147483647，long long 的边界同理。把这两个值丢进去算一遍，看看会不会溢出、会不会在取绝对值时出问题。
• 只有一组数据和大量重复数据：前者能暴露初始化顺序问题，后者可能让你的算法复杂度露馅。
• 超大输入：自己生成一个接近题目上限的数据，跑一遍看时间和内存是否爆掉，顺便确认输出文件大小在合理范围内。

这一类自测看起来很笨，但能过滤掉绝大多数"样例过、评测挂"的问题。而且说实话，等你把 0、最大值、负数都跑通了，你对这个题目本身的理解也会上一个台阶。

4. 从判题规则反推命题人意图：读懂这些你就知道分丢在哪了

4.1 判题结果的五种下场：PE 从哪来、RE 代表什么

判题规则里有一整套状态码，很多人只认识 AC 和 WA，导致看到其他状态一头雾水。这里把最常见的几种列一下，你就知道评测机到底在说什么了。

• AC（Accepted）：所有测试点通过，满分。
• WA（Wrong Answer）：输出结果错误。这有两种可能，一是你的答案在某组数据上确实不对，二是你的输出格式和标答不一致，但当前 OJ 没有单独区分 PE。
• PE（Presentation Error）：输出格式错误，常见于多加了空格、少打了换行、最后多了一个空行等。有些老 OJ 会把它单独列出来，有些则直接算 WA。遇到 PE 别慌，这几乎是"你离 AC 只差一个空格"的意思。
• TLE（Time Limit Exceeded）：超时。别急着骂评测机慢，先看看你的算法复杂度是不是在该用 O(1) 公式的地方写了个 O(n) 循环。
• MLE（Memory Limit Exceeded）：超内存。多半是数组开太大，或者递归深度过大爆栈。
• RE（Runtime Error）：运行时错误。数组越界、除零、栈溢出、空指针访问，都会导致这个结果。RE 在基础计算题里常出现的原因就是数组开小了或者没考虑除数为零的测试数据。
• CE（Compilation Error）：编译错误。本地能编过不代表评测机能编过，评测机的编译器标准和版本可能跟你本地不一样。

理解这些状态码之后，你再看到"卡在某分"，心里大概就有方向了：如果结果是 WA，那就是数据对比不过；如果结果是 RE，那是程序崩溃；如果结果是 TLE，那是效率不够。

4.2 卡分症状与原因对照表：对着症状找病根

我把常见卡分现象做了一张对照表，你可以直接对着自己的情况进行体检。

这张表不是什么权威文档，是我在实际刷题和帮人看代码过程中总结出来的经验映射。你会发现，绝大多数卡分问题最后都能归到三四类原因里，根本没有那么玄乎。

4.3 评测系统的宽容与苛刻：输出重定向、编译警告与时限波动

再聊几个和判题规则直接相关的细节，这些往往是新手完全 unaware 的坑。

第一，文件读写方式。有些题目的输入输出不是标准输入输出，而是明确要求从文件读、往文件写，比如"从 sum.in 读入，输出到 sum.out"。这时候你要是用标准输入输出，评测机会直接认为你没有输出，给你 0 分或全 WA。反过来，如果题目没要求文件读写，你却想当然地加了 freopen，也会出问题。正确做法是严格看题目的输入输出描述，两行字就能避免一个通宵的卡分。

第二，编译器差异。你在 Windows 上用 VS Code 配的 g++ 编过了，不代表评测机的 g++ 版本也能编过。比如有的评测机用的是比较老的编译器，对 C++11 之后的语法支持不全；或者评测机开放了不同语言选项，你提交时选错语言，也会 CE。这类问题虽然不常见，但一旦遇到，排查起来极其痛苦。建议提交前确认语言选项和你在本地写代码用的语言版本完全一致。

第三，时限波动。有些 OJ 一个测试点可能限时 2 秒，但评测机负载高的时候实际运行时间会抖动。如果你的程序本来就在超时边缘，第一次提交可能 TLE，过一会儿再交又 AC 了。如果你多次提交都是同样的分数，那基本可以排除时限波动的因素，老老实实查逻辑问题。

5. 回到那道基础计算题：找回丢分的完整排查清单

5.1 从提交记录到源码逐项过检

如果你现在正卡在一道基础题上，按照下面这个顺序逐项排查，大概率能定位问题。

第一，回到题目描述，重新确认输入输出格式。是多组输入还是单组输入？文件 IO 还是标准 IO？输出保留几位小数？这些信息全部确认一遍，不要凭印象。

第二，检查数据范围，逐个变量过类型。凡是涉及加减乘除后可能超过 2^31-1 的地方，全部换成 64 位类型。如果有取模，确认每个中间步骤都处理到位。

第三，把样例原样复制，重新提交一次。有的 OJ 会给你显示"Wrong Answer on Test 5"之类的信息，或者提供"下载数据"的功能，能拿到的信息越多越好。

第四，如果平台有讨论区或者题解区，去翻翻别人提过的坑。很多题下面都会有过来人留言："注意 long long""注意多组输入""记得判断 0 0 结束"。这些一针见血的评论比你看十遍代码都管用。

第五，实在不行，用本地调试工具跑一遍边界数据。上面对比表里的几种场景挨个测，看程序是不是在某些输入上直接崩溃或者输出异常。

5.2 我的经验：卡分之后，先怀疑自己，再怀疑规则

说点题外话。我刷题这些年，见过形形色色的卡分选手，有些人确实是"思路对但细节翻车"，比如数据类型溢出了，比如多组输入没处理，比如浮点数精度没控制好。但更多的卡分，其实是"没读懂题目规则，就开始写代码"。

我自己早年也干过这事儿。有一道 A+B 的拓展题，我自信满满写完交上去，卡在 30 分。当时第一反应也是"判题规则有问题吧"。后来冷静下来重新读题，发现题目要求处理到文件结尾，而我写的是单组输入——丢的那 70 分丢得明明白白。

从那以后我养成一个习惯：任何一道题，交之前先花两分钟把题目里的"输入""输出""数据范围"三块反复读三遍，确认没有理解偏差再动手。这个习惯救了我很多次，也让我后来帮别人排查问题时效率高了不少。

回到开头那位朋友的问题——"判题规则是不是有问题？"我的回答是：判题规则大概率没错，错的是我们对题目的理解还没到位。与其怀疑评测机，不如按上面的排查清单走一遍。等你把该检查的都检查完，要么你已经找到了 bug 改到 AC，要么你会发现，原来那 10 分 20 分丢得一点都不冤。