AI进前端课堂三天实录：从教代码到教决策

上周我在自己的Web前端课上做了一个实验：连续三天，把学生练习和作业环节里所有“代码不会写”的问题，全部交给AI来解答，我退到一边只做规则制定、结果验收和问题点评。三天后课堂面貌的变化速度远超我的预期——学生开始给AI“下需求”，开始为一句话提示词吵起来，开始抓AI生成代码的漏洞。这是我在一线教Web开发五年来，第一次觉得课堂的主角不再是教材、不再是老师，而是“学生和AI之间的一段对话”。

这篇文章不是什么AI教学的标准答案，就是一次真实实验的记录和反思。写出来给三类人看：正在带前端学生的培训营或高校课程的老师，正在用AI辅助写代码但不知道怎么学的同学，以及所有对“AI会不会改变Web开发教育”这个话题感兴趣的人。我会把实验的设计逻辑、现场发生的事、踩过的坑、改过的评分标准，以及三天后我打算怎么重构整门课，全部摊开来讲。

1. 为什么我决定让AI进课堂——实验的起点

1.1 传统前端教学的三个死穴

我做前端培训已经五年，面对的学生大部分是零基础转行，或者刚进校门不久的大二大三学生。课程内容不外乎HTML、CSS、JavaScript三件套，再进阶一点是框架和工程化。老实说，传统教法下每个班都会遇到同样的三个问题。

第一个是反馈延迟。作业交上来我批改完再发回去，通常需要一到两天。等学生拿到评语时，他早忘了当时写那段代码时是怎么想的，更别说让他去复盘。课堂练习也是一样，四十个学生同时举手说“老师我这里报错了”，我一个个看过去，一轮下来半节课就没了，其他学生就干等着。反馈越慢，学习效率越低，这个道理放在编程课上比任何科目都明显。

第二个是低效错误消耗了大量精力。很多初学者卡住的地方根本不是逻辑问题，而是引号没配对、变量名拼错、标签没闭合这类低级语法错误。理论上这些错误几分钟就能排查完，但一个完全没有经验的学生可能要耗上半小时甚至一整晚。等他终于把语法错误修完，精力也耗尽了，根本没有余力去琢磨这个功能到底该怎么设计、数据流该怎么走。大量本该用来训练“编程思维”的时间，全被浪费在“打字正确”上了。

第三个问题是练习场景失真。传统作业往往是一个静态页面，写完交上来就结束了。但真实的前端开发不是从零开始写一个页面，而是在一个已有的项目里读代码、改代码、修bug、和接口联调、做浏览器兼容。学生学完三件套，会写几个漂亮页面，却完全不知道怎么在一个Web工程里协作，这其实是很严重的能力断层。

这三个死穴加起来，导致前端教学长期处在一个尴尬的位置：老师累、学生苦、出去找工作还是被面试官说“基础不牢”。我一直在找有没有什么东西能把老师从“低级重复答疑”里解放出来，让学生把精力放回真正该练的“判断和设计”上。AI的出现，恰好戳中了这个痛点。

1.2 工具选型：为什么课堂场景下我选了对话式AI

决定做实验之后，第一个问题是选什么工具。目前市面上能帮学生写前端代码的工具大致分三类：对话式大模型、IDE内联补全、AI Agent。我在备课时把三类的课堂效果都试了一遍，最后保留了对话式AI作为主力，另外两类只做了解性演示。

对话式AI的代表就是ChatGPT、Claude这类产品，学生把问题打成文字发过去，它返回解释和代码片段，整个推理过程是显性化的。IDE内联补全的代表是Copilot，写代码时它帮你续写下一段，主打“快”，但学生往往只会按一下Tab，完全来不及理解这段代码为什么这么写。AI Agent级别的工具更猛，像现在不少学生自己下载的前端开发插件，你给一句任务描述，它能自己改文件、跑命令、提交代码，全程不需要人参与。

