AICODE2026/3-lessons/AICODE-06/AICODE06-07 魔幻俄罗斯方块（下）.md

---
课时: 7
主题: 魔幻俄罗斯方块（下）— 魔改升级 + 成果路演
核心能力: [拆解力, 共创力, 表达力]
核心工具: [Kimi 2.5]
时长: 90分钟
透明化层级: 过程层
适用路线: AICODE-06
---

### 1. 课程目标

**知识目标：**
- 理解「功能扩展」的本质：在已有基础上，通过新一轮需求文档 + 生成 + 验收来增加功能
- 理解「需求冲突」的概念：新功能的规则可能跟已有功能产生交互，需要提前想清楚
- 理解路演不只是展示结果，而是展示「设计决策」——你为什么这样设计

**能力目标：**
- 能独立完成「想法 → 需求文档 → 压力测试 → 生成 → 验收 → 迭代」完整流程（共创力）
- 能在验收时主动测试功能之间的交互，发现潜在冲突（拆解力）
- 能用 3 分钟路演清楚说明：加了什么功能、需求文档改了几版、遇到什么问题怎么解决的（表达力）

**情感目标：**
- 体验「每个人的游戏都不一样」带来的成就感和个性化自豪感
- 建立「我能用需求文档控制 AI 做出我想要的东西」的自信
- 感受从「做一个大家都一样的游戏」到「做一个只属于我的游戏」的跨越

---

### 2. 核心概念与误概念预设

**核心概念认知层级：**

| 概念 | 学生类比 | 认知层级 |
|------|---------|---------|
| 功能扩展 | 在基础款手机上加功能——不是重新做一台手机，而是在已有基础上增加 | 理解层 |
| 需求冲突 | 新加了一条规则，跟原来的规则打架了——就像「所有人说话不准超过10秒」和「发言人可以不限时间」同时存在 | 应用层 |
| 增量需求文档 | 只写「新加的部分」以及「新部分跟原有部分的交互规则」，不需要把全部需求重写一遍 | 理解层 |
| 路演 = 决策展示 | 路演不是说「我做了什么」，而是说「我为什么这样设计」——设计背后的思考才是最有价值的 | 迁移层 |

**典型误概念表：**

| 编号 | 误概念 | 正确认知 | 激发策略 |
|------|--------|---------|---------|
| M1 | 加新功能要把整个游戏重新做一遍 | 在已有代码基础上增加功能，只需要写「新功能的需求文档」 | 演示「增量需求文档」的写法，只写新加的部分 |
| M2 | 新功能加进去就算完成了，不用测试已有功能 | 新功能可能跟已有功能冲突，必须测试两者的交互 | 举例：加了「炸弹」，炸弹爆炸后会不会触发消行？触发的话是几分？ |
| M3 | 需求文档越来越长越好，把所有想法都写进去 | 本次迭代只写「这次新加的功能」，保持文档聚焦 | 「这次 AI 只需要知道新加什么，不需要把整个游戏重新理解一遍」 |
| M4 | 路演只要展示游戏好不好玩就行 | 路演的核心是展示你的思考：你加了什么、为什么加、需求文档改了几版、遇到什么问题 | 对比两种路演：一个只展示功能，一个讲设计决策，让学生投票哪个更精彩 |
| M5 | 没写清楚的需求可以让 AI 自己发挥 | 「让 AI 自己发挥」的部分你就失去了控制，结果可能跟你想的完全不同 | 「你让 AI 自己发挥了哪里？那里 AI 做出来的跟你想的一样吗？」 |

---

### 3. 教学准备

**工具与环境：**
- 每台电脑已登录 Kimi 2.5，网络正常
- 学生上节课（第6课）完成的俄罗斯方块 HTML 文件保存在桌面
- 投影可切换至任意学生屏幕
- 准备路演计时器（3分钟倒计时）

**教学资源：**
- 教师准备：「增量需求文档」提示词（见第5节）
- 教师准备：几个功能想法的参考清单（防止学生没有灵感，见第5节）
- 教师准备：路演结构引导卡（见第5节，路演前发给学生）
- 学生资源：第6课完成的俄罗斯方块 HTML 文件

**教师备课体验任务：**
> 备课前，教师必须亲自完成以下操作：
>
> 1. 选2-3个功能（比如炸弹方块、速度加成、颜色主题），各写一份增量需求文档，实际提交 Kimi 测试生成质量
> 2. 故意在一个功能的需求文档里漏写「与消行的交互规则」，观察 AI 会怎么处理
> 3. 练习一遍 3 分钟路演，讲「设计决策」而不只是展示游戏

