621 lines
34 KiB
Markdown
621 lines
34 KiB
Markdown
---
|
||
课时: 6
|
||
主题: 产品迭代与增量开发
|
||
核心能力: [拆解力, 共创力]
|
||
核心工具: [穹狼 Code / Trae]
|
||
时长: 90分钟
|
||
透明化层级: 过程层
|
||
适用路线: 共享
|
||
---
|
||
|
||
### 1. 课程目标
|
||
|
||
**知识目标：**
|
||
- 理解"增量开发"的概念：在已有代码上"加功能"，而不是推倒重来
|
||
- 理解功能优先级分类：必须有（Must Have）vs 最好有（Nice to Have）vs 以后再加（Later）
|
||
- 认识三大增量方向：计分系统（反馈机制）、倒计时/生命值（紧张感）、动画/音效反馈（体验感）
|
||
|
||
**能力目标：**
|
||
- 能对功能清单进行优先级排序，先做最重要的（拆解力）
|
||
- 能在AI对话中引用"现有代码/现有游戏"让AI在已有基础上增量修改（共创力）
|
||
- 能完成至少两轮"提出新功能需求→AI增量实现→验收测试→继续迭代"的完整循环（共创力）
|
||
|
||
**情感目标：**
|
||
- 建立"好产品不是一次做出来的，是一轮一轮迭代出来的"的信念
|
||
- 体验"我的游戏在我手里一步步变好"的成就感和掌控感
|
||
- 从"做出来就行"升级为"做得更好"的产品意识
|
||
|
||
---
|
||
|
||
### 2. 核心概念与误概念预设
|
||
|
||
**核心概念认知层级：**
|
||
|
||
| 概念 | 学生类比 | 认知层级 |
|
||
|------|---------|---------|
|
||
| 增量开发 | 装修房子：不是拆了重建，是在现有房子里加家具、刷新墙面 | 理解层 |
|
||
| 功能优先级 | 考试先做会做的题，难题放最后——功能也有"先做哪个"的顺序 | 应用层 |
|
||
| 计分系统 | 打篮球要有计分板，否则不知道谁赢了——游戏也需要反馈 | 理解层 |
|
||
| 倒计时机制 | 考试有时间限制才会紧张——游戏加倒计时才刺激 | 理解层 |
|
||
| 动画反馈 | 微信发消息有"已读"标记，你才知道对方看到了——游戏也需要"回应" | 应用层 |
|
||
|
||
**典型误概念表：**
|
||
|
||
| 编号 | 误概念 | 正确认知 | 激发策略 |
|
||
|------|--------|---------|---------|
|
||
| M1 | 加新功能就要重新做一个游戏 | 在已有代码上让AI增量添加，原来的功能不会丢失 | 演示"重新做"导致旧功能丢失 vs "在原来基础上加"保留一切 |
|
||
| M2 | 所有想到的功能都要一次性加完 | 一次加一个功能，验收通过后再加下一个；一次说太多AI容易出错 | 让学生尝试一次提5个需求，观察AI"翻车"；再对比逐个添加的效果 |
|
||
| M3 | 功能越多游戏越好 | 核心功能做好比堆砌功能更重要；3个精打细磨的功能胜过10个半成品 | 展示一个功能很多但全都半成品的"烂游戏"对比一个功能少但打磨到位的好游戏 |
|
||
| M4 | 加功能的顺序不重要，想到什么加什么 | 有些功能是其他功能的基础（如没有计分就没法做"最高分"），顺序很重要 | 让学生尝试先加"排行榜"再发现需要先有"计分"，体验依赖关系 |
|
||
| M5 | AI加完功能不用测试，肯定对的 | 每加一个功能都要亲自玩一遍验证，AI经常在加新功能时"弄坏"旧功能 | 演示AI加计分后倒计时意外消失的案例 |
|
||
|
||
---
|
||
|
||
### 3. 教学准备
|
||
|
||
**工具与环境：**
|
||
- AI编程工具（穹狼 Code / Trae，每位学生已在前几课完成配置）
|
||
- 每位学生上节课（第5课）的游戏项目文件（HTML文件）
|
||
- 教师演示电脑 + 投影
|
||
- 教师准备一份"基础版打地鼠游戏"作为演示用的标准起点
|
||
|
||
**教学资源：**
|
||
- 教师准备：一个已验证的基础游戏（上节课的MVP），以及经过三轮迭代后的完成版（用于对比展示）
|
||
- 学生资源：上节课做的可玩游戏（如果有学生缺课或丢失文件，教师提前准备2-3份不同的基础游戏作为备选）
|
||
- "功能优先级排序卡"（打印版，每人一张，含 Must Have / Nice to Have / Later 三个区域）
|
||
|
||
**教师备课体验任务：**
|
||
> 备课前，教师必须亲自完成以下操作：
|
||
> 1. 用一个基础游戏（如打地鼠），分三轮分别添加计分系统、倒计时、点击动画，记录每轮的提示词和AI表现
|
||
> 2. 故意在一轮中一次性提出3个以上功能需求，观察AI是否出错（为课堂演示"一次加太多会翻车"做准备）
|
||
> 3. 故意在新对话中说"帮我做一个有计分的打地鼠游戏"（不引用现有代码），对比在同一对话中说"在现有游戏基础上加计分"的差异
|
||
> 4. 确认每位学生的电脑上保留了上节课的游戏文件
|
||
|
||
---
|
||
|
||
### 4. 教学流程
|
||
|
||
**第一幕：联系 (Connect) — 10分钟** 🔗
|
||
|
||
**【环节：上节课回顾】(3分钟)**
|
||
|
||
**师：** 上节课我们干了一件特别酷的事——每个人用一句话就做出了一个可以玩的游戏！谁还记得，你做的是什么游戏？【诊断点：检测第5课核心体验的保持度——学生是否记得自己的MVP游戏】【识别层】
|
||
|
||
**【分支A】若学生兴奋地说出自己的游戏（"打地鼠！""接水果！""躲避球！"）：**
|
||
**师：** 记得很清楚！那我再问一个问题——你的游戏好玩吗？满分10分你给自己打几分？
|
||
|
||
**【分支B】若学生记忆模糊：**
|
||
**师：** 上节课我们用一句话描述需求，AI就帮我们生成了一个可以玩的游戏。你的电脑上还存着呢，等下我们打开来看看。
|
||
|
||
**【分支C】若有学生缺课没有做过第5课：**
|
||
**师：** 没关系！我这里给你准备了几个基础游戏，等下你选一个来用。今天的重点不是做新游戏，而是把已有的游戏变得更好。
|
||
|
||
**【环节：情景导入】(7分钟)**
|
||
|
||
**师：** 大家给自己的游戏打了分。我猜大部分人打了6分、7分左右——能玩，但总觉得少了点什么。对吧？
|
||
|
||
**师：** 我来给大家看两个东西。第一个——【投影展示一个最基础的打地鼠游戏：点击地鼠，地鼠消失，没有计分，没有倒计时，没有任何反馈】
|
||
|
||
**师：** 这是上节课做的"基础版"打地鼠。能玩吗？
|
||
|
||
**生：** 能玩。/ 但是好无聊。/ 没意思。
|
||
|
||
**师：** 能玩，但不好玩。现在看第二个——【投影展示同一个游戏的"迭代版"：有计分、有倒计时、打中地鼠有动画效果和音效、有"游戏结束"画面和最高分记录】
|
||
|
||
**师：** 同一个游戏！但感觉完全不一样了，对不对？你们觉得第二个比第一个多了什么？【诊断点：探测学生能否自发识别出"增量功能"——计分、倒计时、动画等】【理解层】
|
||
|
||
**生：** 有分数了！/ 有倒计时！/ 打中了会闪一下！/ 还有声音！
|
||
|
||
**师：** 全都对！关键问题来了——这个"升级版"是我推翻了原来的游戏重新做的吗？
|
||
|
||
**【分支A】若有学生说"不是，是在原来的基础上加的"：**
|
||
**师：** 厉害！你已经理解今天的核心概念了。没错——这叫"迭代"。不是重新做，是在已经能跑的游戏上，一个功能一个功能地加上去。
|
||
|
||
**【分支B】若学生认为"可能是重新做的"（误概念M1的早期表现）：**
|
||
**师：** 你猜错了！如果我重新做，那之前调好的游戏玩法可能又要从头来。实际上，我就是在原来的游戏上，跟AI说"帮我加一个计分功能"，它就加上了。这就叫——增量开发！
|
||
|
||
**师：** 今天这节课，你们就要把自己上节课做的游戏，从"能玩"升级到"好玩"！怎么升级？——一个功能一个功能地加。这就叫**增量开发**，也叫**产品迭代**。
|
||
|
||
---
|
||
|
||
**第二幕：建构 (Construct) — 65分钟** 🛠️
|
||
|
||
**【分段一：重开游戏 + 功能清单与优先级排序】(15分钟)** ✨
|
||
|
||
**预设误概念：**
|
||
- M2：所有想到的功能都要一次性加完
|
||
- M4：加功能的顺序不重要
|
||
|
||
**讲解与演示 (Teach & Demo): (5分钟)**
|
||
|
||
**师：** 首先，大家把上节课做的游戏打开，在浏览器里玩一遍。【等30秒让学生打开】
|
||
|
||
**师：** 玩完了？好。现在我教你们做产品经理最重要的事——列"功能清单"。产品经理是什么人？就是决定"这个产品要做什么功能"的人。今天你就是自己游戏的产品经理！
|
||
|
||
**师：** 我先用我的打地鼠游戏做个示范。我玩了一遍基础版，觉得缺了这些东西——【在白板上写】
|
||
|
||
```
|
||
我想加的功能：
|
||
1. 计分——打中一只加10分
|
||
2. 倒计时——30秒时间限制
|
||
3. 打中时有动画效果——地鼠闪一下
|
||
4. 最高分记录——保存我的最佳成绩
|
||
5. 难度递增——越到后面地鼠出现越快
|
||
6. 背景音乐
|
||
7. 排行榜
|
||
8. 不同种类的地鼠（有的加分多有的加分少）
|
||
```
|
||
|
||
**师：** 列了8个功能。但问题来了——我能一次全加上去吗？
|
||
|
||
**生：** 不能！/ 太多了！
|
||
|
||
**师：** 对！一次加太多，AI容易"翻车"——加了新的把旧的弄坏了。所以我们要给功能排优先级！这就像考试——你会先做哪种题？
|
||
|
||
**生：** 先做会做的！/ 先做简单的！
|
||
|
||
**师：** 考试是先做会做的。功能排序呢，我们用另一个方法——分成三类：【在白板上画三个区域】
|
||
|
||
**Must Have（必须有）：** 没有这个功能，游戏就不完整
|
||
**Nice to Have（最好有）：** 有了更好，没有也能玩
|
||
**Later（以后再加）：** 太复杂了或者不急，放到以后
|
||
|
||
**师：** 我来示范排序——
|
||
|
||
| Must Have | Nice to Have | Later |
|
||
|-----------|-------------|-------|
|
||
| 计分 | 打中动画效果 | 排行榜 |
|
||
| 倒计时 | 最高分记录 | 不同种类地鼠 |
|
||
| | 难度递增 | 背景音乐 |
|
||
|
||
**师：** 为什么计分是 Must Have？因为没有分数，你都不知道自己打了多少只！这不是游戏，是"无聊的点点点"。为什么排行榜是 Later？因为排行榜需要先有计分系统——你连分都没有，排什么榜？【诊断点：学生能否理解功能之间的依赖关系】【理解层】
|
||
|
||
**学生实践 (Practice): (8分钟)**
|
||
|
||
**师：** 现在轮到你们了！每个人拿出功能优先级排序卡。
|
||
|
||
任务：
|
||
1. 打开你的游戏，玩一遍
|
||
2. 花3分钟写下你想加的所有功能（至少写5个，越多越好！先别管能不能做到）
|
||
3. 花3分钟把功能分类到三个区域：Must Have / Nice to Have / Later
|
||
4. 在 Must Have 里挑出最重要的一个，画个星号——这就是你今天第一个要加的功能
|
||
|
||
提示：如果你不知道写什么功能，看看这些方向——
|
||
- **反馈类：** 计分、生命值、最高分
|
||
- **紧张感：** 倒计时、速度加快、关卡
|
||
- **体验类：** 动画效果、音效、颜色变化、弹出提示
|
||
|
||
> 教师走动观察：重点关注谁把所有功能都放在 Must Have（误概念M3的表现），谁不知道怎么分类，谁只写了1-2个功能需要帮忙扩展思路。
|
||
|
||
**进度同步 (Checkpoint): (2分钟)**
|
||
|
||
**师：** 好，停一下！谁来分享你的功能清单？先说你列了几个功能，再说你 Must Have 里选了什么。【诊断点：学生的优先级判断是否合理——有没有把"排行榜"放在"计分"前面（M4的表现）】【应用层】
|
||
|
||
**【分支A】若学生排序合理（先基础功能后高级功能）：**
|
||
**师：** 你的排序很有产品经理的思维！注意到了吗——计分是很多其他功能的"基础"，所以它排在最前面。
|
||
|
||
**【分支B】若学生把太多功能放在 Must Have：**
|
||
**师：** 你列了不少 Must Have！但想一下——如果今天只能加两个功能，你选哪两个？真正的 Must Have 是"没有它游戏就缺了一大块"的功能。
|
||
|
||
**【分支C】若学生列的功能很少或不知道分类：**
|
||
**师：** 没关系！想想看你玩别人的游戏时，什么功能让你觉得"这个游戏好好玩"？分数？倒计时？过关？把这些写下来就行。
|
||
|
||
---
|
||
|
||
**【分段二：第一轮迭代——加计分系统】(20分钟)** ✨
|
||
|
||
**预设误概念：**
|
||
- M1：加新功能要重新做游戏
|
||
- M5：AI加完功能不用测试
|
||
|
||
**讲解与演示 (Teach & Demo): (5分钟)**
|
||
|
||
**师：** 功能清单排好了，现在开始动手！第一轮迭代，我们一起加最高优先级的功能。大部分同学 Must Have 里排第一的应该是——
|
||
|
||
**生：** 计分！
|
||
|
||
**师：** 对！计分系统。我来演示怎么跟AI说"在现有游戏上加计分"。注意——这里有一个非常关键的说法！
|
||
|
||
**师：** 错误的说法——【在投影上打出来】
|
||
|
||
```
|
||
帮我做一个有计分功能的打地鼠游戏
|
||
```
|
||
|
||
**师：** 这句话有什么问题？
|
||
|
||
**生：** ……
|
||
|
||
**师：** 这是让AI"重新做一个"！它会忽略我们上节课辛辛苦苦做的游戏，从零开始。之前调好的玩法、样式全没了！
|
||
|
||
**师：** 正确的说法——【在投影上打出来】
|
||
|
||
```
|
||
请在我现有的打地鼠游戏基础上，添加一个计分系统：
|
||
- 每次成功点击地鼠，分数加10分
|
||
- 在页面顶部显示当前得分
|
||
- 分数要大字号显示，醒目一点
|
||
- 不要改动现有的游戏玩法和样式，只添加计分功能
|
||
```
|
||
|
||
**师：** 看到区别了吗？关键词是——**"在现有的……基础上"**和**"不要改动现有的"**。这两句话告诉AI：别重做，在我已经有的代码上加！这就是"增量开发"的核心——**迭代不等于重来**。【诊断点：学生能否理解"在现有基础上加"和"重新做"的区别】【理解层】
|
||
|
||
（教师现场演示：在AI对话中发送上述提示词，等AI修改代码，刷新预览。）
|
||
|
||
**师：** 看！计分加上了。现在最关键的一步——验收！我要亲自玩一遍，检查三件事：
|
||
1. 点击地鼠，分数有没有增加？✅
|
||
2. 分数显示的位置和大小对不对？✅
|
||
3. 原来的游戏玩法有没有被弄坏？——我点击空白处看看，地鼠的出现节奏正不正常？✅
|
||
|
||
**师：** 三项全通过！这一轮迭代成功了。如果验收发现有问题呢？——就用第4课学的 Bug 描述三要素告诉AI修复。
|
||
|
||
**学生实践 (Practice): (12分钟)**
|
||
|
||
**师：** 现在轮到你们了！给你们12分钟，在你的游戏上加你选的第一个 Must Have 功能。
|
||
|
||
注意三个关键步骤：
|
||
1. **写清需求**——在AI对话中明确说"在现有游戏基础上"，具体描述你要加什么
|
||
2. **一次只加一个功能**——不要贪心把所有功能一次说完
|
||
3. **验收测试**——AI改完后，亲自玩一遍！检查新功能是否正常，旧功能有没有坏
|
||
|
||
如果你的 Must Have 是计分，可以参考我的提示词改成自己游戏的版本。如果你的 Must Have 是其他功能（比如倒计时），也用同样的结构去写。
|
||
|
||
保底提示词（如果不知道怎么写）：
|
||
```
|
||
请在我现有游戏的基础上，添加一个[你要加的功能名]。
|
||
具体要求：[用1-3句话描述这个功能应该怎么运作]
|
||
注意：不要改动现有的游戏玩法和样式，只添加这个新功能。
|
||
```
|
||
|
||
> 教师走动观察，重点关注：
|
||
> - 谁在开新对话重新描述整个游戏（M1的表现）→ 提醒"在同一个对话里接着说就行"
|
||
> - 谁一次提了3个以上功能（M2的表现）→ 提醒"先加一个，验收通过再加下一个"
|
||
> - 谁加完功能没有测试就继续下一步（M5的表现）→ 提醒"先自己玩一遍看看对不对"
|
||
> - 谁的旧功能被AI改坏了 → 这是绝佳教学时刻！引导用Bug三要素描述
|
||
|
||
**进度同步 (Checkpoint): (3分钟)**
|
||
|
||
**师：** 好，暂停一下！举手告诉我——加完第一个功能并且测试通过的，举手！【诊断点：完成度统计 + 验收意识检测——有没有人说"加了但没测试"】【应用层】
|
||
|
||
**师：** 没举手的同学，遇到了什么问题？
|
||
|
||
**【分支A】若大部分学生完成且测试通过：**
|
||
**师：** 太好了！你们刚刚完成了第一轮迭代！感觉到了吗——游戏在你手里一点一点变好了。这就是产品经理的感觉。接下来我们进入第二轮！
|
||
|
||
**【分支B】若有学生AI加完功能后旧功能坏了：**
|
||
**师：** 举个手看看，有谁的游戏加了新功能后，原来的功能反而坏了？（几只手举起）很正常！这就是为什么我说"每加一个功能都要测试"！你现在要用第4课学的Bug三要素告诉AI："我加了计分后，地鼠不再消失了。请修复这个问题，不要影响计分功能。"
|
||
|
||
**【分支C】若有学生还没完成：**
|
||
**师：** 没关系，你的节奏慢一点不要紧。先确保第一个功能加好了再往下走。遇到问题可以举手，也可以参考保底提示词。
|
||
|
||
---
|
||
|
||
**【分段三：第二轮迭代——自选增量方向】(15分钟)** ✨
|
||
|
||
**预设误概念：**
|
||
- M2：一次加太多功能
|
||
- M3：功能越多越好（不注重质量）
|
||
|
||
**讲解与演示 (Teach & Demo): (3分钟)**
|
||
|
||
**师：** 第一轮迭代完成了，你们的游戏已经比上节课好了一大截！现在进入第二轮——你可以从两个方向中自选一个：
|
||
|
||
**方向A：加倒计时/生命值（紧张感方向）**
|
||
|
||
提示词参考：
|
||
```
|
||
请在现有游戏基础上添加一个30秒倒计时功能：
|
||
- 在页面顶部显示剩余时间，和计分并排
|
||
- 每秒倒数一次
|
||
- 时间到0后显示"游戏结束！"和最终得分
|
||
- 倒计时最后5秒文字变红色提示紧迫感
|
||
- 不要修改已有的计分功能和游戏玩法
|
||
```
|
||
|
||
**方向B：加动画/视觉反馈（体验感方向）**
|
||
|
||
提示词参考：
|
||
```
|
||
请在现有游戏基础上添加点击反馈动画：
|
||
- 点中目标时，目标放大后消失（或者闪烁一下）
|
||
- 同时在点击位置弹出"+10"的文字提示，1秒后淡出
|
||
- 点空了的时候显示一个"X"标记，半秒后消失
|
||
- 不要修改已有的计分功能和游戏玩法
|
||
```
|
||
|
||
**师：** 选哪个方向都可以！关键是——还是那个原则：一次只加一个功能，加完要测试！
|
||
|
||
**师：** 做得快的同学，可以两个方向都加。但记住——每加一个，先验收再加下一个。不要急着堆功能！质量比数量重要。【诊断点：观察学生选择方向时是否有自主思考，还是盲目跟风】【应用层】
|
||
|
||
**学生实践 (Practice): (10分钟)**
|
||
|
||
学生自选方向进行第二轮迭代。
|
||
|
||
> 教师走动观察，重点关注：
|
||
> - 谁选了方向后犹豫不决 → 帮助简化选择："你更想让游戏更刺激，还是更好看？刺激选A，好看选B"
|
||
> - 谁开始同时加多个功能 → 温和提醒"先把这一个加好，测试通过再说"
|
||
> - 谁两轮都加完了，开始自由发挥 → 鼓励并引导他们看看 Nice to Have 里还有什么可以加的
|
||
> - 谁遇到困难卡住了 → 指导使用保底提示词，或建议简化功能需求
|
||
|
||
**进度同步 (Checkpoint): (2分钟)**
|
||
|
||
**师：** 好！第二轮迭代完成了多少人？举手让我看看！太棒了。谁来简单说说——你加了什么功能？加完后你的游戏体验有什么变化？【诊断点：学生能否描述"加了这个功能后，游戏哪里变好了"——从纯操作上升到产品感知】【迁移层】
|
||
|
||
**【分支A】若学生能说出具体感受（"加了倒计时后感觉紧张多了""加了动画后打中很爽"）：**
|
||
**师：** 你说到了一个很重要的词——"感觉"！游戏好不好玩，就是看玩的人有没有"感觉"。计分给你"成就感"，倒计时给你"紧张感"，动画给你"爽感"。这就是为什么这三个方向这么重要！
|
||
|
||
**【分支B】若学生只说"加了XXX功能"但说不出感受：**
|
||
**师：** 功能加上了，很好！那你现在再玩一遍你的游戏——跟上节课的基础版比，你更想玩哪个？为什么？
|
||
|
||
---
|
||
|
||
**【分段四：调试与打磨——确保所有功能正常】(15分钟)** ✨
|
||
|
||
**预设误概念：**
|
||
- M5：加完功能不用测试
|
||
- M3：功能越多越好（忽视Bug和细节）
|
||
|
||
**讲解与演示 (Teach & Demo): (3分钟)**
|
||
|
||
**师：** 前两轮迭代，你们给游戏加了计分、倒计时、动画……功能越来越多了。但功能多了，Bug的可能性也多了。现在进入最后一个环节——**打磨**。
|
||
|
||
**师：** 什么叫打磨？就像做一个木头椅子——形状做好了（功能都有了），但表面有毛刺（Bug），坐起来不舒服（体验不好）。打磨就是把毛刺磨掉，让椅子又好看又舒服。
|
||
|
||
**师：** 打磨三步检查法——【在白板上写】
|
||
|
||
1. **功能完整性检查：** 每个加过的功能，亲自操作一遍，确认都正常工作
|
||
2. **功能冲突检查：** 新加的功能有没有把旧功能弄坏？（比如加了倒计时后计分还对吗？）
|
||
3. **视觉细节检查：** 分数显示位置对吗？倒计时字够大吗？动画流畅吗？颜色搭配协调吗？
|
||
|
||
**师：** 我演示一下。我的打地鼠游戏已经加了计分和倒计时。我来检查——
|
||
- 计分：点击地鼠，+10……✅ 正常
|
||
- 倒计时：30秒开始倒计……✅ 正常
|
||
- 冲突：时间到了后我再点地鼠，分数还会加吗？——哎，居然还能加分！这是Bug！游戏结束后不应该还能操作！
|
||
|
||
**师：** 发现了一个Bug。我怎么跟AI说？——用Bug描述三要素！
|
||
|
||
```
|
||
发现一个问题：
|
||
- 我做了什么：倒计时到0后，我继续点击地鼠
|
||
- 我以为会怎样：游戏结束后应该不能再操作了
|
||
- 实际怎样了：时间到了还能点击地鼠并加分
|
||
请修复：倒计时到0后，禁止所有点击操作，只显示最终得分和"游戏结束"画面。
|
||
```
|
||
|
||
**师：** 看到了吗？打磨就是——发现细节问题，精确描述，让AI修复。这一步最考验耐心，但也是让你的游戏从"半成品"变成"正式产品"的关键！
|
||
|
||
**学生实践 (Practice): (10分钟)**
|
||
|
||
**师：** 现在，花10分钟给你的游戏做最后的打磨。按照三步检查法：
|
||
|
||
1. 把你加的每个功能都操作一遍，列出发现的Bug
|
||
2. 特别注意不同功能之间有没有冲突
|
||
3. 检查视觉效果——文字大小、颜色、位置有没有不舒服的
|
||
4. 发现问题就用Bug三要素告诉AI修复
|
||
|
||
如果所有功能都正常了——恭喜你，你可以做这些"锦上添花"的打磨：
|
||
- 让AI美化一下界面配色
|
||
- 加一个游戏标题
|
||
- 加一个"重新开始"按钮
|
||
- 调整动画的速度或效果
|
||
|
||
> 教师走动观察，重点关注：
|
||
> - 谁认真在做测试（好现象）→ 表扬"你的验收很专业"
|
||
> - 谁在继续疯狂加新功能而不测试（M3+M5）→ "先停一下，把现有功能测好了再加新的"
|
||
> - 谁发现了有趣的Bug → 鼓励分享给全班
|
||
> - 谁的游戏已经打磨得很好 → 建议帮助旁边的同学
|
||
|
||
**进度同步 (Checkpoint): (2分钟)**
|
||
|
||
**师：** 最后问一个问题。你的游戏从上节课的基础版到现在，一共经历了几轮迭代？每一轮加了什么？【诊断点：学生能否清晰回顾自己的迭代历程——这是"过程层"透明化的核心检验】【迁移层】
|
||
|
||
**【分支A】若学生能说出"第一轮加了计分，第二轮加了倒计时，第三轮修了几个Bug"：**
|
||
**师：** 完美！你刚才描述的就是"产品迭代记录"——专业的产品经理都会记录每一轮做了什么。这个能力以后会越来越有用！
|
||
|
||
**【分支B】若学生只说"加了很多东西"但说不清每轮做了什么：**
|
||
**师：** "加了很多东西"说明你做了不少工作！但如果能说清楚"第一步加了什么、第二步加了什么"，你就能更清楚地知道自己的游戏是怎么一步步变好的。下次试试每轮迭代后记一句话笔记。
|
||
|
||
**【分支C】若有学生只完成了一轮迭代：**
|
||
**师：** 一轮迭代也是迭代！一个功能做好了、测试通过了，比加了三个功能但都是半成品好得多。质量第一！
|
||
|
||
---
|
||
|
||
**第三幕：反思 (Contemplate) — 10分钟** 🤔
|
||
|
||
**【环节：成果展示】(6分钟)**
|
||
|
||
**师：** 现在是最激动人心的环节——展示时间！我请3位同学来展示你的游戏"进化史"。展示的时候要说三件事：
|
||
|
||
1. 上节课的基础版是什么样的（可以说一句话描述）
|
||
2. 你加了哪些功能？按什么顺序加的？为什么？
|
||
3. 现场玩一遍给大家看！
|
||
|
||
（请3位学生展示，每人2分钟。优先选择：①迭代轮数多且有明确节奏的学生 ②遇到Bug并成功修复的学生 ③功能不多但打磨精细的学生）
|
||
|
||
**【环节：互评与讨论】(4分钟)**
|
||
|
||
**师：** 看完了三位同学的展示，每人在心里想两个问题：
|
||
1. 谁的游戏你最想玩？为什么？
|
||
2. 如果你是产品经理，你会建议他/她下一步加什么功能？
|
||
|
||
谁来说说？
|
||
|
||
（请2-3位学生发言）
|
||
|
||
**师：** 最后一个关键问题——今天这节课和上节课有什么不同？上节课是"从无到有"，今天呢？【诊断点：学生能否提炼出"从有到更好"的核心跃迁】【迁移层】
|
||
|
||
**【分支A】若学生能说出"上节课是做出来，今天是做更好"：**
|
||
**师：** 一针见血！这就是产品开发的两个阶段——先做出MVP（最小可玩版本），再通过迭代让它越来越好。真正的产品公司，都是这么做的。
|
||
|
||
**【分支B】若学生说"今天加了很多功能"：**
|
||
**师：** 对！但更精确地说——今天不是"做了一个有很多功能的新游戏"，而是"在已有的基础上一个一个加上去的"。这个"在已有基础上加"就是核心！
|
||
|
||
---
|
||
|
||
**第四幕：延续 (Continue) — 5分钟** 🚀
|
||
|
||
**【环节：抽象总结】(3分钟)**
|
||
|
||
**师：** 今天我们学了三个核心能力，我用三句话总结：
|
||
|
||
**第一句：增量开发——** 不是推翻重来，是在已有的基础上加功能。就像装修房子，不是拆了重建，是一样一样添置进去。
|
||
|
||
**第二句：功能优先级——** Must Have 先做，Nice to Have 后做，Later 放一放。做产品不能贪心，先保证核心功能好用。
|
||
|
||
**第三句：每轮迭代都要验收——** 加一个功能就测一下，发现问题就修。"做了→测了→修了"比"做了做了做了→全崩了"好一百倍。
|
||
|
||
**师：** 这三个能力，不只在做游戏的时候有用。以后你做任何项目——写一篇长作文、准备一次班会、甚至整理自己的房间——都可以用"先列清单、排优先级、一步一步做、每步检查"这个方法。这就是"拆解力"的核心！【迁移诊断】
|
||
|
||
**【环节：下节预告 + 5分钟挑战】(2分钟)**
|
||
|
||
**师：** 下节课预告——我们要学"交互产品架构设计"。什么意思呢？今天你们是在已有游戏上"加功能"，下节课你们要学"怎么从一开始就把功能想清楚"——先设计，再开发。就像建房子——今天是装修，下节课是画图纸！
|
||
|
||
**师：** 本周5分钟AI挑战来了！
|
||
|
||
---
|
||
|
||
### 5. AI助教使用指南
|
||
|
||
**教师演示用提示词：**
|
||
|
||
**课前准备——基础版打地鼠游戏（演示起点）：**
|
||
```
|
||
请帮我用HTML/CSS/JavaScript生成一个最基础的打地鼠游戏：
|
||
- 一个3x3的网格
|
||
- 地鼠随机出现在某个格子里，1.5秒后自动消失
|
||
- 点击地鼠后地鼠消失
|
||
- 没有计分，没有倒计时，没有动画效果
|
||
- 视觉上要简洁可爱，适合小学生的风格
|
||
- 所有代码放在一个HTML文件中
|
||
```
|
||
|
||
**课堂演示——增量添加计分（第一轮迭代示范）：**
|
||
```
|
||
请在我现有的打地鼠游戏基础上，添加一个计分系统：
|
||
- 每次成功点击地鼠，分数加10分
|
||
- 在页面顶部显示当前得分
|
||
- 分数要大字号显示，醒目一点
|
||
- 不要改动现有的游戏玩法和样式，只添加计分功能
|
||
```
|
||
|
||
**课堂演示——增量添加倒计时（第二轮迭代示范）：**
|
||
```
|
||
请在现有游戏基础上添加一个30秒倒计时功能：
|
||
- 在页面顶部显示剩余时间，和计分并排
|
||
- 每秒倒数一次
|
||
- 时间到0后显示"游戏结束！"和最终得分
|
||
- 倒计时最后5秒文字变红色提示紧迫感
|
||
- 不要修改已有的计分功能和游戏玩法
|
||
```
|
||
|
||
---
|
||
|
||
**学生保底提示词：**
|
||
|
||
**通用增量功能添加模板：**
|
||
```
|
||
请在我现有游戏的基础上，添加一个[功能名称]。
|
||
具体要求：
|
||
- [功能的具体表现，1-3句话]
|
||
注意：不要改动现有的游戏玩法和样式，只添加这个新功能。
|
||
```
|
||
|
||
**Bug修复保底模板（结合第4课）：**
|
||
```
|
||
我的游戏出了一个问题：
|
||
- 我做了什么：[描述操作]
|
||
- 我以为会怎样：[描述预期]
|
||
- 实际怎样了：[描述实际]
|
||
请在不影响其他功能的前提下修复这个问题。
|
||
```
|
||
|
||
---
|
||
|
||
**进阶提示词：**
|
||
|
||
**同时打磨视觉效果：**
|
||
```
|
||
请帮我美化游戏界面：
|
||
- 给游戏加一个标题"[游戏名]"，用好看的字体和颜色
|
||
- 计分和倒计时区域加一个半透明背景框
|
||
- 整体配色方案换成[描述想要的风格，如"科技感蓝紫色""可爱粉色系"]
|
||
- 加一个"重新开始"按钮，放在游戏结束画面上
|
||
- 不要改动游戏逻辑，只美化视觉效果
|
||
```
|
||
|
||
**高阶：加难度递增机制：**
|
||
```
|
||
请在现有游戏基础上添加难度递增：
|
||
- 每得50分，地鼠出现间隔缩短0.1秒（最低不低于0.5秒）
|
||
- 每次难度提升时，在页面上闪一下"难度UP！"的提示
|
||
- 不影响计分和倒计时功能
|
||
```
|
||
|
||
---
|
||
|
||
### 6. 教师指南
|
||
|
||
**本课技术备注：**
|
||
|
||
1. **增量开发的技术原理：** 在AI编程工具中，如果学生在同一个对话/项目中发送后续请求，AI会基于已有代码进行修改，这就是增量开发的技术基础。如果学生开新对话或不引用现有代码，AI会从零生成，导致之前的功能丢失。教师需确保学生在同一对话/项目中操作。
|
||
|
||
2. **计分系统的技术实现：** JavaScript变量存储分数，点击事件触发分数增加，DOM操作更新页面显示。学生不需要知道这些细节，只需要通过自然语言描述"每次点击加10分，在页面上显示分数"。
|
||
|
||
3. **倒计时的技术实现：** JavaScript的`setInterval`函数每秒执行一次倒数。时间到后清除定时器、禁用交互。常见Bug：倒计时到0后玩家仍可操作（需要在回调中禁用点击事件）。
|
||
|
||
4. **CSS动画的技术实现：** `@keyframes`定义动画帧，`animation`属性触发动画。常见效果：缩放(`scale`)、渐变透明(`opacity`)、颜色变化(`color`)。AI通常能根据"闪烁""放大后消失""淡出"等自然语言描述生成对应动画代码。
|
||
|
||
5. **功能冲突的常见原因：** AI在添加新功能时可能意外修改了已有代码的逻辑（如重新定义了同名变量、修改了事件监听器）。这就是为什么每轮迭代后都要验收测试。如果出现冲突，让学生描述"加了X功能后，Y功能坏了"，AI通常能定位并修复。
|
||
|
||
**常见问题 FAQ：**
|
||
|
||
| 问题 | 应对 |
|
||
|------|------|
|
||
| "我上节课的游戏文件丢了怎么办？" | 教师提前准备2-3份不同的基础游戏作为备选："没关系，我这里有几个基础游戏，你选一个你喜欢的来迭代。" |
|
||
| "我想加的功能AI做不出来" | "可能是你描述得还不够具体。试试把这个功能拆成更小的步骤：先实现最基本的，再逐步完善。" |
|
||
| "AI加了功能后整个游戏都坏了" | "别慌！告诉AI：'你刚才的修改导致游戏出了问题。请回到上一个版本，然后只添加计分功能，不要改动其他部分。'" |
|
||
| "我能不能重新做一个更好的游戏？" | "你的想法很好！但今天的重点是在已有基础上加功能。就像学开车——先学会直线走，再学会转弯，不能每次都换一辆新车。下节课你会有机会设计新游戏。" |
|
||
| "为什么要一次只加一个功能？" | "就像搭积木——一块一块搭，每搭一块检查一下稳不稳。如果一次堆五块，塌了你都不知道是哪块的问题。" |
|
||
| "我的功能都加完了，没事做了" | "你的打磨做完了吗？视觉效果满意吗？要不要试试加Nice to Have列表里的功能？或者帮帮旁边还在调试的同学。" |
|
||
|
||
**课堂风险预案：**
|
||
- **如果AI服务不可用：** 教师使用课前准备好的三个版本（基础版→计分版→完整版）进行对比展示和讲解，学生用纸笔完成功能清单和优先级排序练习，作为概念课处理。下节课补做实践。
|
||
- **如果学生进度差异过大：** 快的学生完成三轮迭代后，安排"小导师"角色帮助慢的同学；慢的学生只要完成一轮高质量迭代即可，不要求跟上最快的人。
|
||
- **如果大量学生上节课作品丢失：** 全班统一使用教师准备的基础游戏（建议准备3种不同类型：打地鼠、接水果、点击反应），学生选择自己喜欢的类型进行迭代。
|
||
|
||
---
|
||
|
||
### 7. 5分钟日常AI挑战
|
||
|
||
**本周挑战：功能优先级设计师**
|
||
|
||
**挑战说明：** 选一个你常用的App或常玩的游戏（比如微信、抖音、王者荣耀），想象它还是一个"基础版"——只有最核心的功能。然后：
|
||
|
||
1. 列出这个产品至少有的5个功能
|
||
2. 用 Must Have / Nice to Have / Later 给它们排优先级
|
||
3. 用1-2句话解释：为什么你觉得XX功能是 Must Have？
|
||
|
||
把你的排序拍照发到班级群。下节课开始前，我们看看谁对"产品功能"的理解最深！
|
||
|
||
**下节课分享：** 下周课上选2-3位同学展示挑战成果
|
||
|
||
---
|
||
|
||
### 8. 拓展任务
|
||
|
||
**拓展一（推荐）：继续迭代你的游戏**
|
||
|
||
回家后打开今天的游戏，从你的 Nice to Have 列表中再挑1-2个功能加上去。记录你的"迭代日志"：
|
||
- 第X轮：加了什么功能？用了什么提示词？测试结果如何？
|
||
把迭代日志和游戏截图发到班级群，下节课展示"终极版"。
|
||
|
||
**拓展二（挑战）：给朋友的游戏做"产品评审"**
|
||
|
||
找一个同学（或者用教师提供的基础游戏），以"产品经理"的身份进行评审：
|
||
1. 玩他/她的游戏，列出你觉得需要加的功能
|
||
2. 用 Must Have / Nice to Have / Later 排序
|
||
3. 写出最高优先级功能的详细需求描述（要具体到AI能直接执行的程度）
|
||
4. 把你的"产品评审报告"发给那位同学
|
||
|
||
这个挑战训练的是"从用户视角发现需求"的能力——这是产品经理最核心的技能！
|