ClassFeedback/.claude/lesson/AI03/AICODE-06/AICODE06-07 魔幻俄罗斯方块（下）.md

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

### 1. 课程目标

**知识目标：**
- 理解「自动化测试」的概念：不靠人工玩，让代码自己验证代码，更快更全面
- 理解「测试覆盖」：需求文档里每一条规则，都应该有一条对应的测试
- 理解功能扩展的增量思维：新功能只写「增量」，不重写整体

**能力目标：**
- 能把需求文档转化为测试条件，交给 AI 生成测试脚本（拆解力）
- 能读懂测试脚本的 ✅❌ 结果，把失败的测试溯源到需求文档（韧性力）
- 能独立完成「需求 → 审核 → 生成 → 测试 → 修复」完整闭环（共创力）

**情感目标：**
- 体验「一键跑测试，马上知道哪里有问题」带来的效率感
- 建立「测试通过才算完成，不是能玩就算完成」的质量意识
- 感受从「每次手动点来点去找 bug」到「测试脚本自动找 bug」的升级

---

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

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

| 概念 | 学生类比 | 认知层级 |
|------|---------|---------|
| 自动化测试 | 与其自己每次手动检查作业有没有写对，不如写一个「答案核对程序」，把你的答案输进去，自动判断对错 | 理解层 |
| 测试覆盖 | 需求文档里写了10条规则，测试脚本就要测10件事——少测一条，那条出了 bug 你就不知道 | 应用层 |
| 边界条件 | 不只测「正常情况」，还要测「极端情况」——比如方块刚好在边角旋转、同时消4行、积木堆到最顶 | 应用层 |
| 增量需求文档 | 只写「新加的部分」，不重写整体——就像给手机升级系统，不是重新买一台手机 | 理解层 |
| 新窗口原则 | 让同一个人既写方案又审方案，他永远找不出大问题——审核和测试必须开新窗口，让没有上下文的新 AI 来做，才能客观找出漏洞 | 应用层 |

**典型误概念表：**

| 编号 | 误概念 | 正确认知 | 激发策略 |
|------|--------|---------|---------|
| M1 | 测试就是自己玩一遍，没出问题就算通过 | 手动测试只能发现你刚好测到的问题；自动测试每次都覆盖所有条件，不会遗漏 | 「你刚才玩的时候，有没有特意测『同时消4行的得分是不是800』？」 |
| M2 | 测试脚本是程序员才会写的东西 | 把你的需求文档给 AI，AI 就能帮你把每条需求变成一个测试 | 现场演示：需求文档→AI→测试脚本，5分钟完成 |
| M3 | 加新功能要把整个游戏重新做一遍 | 增量需求文档只写新加的部分，在已有代码上加，不是重做 | 演示增量需求文档的写法 |
| M4 | 测试通过了就说明没有 bug | 测试只能覆盖你想到的情况；没覆盖的情况仍然可能有 bug——所以需求文档要写详细 | 「你的测试脚本有没有测『反重力期间消行』？」 |
| M5 | 测试失败说明代码写错了 | 测试失败可能是代码问题，也可能是需求文档没说清楚——先溯源，再决定改哪里 | 展示一个「测试失败但代码没错，是需求文档漏写了」的案例 |
| M6 | 需求审核、测试脚本生成可以在写需求的同一个窗口里做 | 上下文污染——AI 会受之前对话影响，不会客观审核自己生成的东西。审核和测试必须开新窗口 | 演示：同一窗口让 AI 审核自己写的需求，回答很保守；新窗口审核，问题暴露更多 |

---

### 3. 教学准备

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

**教学资源：**
- 教师准备：增量需求文档模板（见第5节）
- 教师准备：生成测试脚本的提示词（见第5节）
- 教师准备：一份提前生成好的测试脚本演示（包含1个 ✅ 和1个 ❌，用于导入展示）
- 教师准备：功能灵感参考清单（见第5节）
- 教师准备：路演结构引导卡（见第5节）
- 学生资源：第6课完成的俄罗斯方块 HTML 文件 + Level 0 需求文档

**教师备课体验任务：**
> 备课前，教师必须亲自完成以下操作：
>
> 1. 用自己的俄罗斯方块代码 + 需求文档，让 Kimi 生成测试脚本，实际运行并记录结果
> 2. 故意在需求文档里漏写一条规则，观察测试脚本是否能发现对应的 bug
> 3. 准备一个演示用的「测试结果页面」，包含至少1个 ✅ 和1个 ❌，用于课堂导入
> 4. 提前试跑「炸弹方块」功能的增量需求文档完整流程，记录 AI 审核会问什么问题

