AI自动批改编程作业：代码评测系统如何“品”出好代码？

可视化演示

展示代码评测系统五步流水线与沙箱安全隔离架构，支持模式切换查看评测全流程。

评测系统概览

想象那位“AI 副厨”正式上岗：它面前排着几百道学生的菜，每道菜都附了一张小纸条，写着“期望的味道”。它要做的事情只有三件——把菜端进小隔间、对照品鉴清单尝一口、写下点评。这三件事合起来，就是代码评测系统的全部：接收学生提交的代码，用预先设计好的测试用例（品鉴清单）去运行它，再根据运行结果判定对错并生成反馈。

从概念上说，评测系统要解决的第一个问题是“什么叫作对”。代码的行为是黑箱，能观察到的只有输入和输出。于是评测系统采用最朴素也最可靠的策略：给定同样的输入，学生程序的输出必须和老师预先算好的期望输出完全一致。就像副厨不会问厨师做菜时心里怎么想，只看端上来的菜咸淡是否正好。

整个评测流水线可以拆成四步：提交阶段接收代码并启动独立进程；测试阶段把测试用例逐个喂给程序；判定阶段把实际输出与期望输出逐字符比对；反馈阶段把编译错误、运行异常和输出差异加工成学生看得懂的语言。这套流程在教育领域遍地开花：在线编程平台用它批改课后作业，OJ 系统用它做竞赛判题，高校实验课用它完成大班作业的自动评分。

1. 期望输出：老师预先给出的标准答案，代表“这道菜应该有的味道”

$$\text{expected} = \text{标准输出}$$

2. 实际输出：学生代码运行后产生的真实结果

$$\text{out} = \text{程序打印的内容}$$

3. 精确比对：逐字符比较两段文本是否完全一致

$$\text{out} = \text{expected} \iff \text{逐字符相等}$$

4. 结论分支：相等则判通过，不相等则判失败

$$\text{通过} \quad \text{vs} \quad \text{失败}$$

副厨的这套做法告诉我们：评测的前提是把“对”定义清楚。定义得越明确，后面的自动化才越有底气。而这把尺子究竟量得准不准，取决于下一节讲的品鉴清单设计得够不够刁钻。

\text{结果} = \begin{cases} \text{通过} & \text{out} = \text{expected} \\ \text{失败} & \text{out} \neq \text{expected} \end{cases}

测试用例生成

副厨的品鉴清单可不是随便写的。它知道一道菜要在“刚好及格”“极端火候”“食材临界”这些位置重点考察：焯水 30 秒和 31 秒的区别，可能就决定了一盘菜是脆嫩还是软烂。测试用例设计的第一招，就是盯住输入范围的边界值。如果题目约定输入是 0 到 100 的整数，那么 0、100 是合法边界，-1、101 是越界边界，这四个值往往最能暴露程序漏洞。

第二招叫等价类划分：把所有可能的输入按行为特征分成几组，每组抽一个代表即可。比如把输入分为“正整数、零、负整数、非数字”，每类选一两个典型值，就能用很少的用例覆盖很大的输入空间。第三招是随机数据生成：用程序批量制造随机输入，配合一个“参照解”来判断学生输出对不对，专门用来捕捉边界值和等价类都没想到的盲区。

但测试用例再多也怕“没测到位”。衡量到位程度的指标叫分支覆盖率——程序里每个 if/else 都是一条分岔路，覆盖率看的是测试用例到底把多少条岔路都走了一遍。走完的分支越多，说明品鉴清单覆盖的“做法流派”越全，对“这道菜合格”的结论就越有信心。

菜要一道一道尝，路要一条一条走。品鉴清单每点亮一条新的分支路径，副厨对这道菜的把握就多了一分。然而清单再完备，也不能让菜在备餐间里“裸奔”——下一节，副厨要给自己搭一个安全的隔离厨房。

运行沙箱设计