---

### 4. 教学流程

**第一幕：联系 (Connect) — 10分钟** 🔗

**【环节】上节课回顾 + 功能发布 (10分钟)**

**师：** 上节课结束前，我让你们想一个下节课要加的功能。现在每个人说出来——你想给你的俄罗斯方块加什么？
【每人快速说一个，教师写在白板/投屏上】

**师：** 我们来看一下大家想加的功能。
（读出清单）有没有一模一样的？

**【分支A】若有学生选了相同的功能：**
**师：** 你们选了同样的功能，但你们的需求文档可能完全不一样——因为每个人对这个功能的设计可能不同。比如同样是「炸弹方块」，炸弹爆炸多大范围？爆炸后会不会消行？这些都是你自己决定的。

**【分支B】若所有人都选了不同的功能：**
**师：** 大家选的都不一样——这节课结束，每个人的游戏都会跟别人的不一样。这就是今天最有意思的地方。

**师：** 来简单说一下——你想加的功能，最难描述清楚的是哪一条规则？
**生：** （各自说出预感最难写的部分）
**师：** 很好，记住这个预感。等会写需求文档的时候，那条规则要特别仔细写。
【诊断点：学生上节课课后是否真的想了，还是现在才开始想】【识别层】

---

**第二幕：建构 (Construct) — 65分钟** 🛠️

**【分段一：写增量需求文档 + 压力测试】(20分钟)**

**预设误概念：**
- 误概念 M1：加新功能要把整个游戏重做
- 误概念 M3：需求文档要把所有东西都写进去

**讲解与演示 (Teach & Demo): (5分钟)**

**师：** 今天写的需求文档，跟上节课不一样。上节课写的是「整个游戏的规则」，今天只写「新加的功能」。这叫增量需求文档。
【投屏展示增量需求文档提示词，见第5节】

**师：** 有一个特别重要的部分——「与原有功能的交互规则」。我举个例子：你加了一个炸弹方块，炸弹爆炸了，爆炸范围里刚好有一整行被清空了——这算消行吗？算消行的话，得多少分？
**生：** ……这个我没想过。
**师：** 对，这就是功能交互。新功能和原有功能之间，总会有一些「撞在一起」的情况，需要提前想清楚。
【理解层：建立「功能之间有交互」的设计意识】

**师：** 我来演示一次——用「炸弹方块」功能写一份增量需求文档，然后做一次压力测试。
【教师演示：写需求 → 压力测试 → AI 提问 → 补漏洞，重点展示「交互规则」这部分】

**学生实践 (Practice): (13分钟)**

1. 学生写自己的功能的增量需求文档（重点写清楚：功能规则 + 与消行/得分的交互规则）
2. 执行「压力测试」提示词
3. 针对 AI 提出的问题，补充完善需求文档

> 教师走动观察重点：
> - 学生是否写了「交互规则」这一部分？
> - 对于「AI 问了什么」感到最意外的问题是什么？

**进度同步 (Checkpoint): (2分钟)**

**师：** AI 压力测试问了你最意外的问题是什么？
**生：** （分享1-2条，重点是「交互规则」相关的问题）
**师：** 这类问题，如果不写清楚，加进去的功能会跟原来的规则「打架」，产生奇怪的结果。

---

**【分段二：提交生成 → 测试交互 → 溯源迭代】(25分钟)**

**预设误概念：**
- 误概念 M2：新功能加进去之后，只测新功能就行
- 误概念 M5：没写清楚的部分让 AI 自己决定

**讲解与演示 (Teach & Demo): (3分钟)**

**师：** 把需求文档提交 Kimi，有一个特别的要求——告诉 AI 「在已有代码基础上增加功能」，而不是「重新做一个游戏」。
【投屏展示「增量生成」提示词，见第5节】

**师：** 生成之后，验收的时候要测两件事：
- 第一：新功能有没有按需求做出来
- 第二：原来的功能还正常吗（消行、得分、游戏结束，都要测）

**师：** 遇到不对的地方，还是同样的动作——溯源到需求文档，找到是哪条没说清楚，改需求，重新生成。

**学生实践 (Practice): (19分钟)**

1. 把需求文档提交 Kimi，基于已有代码增加新功能
2. 验收：新功能测试 + 原有功能回归测试
3. 记录「结果跟预期不一样」的地方
4. 溯源到需求文档 → 修改 → 重新生成
5. 重复迭代，直到功能符合预期

