AI时代软件工程教育：从写代码到为AI产出负责

老师，我现在学软件工程，是不是白学了？

问这句话的，有大一新生，有大三准备秋招的，也有刚拿了实习 offer 回来跟我报喜、转头又陷入自我怀疑的。说实话，我第一次听到这个问题时是愣住的。教了十几年软件工程课程，从来没有哪一届学生像现在这样，一边拿着 AI 工具把作业写得飞快，一边又对自己的能力极度不自信。

后来我带着教研组折腾了大半年，做了企业访谈、跨校调研、三轮课程试点，才慢慢想明白一件事：不是软件工程这门课没用了，而是我们教软件工程的方式，已经跟不上 AI 时代真实研发场景的底层逻辑。

这篇文章算是一份阶段性的教学研究报告，也是我在一线改课过程中攒下来的实操记录，不吹概念，只讲做法。核心就回答三个问题：AI 到底改变了软件工程岗位的什么底层能力？课程体系要怎么重构？改完之后，课程设计、毕业选题、考核方式和老师自身怎么配套落地？内容主要面向软件工程专业的教师和教学管理者，对正在迷茫选课、准备毕业设计的同学，也建议顺着后面的选题思路对照一下自己，很值得参考。

1. AI 对软件工程岗位能力模型的冲击，超出大多数课程的预期

1.1 学生问“学了是不是白学”背后的真实信号

这个焦虑不是个别现象。我带的课程设计班级里，过去做一个图书管理系统要六到八周，学生吭哧吭哧写上千行代码。现在呢？我做过测试，让大三学生用 AI 辅助，三天能跑出一个界面完整、功能齐全的版本，速度快得吓人。但答辩环节马上露馅：问登录会话怎么维护的，答不上来；问购物车库存并发扣减怎么处理的，一脸茫然。

这说明什么？说明 AI 把“写代码的速度”问题解决了，但把“代码判断力”问题放大了。以前代码写得慢，是被语法和框架反复毒打，这种毒打虽然痛苦，但让学生的脑子里留下了“因果链”——改了这一处，那一处会坏。现在 AI 把中间过程全抹掉了，直接给成品，学生如果不具备识别对错、定位缺陷、理解设计取舍的能力，那就真的成了“点按钮的人”。

这不是学生变懒了，而是我们课程培养的目标能力结构出了问题。我们不能继续只教“怎么写”，必须把教学重心挪到“怎么判断、怎么负责、怎么和 AI 共同产出”上面来。

1.2 企业在招聘与用人上到底变了什么

我先说自己调研里最直观的部分。这两年我陆续访谈过十几位技术负责人，有做企业级软件的、有做互联网平台的、也有做行业信息化的小团队。他们的 JD 变化非常一致：初级程序员岗位的描述，从过去的“熟悉 Spring、MySQL、Redis”这类框架清单，开始大量增加“熟练使用 AI 编码工具，能对 AI 生成代码进行审查与修正”“负责 AI 辅助生成模块的质量保障”之类的新要求。

请注意一个关键点：企业没有说“不要会写代码的人”，他们说的一直是“能看懂、能修、能测、能负责”的人。有一位做外包公司的技术总监说得特别直白：“我们现在敢让新人用 AI 写 80% 的代码，前提是他把剩下 20% 的坑给我填明白。什么人我们不敢要？AI 生成的代码报错了连日志都不会看的人。”

这就把软件工程教学的培养目标直接改写了。传统课程的能力模型是线性的——需求分析、设计、编码、测试、维护，每个环节按部就班。而 AI 时代的能力模型更像一个循环：提出任务、拆解任务、用 AI 完成任务、审查产物、修正偏差、沉淀经验。这几个环节里，编码本身被极大压缩，审查、修正、责任判断的权重陡然上升。

我总结下来，岗位需要学生具备的可迁移能力大概有五个：任务拆解与提问能力、代码阅读与审查能力、测试设计与反例思维、架构权衡决策能力、协作与验收责任意识。后面所有课程改造，本质都是在围绕这五条能力重新做文章。

1.3 从“AI 工具辅助”到“AI 原生研发范式”的迁移

很多老师对 AI 进课堂的理解还停留在“学生用 Copilot 补全代码”这个层面。我一开始也是这么想的，直到和企业交流、观察学生真实使用行为后，才意识到这一轮变化的深度。

