当 Cursor、Claude Code、Copilot 成为学生写代码的默认工具，“把代码写出来” 已经不再是难题。 那软件工程课还有教的必要吗？
本学期课程项目要求迭代开发网盘系统，分 Lab1‑Lab4 不断叠加复杂业务逻辑：团队空间、权限、配额、回收站、文件分享等。几乎所有小组都重度使用 AI Coding Agent。
前期 AI 效率拉满：快速生成 CRUD 接口、页面骨架、测试、文档。 不少同学甚至形成循环：需求文档 → AI 生成代码 → AI 自查 → AI 修复。 但随着业务复杂度上涨，AI 的短板集中暴露❗
验收发现五大典型问题
▪️人沦为传话工具 评审提出问题，学生只会把意见复制给 AI，来回搬运反馈，自己无法独立读懂、修改代码，真正做决策的变成 AI。
▪️局部能跑，全局设计缺失 单接口功能正常，但缺少整体扩展性。比如硬编码角色权限，新增角色就要改源码；早期简单设计，后期叠加需求只能疯狂打补丁。
▪️不会质疑错误前提 Prompt 假设某个接口已存在，AI 不会校验真实性，甚至会模拟返回结果，制造 “功能完成” 的假象。
▪️AI 可以生成测试，但不等于测试有效 能产出大量测试用例格式，但很难校验业务语义、跨空间状态、权限可见性，容易出现 “测试看着全过，实际业务逻辑不对”。
▪️放大团队协作不一致 多人各自调用 AI 写模块，出现命名、参数、错误码、权限逻辑不统一，界面看着相似，底层业务语义完全混乱。
对 13 个小组合计约 20 万行代码评审发现： 单文件内的问题修复效果尚可；跨文件、跨模块、跨迭代的系统级问题 AI 很难处理。 高频出现长函数、参数爆炸、代码重复、基本类型偏执、上帝对象。 不是没有分层、DTO 这些框架结构，而是代码增长速度远远快于系统结构的演化速度。 AI 擅长完成单次需求，但很少主动思考：当前类、函数是不是该重构？领域模型是否要调整？
💡课程带来的启发
AI 降低了写代码的门槛，但是软件工程的门槛并没有降低，反而被暴露得更明显。
AI 适合做执行加速器，不适合当架构决策者。
不能只看功能是否跑通，重点考察：懂不懂代码、能不能解释设计、识别 AI 隐患、需求变更下能不能维护系统。
AI 可以生成代码，但不能替人做架构取舍、承担工程责任。 软件工程核心，不是产出代码，而是在变化的需求下，把复杂系统持续控制在人的理解与掌控之内。