从教学角度讲，内联补全和Agent都会把思考过程给吞掉。学生看到的是“代码自己冒出来了”，这和我想要的东西正好相反。我要的是学生能够清晰地表达问题、拆解需求、审查结果，这三个能力在对话式场景里是挤压不掉的。所以课堂主力我定为对话式AI，并且要求学生必须把提问记录保存下来，作为作业的一部分。

这也埋下了后面几天课堂变化的伏笔。第一天还风平浪静，第二天开始，有学生偷偷装了Agent类的工具，这就引发了关于“边界”的争论，后面我会专门讲。

2. 三天课堂实录：规则、加速与评价体系重建

2.1 Day 1：立规矩，AI是教练不是代练

第一天上课，我做的第一件事不是教操作，而是立规矩。我在黑板上写了三句话：AI可以回答你的任何代码问题，但你必须能当面解释它给你的每一行代码；AI帮你写代码，你必须自己验证它能不能跑、对不对；所有对话记录截图保存，提交作业时一并交上来。说白了，AI是教练，不是代练。

规则立完，学生开始做当天的练习：用原生HTML/CSS/JavaScript写一个待办事项应用，支持新增、删除、标记完成，数据存在localStorage里。这个题目在往届学生里一般要花一整节课加课后两小时才能完成，而且会有三分之一的人做不出来。

有了AI之后，出现了两个很有意思的现象。第一个现象是，学生的提问方式在一个小时内肉眼可见地进化了。最开始有人直接把题目往对话框里一丢：“帮我写一个todo应用”，AI确实会生成一个完整代码，但这种学生往往被代码量吓住，改也不敢改。另一部分学生在我的引导下学会了拆任务，有人问：“用localStorage存数据，刷新页面后怎么恢复勾选状态，谁能给我讲讲思路”；有人问：“我要写一个删除功能，点击垃圾图标删除对应那条数据，事件绑定用哪种方式比较好”。这些问题质量明显更高，说明他们已经在一个具体的问题点上思考，而不是空泛地“帮我写一个”。

第二个现象是，低级报错的求助量断崖式下降。那天课堂上有学生报错，我故意没有过去看，让他去问AI。AI不仅能指出是引号没闭合，还能把正确写法展示出来。过去我至少要花五分钟处理一次的问题，现在学生自己三十秒就解决了。但我也发现，AI把所有底层问题都兜住之后，学生反而容易“懒得想”。有几个人拿到代码直接复制粘贴，连注释都不改，下课后根本解释不清楚。所以当天快结束时，我临时加了一个环节：随机抽人上去，现场往AI生成的代码里加一个需求，让他边改边讲思路。

现在回头看，这个“随机抽人+现场改需求”的环节非常关键。它保证了学生不敢完全不思考直接复制，也为后面评分体系的重建埋了伏笔。第一天的经验教训就一条：AI进课堂不是简单地发个账号，规则必须前置，并且要配套“验证手段”来兜底。

2.2 Day 2：学生开始审AI的代码

到了第二天，课堂状态开始变得不受控了，这是我预期的方向。

上午的练习是做一个带筛选功能的产品卡片列表，要求包含数据渲染、分类筛选、空状态展示。我把学生分成三人一组，每个组内做了角色分工：一个人负责向AI提问和持续追问，一个人负责在本地运行代码、测试功能，一个人负责审查AI生成的代码有没有问题。三个角色每练一个任务就轮换一次。

这个设计本来是为了让所有人都参与，结果效果出奇地好。过去那种“一个人写代码三个人围观”的局面消失了，因为AI承担了产出代码的角色，人的任务变成了“管住AI”“验证产出”“判断对错”。一组学生在审查AI生成的筛选函数时发现，AI把筛选逻辑写进了渲染函数里，每次点击筛选按钮都会重新渲染整个列表，功能没问题，但性能很差。几个学生就开始讨论要不要引入缓存，虽然他们当时讲不清术语，但方向上已经很接近“计算属性”和“虚拟列表”这些工程概念了。

