arXiv
版本控制历史让 AI 代码不再无迹可寻
AI 可以让每个学生提交的程序看起来都不一样，但代码的构建过程可能留下有用的痕迹。Argus 分析了普渡大学一门 C 课程六次开课中的 42,695 份作业提交记录，并利用异常的代码特征和快速添加代码的行为，将需要人工复核的案例交给教职员工。在大学编程实验课中，如果课程保留详细的历史记录并制定清晰的 AI 使用规则，教师就可以在采取行动前检查一段可疑的编辑过程。
提交的程序往往是编程教师唯一能看到的东西。因此，如果两个学生互相抄袭，教师可能发现，因为他们的代码看起来很相似。但要判断学生是否借助 AI 助手完成作业、再在提交前修改结果，就困难得多。在大班课中，没有人能读完每一份草稿。错误的指控可能损害学生的学业记录和身心健康。
文件并不是全部故事
传统的代码抄袭检测工具会搜索学生提交内容之间的相似之处。一个学生抄袭另一个学生时，这种方法有效。当 AI 为每个学生生成不同的解法时，它的效果就很差。即使学生并没有独自开发出这个解法，最终文件也可能看起来是原创的。
版本控制历史记录了文件随时间发生的变化，有点像看一幅画保存下来的每个阶段，而不只是最后的成品。它可以显示代码是通过一个个小步骤出现的，还是以一大块代码的形式加入的。它还可以显示这份作业花了多长时间开发出来。不过，这样的记录本身并不是证据。学生的编程风格可能反映其以往的经验，而遇到困难的学生也可能更容易寻求外部帮助。异常代码历史与较低考试成绩之间的关联，并不能证明 AI 导致了较弱的学习效果。
从无形痕迹到复核队列
Argus 的设计目标，是把这些历史记录变成一份供人检查的清单。它将代码中的异常特征与版本控制记录中的行为结合起来。它关注的指标包括课程没有教过的高级 C 特性、不符合课程规范的风格、较短的开发时长，以及这样的代码添加突发情况：至少新增 30 行代码，且速度达到每分钟 15 行或更多。如果某个指标在全班都很常见，Argus 就会降低它的权重。
该系统被用于普渡大学一门本科 C 课程。每当学生运行 make 时，课程服务器都会自动提交代码，而且学生被告知了这一点。在 2020 年以及 2022–2026 年的六次春季开课中，Argus 分析了 3,893 个“学生—学期”组合和 42,695 份作业提交记录。2026 年春季，服务器在 7,769 份提交记录中记录了 381,748 次提交。
这些数字没有被当作裁决依据。教职员工分别复核得分最高的学生，并达成共识。他们复核了累计得分排名前 300 的学生，以及某一份作业得分排名前 150 的学生。三名教职员工每人花了约八小时。在得分排名前 150 的学生中，复核人员认为有四个案例的证据不足。
Argus 的平均得分从 2020 年春季的 1.1 和 2022 年春季的 0.5，上升到 2025 年春季的 4.2 和 2026 年春季的 11.9。2026 年春季，完成第一次期中考试的 584 名学生中，有 267 人（45.7%）在人工复核后被标记。被标记学生三次考试的平均成绩为 61.9%，而未被标记学生为 73.5%。平均得分与考试表现之间的相关系数为 -0.537。这些数字可以帮助教职员工决定从哪里查起，但不能解释任何一名学生为何取得这样的成绩。
编程实验课可以看到什么
如果这种方法行得通，大学编程实验课中的作业就不再只根据截止时间前上传的最终代码来评判。教职员工可以检查编辑过程，重点查看一段可疑的粘贴代码，然后决定是否需要进一步处理。自己完成作业的学生，也就不再那么依赖教师只能通过发现同学之间的抄袭来进行监督。
这样的未来需要的不只是一个检测器。课程必须收集详细的开发历史，并明确说明哪些 AI 帮助是允许的。指控必须继续由人工复核人员负责，而且证据必须足够有力，以保护学生免受错误指控。在这种情况下，AI 使用检测就变成了分流：一种分配有限复核时间的方法，而不是自动执行纪律处分的系统。