研发模式正在经历三层递进。第一层，AI 是代码助手，人写逻辑，AI 补全、生成片段，和多年前的代码提示没有本质区别。第二层，AI Agent 开始承担完整子任务——让它“给这个模块补一套单元测试”“查一下这段日志里的异常分布”“把这个接口的 mock 数据生成了”，它真的能干。第三层，AI 原生研发范式，AI 嵌入全流程：需求阶段生成 PRD 初稿，设计阶段生成接口文档和初步架构，编码阶段完成大部分实现，测试阶段自动维护回归用例，人的角色变成定义标准和做关键节点的质量守门员。

我举一个教学过程里的例子。以前讲需求分析，学生需要从零开始访谈用户、整理用户故事、画用例图，一套流程走下来几周。现在学生用 AI 生成一份 PRD 草稿，这并不难，难的是发现草稿里“自动登录”和“账号安全”两个需求存在冲突，并决定以哪个为准。这种“发现矛盾、做出取舍、承担后果”的能力，恰恰是 AI 给不了、也恰恰是软件工程课程最有价值的部分。

所以我在教研组里反复和同事们对齐一个认知：课堂教学不能只教“用 AI”，而是要把“AI 原生研发模式下的工程判断”当成新的核心素养来培养。这一条想清楚，后面的课程体系怎么改，就有了总纲。

2. 课程体系如何重构：保留什么、增强什么、新增什么

2.1 基础编程与数据结构课：为“人机协作编码”重建地基

第一反应“禁止用 AI”是不现实也不科学的。学生课外偷偷用，你根本管不住，而且这本身也违背工具发展的方向。我的做法是双轨并行。

第一轨叫“裸编码能力考核”。每章安排固定的限时练习，难度控制在学生独立能完成的范围里，禁用任何 AI 工具，目的就是检验个体编程的基础能力。这一轨绝对不能取消，它是学生判断 AI 输出的底气。一个链表反转都要靠 AI 的人，是完全没有能力审查 AI 写的树的遍历代码的。

第二轨叫“AI 加速任务”。给一个真实的功能目标，允许用任意 AI 工具，但必须提交一份“AI 使用说明”，内容包含三块：我给了 AI 什么提示词、AI 返回了什么、我修改了哪些地方以及为什么这么改。这个说明才是真正教学发生的地方。

我后来在数据结构的课程试点里发现一个很有价值的现象：学生刚开始给的提示词往往很粗糙，比如“帮我写一个红黑树插入算法”，AI 生成后运行报错，他又把错误粘回去，AI 再改。几个来回之后，他慢慢学会在提示词里写清楚约束条件、输入输出格式、性能要求、不要使用什么库——这不就是需求规格说明的训练吗？所以说，与其禁止，不如把它设计成教学工具。

这里有一个重要观念：AI 编程时代，代码写得快不是本事，知道代码为什么错才是本事。基础课的地基，要从“手写能力强”转向“手写能力 + 审查能力”共同发展。

2.2 软件工程导论课：概念不动，案例与作业全面换血

软件工程导论课，包括经典的“软件工程导论头歌”这类线上练习，讲的核心概念——需求、设计、测试、维护、项目管理、敏捷开发——并没有过时。但必须承认，如果还用 2015 年的案例、2015 年的作业来教，学生一定会觉得这门课是“考古学”。

我的处理方式是：概念框架保留，案例和作业彻底换掉。讲生命周期模型时，让学生用 AI 生成同一个项目在不同模型下的文档链，比较“文档成本几乎为零之后，为什么我们还需要设计评审”；讲需求工程时，把传统的“用例图”建模练习保留，增加一个环节：给定一段用户会说的大白话，让学生先用 AI 生成候选用例集，再人工筛选、合并、补漏，最后画出用例图。

这个改动看着不大，但教学效果完全不一样。以前学生画用例图是为了交作业，现在画用例图是为了让 AI 更好地理解需求、生成更准确的测试用例——工具变成了思考的脚手架，而不是负担。

导论课还应该补一个以前没有的讨论题：一个研发团队从 5 个人变成“3 个人 + 若干 AI Agent”的时候，原来的角色分工（产品经理、架构师、开发、测试、运维）哪些会消失、哪些会增强、哪些是全新的？这个讨论没有标准答案，但每一次都能把课堂气氛引向对软件工程本质的思考——软件工程管的是复杂度，而 AI 重构的是复杂度的分布方式。

2.3 新增课程群：大模型基础、Agent 构建与 AI 测试