另一组的情况更刺激。AI给它们生成了一段删除功能的代码，用的是事件委托，在列表容器上监听click事件，然后判断点击的是不是删除按钮。结果组里有个同学说，之前AI生成过另一版，是把点击事件绑定在每个按钮上的。两版代码都能跑，但全班出现了分歧：有人说事件委托更省内存，有人说直接绑定更直观。我顺势在黑板上把两种方案的优缺点画了出来，顺势讲了事件冒泡原理，这是往年要到课程中段才会涉及的比较深入的DOM知识。而今年，学生在真实的代码审查场景里主动撞到了这个问题。

第二天的核心变化其实是教师角色的转变。我已经不太像一个“知识讲授者”了，更多时候在充当“验收标准的制定者”。学生问我最多的问题从“老师这行代码是什么意思”变成了“老师这样算不算好代码”。后者需要我讲清楚性能、可维护性、可访问性、语义化这些评价维度，这恰恰是目前很多前端课程里缺失的部分。也让这场实验的价值出现了第一次集中爆发。

2.3 Day 3：评分体系翻车后的重建

第三天的上午，我用传统标准收了一次作业，然后直接翻车了。

翻车原因很简单：所有作业看起来都很完整，因为代码都是AI生成的。语法干净、注释完整、功能齐全，按旧标准这些作业全是高分。但我随机抽人提问，明显感觉到有人答不上来。如果照旧打分，等于在告诉学生：只要会问AI，就能拿高分。那这门课就真的废了。

我紧急改了一套新的作业提交规约，当天下午就宣布。规约要求四样东西：第一，代码；第二，完整的AI对话记录截图；第三，一份修改说明，列出哪些代码是AI生成的、哪些是你自己改的、为什么改；第四，一份测试结果记录，你在什么浏览器、什么数据下验证过哪些功能。听起来复杂，其实就是要让整个思考过程“显形”。

配套的是一张新评分表，核心逻辑从“给代码打分”变成“给决策打分”。功能完整度变成前提项，只要功能没做完，后面不予评分；真正的评分维度变成“需求理解能力——提示词是否准确表达了需求”“问题拆解能力——有没有把大任务拆成小步骤提问”“代码审查能力——能不能指出AI代码里不合理的地方”“验证能力——有没有主动测试边界情况”。我会在后面放一份完整的对照表，这里先说结果。

这套评价标准改变之后，当天下午的作业质量完全不一样了。做作业变成了写对话记录、查文档、调整方案。学生提交的AI对话记录里，出现了大量追问：“为什么这里要用createElement而不是innerHTML”“localStorage满了怎么办”“这个筛选函数的时间复杂度是多少”。这些问题放在传统课堂里，属于教师求着学生问都问不出来的级别。

三天的课堂氛围变化最直观。往届课堂答疑区的低端报错几乎绝迹，取而代之的是技术选型、性能取舍、兼容性选择这类讨论。互动密度高了三四倍，并且讨论的主体不再是“我和一个学生”，而是“学生和AI之间反复拉扯之后，再把问题抛给我”。我作为教师的角色不再是搜索引擎，而是裁判和标准制定者。

3. AI教前端时，教的到底是什么——课堂上正在发生的三种位移

3.1 技能栈位移：从手写能力到审稿能力

三天的实验做完，我脑子里一直盘旋着一个问题：AI教的到底是什么？表面上是代码，实际上是一种技能栈的整体位移。

过去前端工程师的核心能力是“写”：把设计稿切成页面、把接口数据渲染到界面上、把业务逻辑封装成函数。初学者围着“怎么写出来”下功夫，各种快捷键、属性、API背得滚瓜烂熟。但现在，AI能把七八成的“写”完成，而且完成得比新手快得多、规范得多。这种情况下，人力资源的稀缺点就不再是“写代码”，而是“判断代码好不好”和“让代码符合复杂业务要求”。

这就好比以前的编辑要会手写字，后来打字机普及了，你的核心能力就变成了遣词造句和校对；再后来AI能一口气写十篇初稿，你的核心能力就变成了定方向、给框架、改重点、审事实错误。前端开发者的角色也在经历同样的变化。