---

### 4. 教学流程

---

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

*本幕目标：用每人的功能构想激活学生兴趣，制造「今天不只是加功能，还要学一个新技能」的认知悬念*

**【环节】上节课回顾 (4分钟)**

**师：** 上节课结束前，我让你们想一个今天要加的功能，而且在出门前每人说了一句话。我们来回顾一下——上节课我们用了 Plan Mode，它有几步？谁来说？
【诊断点：检测 Plan Mode 三步流程的记忆保持度】【识别层】

**生：** （预期：打开 Plan Mode → 写需求文档 → 让 AI 审核……）

**【分支A】若学生能说出三步（写文档、审核、执行）：**
**师：** 说得很准。今天还是这三步，但是有一点不一样——今天写的是「增量需求文档」，不是重新写整个游戏。等会儿我会解释区别在哪里。

**【分支B】若学生只说出一两步：**
**师：** 没关系，我帮你补一下。Plan Mode 三步：第一步，写需求文档，把你想做的东西说清楚；第二步，需求审核，让 AI 扮演审核工程师找漏洞；第三步，执行，生成代码。今天还是这三步，我们继续。

**师：** 好，现在说说你想加的功能——每人说一个，我把它们写在黑板上。
【每人快速说一个，教师写在白板/投屏上，列成一列】

**生：** （各自说出功能：炸弹方块、速度加成、冻结方块、彩虹消行……）

**师：** 大家看一下黑板——（指着功能列表）这里有六个不同的功能方向，没有两个人做一样的。你们今天各自在做一个完全不同的版本。

**师：** 我们来做一件有趣的事——互相评一下别人的功能想法。你觉得黑板上哪一个功能听起来最难描述清楚？
**生：** （讨论，指出某个功能）
**师：** 为什么觉得难？
**生：** （例如：「重力反转不知道要怎么写规则」「炸弹不知道爆炸范围算不算消行」）
**师：** 你们刚才说的这些「不知道」，就是今天需求文档里必须写清楚的部分。不写清楚，AI 就会自己决定，结果可能跟你想的完全不一样。

**【环节】引发认知冲突 + 悬念铺垫 (6分钟)**

**师：** 我再问你们——你刚才说想加的功能，你觉得最难描述清楚的规则是哪一条？比如你想加炸弹方块，「炸弹爆炸」这件事，你要怎么告诉 AI？
【诊断点：探测学生对「把直觉转化为精确规则」的困难点认知】【理解层】

**生：** （各自说出难点——爆炸范围？爆炸后消行吗？得分怎么算？）

**师：** 很好，你已经在思考这个问题了。等会儿写需求文档的时候，那条规则要特别仔细。

**师：** 今天除了加功能，我们还会学一个新技能。上节课你们手动测试游戏——自己玩、自己找 bug，对吗？手动测试有一个问题，一会儿让你们自己感受。
【故意不展开，制造悬念】

**师：** 我问你们——你的游戏有5条规则，你在手动测的时候，你能保证5条都测到了吗？
**生：** （预期：不一定……有点难……）
**师：** 等会儿让你们亲身体验这个问题，我们先进建构。

**师：** 打开你上节课的游戏文件，确认能正常运行。我们进入建构阶段。

---

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

---

**【分段一：增量需求文档 + 需求审核】(15分钟)**

*本段重点：理解「增量」思维，写出可测试的需求文档，尤其是交互规则和验收标准*

**预设误概念：**
- 误概念 M3：加新功能要把整个游戏重做
- 误概念：验收标准可以写成「功能正常」这种模糊的话

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

**师：** 今天继续用 Plan Mode。但今天写的是「增量需求文档」——只写新加的部分，不重写整个游戏。

**师：** 类比一下——你手机升级系统，是重新买一台手机，还是只更新改变的那一部分？
**生：** （预期：只更新改变的部分）
**师：** 对。增量需求文档就是这个意思：你的游戏核心逻辑不动，你只描述「要在这个基础上加什么」。

**师：** 增量需求文档有一个特别重要的部分，叫「与原有功能的交互规则」。我举一个具体例子——你加了炸弹方块。炸弹落地，爆炸了。爆炸之后刚好把整行都消干净了——这算消行吗？得多少分？是按炸弹规则算，还是按消行规则算，还是两个叠加？

**师：** 如果你没写清楚，AI 自己决定，结果可能跟你想的完全不一样。所以交互规则必须写。