> 教师走动观察重点：
> - 新功能和消行之间的交互是否符合需求文档的设计？
> - 是否有学生因为新功能导致原有功能出问题（回归 bug）？
> - 学生是否在需求文档里找到了回归 bug 的根源？

**进度同步 (Checkpoint): (3分钟)**

**师：** 你加的新功能，有没有让原来的某个功能出问题？怎么溯源到需求文档的？
【诊断点：学生是否理解「新功能可能影响旧功能」，并能溯源到需求文档里的交互规则】【应用层】

**【分支A】若学生发现了回归 bug 并成功溯源：**
**师：** 非常好！你刚才发现的问题，在需求文档里是哪条交互规则没有写清楚？

**【分支B】若学生说「没有出问题，一切正常」：**
**师：** 那我们来测一个边界情况——你的新功能触发的同时，刚好消了一行，得分是怎么算的？
【主动暴露交互场景，测试是否真的没问题】

---

**【分段三：路演准备】(10分钟)**

**预设误概念：**
- 误概念 M4：路演只要展示游戏好不好玩就行

**讲解与演示 (Teach & Demo): (3分钟)**

**师：** 接下来每个人做一个 3 分钟路演。但我们的路演跟一般的展示不一样——不是「看，我做了个游戏」，而是「我为什么这样设计」。
【发放路演结构引导卡，见第5节】

**师：** 路演要说三件事：
1. 我加了什么功能，这个功能是什么效果
2. 我的需求文档改了几版，每次改了什么
3. 遇到的最难的地方是什么，怎么解决的

**师：** 注意第二和第三点——这才是最有价值的部分。任何人都能展示一个游戏，但你经历了哪些思考和决策，是只有你有的。

**学生实践 (Practice): (7分钟)**

学生准备路演，按三点结构整理思路（不需要写逐字稿，想清楚就行）。
教师走动帮助学生回忆「需求文档改了几版」「哪里卡住了怎么解决的」。

---

**第三幕：反思 (Contemplate) — 10分钟** 🤔

**【环节】成果路演 (8分钟)**

每位学生 3 分钟路演（按人数调整，6人小班每人约 1.5 分钟，重点展示设计决策）。

**师：** （每人路演后）你的需求文档改了几版？最关键的那次修改是什么？

**【环节】互评 (2分钟)**

**师：** 刚才大家展示的游戏里，哪个功能的需求文档你觉得写得最清楚？
**师：** 哪个功能的设计，是你之前没想到可以这样做的？
【诊断点：学生是否能评价「需求清晰度」，而不只是「游戏好不好玩」】

---

**第四幕：延续 (Continue) — 5分钟** 🚀

**【环节】抽象总结 (3分钟)**

**师：** 两节课，你们从零做了一个俄罗斯方块，还加了自己设计的功能。我们用的核心方法是什么？
**生：** 写需求文档，让 AI 做，然后验收，有问题就改需求文档……
**师：** 对。这个流程有个名字：需求 → 设计 → 实现 → 验收 → 迭代。这是真实的工程师每天都在做的事情。
**师：** 你们今天做的，跟真实的产品开发，步骤上是完全一样的。

**师：** 最后一个问题：如果今天你的功能需求文档第一版就做对了，是因为你运气好，还是需求写得好？
**生：** 需求写得好？
**师：** 对。运气不可靠，清晰的需求才可靠。这是今天最重要的一句话。

**【环节】下节预告 (2分钟)**

**师：** 接下来的课程，你们会进入更大的项目。今天学到的方法——需求文档、压力测试、结果溯源——会一直用到。你们已经会了，后面只是把项目变得更复杂。

---

### 5. AI 助教使用指南

**增量需求文档模板（学生填写）：**

```
# 新功能需求文档：[功能名称]

## 功能描述
[用一两句话说清楚这个功能是什么]

## 触发条件
[什么情况下这个功能会出现/触发？]

## 功能规则
[这个功能具体怎么运作？每条规则尽量具体]

## 与原有功能的交互规则
- 与消行的交互：[这个功能触发时，如果同时消了行，怎么处理？]
- 与得分的交互：[这个功能会影响得分吗？怎么影响？]
- 与游戏结束的交互：[游戏结束时，这个功能有没有特殊处理？]

## 验收标准
[我怎么测试这个功能做对了？列出2-3条可以测试的情况]
```

**「增量生成」提示词：**