课程体系光靠改造老课不够，必须新增部分内容。根据我们的试点经验，有三门课值得尽快纳入，不一定要都做成独立课，可以先用“模块”的方式嵌进高年级课程里。

第一门是《大模型应用开发基础》。不等同于“教 prompt”，而是要让学生理解大模型的能力边界和调用方式。内容包括：提示词工程的基本方法、上下文窗口与记忆管理、检索增强生成（RAG）的概念、模型微调的基本原理、幻觉现象与检测手段、API 调用的成本与限流。学完的产出是“能独立完成一个带知识库的问答 Agent，并清楚说明它在什么场景下会答错”。

第二门是《AI Agent 构建与评测》。这是目前企业最缺的方向之一。内容涵盖 Agent 的任务拆解、工具调用、记忆机制、规划策略，以及多 AI 协作的编排方式——一个 Agent 负责需求理解，一个 Agent 负责代码生成，一个 Agent 负责测试验证，学生作为“总编”负责协调它们。课程的关键不是把 Agent 跑通，而是建立评测体系：什么样的任务适合交给 Agent、准确率怎么算、失败怎么恢复。

第三门是《AI 辅助软件测试》。传统测试课讲用例设计、等价类、边界值、白盒黑盒，这些全保留，但增加一个大的新模块：AI 生成测试用例与人工补充的协同策略；以及自动化测试脚本的 AI 辅助生成。后面详细说测试课怎么改，这里先记住定位——软件测试工程师正在从“写用例的人”变成“设计测试策略、审查 AI 产出的用例、维护测试资产的人”。

2.4 一张课改地图，厘清三层次能力目标

嫌复杂的话，可以直接抄下面这张课改地图，这是我们教研组做课程梳理时的内部版本。

这张表的逻辑就是三条线：保住算法和数据结构的地基，强化需求、设计、测试、管理等工程环节的判断力，新增 AI 原生研发的核心技能。它不是“推倒重来”，而是“地基不动、框架改造、顶层加新”。

3. 关键课程的教学方法改造：具体到每节课怎么上

3.1 需求分析：教会学生和 AI 客户“拉扯”

需求分析课最容易变成“文档写作课”，学生对着模板编出一堆看似完整、实则没人看的需求规格。AI 时代反而给了这门课一个翻身的机会——我们设计了一个“AI 客户”训练环节。

具体操作是：每 4 到 5 人一组，给定一个真实场景（比如校园二手交易平台），先让学生通过提示词“调教”出一个 AI 客户。这个 AI 客户的人物设定是：有明确的产品目标、有行业背景、有预算约束、有拖延和隐瞒倾向。然后学生分组去和这个 AI 客户做需求访谈，目标是输出一份可以开发验收的用户故事列表。

课堂上最精彩的瞬间，永远是学生第一次访谈时的“需求爆炸”。学生问“你有什么功能需求？”AI 客户什么都说要，于是生成一个 30 条功能的需求池。这时候教师引导他们学会追问：目标用户是谁？使用频率最高的三个场景是什么？如果只能做三个功能你选什么？事先准备的预算是多少？异常情况怎么处理？

几轮下来，学生自己会发现一个规律：好的需求不是“问出来的”，而是“追问出来的”。这就是软件工程一直强调的干系人沟通能力。而 AI 客户的好处是它可以被反复访谈、反复验证，学生还能把自己总结的访谈技巧反过来优化提示词，下次让 AI 客户“更配合”或“更刁难”。

我给这个环节的评分标准很简单：一是提问质量，看在五轮对话内能否收敛出关键需求；二是需求验收标准，看能否把用户故事写成“可测试、可验收”的格式。这样的训练，既练了传统需求工程的核心技能，又练了和 AI 协作的提问能力。

3.2 系统设计：用 AI 生成方案，用人完成架构权衡

系统设计课是另一个适合深度改造的课。传统教学是老师讲架构模式，学生完成一个设计文档。现在我的做法是让 AI 当“方案生成器”，学生当“架构评审委员会”。

第一步，给定一个中等规模系统（例如一个支持 10 万用户的在线考试系统），每个小组让 AI 生成三个候选架构方案：单体应用、模块化单体、微服务架构。AI 会给出每个方案的优势劣势、适用场景、成本粗略估计。

第二步，让学生用 ATAM（架构权衡分析方法）风格的属性权衡树来评估——性能、可扩展性、可维护性、安全性、部署成本，每一项打分并说明理由。关键要求是：AI 说的“性能更高”，不允许直接采信，必须用一个小原型或压测数据来验证。