**师：** 还有一个字段叫「验收标准」。它的格式是这样的：
**「[情况] → [预期结果]」**
比如：「炸弹落地时周围没有积木 → 爆炸动画播放，得分+50，无消行」。
验收标准必须是可以测试的——能测试 = 说清楚了具体情况，说清楚了预期结果。不能写「功能正常运行」，那不是验收标准，那是废话。

**师：** 我来考考你们——以下两条验收标准，哪条是可测试的？
- A：「炸弹功能运行正常」
- B：「炸弹落地后，落点周围3×3格内的积木清除，得分+50」

**生：** （预期：B）
**师：** 对，B 是可测试的——它告诉了 AI「清除3×3范围」和「+50分」。A 是废话——AI 不知道「正常」是什么意思。你的验收标准必须全部像 B 这样写。
【投屏展示增量需求文档模板，见第5节】

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

1. 学生填写增量需求文档（重点：功能规则 + 交互规则 + 验收标准）
2. **⚠️ 开新窗口**：复制需求文档内容，打开全新的 Kimi 对话，执行「需求审核」提示词
   - 不能在写需求的同一个窗口里审核——AI 会受上下文影响，不会客观指出问题
3. 回答 AI 的问题，把答案补充进需求文档（回到原来的窗口补充）

> 教师走动：检查以下三项——是否写了「与原有功能的交互规则」？验收标准是否是「情况 → 预期结果」格式？验收标准条数是否至少3条？

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

**师：** AI 审核出了什么？有没有让你意外的问题？
**生：** （分享，例如：「AI 问我炸弹同时触发消行怎么算」）

**【分支A】若学生说 AI 问出了没想到的问题：**
**师：** 这个问题你之前有想到吗？
**生：** 没有……
**师：** 所以 AI 审核是真的有用的——它问的问题不是废话，是你确实需要回答的问题。

**【分支B】若学生说 AI 没审出什么问题：**
**师：** 把你的需求文档发我看一下。（观察）——你的验收标准里有没有写边界情况？比如「功能触发时恰好也消行」这种情况？如果没有，让 AI 专门针对边界情况再审一遍。

**师：** 好，需求文档基本确认了，进入执行阶段。

---

**【分段二：生成第一版 → 手动测试 → 感受痛点】(15分钟)**

*本段重点：先让学生亲身体验手动测试的局限，再自然引出「让电脑帮我们测」的需求*

**预设误概念：**
- 误概念 M1：手动玩一遍没出问题就算通过
- 误概念：测试只需要测「好不好玩」，不需要逐条对照需求

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

**师：** 把确认好的增量需求文档提交 Kimi，基于上节课的代码增加新功能。
【投屏展示「增量生成」提示词，见第5节】

**师：** 生成之后，先手动测几条——自己玩一玩，看看新功能有没有按需求做出来。特别注意：不是随便玩，是对照着你的验收标准一条条测。

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

1. 提交增量需求文档 + 旧代码给 Kimi，生成第一版
2. 打开游戏，手动测试：新功能触发了吗？原有消行/得分还正常吗？
3. 对照验收标准逐条检查，记录发现的问题

> 教师走动观察：故意不干预，让学生自己感受「手动测试的局限」。观察：是否有学生只是「玩了一会儿」而没有逐条对照验收标准？是否有学生根本没有测「新功能和消行同时触发」的边界情况？是否有学生测了3条就觉得「差不多了」？

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

**师：** 手动测了哪几条？对照你的验收标准，你测了几条？
**生：** （预期：2条、3条……）

**师：** 你的验收标准里一共有几条？
**生：** 5条……

**师：** 你测了3条，还有2条没测。你确定那2条没有问题吗？
**生：** 不确定……

**师：** 还有一个问题——就算今天你把所有5条都测了，下次你改了代码，你还要重新手动测一遍。如果你做了第二版、第三版，每次都要从头手动测一遍。需求文档越来越长，要测的条数越来越多，手动测试需要的时间也越来越长。

**师：** 有没有办法，让电脑帮我们测，而且每次都自动把所有条件测完？

**【分支A】若有学生说「那肯定有程序能做这个」：**
**师：** 你说对了！这个东西叫测试脚本。我们现在就去做一个。

**【分支B】若学生面面相觑，不知道答案：**
**师：** 答案就是——用 AI 帮我们写一个测试脚本。这个脚本会自动运行你的游戏逻辑，逐条对照需求文档，告诉你哪条通过了、哪条失败了。我来给你们看一下它长什么样。

---