副厨试菜有个铁规矩：必须在小隔间里进行。为什么？因为新厨师做的菜有可能是“毒蘑菇”——代码里可能藏着删除服务器文件、疯狂占用内存、甚至联网攻击的恶意指令。评测系统同样需要一个铁规矩：学生代码必须在运行沙箱内执行。沙箱就像一个全封闭的小厨房，菜在里面被翻来覆去地检查，但厨房外的一切都碰不到。

沙箱要管住的第一件事是时间。万一学生写了个死循环，程序永远跑不完怎么办？所以要设置时间预算。做法很简单：先用老师的参考解法跑一遍，记下基准时间，再乘上一个安全系数作为学生代码的“最多可运行时间”，超时就判超时并强行终止。

除了时间，沙箱还要限制内存峰值、切断网络访问、把文件系统设为只读，并限制子进程的创建数量。这就像隔离厨房不仅限时，还要提前清走所有易燃易爆品、封死对外窗户。菜再怎么折腾，也翻不出这个小隔间。但副厨的活儿还没完——尝出了问题，还得把话说清楚。

反馈生成策略

副厨最拿手的一项技能，是“尝一口就告诉你哪里不对”。它不是含糊地说“这菜不行”，而是具体到“盐多了一克”“火大了 30 秒”。反馈生成策略要做的，就是把编译器和运行时的错误信息，翻译成学生能立刻行动的语言。

反馈分成三个层次。第一层是编译错误：学生代码根本跑不起来，系统就要截取编译器报错的关键行，把“SyntaxError: unexpected indent”这种天书翻译成“第 5 行缩进有问题”。第二层是运行异常：程序跑起来但中途崩溃，要识别出“除零错误”“数组越界”“空指针”这些常见异常，并指出崩溃发生在哪一行。第三层是逻辑错误：程序能跑但结果不对，这时候系统把期望输出和实际输出并排对比，找出从哪个位置开始分叉。

定位输出差异用的是编辑距离的思想：“期望输出”和“实际输出”都是字符串，把 A 变成 B 最少需要几次插入、删除、替换操作，这个次数就是差异的度量。编辑距离越小，输出越接近；编辑距离为 0，就说明两个文本完全一致。

点评要具体到“位置 + 原因 + 行动”。副厨不会替你重新炒一盘菜，但会精确指出你哪一步做错了——这样学生才能真正学会。不过话说回来，副厨的点评再准，如果每次尝菜时手都在抖，那评分也毫无意义。公平性保障就登场了。

公平性保障

副厨试菜最怕两件事：手抖和心乱。同一道菜第一次尝觉得咸，第二次尝又觉得刚好——这不是菜的问题，是味蕾的随机波动。评测系统也有类似的“手抖”，叫环境抖动：CPU 调度、缓存命中率、后台进程抢占，都会让同一段代码在不同时刻运行时间差出一大截。

为了公平，评测系统先做“统一环境”：所有学生的代码都在同一套镜像、同一个编译器版本、同样的 CPU 配额里运行，从根上消除软硬件差异。但环境再统一，抖动也无法完全消灭，所以性能类评测要“多次运行”：同一份代码连跑 n 次，每次记录运行时间，然后取中位数作为最终成绩。

统一环境是“同一把尺子”，中位数是“多量几次再读数”。两者合起来，才保证副厨不会因为自己打了个喷嚏，就冤枉了一道好菜。但公平是对好人说的，对故意使坏的人，副厨还得有另一手准备——把危险分子挡在门外。

安全性防护

后厨有条铁律：副厨的隔间里只能用自己带来的那几把刀，谁都不许私自带刀进来。这条铁律的思想，在安全领域叫“白名单策略”。它默认一切操作都是危险的，只有被明确列入白名单的才允许执行。学生代码想读文件？白名单里只有“只读打开”这一项，写文件、删文件、联网、开子进程统统没有。

