feat: 新增 AICODE-06 魔幻俄罗斯方块第6-7课教案及 demo

- AICODE06-06 魔幻俄罗斯方块（上）：工程师思维启蒙，Level 0 需求文档 + 压力测试 + 结果溯源
- AICODE06-07 魔幻俄罗斯方块（下）：增量需求文档 + 魔改升级 + 成果路演
- demo/demo-level0.html：完整基础俄罗斯方块（含虚影、暂停、升级）
- demo/demo-level1-bomb.html：炸弹方块示例（含粒子爆炸特效）

Co-Authored-By: Claude Sonnet 4.6 (1M context) <noreply@anthropic.com>

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

@@ -0,0 +1,356 @@
+---
+课时: 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 需求文档合并版」——把上节课的需求文档和今天的增量需求文档合并成一份完整的文档，让任何人读了都能理解整个游戏的所有规则