1. AI正在改写软件工程教学的每个环节
去年秋季学期的一堂上机课，我让学生用Java写一个带异常处理的银行账户转账模块。以前的课堂上，这道题足够让大多数人忙上一整节课，而这次不到二十分钟，大半学生已经“完成”了。代码风格工整，异常处理齐全，甚至注释都比平时作业认真。但我把AI关掉，把其中一段代码改成了边界条件错误和隐性逻辑冲突的版本，让这些学生手动调试，结果大量学生卡住了。他们能快速“产出”代码，却说不清楚自己交付的东西为什么能跑。
这不是个别现象。AI编程助手、AI大模型、AI agent这类工具快速普及之后，软件工程专业的课堂教学正面对一个尴尬局面：写代码这件事的焦虑被工具消解了，可软件工程真正要训练的判断力、审查能力、工程质量意识，在“一键生成”面前反而变得更难培养。课程设计、毕业设计里，AI代写代码和代写报告的情况已经让很多老师头疼。作为软件工程课程的负责人，我花了一整个学期重新梳理了从软件工程导论、课程设计到毕业论文选题的教学方法，这里把实践过程中的观察、调整、踩坑和可复用的操作方案一起整理出来，给同样在一线面对这个问题的同行做个参考，也让学生提前理解课堂为什么正在变成现在这个样子。
1.1 编码类课程：任务重心从“怎么写”变成“怎么改、怎么审、怎么指挥”
传统软件工程课程里，编码能力几乎等同于语言语法、基础算法和代码风格的训练。学生从零开始写一个函数，记住类的继承关系，掌握集合框架的用法，这就是很多人理解中的“会编程”。但AI时代，代码生成这件事的门槛已经大幅降低。学生只要用自然语言描述清楚需求，AI能在几秒内给出一个基础版本。难点随之转移到了三个新能力上。
第一个能力是把需求拆解成AI能准确执行的指令。很多学生第一次用AI写代码时只会说“帮我写一个登录功能”，AI给出的往往是结构完整但完全不可用的泛化代码。会拆解任务的人会把输入条件、输出格式、异常情况、边界值、接口约束逐条列清楚，AI生成的代码可用性会大幅提高。我在课堂上让学生做过一个对比实验，同样一个“图书检索”功能，给AI一句模糊描述和一份包含字段约束、排序规则、空值处理的详细说明，生成结果的可用性差异极其明显。
第二个能力是审查AI生成的代码。AI生成的代码有一个典型特征：表面上规范齐全，但细节处经常藏着问题。比如无限循环的风险、类型边界溢出、异常被吞掉、资源未关闭。学生如果只是复制粘贴，这些问题会在集成测试阶段集中爆发。所以我的编码课现在有固定环节：拿到AI生成代码后，先不运行，逐行审查，记录可疑点，再执行验证。这一环节实际上是把过去“自己写代码”的精力转变成“御史台式挑错”的精力，训练量并没有变少。
第三个能力是整合与重构。AI生成的代码风格、命名习惯、架构思路和已有工程代码经常不一致。直接把AI代码塞进团队项目，会造成技术债沉淀。教学中我会故意给学生一个混合了三种不同AI来源代码的工程，让他们统一重构出可维护的版本。这个训练模仿的是真实工作中“接手别人代码”的场景，学生毕业后通常面对的第一件事，大概率不是从零写代码，而是给已有系统迭代功能。
注意：编码课不能因为AI能生成代码就取消手写代码的作业。我的做法是“手写基础题照考不误，AI辅助任务另设门槛”——手写题考语法、逻辑和调试基本功，AI辅助任务考的是需求拆解、代码审查和工程决策。两者不能互相替代。
1.2 需求分析与建模课程：AI生成用例图之后，教学锚点转向“缺陷识别”
软件工程导论里，需求分析、用例图、类图这些内容是学生公认“听着容易做题难”的部分。以往的教学套路是让学生对着案例问题画用例图、写需求规格说明书，老师再点评。现在麻烦在于，AI几秒钟就能生成一份看起来相当专业的用例图描述和需求文档。头歌这类平台上软件工程用例图的习题，学生用AI辅助完成的效率比人工画图不知道高了多少。表面上看这个环节的教学目标已经废掉了，但实际情况恰恰相反——AI的介入让需求分析教学有了更扎实的训练点。
AI生成的需求文档和用例图存在非常明显的硬伤：异常流覆盖不全，术语前后不一致，角色边界模糊，非功能性需求几乎空白。比如你让AI给“智能门锁系统”画用例图，它通常能列出开锁、关锁、查看记录这些主用例，但关于“电量耗尽时的应急开锁”“管理员被锁定后的恢复流程”“离线状态下的临时密码生成”这些异常流，AI经常选择性忽略。真实软件项目的复杂度，恰恰主要藏在这些异常流里。
我把课堂教学改成“AI生成加人工审校”的双流程结构。第一步，学生先自己画出用例图初稿；第二步，用AI工具生成同一系统的用例图；第三步，对照两份结果，找差异；第四步，以“缺陷报告”形式记录AI忽略掉的用例、冗余用例和错误关系。评分依据不是谁的图更标准，而是谁提交的缺陷清单更完整、更有说服力。课程最后回收的作业里，学生交上来的不仅是画好的用例图，更是一份对AI产出质量的评估论证。这个转变让我很意外——过去一个班的用例图作业有三分之一是高度雷同的标准答案，现在每份作业的“审校记录”都不太一样，学生被迫去参考国家标准、查阅业务场景，知识深度反而加深了。
1.3 测试类课程：测试用例可以自动生成，测试设计能力不能自动获得
测试教学受到的冲击比编码更隐蔽。常规单元测试、边界值分析、等价类划分这些内容，AI生成测试用例的速度和覆盖面远超学生手工编写。课堂上我让学生对一个字符串解析模块设计测试用例，学生拿出二十多行用例已经觉得自己很努力了，而AI在十秒内给出了覆盖正常、异常、空值、超长、特殊字符等几十种情况的测试集。看起来AI完胜，但当我把这个AI生成的测试集放进一个故意埋了三个细微逻辑漏洞的代码里时，多数学生发现不了问题——他们不知道AI生成的用例都覆盖了，但没有覆盖“临界状态转换”这种隐藏分支。
这里值得认真对待的一个点：测试用例的数量不等于测试的有效性。AI擅长从已知输入空间枚举样例，但它对“被试系统的业务逻辑缺陷在哪里”没有真正的理解。真正的测试设计需要人先建立“哪些地方最容易出错”的心智模型，再让AI去枚举覆盖方案。所以我在测试类课程里引入了一个新环节：学生先手工设计一个“平均故障最多的五个测试点”清单，然后让AI生成补充测试集，两者合并成一个完整的测试方案。课堂上要求学生对每个测试用例标注“这条用例针对的缺陷假设是什么”，这是AI永远替代不了的部分。
测试教学还要把工程标准落地。实验室里我会带学生一起读性能测试方法相关的标准，比如GB/T 39788-2021《系统与软件工程 性能测试方法》，让学生理解负载模型、性能指标、测试报告这些术语是怎么在工程中定义和执行的。AI能帮助生成压测脚本和报告模板，但性能测试中的并发模型设计、瓶颈定位和结果分析，每一步都需要工程判断。
1.4 软件工程过程与管理：AI agent正在重塑团队分工
软件工程课堂讨论比较薄弱的领域是项目管理。大多数学生毕业后进入的真实团队，已经不是传统的“一个人写模块、一个人写文档”的线性流水线了。AI agent的普及正在改变软件工程的协作结构：一个AI agent可以独立完成代码生成、测试脚本编写、文档整理甚至简单的代码审查，团队里的人类成员从“执行者”往“决策者、协调者、验收者”的方向转移。
我在高年级课程里设置了一个“多AI协作”的模拟项目。把三个AI助手的角色分别定义为“开发者”“测试者”“审查者”，让学生担任项目经理和技术负责人，负责分配任务、定义接口、审查结果、决定到底采信哪个AI的输出。这个设计模仿的是AI软件研发范式中的真实工作流——AI生成初稿，AI交叉检查，人类做最终决策。第一次操作这个项目时，课堂讨论异常激烈，因为不同AI常常给出互相矛盾的建议，学生必须像开会一样协调冲突，这在传统教学模式里几乎不会出现。
这个变化给课程的启示很明确：软件工程教育不能只教“一个人怎么开发软件”，还要教“一个混合团队怎么协作”。传统软件工程管理中的角色划分、里程碑设置、风险管理框架依然有效，只是角色对应的责任主体从“人”变成了“人和AI共同承担”。下图式的流程管理软件仍然值得学，但重点从“录入任务、跟踪进度”变成“定义AI可自动化的任务边界”。
2. 课程改革的核心思路——不是封禁AI，而是重构能力目标
评估了一轮课堂情况之后，我最深的感触是：直接禁用AI的路线走不通，也完全没有必要。学生的设备五花八门，课堂外根本管不住；更重要的是AI已经是行业真实使用的工具，学校屏蔽它等于让学生用过时的技能上战场。课程改革的关键，是把AI从“替学生做事的工具”变成“训练学生判断力的素材”。顺着这个思路，我把能力目标重新划成三个层次。
2.1 能力目标重构：会指挥、会校验、会决策
“会指挥”指的是学生要能用结构化的方式向AI传递意图，包括任务拆解、约束描述、质量标准定义、多轮对话纠偏。这一层对应过去“需求分析加设计”能力的延伸，只不过沟通对象从人类变成了AI。
“会校验”指的是面对AI给出的代码、文档、测试结果，学生有能力发现错误和隐患，并用验证手段确认。这一层对应过去的“代码审查与测试”，但工作要求大幅提高，因为AI产出常见“表面合理”，错误密度低但隐蔽性高。
“会决策”指的是在多个AI方案之间做出选择，判断什么时候该用AI、什么时候该手写、什么时候AI的结果不可信。这一层是软件工程经验和工程判断能力的综合体，也是本科阶段应该重点培养的素养。
用一个生活里的类比：以前我们培养的是“亲手盖房子的人”，现在我们要培养的是“能看懂图纸、会指挥施工队、在验收时能发现偷工减料的人”。亲手砌砖的能力仍然需要学，但人才培养的重心必须往上移。
2.2 课程矩阵：AI能力按年级分层递进
我按照年级建立了AI能力分层导入的课程矩阵。大一阶段，以计算机基础课程为主，保留手写代码练习的同时，允许学生用AI解释概念、生成练习题、调试简单语法错误，但核心课程考核中不允许依赖AI独立完成大作业。大二阶段，数据结构、算法、数据库等专业核心课开始引入AI辅助编程，要求学生提交“提示词记录”作为作业的一部分，并对手工实现的核心算法保留现场书写考核。大三阶段，软件工程、软件测试、课程设计这些课程全面拥抱AI，要求学生完成“AI生成、人工审查、补充测试、记录反思”的闭环。大四阶段，毕业论文和综合实训采用“AI开放但必须审计”的规则，所有使用过AI的部分都要在附录中写清楚使用方式和对结果的影响。
这套矩阵解决了一个之前很头疼的问题：不同课程的AI使用尺度不一致。以前专业课老师各有各的口径，有的完全放开，有的全面禁止，学生反而会钻空子。现在每门课开学第一节课会发一张“课程AI使用说明卡”，写清楚本课程允许用AI做什么、必须手工完成什么、违反规则的后果是什么。规则透明，边界清晰，执行阻力小了很多。
2.3 课程之间的口径协同：一张“AI能力卡片”打通所有课
课与课之间的衔接问题比想象中大。软件工程导论里如果允许学生用AI画用例图，到了课程设计里老师又要求手绘草图，学生就会困惑“到底该不该用”。课程设计要求用AI生成测试用例，到了软件测试课又要求全手工设计，同样会产生认知冲突。
解决办法是统一“AI能力卡片”制度。每门课程的大纲附上一张小卡片，包含四栏：本课程允许的AI使用场景、必须人工完成的场景、AI使用记录要求、违规处理办法。比如软件工程导论的卡片写的是：允许用AI辅助生成需求文档草稿，但人工必须完成异常流补充和术语一致性审核；用例图必须人工绘制终稿并留存AI草稿对比记录；违规处理是扣除该作业40%分数。课程设计课的卡片写的是：允许用AI辅助生成代码和测试，但必须提交完整的提示词记录和人工审查清单；最终答辩时随机抽代码段进行解释，无法解释的按代写处理。
这个卡片制度要对学生公开，同时课程组内部共享。不同课程的卡片可以横向对比，确保不存在一门课让AI“全包”、另一门课完全不让碰的情况。执行下来之后,学生的投诉和困惑明显减少。
2.4 改革路径建议：从课程设计这门综合性课程试点
我的一个直接经验是：不要把改革一开始就铺到所有课程。AI教学方法的落地牵扯到课堂流程、考核方式、工具环境、学生习惯多个因素，一次全改必然后会失控。比较稳妥的路径是从“软件工程课程设计”这门综合性实践课开始试点，理由有三条。
第一，课程设计本身就是多课程知识的综合应用场景，学生在课程设计里的表现能充分暴露AI使用情况和能力短板，改革效果最容易观察。第二，课程设计成绩影响相对集中，一门课的模式调整不会引发大面积课程连锁反应。第三，课程设计里学生投入时间最长、项目真实度最高，正好用来验证“AI辅助加人工审计”这个核心模式到底可不可行。我第一学期只改了这一门课，积累了完整的题库、评分量表和常见问题清单，第二学期再横向推广到软件工程导论和软件测试课程，阻力小很多。
3. 把方法落到课堂——四个可以直接复用的教学案例
方法说得再多，课堂拿不出可用的教案也是空的。下面这几个教学案例都是实际跑过一个学期以上的。每个案例我都写清楚了课前准备、课堂流程、产出物和评分标准，其他学校可以照着改造。
3.1 案例一：AI结对编程实验课
这个实验适合放在“软件工程课程设计”的编码阶段，目标是训练“人机结对”的开发习惯，时长两个课时加一周课后产出。
课前准备：选一个统一的AI编程环境，可以是大模型网页版，也可以是编辑器里的编程助手插件，优先选学生最容易访问、操作门槛低的形式。教师准备好一个结构完整的课后作业题目。我常用的任务描述是一个“图书管理系统”的借还模块，要求包含借出校验、还书日期计算、逾期罚金计算三个核心功能，外加输入校验和异常处理。
课堂流程分为四步。第一步，禁止写代码，学生先用自然语言把需求拆解成五条以上的具体指令，每一步必须包含输入、输出、约束条件和验收标准。第二步，把指令输入AI，得到第一版代码。第三步，人工审查第一版代码，找出至少三个缺陷或可疑点，并记录理由。第四步，针对缺陷修改提示词，重新生成第二版，然后手工补充两个关键测试用例，验证修复效果。
产出物有四样：提示词迭代记录、两版代码、缺陷清单、测试用例补充说明。评分量表我用了五个维度：需求拆解质量占20分，提示词优化能力占25分，缺陷发现数量与质量占25分，手工测试设计占15分，答辩表达占15分。这个实验做下来,最大的收获是学生第一次意识到“AI生成的代码不能直接信”，因为缺陷清单在评分中比重很高，他们开始主动较真。
3.2 案例二：用例图课堂——“AI生成加人工挑错”
这个活动放在软件工程导论的需求分析章节。课前让AI生成一个指定系统的用例图和用例描述，打印出来或发到学生端。课堂上不给原始需求文档，只给一个简要业务描述，让每位学生独立对照AI生成的用例图，找出至少五个问题并写“审阅意见”。要求审阅意见必须写到具体用例，比如“借书用例缺少‘读者已挂失’的异常路径”，而不是“用例不够完整”这种空话。
两节课各留出十五分钟做小组讨论：为什么AI会漏掉这些信息？哪些信息是业务常识但不在提示词里？如果你重新提问，会在提示词里加什么约束？讨论结束后，每位学生提交自己的增强版提示词和二次生成的结果对比。评分标准以“缺陷发现的覆盖广度”“提示词改进的有效性”两个维度为主。这个活动的隐蔽价值在于，学生必须真正理解业务规则才能写出有效的挑错意见，对需求分析的理解深度远超简单画图。
3.3 案例三：代码审查课——“找茬擂台”
代码审查能力是AI时代最值钱的工程能力之一，但常规教学很难让学生投入。我设计了一个“找茬擂台”活动：准备一段故意埋了八个错误的代码，覆盖空指针、数组越界、资源泄漏、逻辑短路、事务边界缺失等典型缺陷，同时让AI和学生分别审查同一个代码块。学生先独立找茬，然后比对AI的审查结果，最终提交一份“人机审查对比报告”。
报告包含三个部分：AI找到了哪些问题，我找到了哪些问题，AI没找到但是我找到的问题（或反过来）。课堂统计结果显示，AI对语法风格、未使用变量这类浅层问题非常敏感，但对涉及业务流程一致性的问题几乎无感。比如一个“支付成功后状态位被重置”的缺陷，AI很可能发现不了，因为它只在特定业务时序下才会触发。学生自己找出来的业务类缺陷会让他们很有成就感，也会更理解“为什么测试无法完全自动化”。
课后作业是让学生挑选一个自己项目里的模块，分别让AI和同学互审，写出对比报告。这个作业的完成情况通常出乎意料地好，因为“审别人的代码”本身就比“写自己的代码”更有动力。
3.4 案例四：课程设计与毕业论文选题指导
很多学生临近毕业设计选题时，习惯选那些“好做”的题目，比如某某管理系统、某某网站。这类题目在AI时代几乎没有训练价值——AI几天就能做完，学生学不到东西。我的选题指导改成从“问题导向”出发，鼓励学生寻找“AI能做部分工作、但核心决策需要人来判断”的方向。
我给出一个选题清单参考：AI辅助测试用例生成工具的有效性评估、基于代码审查日志的缺陷模式分析、低代码平台二次开发中的工程方法实践、AI生成代码的维护性度量研究、多AI协作流程在团队项目中的应用实验。这些题目有一个共同特征：都涉及“人类工程师与AI工具的协同质量评价”，学生必须做实验、收集数据、分析结果，而不是简单地把AI输出誊抄到论文里。
选题阶段用AI辅助头脑风暴是高效的。我提供给学生一组提示词模板，比如“请以软件工程课程设计为场景，列举三个适合本科生的研究题目，每个题目需要包含研究问题、数据来源、预期成果”，然后用节课专门过“筛选AI建议”这一步。AI给的题目很多很泛，学生必须逐一追问：数据从哪来？实验怎么做？结论对谁有参考价值？能在六个月时间完成吗？通过这轮筛选，留下来的题目比往届自己拍脑袋想出来的题目质量高不少。
4. 考核怎么改——把“AI代做”变成“AI使用能力”考核
考核是整个教学改革里最难啃的部分。传统的“交作业、改作业、给分数”模式在AI代做普遍化之后基本失效了。我换了思路：既然学生能用AI，那就把“怎么用AI、怎么用得好、怎么判断AI用得到底对不对”变成考核内容本身。
4.1 过程性考核：AI使用记录成为关键交付物
所有和AI相关的作业，统一要求提交一份“AI使用记录”。这个记录不是流水账，而是结构化的三段式说明：我让AI做了什么、我修改了什么、我为什么这样改。编码类作业还额外要求附上提示词原文和AI生成的初版代码，不得直接覆盖历史版本。一开始很多学生嫌麻烦，觉得“多此一举”，坚持一个学期之后，他们才明白这份记录本身就是能力和反思的沉淀。
评分时AI使用记录占作业总分的一定比例。重点看学生能不能说清楚自己做了哪些审校动作和决策依据。有份优秀作业让我印象极深，学生在记录里写：“AI第一版用了递归实现目录遍历，我改成了迭代加显式栈，因为递归在深层目录结构下会爆栈。”这就是典型的工程决策能力。而满分记录往往不是“AI用得最多”的作业，恰恰是“最会挑AI毛病、最会重构AI方案”的作业。
4.2 离线限时编码测试：AI时代的“照妖镜”
过程性考核之外，保留一两次离线限时编码测试非常有必要。考试环境断网、禁用AI辅助，题目设计上就不能是常规题，否则AI常跑出来的“惯性答案”学生可能已经背下来了。我设计考试题有一个原则：出AI训练数据里大概率没有的“非典型逻辑题”。
举个例子：让学生实现一个带状态机的命令行参数解析器，规则中混入了几条反直觉的组合约束，比如“当同时出现-a和-b时，-b的优先级在特定后缀条件下失效”。这种题目AI的训练集中很少出现完整版本，学生如果要硬记AI答案反而容易被规则绕晕，只有真正理解了状态转换逻辑才能做对。测试结果显示，这类题目比传统的“实现排序算法”区分度高得多。
4.3 答辩追问法：让AI代做无处遁形
课程设计、毕业设计这类大型任务，我坚持全息答辩制度。答辩不是让PPT念一遍，而是随机抽取学生提交代码中的一段，让他脱离PPT和编辑器，用自然语言逐步解释关键逻辑。追问有三板斧：“你为什么在这个位置做这个判断？”“如果输入变成空值，这段代码会发生什么？”“如果去掉AI工具，你能在同样时间内完成哪一部分？”
回答的效果真实反映出参与程度。真正动手做过、重构过AI代码的学生，即使表达不流利也能说出核心思路；完全依赖AI代做的学生，面对稍微偏离常见路径的追问，基本上只能复述AI生成的注释。这个办法不完美，但执行一个学期后，课程设计代做现象明显减少，因为学生都知道“会被随机抽到当堂讲代码”，只能自己把工程真正搞懂。
4.4 误用识别与学术诚信边界讨论
AI代做识别有一些可操作的信号：代码风格突然变统一（全班交上来的代码结构雷同），注释和实现逻辑对不上，引用不存在的库函数，作业完成时间短到不合理，答辩时支支吾吾。这些信号不一定能定论，但可以作为谈话抽查的依据。
更重要的是在学期开始就组织一次“AI辅助与学术诚信”专题讨论，把边界讲清楚。我给的规则是三条：可以借助AI完成机械性劳动（写重复代码、格式化文档、生成测试数据）；必须人工完成判断性劳动（软件架构决策、缺陷定位、方案评估）；所有借助AI完成的内容只要进入作业或论文，都必须可解释、可维护、可审计。这三条规则虽然无法穷尽所有情况，但至少给学生一个清晰的自我判断框架。
提示：千万不要一上来就把“用了AI”和“学术不端”划等号。一刀切反AI只会逼着学生隐瞒真实使用情况。先通过明确的规则和考核设计把行为引导到正轨，远比事后惩罚有效。
5. 教师备课与工具选型——不依赖某一家AI，而是形成教学工具箱
教师群体里最常见的一个问题是：“你觉得哪个AI工具最好用？”这个问题其实没有标准答案。教学场景对AI工具有特殊要求：第一要稳定可访问，第二要有过程记录能力，第三要支持不同复杂度的任务，第四还要能防止学生钻空子。所以我的建议不是“选一个”，而是建立一套覆盖不同场景的教学工具箱。
5.1 常见AI工具分类与教学场景适配
我把教学常用的AI工具分成几类。文本大模型通用性最强，适合做需求文档草稿、代码解释、项目方案讨论，课堂演示和课后任务都方便。AI编程助手嵌在编辑器里，适合编码实践课，能完成代码补全、单元测试生成、重构建议，但对学生的基础理解训练覆盖较弱。代码审查类工具和测试生成类工具各有侧重，适合在软件测试课和代码评审环节使用。此外还有图表生成和文档生成类工具，适合软件工程导论里的模板化文档任务。
教学场景中选型时要注意几个现实问题。第一是账号和网络环境，校园网里有些云端工具访问不稳定，一定要提前测试。第二是输出稳定性，有的工具在教学演示时会出现拒绝回答或内容过于泛化的情况，教师需要准备本地离线方案兜底。第三是数据安全，学生作业中可能包含个人信息，要提醒他们不要上传敏感数据。第四是学生之间的公平性，建议要么全班统一提供同一工具入口，要么允许自由选择但要求提交使用记录，避免“选对工具”变成扎堆的替代变量。
5.2 AI基础理论进课堂：提示词、上下文窗口、幻觉与评测
学生天天用AI，但对AI的工作原理知之甚少，这会导致一个典型问题：把AI的“幻觉输出”当成权威结果。我在课堂里增加了AI基础理论模块，不求深入推导，只讲四个和工程实践直接相关的概念。
第一是提示词的结构化方法。教学生用“角色加任务加约束加示例”四要素来写提示词，并通过对比实验体会模糊提示词和结构化提示词的输出差异。第二是上下文窗口的概念。告诉学生AI不是“无限记忆”，让它处理大型工程时要把信息拆成块，并在多轮对话里确认关键信息是否被正确理解。第三是幻觉问题。用实际案例展示AI生成不存在的API、不存在的标准条款、不存在的论文引用，并强调“用AI生成内容必须经过外部验证”。第四是AI输出质量的评测维度。从正确性、可维护性、安全性、性能四个维度看待AI生成代码，每个维度配合实例讲解评分规则。
这些基础概念不要求学生记住所有技术参数，但必须形成“AI输出的每句话都要验证”的肌肉记忆。后续课程中出现AI“胡说八道”的情况，学生第一时间想到的不再是“AI出错了”，而是“我要用什么方法验证”。这个意识的建立价值非常大。
5.3 机房环境与本地化部署的备选方案
校园网络环境不稳定几乎是各地高校的普遍情况。云端AI工具在关键课堂时间出现无法访问、响应超时的问题，会直接影响教学节奏。我准备了两层备选方案。
第一层是本地部署小规模开源模型，用于课堂演示和基础代码补全。现在的消费级硬件上跑一个量化版的中小参数模型，已经能完成代码解释、简单补全、文档草稿这类教学任务。第二层是教师自建题库配合离线AI沙箱。把常用的AI工具功能做成离线可用的简化版本，或者直接提前生成好AI输出结果，在课堂讨论中作为“预制备料”使用，避免现场依赖网络。
我实际操作中的经验是：教学任务对AI能力的敏感度没有想象中高。课堂上真正有价值的不是调用多强大的模型，而是任务设计本身。一个设计良好的对比分析任务，即使AI输出并不完美，也照样能引导学生展开深入讨论。反而过于追求“最强模型”容易把课堂变成工具推介会。
5.4 用AI给教师减负：备课、出题、批改的替代方案
教师对AI进课堂的抵触情绪，很多时候来自对“又要学新东西”的抗拒。我的应对思路是：先让教师尝到AI减负的甜头。备课阶段，AI可以帮助生成练习题变体、设计课堂讨论案例、整理教学素材。出题阶段，AI可以根据已有题库反向生成同难度、同考点的新题，经过教师审核后进入题库。批改阶段，代码风格和文档规范类的问题可以交给AI初筛，教师重点审阅逻辑错误和设计决策。
这些都不是理论设想，我这学期已经把AI用在两门课的出题和批改辅助上。原来出一份难度均衡的测试题大概需要半天时间，现在先让AI生成二十题，我再筛掉一半、修改三分之一、补两个自己设计的陷阱题，整体一个半小时搞定。省下的时间主要用于课堂观察和一对一答辩，教学效果提升明显。
6. 教师转型与教研路径——教改不是一场运动，而是一次升级
课程体系改不动，瓶颈往往不在学生，而在教师自己。不少老师还在用“我当年学软件工程的时候”的经验看待现在的课堂，对AI的了解停留在“听说过”的阶段。想让AI真正融入课程，教师是第一道关卡。以我自己的经验来说，关键不是报一个培训班，而是用最低成本在真实教学任务里练起来。
6.1 教师可以先完成的十个AI教学自测动作
我给团队老师列过一个“AI教学能力自测清单”，大家反响不错，在这里也放出来供参考。第一，用AI把一个旧实验任务改造成“指令拆解加审查”形式。第二，让AI生成一个含有至少三个缺陷的代码块，并设计参考答案。第三，让AI为一门课生成一份课程大纲初稿，再人工修订出终稿。第四，用AI批量生成同一个知识点在不同难度下的十道变体题。第五，用AI生成一份需求文档，然后人工找出其中的术语不一致和异常流缺失。第六，让AI审查一段自己写过的代码，观察它发现的漏洞是否准确。第七，用AI生成一份课堂讨论纪要模板，放入实际讨论结果检验效果。第八，自己手写一段代码，再让AI优化并解释优化理由。第九，用AI辅助设计一门课的考核评分量表。第十，把AI生成的内容逐条标注可信度，梳理出哪些内容需要人工强制校验。
这四个以上合格，六个以上良好，全部完成基本可以胜任AI辅助教学工作。整个清单大约需要三十个小时的实操，比任何一场两天培训都更系统。
6.2 教学研究可以从这些方向切入
对高校教师来说，教学改革同时也是一个研究机会。AI与软件工程教学的交叉点可以做不少实证研究。比如“AI辅助编程对软件工程学生代码理解能力的影响”这个课题，可以用对照班实验，一个班允许AI辅助，另一个班禁止，比较两个班在离线编码测试上的差距。“学生提示词质量与软件工程质量的相关性研究”也不错，直接用课程设计数据做分析，样本量充足。“AI生成代码审查教学对缺陷发现能力的提升效果”则可以通过前后测设计来验证。
这些研究方向的共同特点是数据容易采集、样本好获取、结论对教学实践有明显反馈价值。做研究的过程本身也会加深教师对AI教学方法的理解，形成“研究促进教学、教学带动研究”的正循环。我们这轮改革积累的评分量表、AI使用记录模板，已经可以作为研究工具变量使用。
6.3 少折腾、多沉淀：把教学AI能力当成软件一样迭代
最后想对同行说一句实在话：AI教学改革没有终态，不要指望一年之内就形成一套完美方案。这个学期引入一个案例，下个学期改进一套评分表，第三年再补一个工具选型清单，才是常态。我的做法是每学期末用半天做“教学AI能力复盘”：本学期哪些AI任务设计有效，哪些无效；评分量表有没有区分度；学生AI使用记录里反映出的共性弱点是什么；下一轮需要新增什么内容。
把教学改革当成一次持续迭代的软件工程来做，每次只改一个变量，保留稳定的对照组，不断观测学生反馈和学习产出。这个思路本身就符合我们教给学生的软件工程理念。这也是我现在最想传递的经验：用软件工程的方法做教学改革，让课程像软件一样持续演进，而不是每年推倒重来。
我个人在这一轮改革里体会最深的一点是：最难改的不是学生的使用习惯，而是教师自己的评价惯性。一开始我总是忍不住用“不能抄AI”的旧思路去判断作业质量，后来才慢慢接受“怎么用AI做得好”本身就是新的作业质量维度。一次期末答辩时，有个学生跟我们说：“以前我觉得软件工程就是写代码，现在才明白，真正值钱的是写完代码之后那些判断。”这句话让我觉得，这一轮折腾值得。