所以我在课堂上明显感觉到，学生对“阅读代码”的兴趣高了。过去学生更爱缠着你问“怎么写”，现在他们最大的困惑变成了“AI这行代码是什么意思”“AI为什么这么写”“我能不能改成我知道的写法”。这些困惑虽然暂时让他们觉得吃力，但实际上是往真正的前端工程能力靠拢。

3.2 提示词即需求文档：提问质量的背后是理解深度

三天实验里，我批改最多的不是代码，而是对话记录。看学生和AI的对话，比看代码更能看出一个人的真实水平。

一个只会背语法、不理解业务逻辑的学生，他问AI的问题往往是“帮我写一个页面”这种一句话需求。AI给他一个通用方案之后，他看不懂，改不动，最后只能干瞪眼。反过来，一个平时成绩还不错的学生，会这样提问：“我要做一个卡片列表页，数据源是本地的JSON数组，需要在卡片上显示标题、图片和价格，点击卡片跳转到详情页。使用原生JS实现，要求渲染函数和数据操作分开，先给我一个结构设计，我再决定具体实现。”这个提示词一出来，我基本能判断，这个学生已经理解了分离关注点、数据驱动渲染、模块划分这些核心概念。

我后来总结出一个教学用提示词模板，在课堂上发给学生：

角色：你是擅长前端开发和技术讲解的助手。 任务：实现一个[页面/功能]，要求满足[功能清单]。 边界：不使用[框架/库]，或者必须使用[某技术]；兼容[目标浏览器]。 验收：请先给出方案设计和关键伪代码，我确认后再输出完整代码。

这个模板的目的不是让学生背下来，而是强迫他在提问之前，先想清楚自己的需求是什么、有哪些约束条件、怎么验证完成了。能把这几个问题回答出来，写不写代码其实已经不重要了。这个思路放在真实Web开发中完全成立——给AI提需求的提示词，本质上就是一份简化版的需求文档。

3.3 课时结构：哪些必须重排，哪些不能动

AI进了课堂之后，教学内容的重排几乎是必然的。我原来花很多课时讲CSS的各个属性、JavaScript的各种API，都是“讲授式+练习”按部就班。现在这些内容AI秒出结果，学生也缺乏耐心听我逐条念文档，再这么上就没意义了。

我打算把原课时结构砍掉一大半，改成“场景导向”的模块：先给一个真实项目的小页面目标，让学生用AI辅助实现，实现过程中遇到什么概念，就现场拆解什么概念。比如第一天练的是布局，遇到弹性盒子时讲解flex，遇到定位时讲解position。这种“以项目带知识点”的方式，学得快、记得牢，而且学生自己动手验证过，比PPT上干讲管用得多。

但这个重排有底线。有三块内容我坚决不压缩：DOM事件机制、异步流程控制、数据模型设计。AI可以帮学生写出很漂亮的addEventListener或者fetch调用，但它很难解释清楚事件冒泡捕获的机制、回调与Promise之间的控制流转换、以及状态变化如何驱动界面更新。这三块恰恰是前端面试和真实业务里最常问、最难靠AI代劳的部分，也是Web开发区别于“套模板”的护城河。把这三块扎扎实实讲透，AI才真正是助力而不是替代。

可访问性这一课以前往往被放到选讲或者不讲，现在必须提前。因为AI生成的代码看起来很整洁，但经常出现图标只有装饰性div、没有aria标签、对比度不足这类问题。这些代码能跑，但放到真实Web项目中是会被无障碍扫描工具标红的。教学生审查AI生成代码时，应该把可访问性和响应式放进去，这比多练十个页面更有价值。

4. 翻车现场：四类高频问题与处理方案

4.1 代写全案：怎么分辨学生是真会还是假会