**【分段三：AI 生成测试脚本 → 跑测试 → 修复】(25分钟)**

*本段重点：生成并运行测试脚本，学会读懂 ✅❌ 结果并溯源，建立「测试才算完成」的质量意识*

**预设误概念：**
- 误概念 M2：测试脚本是程序员才会写的
- 误概念 M5：测试失败说明代码写错了，不可能是需求问题
- 误概念：看不懂代码就没法用测试脚本

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

**师：** 我来给你们看一个东西。
【投屏展示教师提前准备好的测试结果页面，显示 ✅❌ 列表】

**师：** 在看之前，先讲一个重要规则——**生成测试脚本必须开新窗口。** 这和上节课需求审核的原因一样：AI 不会承认自己的问题。你在写游戏代码的同一个窗口里让 AI 生成测试，它会倾向于「测试通过」，因为它觉得自己写的代码没问题。换新窗口，让新的 AI 来测，它才会客观地发现问题。

**师：** 整个项目的窗口规则是这样的：写需求一个窗口、审核需求一个新窗口、生成代码一个新窗口、生成测试一个新窗口。**每个独立的任务，都在自己干净的窗口里做，避免上下文污染。**

**师：** 这是一个测试脚本跑出来的结果。你们来读一下——
- ✅ 消1行得分100分：通过
- ✅ 消2行得分300分：通过
- ✅ 消4行得分800分：通过
- ❌ 炸弹爆炸得分：期望50，实际得到0
- ✅ 游戏结束条件：通过
- ❌ 炸弹+消行叠加得分：期望150，实际得到100

**师：** 它自动测了6条规则，告诉我哪些通过了、哪些失败了，还说明了失败的具体原因——期望是多少，实际是多少。我没有玩游戏，是代码自己测自己。

**师：** 你们说，这个测试脚本是怎么工作的？它是怎么知道「消1行应该得100分」的？
**生：** （预期：从需求文档里知道的？）
**师：** 对！测试脚本的工作方式就三步：第一步，构造一个具体的场景——比如「棋盘最底行全满了一行」；第二步，调用游戏里的消行函数；第三步，对比结果和需求文档里写的数字。需求文档说100分，结果也是100分，就是 ✅；结果是别的数字，就是 ❌。

**师：** 你不需要看懂每一行代码。你只需要：能读 ✅❌ 结果、能看懂失败原因、能判断是代码问题还是需求文档问题。

**师：** 怎么判断失败原因？方法是这样的——
**师：** 如果 ❌ 显示「期望50，实际0」，你先查需求文档：文档里有没有写「炸弹爆炸得50分」？
**师：** 如果需求文档写了，但代码算出来是0，那是代码问题——让 AI 修代码。
**师：** 如果需求文档漏写了这条规则，那是需求问题——先补需求文档，再重新生成代码。

【投屏展示「生成测试脚本」提示词，见第5节】

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

1. 把需求文档 + 游戏代码提交 Kimi，生成 `test.html`
2. 双击打开 `test.html`，查看测试结果
3. 对每一个 ❌，按以下步骤处理：
   - 读失败原因：「期望 X，实际 Y」
   - 查需求文档：这条规则文档里写清楚了吗？
   - 如果是代码问题 → 告诉 Kimi「这个测试失败了：[失败信息]，帮我修复」
   - 如果是需求问题 → 先补充需求文档，再让 AI 重新生成代码
4. 修复后重新跑测试，目标：全部 ✅

> 教师走动观察重点：
> - 学生是否看到 ❌ 就直接让 AI「修代码」，而没有先判断是需求问题还是代码问题？
> - 是否有学生测试结果全是 ✅，但游戏实际上还有问题？此时引导：「哪条 bug 对应的规则，在需求文档里没有写到？」
> - 是否有学生 `test.html` 打开是空白？提示使用「测试失败溯源」提示词

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

**师：** 你的测试脚本发现了几个 ❌？哪一个让你最意外？
【诊断点：学生是否发现了手动测试时没有发现的问题】【应用层】

**【分支A】若测试发现了手动没发现的 bug：**
**师：** 这个 bug 你刚才手动玩的时候发现了吗？
**生：** 没有……
**师：** 这就是自动测试的价值——你没想到去测的地方，它帮你测了。想象一下，如果你发布了这个版本，别人玩到这个 bug 会怎么样？
**生：** 会觉得游戏有问题……
**师：** 但是因为你有测试脚本，你在发布之前就知道了。这就是「安全网」。