白名单之外，还有两道防线。第一道是容器资源隔离：用 Linux 的命名空间和控制组，把学生代码装进食谱受限的“独立车间”，CPU、内存、进程数都被限死，互相之间看不见也抢不到。第二道是只读文件系统：学生代码运行在只读根目录里，改不了系统文件，删不了重要数据。三管齐下，副厨的小隔间就固若金汤了。

安全这道门守住了，副厨还剩最后一个心结：两个学生端上来的菜一模一样，连葱花数量都分毫不差，这绝对不正常。怎么抓出这种“代做”行为，是防作弊机制要解决的问题。

防作弊机制

副厨的鼻子很灵，它只要把两盘菜并排放，就能闻出是不是出自同一口锅。代码评测系统的防作弊机制，本质上就是训练这套“嗅觉”。最常用的手段是代码相似度检测：先把代码拆成一个个语法单元（token），再比较两段代码的 token 集合有多像。

衡量相似度最经典的工具是 Jaccard 相似系数：两段代码 A 和 B 的 token 集合，交集大小除以并集大小。相似度超过阈值（比如 0.8），系统就标记为疑似抄袭，交给老师人工复核。

不过副厨深知，两盘菜都用了餐厅统一配发的盘子，不能因此就断定是同一个人做的。所以评测系统在算相似度之前，会先把老师提供的公共模板代码剔除掉，避免误伤。同时还会分析提交模式：比如比赛刚开始 10 秒就交满分答案，或者两台“不同”的机器提交时间间隔高度规律，这些异常信号都会触发人工复查。聪明的副厨既不冤枉好人，也不放过坏蛋。

AI 应用场景

Python 演示

"""迷你代码评测系统 MiniJudge"""import osimport subprocessimport sysimport tempfile  class MiniJudge:    """像 AI 主厨助理一样试菜打分"""    def __init__(self, time_limit=2):        self.time_limit = time_limit     def run_solution(self, code, test_input):        """在独立子进程中运行学生代码"""        script = code + "\nprint(solution(" + repr(test_input) + "))"        fd, tmp = tempfile.mkstemp(suffix=".py")        with os.fdopen(fd, "w") as f:            f.write(script)        try:            result = subprocess.run(                [sys.executable, tmp],                capture_output=True,                text=True,                timeout=self.time_limit,            )        except subprocess.TimeoutExpired:            return None, "超时: 运行时间超过限制"        finally:            os.unlink(tmp)        if result.returncode != 0:            return None, result.stderr.strip()[:200]        return result.stdout.strip(), None     def judge(self, code, cases):        """逐个运行测试用例并输出结果"""        passed = 0        failed = 0        for i, (inp, expected) in enumerate(cases, 1):            out, err = self.run_solution(code, inp)            if err is not None:                print(f"[用例 {i}] 运行失败 -> {err}")                failed += 1            elif out == str(expected):                print(f"[用例 {i}] 通过")                passed += 1            else:                print(f"[用例 {i}] 失败 -> 期望 {expected} 实际 {out}")                failed += 1        print(f"评测完成: {passed} 通过 / {failed} 失败")  if __name__ == "__main__":    student_code = """def solution(x):    if x > 100:        return -1    return x * 2"""    test_cases = [        (1, 2),        (-1, -2),        (0, 0),        (100, 200),        (101, -1),    ]    judge = MiniJudge(time_limit=2)    judge.judge(student_code, test_cases)

1. subprocess.run([sys.executable, tmp], capture_output=True, text=True, timeout=self.time_limit)把学生代码放进独立子进程运行，“隔离厨房”的关键一步
2. timeout=self.time_limit超时熔断，死循环代码会被强行终止
3. result.returncode != 0判断编译或运行是否出错
4. out == str(expected)实际输出与期望输出逐字符比对，判定对错
5. result.stderr.strip()[:200]截取报错信息并截断长度，避免反馈淹没关键信息
6. tempfile.mkstemp(suffix=".py")为学生代码创建独立临时文件，互不干扰

常见误区

面试题