返回博客
教育

氛围编程危机:为什么计算机毕业生在没有 AI 的情况下不会写代码了

PPlagly.ai 团队||阅读时间 14 分钟

在 2026 年 3 月的一个迅速超过 8,000 次点赞的 Reddit 帖子里,一家 B 轮初创公司的资深工程师发布了他刚刚拒绝的一项带回家面试(take-home interview)的截图。候选人是一名刚毕业的计算机科学(CS)专业毕业生,在一所名校拥有 3.9 的 GPA,他提交的代码在常规路径(happy path)上运行完美,但在每个边缘情况(edge case)下都会默默地损坏数据。在后续电话中被要求逐步讲解逻辑时,该候选人甚至无法解释为什么他自己写的一个函数使用了递归。让该帖子彻底爆火的是他坦诚的回答:“我只是告诉 Claude 我们需要什么,它就写出了这个。通常只有在代码不起作用时我才会去读它。”

这就是“氛围编码(vibe coding)”危机。到 2026 年,它已从开发者推特(Twitter)蔓延到人力资源管道、招聘汇报会中,并越来越多地出现在计算机系主任的办公室里,他们正试图弄清楚他们的毕业生到底发生了什么。这个术语由 Andrej Karpathy 于 2025 年 2 月提出,用于描述一种积极的新工作模式:描述你的意图、接受模型生成的内容、发布。但在不到一年的时间里,同一个短语就变成了该领域对整整一代程序员的代称——他们可以流利地写提示词(prompt),但无法推导他们的代码实际在做什么。

对于编程教育工作者来说,这不是一个关于未来工作的假设性问题。这是一场关于你们当前毕业的学生的现实教学紧急情况。本文探讨了研究和实地报告实际显示的关于 AI 引起的技能萎缩(atrophy)、为什么从 CS1 到高年级毕业设计(capstone)都极其脆弱,以及一小群但不断壮大的教育工作者如何重构课程,以确保学生毕业时能够编写代码 — 而不仅仅是能够编写提示词。

Vibe Coding 究竟意味着什么(以及为什么 Karpathy 说它应该很有趣)

Karpathy 最初的设想是很具体的。氛围编码意味着接受个人项目的编程现在可以感觉像是一场创意游戏:你告诉模型你想要什么,它生成代码,你调整提示词而不是代码本身,然后发布一些可以运行的东西。他明确指出,在自己的副业项目中,他不再逐行阅读代码。这种设定是为了享受、提高生产力,以及合理的观察,即对于低风险的一次性代码,仔细的手动审查实属多余。

该术语随后逃逸到了更广泛的领域,并在两个截然不同的语境中落地:

  • 资深工程师刻意使用它: 将 AI 生成的代码视为草稿,在提交前阅读并重构它,利用 AI 跳过样板代码,但应用数十年的模式识别经验来评估输出。这就是 Karpathy 所描述的,而且它很有效。
  • 初级工程师和学生将其作为默认模式: 将 AI 生成的代码视为已完成的成品,不加阅读地接受它,仅在测试失败时进行调试,只有当 AI 无法修复其自身的输出时,才升级向资深工程师或讲师求助。这不是 Karpathy 所描述的,而且它行不通。

教学上的问题是第二类群体,他们占了 2026 年进入 CS 专业的学生的大多数。Karpathy 本人在 2025 年晚些时候收回了他的说辞,并指出氛围编码对做个人项目的专家有意义,而对其他所有人都是腐蚀性的。

以真实数据呈现的技能萎缩模式

现在的证据非常充分,并且都指向一个方向。CodeRabbit 于 2025 年 12 月发表的一项分析检查了数百个开源仓库的拉取请求(PR),发现由生成式 AI 共同编写的代码包含的“重大”问题比人类编写的代码多出大约 1.7× 倍。逻辑错误(错误的依赖关系、有缺陷的控制流)和安全漏洞都显著增加,其中安全缺陷的出现率是纯人类编写代码的 2.74× 倍。

TechSpot 在 2025 年底的一份报告调查了在职开发人员关于被迫使用氛围编码工作流的认知影响。普遍报告的模式是:调试时间增加、在大脑中模拟代码运行的能力下降,以及对于什么是生产级代码的直觉在退化。一位开发人员将他在氛围优先工作六个月后的经历描述为完全“失去了解决问题的肌肉记忆”。