**【分支B】若测试全部通过：**
**师：** 全部通过——说明你的需求文档写得很清楚，AI 也执行得准确。但我再问一下：测试脚本测了几条？你的验收标准里有几条？
**生：** （如：测了5条，文档里写了7条……）
**师：** 有2条没有被测到。是不是那2条在生成测试脚本的时候，AI 没找到对应的逻辑？或者写得不够清楚，没办法生成测试？把那2条拎出来，让 AI 单独补测。

**【分支C】若测试脚本打不开或全是错误：**
**师：** 不要慌，这种情况很正常。我们用「最小化调试法」——不是让 AI 修整个测试脚本，而是只请它「单独测一条最简单的规则，比如消1行得100分」，先让一条测试跑起来，再逐步扩展。

---

**【分段四：有了安全网，放心魔改——第二版、第三版】(10分钟)**

*本段重点：建立「跑测试 → 确认安全 → 再改代码」的迭代习惯，鼓励学生大胆扩展*

**预设误概念：**
- 误概念：有了测试脚本，每次改完不用跑，「应该没问题」
- 误概念：第一版做到及格就行，没必要做第二版

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

**师：** 你现在有了一个测试脚本。这个测试脚本是你的「安全网」。它的具体意义是什么？

**师：** 没有安全网的时候，你怕改出问题，所以不敢改太多。每次改完要自己手动测半天，万一改出新 bug 还得找半天。结果是——你不敢大胆加功能。

**师：** 有了安全网之后：每次改完代码，双击 `test.html`，10秒钟看结果。全部 ✅，说明原有功能没被破坏，可以继续加。出现 ❌，马上知道哪里出问题，立刻修。这就是「安全网」的具体作用——让你敢放心改代码。

**师：** 所以现在，有了安全网，我们才敢做更大胆的第二版。去做——比第一版更酷、更复杂。每加完一个功能，跑一遍测试，确认 ✅ 再继续加下一个。

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

1. 在第一版基础上继续扩展——加第二个功能，或者把第一个功能做得更完整
2. 每次生成新代码后，跑 `test.html`，确认没有破坏原有逻辑
3. 有余力的学生继续做第三版，目标：做出功能灵感清单里「⭐⭐⭐」的功能

> 教师走动：鼓励学生跑测试，发现有学生只靠手动玩来验证时，提示：「跑一遍测试脚本，10秒就有答案，比手动玩快多了。」

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

**师：** 做了第二版的举手。你加了什么？跑测试了吗？结果怎样？
【诊断点：学生是否形成「加功能 → 跑测试 → 检查结果」的迭代习惯】【应用层】

**【分支A】若学生说「跑了测试，全部通过，然后继续加」：**
**师：** 这就是正确的迭代节奏。以后做任何项目都是这个节奏。

**【分支B】若学生说「加了功能但忘记跑测试」：**
**师：** 现在跑一遍。——有没有 ❌？
**生：** （跑完结果）
**师：** 如果有 ❌，这就是「不跑测试的代价」——你可能在不知情的情况下，新加的功能破坏了原来的逻辑。

---

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

*本幕目标：通过路演和互评，让学生反思「测试覆盖」的本质，以及「需求文档质量 = 测试质量」的核心认知*

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

**师：** 每人1.5分钟路演（6人小班）。路演有引导卡，大家拿一张。
【发放路演结构引导卡，见第5节】

**师：** 路演不是「打开游戏给大家看」——那只是演示，不是路演。路演要讲三件事：你加了什么功能、测试脚本发现了什么、你怎么修的。开始。

（每人依次路演，教师计时。路演要点：）
- 展示最终版本游戏（20秒演示）
- 展示测试脚本的 ✅❌ 结果（告诉大家发现了几个 ❌）
- 重点讲：最意外的那个 ❌ 是代码问题还是需求问题？怎么修的？
- 一句话总结：「如果重来一次，需求文档哪里会写得不一样？」

> 教师观察：是否有学生的路演只说了「我加了炸弹方块」，但没有说测试相关的内容？提示：「测试脚本发现了什么？」

**【环节】互评与讨论 (3分钟)**

**师：** 刚才大家的路演里，哪一个测试脚本发现的问题最有价值？
**生：** （讨论）

**师：** 我们来做一个结构化互评——选一位刚才路演的同学，给他的作品说「一个你觉得做得好的地方」和「一个你觉得可以改进的地方」。
**生：** （互评，例如：「他的炸弹功能很酷，但是我觉得爆炸范围可以更大一点」）
**师：** 「更大一点」——具体怎么大？你能告诉他怎么写到需求文档里吗？
**生：** （尝试表达：「爆炸范围从3×3改成5×5」）
**师：** 这就是一条可测试的需求改进建议。他可以把这条加到需求文档里，然后让 AI 重新生成。

