系统开发的终极目标仍然是满足真实用户需求
旧门槛是手写代码，新门槛是写清需求、组织上下文、做出验收判断
学生过去卡在实施层，如今更容易卡在“我到底要让 AI 做什么”
讲者备注：延续旧版“龇牙咧嘴”的课堂情绪，但把焦点从编码苦力转向任务定义
编程基础弱的学生往往更少路径依赖，更愿意快速试错
AI 降低实现成本后，他们把精力转向调研、共情、沟通和迭代
真正稀缺的，不再只是“会写代码”，而是“能判断什么值得做”
讲者备注：这里可插入你在《信息系统开发》课程中的真实观察
第一阶：代码补全，帮你把已知写法补齐
第二阶：自然语言生成，帮你把目标翻译成可运行原型
第三阶：Agentic IDE / Builder，能读上下文、规划步骤、连续执行
第四阶：Spec 驱动协作，把需求、约束、任务拆解串成闭环
图示建议：做一条四段式演进阶梯，不再堆叠旧截图
小游戏仍是最低风险的第一次成功体验
但它只是入口，不是终点
我们今天不把“会做贪吃蛇”当成功，而把“能做出可验收原型”当成功
讲者备注：可快速对照旧版贪吃蛇和字符雨案例
AI IDE：适合已有代码与文件上下文的任务
AI-native builder：适合快速生成可交互原型
Agent workflow：适合复杂任务、多步协作、长任务执行
示例工具：Trae、秒哒，以及其他你课堂上可稳定访问的入口
讲者备注：点名工具时强调“今天可用，不代表永远唯一”
先指定一个明确用户和一个明确痛点
让 AI 做出一个最小可运行交互原型
学生必须提交三件东西：目标用户、验收标准、复盘说明
创意仍然欢迎，但不能只有创意没有验收
当任务变复杂，单轮提示词就会失控
需求调研结果必须先落成 spec，而不是直接丢给 AI 开始乱试
一个好 spec 至少写清：问题、用户、边界、关键流程、验收条件
讲者备注：这里承接旧版“Spec 驱动编程”页
第一步：需求调研，弄清楚谁痛、痛在哪里
第二步：Spec 文档，把目标、边界、约束写明确
第三步：Prototype 生成，用 AI IDE / builder 做第一版
第四步：Evaluation，对照验收标准复盘，不满意就回 spec
图示建议：需求 -> Spec -> Prototype -> Evaluation 的循环箭头
每组选一个真实调研对象
先写 spec，再调用 AI 工具生成原型
小组汇报时必须回答：删掉了哪些需求，为什么
讲者备注：这页决定课程是否从“玩具 demo”升级为“系统实施”
人负责目标、约束、取舍、验收
AI 负责实现、试错、重构、加速
真正的协同发生在中间层：需求解释、方案比较、迭代修正
金句可用：人更像 AI 乐团的指挥，而不是每个音符都亲手演奏的人
生成代码的 Agent 不应该自己给自己判无错
复杂任务中必须引入独立校验者
校验对象包括代码、原型、规则、计划，而不只是最终结果
讲者备注：用“考试自己检查”和“同桌帮你检查”的类比解释
高价值复杂任务：优先强模型，减少返工和误判
低风险重复任务：优先低成本路线
课堂中比“最强模型”更重要的是“知道何时值得上强模型”
讲者备注：只给出原则，不展示会很快过时的静态价格截图
同一个工具里也可能接不同模型
同一个模型在不同工具里的可用上下文和自治能力不一样
课堂汇报时要让学生区分：我选的是模型，还是入口，还是工作流
图示建议：工具层、模型层、任务层三层示意图
第一类：AI 自检失效，自己查自己常常查不出来
第二类：权限与 secrets 泄露，尤其在带工具调用时
第三类：提示注入、工具误用、误删误改
第四类：把需求判断和价值判断一并外包给 AI
讲者备注：风险页要给动作，不要只给恐惧
绿灯：样板代码、重复修改、低风险实现，AI 主导
黄灯：需求解释、方案比较、验收测试，人机协同
红灯：价值判断、边界裁定、最终责任，人绝对主导
课堂要求：学生汇报必须说明哪一步交给 AI，哪一步必须人工拍板
AI 提升的是实现效率，不会自动替代目标判断
好课程不是让学生更依赖工具，而是更清楚自己在负责什么
新时代的系统开发者，核心竞争力是洞察、取舍、沟通和验收
最后一锤：人保留目标、约束、验收和责任；AI 负责把实现加速到可用速度