第三步，让 AI 扮演“架构评审专家”，对学生的方案发起质疑。学生需要回应这些质疑，给出修改后的最终方案。

这里我最想提醒其他老师的一点是：AI 生成架构方案的能力已经很强，但它的“决策”完全没有责任意识。一个学生让 AI 推荐微服务方案，理由是“可扩展性强”，我追问了一句“你们团队现在只有 3 个人，运维能力为零，你准备怎么维护十几个服务？”他当场愣住了。后来他改成了模块化单体，并在报告里写清楚了“技术选型不能脱离组织能力”。这种判断力，就是 AI 给不了、而课堂必须给的东西。

3.3 软件测试：AI 生成用例与人的反例思维互为补充

软件测试课程改造的空间非常大，因为 AI 在测试领域的可用程度已经相当高了。我的课堂流程分三步走。

第一步：给定一个有缺陷的代码模块，让 AI 生成 20 个单元测试用例。学生很快会发现，AI 生成的用例覆盖面广，但边界意识弱，很多都是“常规输入测一遍”就完了。而且更隐蔽的问题是：AI 的测试断言经常是错的，它会把错误行为当成正确行为写进测试期望值。

第二步：学生人工补齐边界用例——闰年、时区、非法输入、超大数值、空值、并发调用等。这一步不能省略，因为反例思维恰恰是人类智能相对 AI 的显著优势。我常跟学生说：“AI 擅长全覆盖，人类擅长找例外，软件测试质量取决于例外有多少被捕获。”

第三步：引入变异测试思想。让 AI 在正确代码里播撒不同类型的缺陷（改掉判断条件、删掉一行、把大于号变成小于号），学生提交自己的测试用例集去“杀变异体”，看看谁能杀掉更多。这个环节特别刺激，学生为了杀更多变异体，会主动去想各种刁钻场景，课堂参与度明显上升。

性能测试方面，我让学生对照 GB/T 39788 - 2021《系统与软件工程 性能测试方法》的标准流程，用 AI 辅助生成 JMeter 或 locust 脚本，但场景设计、指标口径、阈值判定这些核心工作必须手工完成。这样学生既了解了性能测试的标准流程，又体验了 AI 在重复劳动上的价值。

3.4 项目管理：AI 负责估算与记录，人负责决策与沟通

项目管理课在过去是“文科课”的感觉，学生背概念、画甘特图，觉得离技术很远。引入 AI 之后，这门课反而变得非常有趣。

我设计了三个配合实验。第一个是“AI 估算 vs 真实排期”：给出一个功能列表，先让学生用功能点/故事点估算工期，再让 AI 基于一个模拟历史数据做回归预测，最后让学生按自己的节奏实际执行编码任务，对比三者的差距。结果往往很有意思——AI 的估算通常比学生更乐观，但它考虑不到课程冲突、状态不好、需求理解偏了这些真实因素。学生由此理解了“估算从来不是算数，而是风险管理”。

第二个是“AI 会议纪要 vs 人做会议纪要”：让学生开一个需求评审会，用 AI 做语音转录和纪要整理，学生对照人工纪要，判断 AI 漏掉了哪些隐含决策和情绪信号。绝大多数情况下，AI 能把待办事项整理得很好，但会把一些“带着犹豫的承诺”漏掉——而这恰恰是项目后期延期的主要来源。

第三个是“AI 干系人扮演”：让 AI 分别扮演客户、测试负责人、运维负责人，轮番向项目组追问计划里的漏洞。学生为了应对质疑，必须真正理解项目计划的依赖关系和关键路径。这个练习虽然没有一行代码，但教的恰恰是软件工程最核心的“在约束下做承诺、在不确定性中做决策”的能力。

经过这一轮改造，项目管理课不再是“背概念”，而是变成了“角色扮演 + 决策训练”，学生反而对软件工程的价值更加信服。有学生在课程反馈里写：“以前觉得项目经理谁都能当，现在才知道，那个位置要承担的东西太多了。”

4. 实践环节怎么落地：课程设计与毕业选题的新思路

4.1 课程设计：小、真、新、可验证的选题原则

课程设计是软件工程教学最传统也最容易被吐槽的环节——一个图书管理系统做了二十年，学生没兴趣，老师批改也疲劳。AI 时代给了我们一个完全重新设计的机会。