**师：** 有没有人的测试结果全是 ✅，但路演时我们发现游戏还是有问题？
**生：** （可能有学生举手）
**师：** 这说明什么？
**生：** （预期：测试没有覆盖到那个情况……）
**师：** 对。测试只能发现「你写进需求文档的问题」。你没写的，它不知道要测。这就是为什么需求文档要尽量详细——需求文档越完整，测试覆盖越全，漏掉的 bug 越少。

**师：** 给今天的工作做一个评分——需求文档 100 分、测试脚本 100 分、游戏功能 100 分，你自己的三项各给多少分？
（让学生自评，不需要出声，心里有数就好）

**师：** 哪位愿意说说自己的分？
**生：** （分享，例如：「需求文档70，测试80，功能90」）
**师：** 三项里面，哪一项你觉得下次会做得更好？
**生：** （分享）
**师：** 记住这个答案。这就是你下一个项目要重点改进的地方。

---

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

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

**师：** 两节课，我们走了一个完整的流程。谁来说说是哪几步？
**生：** Plan Mode → 需求文档 → 审核 → 生成 → 测试 → 修复……

**师：** 对。这个流程有个名字：需求 → 实现 → 测试 → 修复。真实的工程师每天都在走这个循环。
**师：** 今天最重要的一句话：**「测试通过才算完成，不是能玩就算完成。」**
**师：** 能玩是 60 分，测试通过是 90 分，需求文档里每一条都有测试覆盖是 100 分。

**师：** 还有一件事——今天你们体验了什么是「安全网」。这不只是测试脚本的概念，这是一种工作方式：在做危险操作之前，先建立一个保护机制。以后你们做任何项目，都可以问自己：「我有没有安全网？」

**师：** 最后，我想让你们想一个问题——今天学到的「需求文档 → 测试 → 修复」这个流程，除了做游戏，还能用在哪里？
**生：** （讨论：做网站？做 App？……）
**师：** 对。你们今天走的这个流程，和真实的工程师在公司里走的流程是一样的。只不过他们的项目更大、需求文档更长、测试脚本更复杂。但方法是一样的。

**【环节】下节预告 + 5分钟挑战 (2分钟)**

**师：** 接下来的课程，你们会做更大的项目。今天学到的——Plan Mode、需求审核、自动测试——会一直用到，只是项目变得更复杂。你们已经有了完整的工具箱。

**师：** 本周5分钟AI挑战：找到你需求文档里一条没有被测试覆盖到的规则，把它补进需求文档，然后让 Kimi 给测试脚本加上这条测试，跑一下看是 ✅ 还是 ❌。下节课说出你补的是哪条规则，测试结果是什么。

---

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

**⚠️ 新窗口使用规则（必须遵守）：**

```
本课四个阶段的窗口规则：

窗口 A：写增量需求文档（整理新功能需求用这个窗口）
窗口 B：需求审核（全新窗口——AI 不会承认自己写的有问题）
窗口 C：执行生成（全新窗口——基于原代码增加新功能）
窗口 D：生成测试脚本（全新窗口——让新 AI 客观测试）

核心原则：审核、测试必须换新窗口。在同一个窗口里又写又审
又测，叫「上下文污染」——AI 会偏向为自己生成的内容辩护，
找不出真正的问题。
```

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

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

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

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

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

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

## 验收标准（每条都要能自动测试）
1. [情况] → [预期结果]
2. [情况] → [预期结果]
3. [情况] → [预期结果]
```

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

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

[粘贴增量需求文档]

要求：
1. 在已有代码基础上增加，不要改变原有功能的行为
2. 严格按照需求文档实现，不要添加文档里没有提到的内容
3. 核心逻辑函数（collides、clearLines、rotate 等）必须保持独立，
   不要把逻辑和渲染混在一起（方便后续生成测试脚本）
4. 输出完整的 HTML 文件（内联 CSS 和 JS）

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

**「生成测试脚本」提示词（本课核心）：**

```
我有一个俄罗斯方块游戏，代码如下：

[粘贴游戏 HTML 代码]

我的需求文档如下：

[粘贴需求文档]

