普渡大学炸了：近一半学生被指控用AI写代码，要么成绩清零，要么直接挂科

近日，普渡大学计算机专业发生了一件震动全美教育圈的事件。

该系这学期的CS240——一门叫做"C语言程序设计"的必修大课，数百名学生选修——在学期接近尾声时，突然被引爆。

教授Jeff Turkstra

任课教授Jeff Turkstra宣布，他的检测系统发现，班上近一半的学生在编程作业中使用了AI。

这一半学生，面临的不是口头警告，不是扣分，而是一个二选一：承认使用AI，全学期所有作业成绩清零；不承认，直接挂科。

消息一出，计算机系炸了锅。学生联名抗议，系主任被迫出面，宣布将与学生举行座谈，讨论应对方案。事件迅速蔓延至Reddit、Hacker News等论坛，引发数千条评论。

Turkstra本人是普渡大学计算机系的教学副教授，在这里任教已逾二十年。他不仅教书，还同时从事教学工具的研究开发，研究方向专注于"大规模课堂管理与教学支持系统"。

他开发的工具有：代码风格检查器Eastwood、C语言测试框架C-Lab、同伴互评系统PeerVal，以及本次事件的核心技术——EnCourse。

这些系统，据他本人介绍，"已被数千名学生、数十门课程使用"，并在国际计算机科学教育学术会议SIGCSE上发表论文。

在普渡，Turkstra是一个评价极度两极分化的教授。有学生在教师论坛写道，他的讲座充满感染力，是大学四年听过最好的课之一；也有学生毕业多年后仍专程发邮件致谢，感谢他为自己的职业发展打下了基础。

但另一批学生则描述了截然不同的体验：每周作业动辄需要二十小时以上，助教能给的帮助极为有限，"感觉他更热衷于让学生挂科，而不是教学生学东西"。

CS240是一门进阶的C语言课程，该系的必修课，涵盖C语言的完整体系：文件操作、指针与内存管理、等等。这门课一周两次讲座（每次75分钟），共设有12次课后作业，两次期中考试，以及一次期末考试。

这门课作业提交方式，从一开始就与普通编程课有所不同。

每个学生在课程服务器上都有一个专属的Git代码仓库。从第一次作业（Homework 0）起，学生就被引导克隆这个仓库到本地，然后在里面编写代码。

许多高校编程课都有类似的设置。

但Turkstra的系统多做了一件事：课程提供给学生的Makefile（编译配置文件），被植入了额外的Git命令。这意味着，每当学生在本地执行一次编译——哪怕只是敲了一行`make`——这个Makefile就会自动悄悄地触发`git commit`和`git push`，将当时的代码状态上传至服务器。

这与学生手动提交完全不同。手动提交，是学生主动决定"这段代码写好了，我要存档"；而这个自动机制，则是在学生每一次编译时都留下一个时间戳精准的快照——无论那段代码是完整的、残缺的、还是刚刚粘贴进来还没改动的。

Turkstra在论文摘要中描述，这套系统的原始目标是：在大班教学中，帮助教授实时了解每位学生的学习进度，识别哪些学生卡在哪个知识点上，以便早期干预。

而现在，Turkstra还可以通过这个系统判断代码究竟是学生一行一行亲手写出来的，还是一次性从AI那里复制粘贴过来的。

一个真实学习过程产生的Git提交历史，应当是密集而渐进的：写几行，编译一次；报错了，修改，再编译；循环往复，提交记录多而细碎，代码的演进清晰可见。

但如果代码来自AI生成，往往会出现这样的提交记录：在某一个时间点，一大块完整的代码突然出现，之后或许只有少量细微改动。这种"大跃进式"的提交模式，与正常的编程学习过程明显不符。

这套逻辑，在技术层面有其合理性。但它也存在明显的漏洞：学生在其他文本编辑器里写好再粘贴进来、网络不稳定导致部分提交失败后重新同步、换电脑操作、或者在思考清楚后集中录入代码……这些完全合理的行为，都有可能产生"异常"的提交历史。