我现在要求课程设计选题满足四个原则：小、真、新、可验证。“小”指两周到四周能完成，不追求大而全；“真”指解决真实问题，最好有真正会使用的用户；“新”指必须有一个环节是 AI 参与研发——AI 生成的代码必须有人工审查记录，或者系统本身就是一个 AI 应用；“可验证”指必须有自动化测试或明确的评测指标。

从试点效果看，最大的变化是学生把课程设计当成了“自己的产品”。我见过一个小组做了校园闲置物品回收的 AI 问答机器人，真的找环保社团用了几周，在真实用户反馈里迭代了两轮，这比任何模拟项目都能带来工程成就感。

实操层面的一个具体建议是：把课程设计的交付物从“源代码 + 报告”改成“源代码 + AI 使用日志 + 测试报告 + 现场演示”。AI 使用日志记录每次 AI 交互的目标、提示词、输出和人工改动点，这既是过程考核的依据，也是教师诊断学生理解深度的工具。后面考核部分会细说。

4.2 毕业选题：从“做系统”转向“研究 AI 参与研发”

“软件工程本科毕业论文如何选题”是每年大四学生问得最多的一个问题。以前我建议选题要“做一个小而完整的系统”，但在 AI 时代，这个建议已经过时了——AI 让“做个系统”的成本急剧下降，论文的价值必须转移到“对某个问题的深入理解和可验证的回答”上来。

我建议学生从三个方向里选题。第一个是工程工具类，做一个 AI 辅助软件工程某环节的工具并评测，比如“基于大模型的测试用例自动生成与人工审核工具”，必须有明确的评测基准；第二个是实证研究类，通过对照实验回答一个问题，比如“AI 辅助编程对开发效率的影响——基于 20 名学生结对开发的实验研究”，它的价值在实验设计和结论分析，而不是代码本身；第三个是技术应用类，做一个大模型驱动的垂直领域 Agent，重点放在评测与失败边界分析，避免“又一个聊天机器人”。

我给学生一个选题检查单：第一，这个问题有没有一个明确的研究问题，而不是一个待开发的系统？第二，有没有一个可比的基准——和人工对比、和另一工具对比、和基线方法对比？第三，能不能清晰地描述失败边界——在什么情况下你的方案会失效？三点都满足，这个题目基本就能撑起一篇本科毕业论文。

同时强调一点：时间紧的本科毕业设计，选题的“窄”永远优于“大”。一个只针对“教学评价文本的情感分析”的小工具，只要评测扎实、边界清晰，远比一个什么都能干的“智能助手”更有论文价值。

4.3 教学工具链的低成本搭建：免费与开源组合拳

工具链是所有教学改造的基础设施。很多学校没有充足预算，但只要方向对，完全可以低成本搭出一条完整的教学流水线。

我推荐一套组合：Python 作为基础语言，PyCharm 作为 IDE，课堂统一安装 Fitten Code 这类免费 AI 编程插件，学生和教师用同一套提示词规范；代码托管与协作用 GitLab 或 GitHub Education，配置 CI/CD 流水线实现自动构建和自动测试；实验环境用 Docker 统一封装，避免“在我电脑上是好的”这种经典翻车现场；AI 实验用本地部署的小尺寸模型，比如 Ollama 加开源模型，既解决数据隐私问题，也保证机器配置不一的学生都能跑起来；性能测试用 JMeter 或 locust，配合 GB/T 39788 标准做流程训练。

为什么不直接全员开通最贵的商业 AI 编程工具？成本是一方面，更关键的是教学需要“可控的 AI”——教师能统一知道学生用的工具是什么、能力边界在哪，才能设计合理的考核。商业工具很强，但不同学生能力差异、不同模型行为差异，会让教学评价变成一锅粥。先统一配置，把流程跑通，再鼓励有条件的同学自己探索更高级的工具，这是更稳的做法。

工具链真正重要的不是哪个工具多强，而是它能不能串起一条完整的链路——从写代码、做评审、跑测试、部署上线到看监控反馈。让学生在课程里完整走一遍 AI 时代的研发流水线，这门课就成功了一大半。

5. 考核方式、学术诚信与教师转型：课程改革的后半场

5.1 过程性考核：把 AI 使用过程变成可评价的证据

考核是课程改革的指挥棒，这一条不改，前面的课程设计再花哨也会被学生用脚投票投回老路。AI 时代最直接的挑战是：只看最终代码，你无法判断学生是否真的理解了自己的作业。所以必须把“过程证据”纳入评分。

我现在的评分体系分五个维度：