```
我已经有一个俄罗斯方块游戏（代码在下面）。
现在我需要在这个基础上增加一个新功能，需求如下：

[粘贴你的增量需求文档]

要求：
1. 在已有代码基础上增加这个功能，不要改变原有功能的行为
2. 严格按照需求文档实现，不要添加文档里没有提到的内容
3. 输出完整的 HTML 文件（内联 CSS 和 JS）

已有代码：
[粘贴你的游戏 HTML 代码]
```

**功能灵感参考清单（学生没有想法时参考）：**

| 功能 | 一句话说明 |
|------|---------|
| 炸弹方块 | 特殊方块，落地后炸掉周围一圈 |
| 速度加成方块 | 碰到就让下落速度加快 5 秒 |
| 冻结方块 | 碰到就让当前方块暂停 3 秒不下落 |
| 彩虹模式 | 消行的时候屏幕闪一下彩虹色 |
| 双人模式 | 两个人在同一个游戏区域交替操控 |
| Boss 行 | 每隔 10 行出现一行不能被普通消行消掉的「Boss 行」 |
| 方块预言家 | 显示接下来 3 个方块而不只是 1 个 |
| 重力反转 | 消 4 行一次触发 5 秒重力反转，方块往上飞 |

**路演结构引导卡（课前发给学生）：**

```
我的路演（3分钟）

1. 我加了什么功能（30秒）
   → 演示给大家看

2. 我的需求文档改了几版（1分钟）
   → 第一版写完之后，AI 问了我什么让我意外的问题？
   → 我改了哪里？改完之后结果有什么变化？

3. 最难的地方（1分钟）
   → 我遇到的最难描述清楚的规则是什么？
   → 最后是怎么写清楚的？
   → 有没有发现新功能让原来的功能出了问题？怎么解决的？

4. 如果重来一次（30秒）
   → 需求文档哪里会写得不一样？
```

---

### 6. 教师指南

**本课技术备注：**

增量开发策略：把已有的 HTML 代码粘贴给 Kimi，让它在基础上增加功能，比重新生成稳定得多。如果 Kimi 倾向于重写整个游戏，在提示词里加「请务必基于我提供的代码修改，不要重新生成整个游戏」。

功能复杂度控制：炸弹方块、速度加成、冻结方块是低复杂度功能，适合大多数学生。重力反转、双人模式是高复杂度功能，适合进度快的学生挑战。教师可以根据学生能力在发清单时口头引导。

**常见问题 FAQ：**

| 问题 | 应对 |
|------|------|
| 「加了新功能之后原来的功能坏了」 | 先检查需求文档里「与原有功能的交互规则」写了什么；如果没写，补上去重新生成 |
| 「Kimi 加功能之后把整个游戏重写了，之前的功能不见了」 | 提示词里强调「在已有代码基础上修改」；或者把原有代码中关键的函数名告诉 Kimi，要求保留 |
| 「我想要的功能 AI 做不出来」 | 先检查需求文档是否足够具体；可以要求 AI「只实现这一个功能，不要改其他任何部分」；确实做不到的记录进 Backlog 留待下次 |
| 「路演不知道说什么」 | 引导卡上的4个问题逐一回答就够了；重点提醒「不需要说得很完整，说你觉得最有意思的那件事就行」 |
| 「时间不够，功能还没做完」 | 没关系，路演时说「我加了什么功能、需求文档写到第几版、还差什么没完成」也是完整的路演——这本身就是真实工程师的日常 |

**课堂风险预案：**
- 如果多名学生选了同一个功能（比如炸弹方块）：利用这个机会对比两个人的需求文档——相同的功能，两份需求文档有什么不同？最终生成的结果有什么不同？这是很好的教学素材。
- 如果某个学生的功能过于复杂（比如联机对战）：引导学生做「最小可行版本」——先只实现最核心的规则，其余的加进 Backlog，下次再加。

---

### 7. 5分钟日常AI挑战

**本周挑战：** 再加一个功能，或者把这次没做完的功能完成
**挑战说明：** 用同样的方法——写增量需求文档、压力测试、生成、验收——自己在家给游戏再加一个功能（或者完成这节课没完成的部分）。下节课展示。
**下节课分享：** 选 2-3 位同学展示在家加的功能，重点说「需求文档是怎么写的」

---

### 8. 拓展任务

**拓展一（推荐）：** 给你的游戏加一个「暂停功能」——按 P 键暂停，再按 P 键继续；暂停时显示一个半透明遮罩
**拓展二（挑战）：** 给你的游戏写一份「完整的 Level 0 + Level 1 需求文档合并版」——把上节课的需求文档和今天的增量需求文档合并成一份完整的文档，让任何人读了都能理解整个游戏的所有规则