而这套系统本身的背后运行，学生也不知情。Homework 0的操作说明里，只是告知学生如何使用Git提交作业，并未明确说明Makefile会在每次编译时自动上传代码快照，也未说明这些数据将被用于作弊检测。

4月18日，学期已近尾声。作业基本交完，期末考试在即。

就在这个时间节点，Turkstra向涉嫌的学生们发出了通知。

选项一：承认在作业中使用了AI。代价是：全学期十二次作业的成绩，全部归零。这意味着，无论这些学生在期中、期末考试中表现如何，作业这一块的分数彻底蒸发。课程能不能过，悬在一条细线上。

选项二：不承认。代价是：教授直接给出课程不及格的评定。

在美国大学，课程挂科的连锁反应不只是重修那么简单——它会影响GPA，可能导致奖学金受损，甚至触发学术诚信审查，在成绩单上留下永久记录。

对于那些本身就在及格线边缘挣扎的学生来说，这两个选项，没有一个真正意义上的"活路"。

消息传出后，学生们的愤怒瞬间点燃。有学生在Reddit的普渡版块发帖，描述自己收到通知时的震惊——他们并不认为自己违反了规定，或者根本不确定自己的行为是否构成违规。

帖子迅速发酵，涌现出大量类似的声音：有人说自己只是用AI解释了一个报错信息，随后自己修改了代码；有人说自己确实参考了AI给出的思路，但代码是自己写的；还有人说，他们压根没用AI，不知道为什么会被系统标记出来。

这场风波逼得系主任不得不出面。学校宣布，将专门安排一次院系与学生的座谈会，时间定在4月26日，讨论这件事的后续处理方案。

最大的争议在于：被标记的学生，占到了全班的近一半。

在一门几百人的大课里，这意味着被点名的学生数以百计。

这个数字，可以有两种解读。

第一种解读：AI在编程作业中的使用，已经渗透到难以想象的程度。学生们把AI辅助视为理所当然，就像查Stack Overflow一样普通，边界感早已模糊。

第二种解读：一套声称能在几百人的大课里识别出近一半学生存在问题的系统，本身的准确率和误报率，应当接受严格审视。

在美国高校的学术诚信处理程序中，对学生提出正式作弊指控，通常需要走一套有申诉机制的程序，需要提供足够证据，需要给被指控方陈述的机会。

Turkstra的通知，跳过了这套程序，直接给出了二选一的最终裁决——要么认罪，要么接受挂科。

在没有完整申诉程序的情况下，以"挂科"作为"不认罪"的惩罚，在法律层面可能站不住脚。如果有学生决定通过学校的正式申诉渠道挑战这一决定，甚至最终走向法律程序，Turkstra和普渡大学面临的局面将相当被动。

抛开程序正义不论，Turkstra教授的做法在时机上，也引发了强烈的道德质疑。

他有整整一个学期。如果他的系统能够实时追踪每一次编译提交，他就应该同样能够实时看到"异常"的提交模式。如果有学生在第一份作业就触碰了红线，他完全可以立刻介入——发出警告，明确告知什么行为被视为违规，给学生纠正的机会。

他没有这样做。

他全程沉默，积累证据，直到学期末，在学生已经无法弥补任何错误的时间点，一次性祭出这把大锤。

这种"钓鱼执法"式的处理逻辑，让人想起《论语》里的一句话：不教而杀谓之虐。

另外，2026年的计算机系，是否还值得花大力气禁止学生使用AI写代码？

今天的软件工程现实是：GitHub Copilot、ChatGPT、Claude等AI编程助手，已经成为大量专业开发者日常工作流程的一部分。AI辅助下的代码生产效率大幅提升。一个走出校园的计算机系毕业生，如果不会与AI高效协作，在竞争日益激烈的职场中将处于明显的劣势。

从这个角度看，强制要求学生在每一份作业中"纯手工"完成所有代码，是在训练一种正在快速边缘化的工作方式。

Turkstra的选择，是面向过去的路径。这场风波，也是AI时代高等教育与新技术之间最尖锐的一次正面碰撞。