第一个翻车现场，也是我最担心的：代写。实验进行到第二天晚上，班里有个男生交了一份作业，代码非常完整，还附带了一个漂亮的README，明眼人一看就是AI全盘生成的。我把他叫过来，现场提了一个需求：把列表里的删除功能改成二次确认弹窗。他愣在原地，手放在键盘上不知道该干什么。过了两分钟，他说“老师你等我一下，我问问AI”。

这个案例很典型。关键不在于不能问AI，而在于他连“弹窗里应该包含哪些按钮”“点击确认后调用什么方法”“取消怎么关闭”这些最基本的步骤都理不清。他完全不知道AI在替他做什么，所以面对改动就彻底瘫痪。

我的处理方式有三步。第一，把规定再收紧，明确要求：凡是AI生成的核心功能代码，学生必须在旁边手写注释解释逻辑，不能用AI生成的注释充数。第二，作业必须附带修改说明，标记哪些代码是手工改过的；每天开课前随机抽人，现场做“功能变更”小测，题目都不难，就是往原有AI代码上加需求，观察他能不能自己定位、调整。第三，在评分表里增加“独立修改”专项分，独立改动越多、思路越清晰，分数越高。事实证明，效果立竿见影，后面几天再没出现过“带不走代码”的学生。

4.2 AI幻觉代码：能跑不等于对

第二个翻车来自AI本身：幻觉代码。课上有个学生让AI帮他做一个“网页端实时消息提示”功能，AI生成了一整段代码，看起来逻辑严丝合缝，还在注释里写了一个API地址。学生运行之后页面报错，他反复查自己的代码都没找到问题，最后把错误信息丢回给AI，AI才承认它编造了一个不存在的API接口和返回字段。

我把这个案例拿到全班做了一次“代码体检”教学，专门列举幻觉高发区，提醒学生重点审查：CSS里不存在的属性或新属性在旧浏览器的兼容性，比如flex的gap；JavaScript里虚构的数组方法或对原生API的错误理解；第三方库的接口名称和参数；npm包的最新版本号；API的返回数据结构。这些区域AI的犯错率明显高于普通代码。

怎么防？我的口诀是“AI说的不算，跑了才算”。要求学生把AI生成的代码里涉及外部接口、浏览器兼容、版本依赖的部分当成高危代码，必须手动验证，或者让AI把代码对应的官方文档链接列出来再去核对。看AI生成的代码没有错也不能信，要看它背后引用的标准是什么。这种“怀疑AI、验证AI”的意识，现在已经成为学生的本能反应。

4.3 两种极端心态：依赖与恐慌

第三个问题是情绪层面的。实验进行到第三天，班级里出现了两种极端心态，经常在同一个人身上同时出现。

第一种是过度依赖，有个学生直言，“老师，既然AI能写代码，那我学底层还有啥意义呢”。这种心态很危险，他会把AI当拐杖，理解能力彻底停摆。第二种是恐慌，另一个学生焦虑地问我，“老师，AI都能写前端了，前端面试题是不是以后就没了，我还学这个干嘛呢”。这两个问题其实指向同一件事：对AI与Web开发关系的认知还不清楚。

我的回应是拿面试题说事。2026年的前端面试题已经明显在变化，还抱着“CSS里有几个隐藏文本的方案”这种背诵型问题死磕，意义不大；现在真正有区分度的题目变成了“给你一段AI生成的代码，你能说出它有哪几个潜在问题吗”“如果让你用AI重构这个组件的状态管理，你会怎么设计提示词”“这个页面在低网速下加载慢，你能定位到瓶颈吗”。这背后考验的就是代码审查能力、系统设计能力和调试能力，这些能力不可能靠AI替你练出来。

至于“前端会不会消失”这种大问题，我给出的回答是：Web不会消失，但干重复活的前端会消失；会用AI把自己从低水平劳动里解放出来，把判断力、设计能力、协调能力提上去的前端不会消失。课堂上的作用也是一样，AI不会取代学生，但会定义问题、会验证结果的学生不会被取代。

4.4 新的作业评分标准：给“决策”打分，不给“结果”打分