最清晰的例证来自一名在 2026 年初进行了 30 天实验的开发人员:一个月不使用 AI 辅助,然后反思其中的差异。他在 dev.to 上写的文章《I Coded Without AI for 30 Days: The Results Were Embarrassing》成为了当年分享次数最多的开发者随笔之一。核心发现是:一名拥有八年经验的在职资深工程师无法再凭记忆编写一个简单的二叉树遍历。这项技能已被外包,然后悄然退化了。

如果一个在职的资深工程师的调试肌肉记忆在依赖 AI 几个月内就会退化,那么想象一下对于一个从一开始就根本没有这种肌肉记忆的 CS1 学生来说,其轨迹会是怎样的 — 他们所有的编程体验都是通过一个在看到问题陈述后十秒内就能生成可行解决方案的 LLM 来进行的。

为什么编程教育特别脆弱

其他教育领域在应对 AI 时虽不完美,但大多数仍保留着完整的评估框架。文学系的学生仍可以被要求在研讨会上讨论某个段落。化学系的学生仍可以被要求执行实验步骤。数学系的学生仍可以被要求在黑板前推导证明。而编程教育则没有任何这些完整的评估模式。几乎每个编程作业都是带回家完成的,根据代码是否通过测试来进行评估 — 而 2026 年的 AI 可以轻易通过这些测试。

这造成了三个编程特有的脆弱性:

  • “作业-测试”循环是完全可以自动化的。 Codex、Claude Code 和 Cursor 可以阅读作业、编写代码、运行测试套件、针对失败进行迭代并提交可行的解决方案。学生应该完成的完整周期 — 理解需求、设计解决方案、实现并调试 — AI 可以在学生读完说明书之前就完成。
  • 现场评估在物流上是昂贵的。 一个有 200 名学生的 CS1 班级在不消耗助教(TA)每个作业周期 20 个小时时间的情况下,实际上无法对每个作业都进行五分钟的口头答辩。大型 CS 课程的经济模型假设采用异步的带回家打分制。
  • 作弊对学生来说是隐性的。 复制文章的学生知道自己作弊了。而提示 AI 解决作业的学生可能不会认为这是作弊 — 社会规范的变化速度快于政策的变化,这种行为感觉与查找资料没有什么区别。等到他们上四年级需要独立思考时,他们已经度过了四年,没有建立任何相关技能。

其结果是毕业人才管道输送的学生,其凭证(学历)不再与技能相匹配。2026 年的招聘经理越来越多地绕过简历和 GPA,转而进行现场技术评估,正是因为凭证系统已经与底层能力脱节。

在 CS 答疑时间里,“一无所获”的表现

如果您教授编程,您可能已经见过这种模式,即使您还没有为其命名。我们收集了 2025 年底和 2026 年初 CS1、数据结构和高年级毕业设计(capstone)课程的讲师们最常见的诊断信号。

  • 学生无法找到自己的 Bug。 提交的代码运行完美。新的单元测试失败。学生打开文件,看着代码就像是第一次见到一样,在没有假设的情况下上下滚动,最后说:“我还是问问 Claude 哪里出错了。” 对测试失败的第一反应是上报给 AI,而不是形成一个假设。
  • 学生无法回答“为什么”。 被问到 “为什么在这里使用哈希表(hash map)而不是数组” 时,回答是 “这是 AI 建议的。” 选择已经做出,但背后的合理性从未内化。代码下没有任何认知模型。
  • 学生无法进行微小的改动。 “修改此项以同时处理负数” 本应是 30 秒的编辑。但对于依赖 AI 的学生来说,这变成了一个 5 分钟的提示词编写过程,因为他们需要将约束条件反馈给模型,而不是思考修改应该放在现有代码的什么地方。
  • 学生精通工具,但在解决问题上是个文盲。 他们可以配置 Vercel、构建 React 组件、设置 Postgres 数据库、使用 Docker 部署。他们可以使用整个现代工具链。但让他们实现快速排序(quicksort)时,只有一片沉默。
  • 毕业设计原形毕露。 高年级毕业设计(Senior capstone)本应是积累的技能发挥作用的时刻,却越来越多地成为积累的技能缺失被暴露的时刻。那些从 CS1 到大三都一路混过来的团队,到了毕业设计阶段却无法设计系统、无法分解功能、无法处理 AI 做得最差的编程部分。

教学上的解决方法:将 AI 熟练度视为一项真正的技能(并使其可以通过努力获得)