请帮我生成一个独立的 test.html 文件，要求：
1. 把游戏的核心逻辑函数（碰撞检测、消行、得分计算等）提取出来
2. 根据需求文档里的每一条规则，编写一个对应的测试
3. 每个测试构造一个具体的场景，调用函数，验证结果是否符合需求
4. 在页面上显示测试结果：✅ 通过 / ❌ 失败（失败时说明期望值和实际值）
5. 不需要任何外部依赖，双击 test.html 就能在浏览器里运行

重点测试的边界条件：
- 方块在左/右边界的碰撞
- 底部锁定
- 消1行/2行/4行的得分是否符合需求文档
- 消行后上方积木是否正确下移
- 游戏结束条件
- [新功能]的触发条件和结果
```

**测试脚本示例输出（教师用于课堂展示）：**

```
俄罗斯方块测试结果
───────────────────────────────────
✅ 消1行得分 100 分              通过
✅ 消2行得分 300 分              通过
✅ 消4行（Tetris）得分 800 分    通过
✅ 游戏结束条件（积木超出顶行）   通过
❌ 炸弹方块落地得分               失败
   期望：50   实际：0
   → 提示：clearBomb() 函数未返回得分
✅ 消行后积木正确下移             通过
❌ 炸弹 + 消行叠加得分            失败
   期望：150（50+100）  实际：100
   → 提示：爆炸触发消行时，炸弹得分未累加
───────────────────────────────────
6/8 通过  2/8 失败
```

**「测试失败溯源」提示词：**

```
我的测试脚本显示这个测试失败了：
测试名称：[测试名称]
期望结果：[期望值]
实际结果：[实际值]

我的需求文档里关于这条规则写的是：
[粘贴相关需求]

请帮我分析：
1. 是代码实现有问题？还是需求文档没有说清楚？
2. 如果是代码问题，具体是哪里需要修改？
3. 如果是需求问题，我需要在需求文档里补充什么？
```

**测试失败溯源示例对话：**

```
学生输入：
测试名称：炸弹方块落地得分
期望结果：50
实际结果：0
需求文档写的是：炸弹方块落地时，播放爆炸动画，得分+50

AI 回答：
这是代码问题。你的需求文档写得很清楚——「落地得分+50」。
问题出在 clearBomb() 函数：当前函数只处理了爆炸效果，
没有调用得分更新逻辑。建议修改：
在 clearBomb() 函数末尾加一行 score += 50 并调用 updateScore()。
```

**功能灵感参考清单：**

| 功能 | 复杂度 | 一句话说明 |
|------|--------|---------|
| 炸弹方块 | ⭐⭐ | 落地后炸掉周围3×3范围 |
| 速度加成方块 | ⭐⭐ | 碰到就让下落速度加快5秒 |
| 冻结方块 | ⭐⭐ | 碰到就让当前方块暂停3秒 |
| 彩虹消行 | ⭐ | 消行时屏幕闪彩虹色 |
| 方块预言家 | ⭐⭐ | 显示接下来3个方块 |
| Boss 行 | ⭐⭐⭐ | 每隔10行出现一行无法普通消除的行 |
| 重力反转 | ⭐⭐⭐ | 消4行触发5秒方块往上飞 |

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

```
我的路演（每人约1.5分钟）

1. 我做了几个版本，加了什么功能（20秒）
   → 演示给大家看

2. 需求文档改了几版（20秒）
   → AI 审核问了我什么让我意外的问题？

3. 测试脚本发现了什么（30秒）
   → 发现了几个 ❌？
   → 最意外的 ❌ 是什么？是代码问题还是需求问题？怎么修的？

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

---

### 6. 教师指南

**本课技术备注：**

测试脚本的原理：游戏的核心逻辑函数（`collides`、`clearLines`、`rotate`）是纯函数——给定输入，返回确定的输出，不依赖渲染。测试脚本把这些函数复制出来，构造特定的棋盘状态作为输入，调用函数，然后检查输出是否符合需求文档的描述。整个过程在浏览器里运行，不需要任何安装。

需求文档与测试的关系：测试脚本的质量取决于需求文档的质量。需求文档里写「消行得分」但没写具体数字，AI 就无法生成有意义的测试。这是本课的核心教学点——需求越具体，测试越有效。

增量需求文档的代码实现原理：教师需要了解，增量功能是在已有代码的基础上「插入」新逻辑，而非替换。Kimi 在生成增量代码时会查找合适的插入位置（比如 `clearLines()` 函数内部）并添加新逻辑。如果原有代码结构混乱（逻辑和渲染混在一起），AI 会很难找到插入点，导致生成失败。这就是为什么第6课的「增量生成」提示词里要求「核心逻辑函数保持独立」。