传统前端作业评分有个通病：好的标准模糊，差的都统一归为“功能没写完”。AI时代的作业评分，需要一张更清晰的表格。

我在实验三天后定了一套标准，列出几个维度，和旧的评分方式做对比：

这套标准一落地，效果很明显。学生不再比拼谁交的代码长，而是比拼谁的对话记录里围绕同一个需求来来往往的次数更多、边界问题思考更周全。有人会在对话记录里问AI“如果用户连续点击删除按钮会怎样”，把边界情况纳入考量。这类问题是过去期末大作业里都很少见到的思考深度。

我知道一定会有老师担心，新标准会不会导致学生手写能力变差，以后遇到没网的环境就抓瞎。这个问题我在实验结束后专门做了测试，把AI撤掉，出了一套限时手写小测。结果确实比往届稍有下滑，主要是速度和API细节，但逻辑完整度和思路清晰度反而有所提升。AI帮学生腾出了记忆细节的体力，让他们把精力压在了推理和判断上，长期看这是划算的。

5. 三天之后：我在改的课纲与给同行的第五课

5.1 新版课纲的四个模块设计

实验结束后，我立刻着手改造整门前端课程的课纲。目前设计是四个模块，每一个模块都对标一个明确的能力目标。

第一个模块叫“人机协作基础”，两周时间，目标是让学生掌握“和AI一起工作的规矩”。这个模块不讲太多语法，而是讲提示词框架、AI幻觉识别、对话记录复盘、代码审查清单。这相当于给每个学生发了一副“AI驾驶的驾照”，先学会刹车和看路再上高速。

第二个模块叫“Web核心原理”，这是保留下来并加厚的部分。CSS布局、JavaScript语言核心、DOM机制、异步流程、浏览器工作原理、网络请求，全部采用项目驱动的方式来讲。以前是知识点坐车、练习当陪跑，现在是项目当主角、知识点在项目中蹭亮登场。这个模块也是整门课的护城河，AI取代不掉的核心概念都在这里。

第三个模块叫“真实项目实战”，四周时间做一个完整的Web项目，从需求拆分、数据结构设计、UI实现到部署上线。学生在这个过程中要用AI辅助完成大部分编码工作，但每个关键设计决策都要自行论证，并在代码审查会上讲清楚。这个模块的训练目标，就是把课上学的提示词能力和代码审查能力放到真实压力下面检验。

第四个模块叫“求职与面试准备”，专门应对已经变化了的面试题。这个模块不再让学生死背概念，而是让他们直接面对“AI生成代码后发现问题”“手工调试”“需求评审”“重构讨论”这类场景化面试题。面试官越来越喜欢问“你在开发过程中如何使用AI”这类问题，因此学生需要在面试前准备好，说明自己的AI使用边界和验证方法。

5.2 给想试的同行：一周内就能启动的实操清单

如果你也想在自己的前端课堂里做类似实验，我整理了一份一周内就能启动的最小清单。

技术准备先做三件事：去申请一个可用的AI产品账号，自己提前准备三个完整的课堂演示提示词，再找一个真实业务页面作为训练素材。规则准备也很重要，把“AI使用边界”写成课堂守则贴在显眼位置，核心是“AI生成代码必须有注释和自己的理解记录”。心理准备这条才是最关键的：学生比你上手快，他们甚至会嘲笑你的提示词不够优化，这非常正常，坦然接受即可，你要做的不是比他们更懂AI技术，而是比他们更懂评判标准。

最后分享一个我在班级黑板上一直留着的句子：“AI不会取代前端工程师，会用AI的前端会取代不会用AI的前端，但在课堂上，这句话要改成——AI不会取代学生，会定义问题、会验证结果的学生，不会被AI取代。”我自己的体会是，跑了三天实验，最值钱的不是学生成绩提升了多少，而是我第一次在教室里看到一个个年轻人在面对一台会写代码的机器时，仍然敢提出问题、敢于质疑、敢于动手改它。这个能力本来就是教育应该给的东西，AI只是帮我们把它逼了出来。