能够很好地应对这一转型的教育工作者并不是那些执行最严格禁止 AI 政策的人。他们围绕一个清晰的区别重构了课程:AI 是学生应该学会好好利用的工具,同时学生必须能够独立展示 AI 所练习的认知技能。这两项要求并不冲突 — 它们是互补的,走对这条路的课程培养出的毕业生,其表现优于氛围编码者和禁止使用 AI 的对照组。

我们在 2026 年编程课程中看到的行之有效的具体设计模式:

  • 1. 双轨制规划。 每个作业都包含一个 “单人” 部分(不允许使用 AI,通常是小型的课堂练习)和一个 “工具” 部分(允许使用 AI,但要记录下来)。单人部分考察学生实际能做什么。工具部分教他们如何做更多的事情。
  • 2. 将 AI 熟练度作为评分项。 学生提交他们使用的 AI 提示词、得到的回复,以及关于 AI 何处出错或低效的分析。批判性地阅读 AI 输出被视为一个课程目标,而不是一种权宜之计。
  • 3. 仅限调试的评估。 给学生一些带有微妙 Bug(差一错误、错误的基准情况、缺失空值检查、安全漏洞)的 AI 生成的可运行代码,并根据他们寻找和修复 Bug 的能力进行打分。这训练了 AI 表现最差而雇主最看重的技能。
  • 4. 过程可视化的评分。 要求的提交(commit)历史、记录设计决策的强制性注释、录制的讲解。光是成品本身不再是全部的成绩。
  • 5. 现场技术交流。 在每个重大作业中增加简短、结构化的口头问答环节。每位学生五分钟,侧重于一两个诊断性问题。阻力是真实的;反馈信号是极好的。
  • 6. 系统级别的真实性验证。Plagly.ai 这样的工具会扫描提交的作业,检查 AI 生成模式、班级级别的文体一致性,以及是否缺乏真实学生作业通常表现出的迭代作者痕迹。这不作为分数,而是一个标志,用以筛选出值得在答疑时间进行交流的提交。

使之切合实际的工具层

对上述模型的最大反对意见是后勤(组织)上的。实际的班级有数百名学生;实际的教师没有时间逐行阅读每次提交、对每个作业都进行口头答辩,或者用肉眼注意到班级级别的模式。工具必须执行表面扫描,以便人类能够对重要的案例进行判断。

这在一个有 200 名学生的 CS1 班级中实践起来是什么样的:

  • 提交内容自动扫描: 每个上传的文件都会经过一次 AI 检测,返回一个置信度得分和分块标记。Plagly.ai 在 GPT-5.5、Claude 4.6、Gemini 3.1 和其他主要模型上以 99% 的准确率执行此项分析,包括这些模型偏好的特定代码变体。
  • 班级级别仪表盘: 教师可以看到整个班级文体模式的聚集情况。当八份提交的作业共享了习惯性措辞、相同的注释密度以及相同的防御性边缘情况模式时,该聚集就会显现出来供审查。
  • 作者痕迹: Plagly.ai 的 Agentic Council — 七个领域专家模型分析提交的写作质量、结构、AI 检测、原创性和一致性 — 生成一份带引用的报告。该报告不会断言学术不端,它记录了教师可以调查的模式。
  • 有针对性的答疑交流: 被筛选出来的学生将接受五分钟的口头检查。大多数人很快就排除了嫌疑;少数没有排除的将成为教师需要慎重处理并记录在案的案例。

目的并不是要抓住每一个作弊者。目的是为想学习的学生保持学习闭环的完整。一个没有验证的课堂是一个投机取巧的学生决定成绩曲线、而诚实学习的学生成为傻子的课堂。一个有验证的课堂是社会规范得以维持的课堂 — 作业依然起教学作用、成绩依然代表着什么,而毕业生依然能够编写代码。

编程教育的 18 个月展望

我们在 2026 年接触的大多数在职编程教育工作者都有一个共识,即目前的设定是不稳定的。通过测试评估的带回家作业结构上与智能编码工具的存在是不相容的。总有一些东西需要做出改变。以下是三个合理的方向,按可能性递增排列:

  • 全面禁止 AI: 一些机构会尝试,但大多数会失败。禁令无法执行,政策变得不一致,遵守规则的学生毕业时的技能还不如不遵守规则的学生。这是最糟糕的结果,而且在 2023-2024 年尝试过该方法的几所大学中已经宣告失败。
  • 课程体系中的能力重心下移: CS1 开始得更晚,更侧重于概念基础。CS2 涵盖以前 CS1 涵盖的内容。高级课程变得更加理论化,因为实现部分不再是发生学习的地方。这种情况正在缓慢发生。
  • 评估转向现场演示: 带回家作业变成了形成性评估。终结性成绩由监督下的现场编码、口头答辩和过程可视化工作决定。这是最强大的 CS 课程已经在迈进的方向,也是我们认为大多数课程最终会定下来的方向。