**常见问题 FAQ：**

| 问题 | 应对 |
|------|------|
| 「测试脚本打开是空白页」 | 检查 HTML 文件是否完整；让 Kimi 检查生成的代码有没有语法错误 |
| 「测试全部 ❌」 | 很可能是函数提取时出了问题；让 Kimi「只提取 clearLines 函数写一个最简单的测试」，逐步调试 |
| 「测试全部 ✅ 但游戏还是有 bug」 | 引导学生找到：哪条 bug 对应的规则，在需求文档里没有写到？这就是测试覆盖不足 |
| 「Kimi 生成的测试脚本太复杂看不懂」 | 「你不需要看懂每一行代码，只需要看 ✅❌ 结果和失败原因」；理解结果比理解实现更重要 |
| 「测试失败但不知道是代码问题还是需求问题」 | 使用「测试失败溯源」提示词，让 AI 帮你判断 |
| 「AI 审核问了太多问题，不知道怎么回答」 | 让学生先回答最好回答的那一条，其他的暂时写「待定」，先生成第一版，跑测试的时候再补 |
| 「增量生成后原有消行功能不见了」 | 说明 Kimi 误修改了原有逻辑；把原版代码重新提交，强调「不要改变原有功能的行为」 |
| 「验收标准不知道怎么写」 | 用「情况 → 预期结果」句式套一遍：「[什么情况] → [应该看到什么]」；如果写不出来，说明还没想清楚这条规则 |
| 「第二版加完功能跑测试有 ❌，但不知道是新功能的问题还是旧功能出了问题」 | 先把新功能注释掉，跑测试，确认旧功能全部 ✅；再把新功能打开，重新跑，锁定是新代码引入的问题 |
| 「路演超时怎么办」 | 路演前说清楚：演示只需要展示「最酷的那一个功能」，不需要演示全部；测试部分只说「最意外的 ❌」 |

**课堂节奏控制：**

- 分段一（15分钟）：最容易超时的环节是「AI 审核」——有学生会和 AI 进行很长的对话。给学生一个限制：AI 审核最多回答3轮问题，然后就进入执行。
- 分段二结束时，学生手动测完后，教师主动提问「你需求文档里有几条规则，你测了几条」——制造认知冲突，让学生自己感受手动测试的不完整性，再引出自动测试。
- 分段三的核心是「看懂 ✅❌ 结果并溯源」，不是「让每个学生都把测试写完」。进度慢的学生只要跑出测试结果、理解一个 ❌ 的原因即可。
- 分段四时间有限，对于进度慢的学生，「跑一遍测试确认第一版没问题」就算达标，不强求做第二版。
- 路演时间（第三幕）要严格控制在1.5分钟/人。如果有学生的功能特别复杂，教师可以帮助提炼：「你只需要说最意外的那个 ❌，其他的可以跳过。」

**课堂风险预案：**
- 如果 Kimi 生成的测试脚本无法运行：教师用提前准备好的演示版本讲解概念，让学生理解「测试脚本是什么、能发现什么问题」即可，不强求每人都跑成功。
- 如果学生进度差异大：进度快的学生尝试「给测试脚本加更多边界条件测试」；进度慢的学生重点完成「生成第一版 + 跑一次测试 + 理解结果」。
- 如果网络不稳定导致 Kimi 响应慢：提前在教师电脑上缓存一份完整的增量生成 + 测试脚本生成示例，用于离线演示。

---

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

**本周挑战：** 给你的游戏补一条没有被测试覆盖的规则
**挑战说明：** 找到你需求文档里一条没有被测试脚本覆盖到的规则，把它补进需求文档，然后让 Kimi 给测试脚本加上这条测试，跑一下看是 ✅ 还是 ❌。
**下节课分享：** 说出你补的是哪条规则，测试结果是什么

---

### 8. 拓展任务

**拓展一（推荐）：** 让你的测试脚本覆盖所有需求文档里的规则——对照需求文档逐条检查，补上缺少的测试。目标：测试脚本的条数 = 验收标准的条数。

**拓展二（挑战）：** 在需求文档里加一个你自己想出来的「边界情况」，写清楚预期结果，让 AI 生成对应的测试，看游戏能不能通过。参考方向：「同时消4行 + 炸弹爆炸」这种极端叠加情况的得分是多少？

**拓展三（超级挑战）：** 试着把你的增量需求文档写得让另一个同学能看懂——交换给同桌，让他/她用你的需求文档，在他/她的游戏上生成同样的功能。看看你的需求文档清不清楚。