这套体系最大的特点是不再“唯结果论”。一个学生哪怕最终系统功能不多，但他在 Git 提交记录中把任务拆解得明明白白，每次 AI 生成代码后都有认真的人工审查痕迹，答辩时能把自己的设计决策讲透彻——他照样能拿高分。相反，如果整段代码都有 AI 生成痕迹，但一问三不知，分数会很难看。

试点时也有一些讨论，比如“裸编码测试占比是不是太低”。我的看法是：20% 已经足够保住底线，因为课程的目标是培养能驾驭 AI 的工程师，而不是把人训练成 AI 的对手。真正重要的是，学生知道老师看得见过程，他就会认真对待过程——这本身就是工程素养。

5.2 学术诚信：不是禁止 AI，而是划定边界与设计追问

AI 时代的学术诚信问题不能靠“一刀切禁止”解决。你禁止等于让学生偷偷用，反而养成了一种“躲避检查”的习惯，和工程诚信背道而驰。我的立场从一开始就定为：鼓励合理使用，但要划定清晰边界。

具体操作是，课程大纲里明确写出三个等级的场景：完全允许——资料检索、代码草稿、文档初稿；有条件允许——AI 生成代码必须先审查再提交，并在注释中标注哪些部分是 AI 生成的；完全禁止——限时裸编码考核、开题报告与答辩陈述的个人表述环节。

比规则更重要的是“设计追问”。我在答辩时有一个固定动作：随机从学生仓库里挑一段看起来最关键、也最像 AI 生成的代码，让他现场讲清楚每一行的意图，再让他现场改一个需求场景，看代码会怎么变化。这种追问防不了也不该防“所有作弊”，但它能筛选出真正理解系统的学生。

还有一个被证明有效的做法：要求学生在最终交付物中附上“AI 使用日志”，记录每次使用 AI 的目标、提示词、输出摘要和人工改动点。很多老师担心这是额外负担，但从试点看，学生普遍反映“这个日志让我更清楚自己到底卡在哪里了”。更重要的是，日志让教师能精准定位学生的真实能力水平——哪些任务他需要提示，哪些任务他自己能改，一目了然。

学术诚信教育的本质，是让学生明白一个责任原则：AI 产出的所有内容，最终署名者是开发者本人，所以开发者必须能解释、能负责、能兜底。这不只是防作弊，这本来就是软件工程师的职业伦理。

5.3 教师转型：先让一部分老师跑通，再共建案例库

所有改革最后都会卡在人身上。我见过不少老师，不是不愿意改，而是“不知道怎么教 AI”——自己都没用过几次 AI 工具，怎么可能设计出好的 AI 教学任务？

我推荐一套“三层推进”的教师转型策略。第一层，全员普及：教研组统一组织“AI 工具月”，规定每位老师在一个月内，用自己教的一门课完成一次 AI 教学体验，不用做得多好，关键是迈出第一步。第二层，骨干开发：选拔 3 到 5 名先行教师，专门开发 AI 教学案例，每个案例必须包括任务设计、工具配置、常见坑、评价方案四个部分，相当于把“如何教 AI”本身做成产品。第三层，共建共享：把案例库在校内甚至跨校开放，和兄弟院校一起维护，让好经验持续流动。

这里分享一个我在培训中反复遇到的规律：老师们抗拒的不是 AI 本身，而是“未知”。一旦有人把一整套“任务单 + 配置教程 + 常见坑清单”摆到他面前，他照着跑一遍就发现没那么难。所以教师转型的关键，不是开几场讲座洗脑，而是提供足够的“上手材料”和“同伴支持”。

我的另一个建议是，教研组可以建立“公开课 + 评课”的常态机制。每一轮教改，让一位老师拿一个改造后的案例上公开课，其他老师旁听评分、提意见。这比任何培训都有效，因为教学教改本身就是一种过程性活动，教师也需要像学生一样，在真实场景中反复迭代。

做完这一整轮课程改革，我的体会是：AI 并没有让软件工程教育变简单，反而让它变难了——难在我们要想清楚什么事该交给 AI、什么事必须由人负责、怎么把人机协作出现在课程设计和考核评价的每一个环节。但也是这个“难”，让软件工程教学重新有了一种真实的深度。学生不再问“学这个有什么用”，因为每一节课都在回应真实研发场景里的问题。AI 时代的软件工程教育，不是把人培养成“会命令 AI 的人”，而是培养成“能为 AI 的产出负责的人”——这两个目标，差的恰恰是传统软件工程课程里最精华的部分：判断、权衡、决策与责任。