这些结果都无法解决这个学期你该如何面对眼前的学生的问题。为此,实际的举措是混合模式:保留你当前的作业,增加一个能抓住最坏情况的验证层,每门课程增加一到两个亲自评估环节,并开始更缓慢的工作,即为一个将智能 AI 视为基线的水准重新设计课程体系。验证工具为你赢得了重新设计课程的时间,同时在此期间不会让这批学生在氛围编码中迷失。

在您的编程课程中恢复学习闭环

Plagly.ai 为编程教育工作者提供了他们在 2026 年教学中所需的验证层:跨越每种主要语言的编程提交的 AI 生成检测、班级级别的模式分析、句子级(和行级)的证据报告,以及针对需要更深层文档记录的任何提交而设的 Agentic Council 多专家审查。教育工作者账户包含批量上传、班级仪表盘以及符合 FERPA 规范的数据处理。

免费试用专为教育工作者设计的 Plagly.ai

常见问题

问:氛围编码(vibe coding)总是坏的吗,还是有时是合理的?

对于在低风险个人项目上工作的经验丰富的开发人员来说,这是合理的,因为这些项目中的 Bug 成本很低,并且开发人员具备在关键时刻评估输出的底层技能。但对于仍在构建底层技能的学生来说,这是有腐蚀性的,因为它绕过了编程教育本应培养的认知工作。这种区别大致相当于主厨点外卖(没问题)与烹饪专业学生在期末考试中点外卖(有问题)之间的区别。两者都涉及接收他们没有烹饪的食物。但只有一个破坏了学习项目。

问:学生可以声称他们自己编写了被 AI 检测到的代码吗?

他们可以,而且有时他们说的是对的。代码检测中的误报在学生编写非常教科书风格的代码时最为常见,这些代码恰好符合 AI 通常生成的模式。值得提倡的工作流并不把检测得分当作判决 — 而是将其视为一个五分钟谈话的契机。自己编写代码的学生能够解释它,当场修改它,并跟踪其执行。而使用提示词生成的学生几乎永远无法做到这一点。解决问题的是谈话,而不是分数。Plagly.ai 的报告旨在支持该谈话,而不是取代它。

问:代码 AI 检测与散文(文本) AI 检测有何不同?

代码检测使用类似的统计基础 — 困惑度、突发性、文体指纹识别 — 但将它们应用于不同的表面特征。在代码中,最具信息量的信号是结构性的而非词汇性的:变量命名模式、注释密度和风格、库使用习惯、错误处理样板,以及惯用结构的选择。多模型融合检测器在 2026 年对孤立的代码提交可以达到 90-95% 的准确率,当班级级别的模式分析与文件级别的评分相结合时,这一比例可以攀升至 95% 以上。

问:如果学生仅仅将 AI 用作导师而不复制其输出会怎么样?

这正是验证层明确设计不予以惩罚的人群。使用 AI 理解概念然后自己编写解决方案的学生,所产生的代码在行级别上与 AI 生成模式不符。检测信号捕捉的是成品,而不是研究过程。如果您的课程政策允许 AI 担任导师 — 而且我们认为应该允许 — 该工作流程将继续起作用。您检查的是提交的作业,而不是学生的学习方法。

问:这适用于基于项目的课程和毕业设计吗?

是的,经过调整后适用。对于跨越数周、包含多个文件的项目工作,最实用的信号转移到过程可视化上:提交历史分析(代码是在一次大提交中出现的,还是随着时间推移演变的?)、文件之间的作者身份一致性(代码库读起来像是一个人写的,还是像不同的补丁缝合在一起的?),以及设计决策文档(学生能否解释为什么做出特定的架构选择?)。毕业设计式的项目从结构化的口头答辩以及书面的设计原理中获益最多,而 AI 检测是第三级信号,而不是首要信号。

针对特定 AI 模型检查文本

使用针对您怀疑的模型专门调优的检测器分析文本。

分享此文章

免费试用 Plagly.ai

以行业领先的准确度检测 AI 生成内容并检查抄袭。无需信用卡。

Get Started Free