feat: 新增涂鸦PK四课教案（第8-11课）及大纲更新

- 新增 AICODE06-08~11 完整逐字稿教案（每课600+行）
- 涂鸦PK主题：画图工具→基础对战→动画音效→班级锦标赛
- 核心工程思维：需求驱动→测试验证→增量迭代→数据驱动
- 更新 AICODE-06 课程大纲，追加第8-11课内容
- 新增 demo-pk/ 目录（画图工具/对战/动画三个demo）

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

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

@@ -1,7 +1,7 @@
 ---
 课时: 7
-主题: 魔幻俄罗斯方块（下）— 魔改升级 + 成果路演
-核心能力: [拆解力, 共创力, 表达力]
+主题: 魔幻俄罗斯方块（下）— 魔改升级 + AI 自动测试
+核心能力: [拆解力, 共创力, 韧性力]
 核心工具: [Kimi 2.5]
 时长: 90分钟
 透明化层级: 过程层
@@ -11,19 +11,19 @@
 ### 1. 课程目标
 
 **知识目标：**
-- 理解「功能扩展」的本质：在已有基础上，通过新一轮需求文档 + 生成 + 验收来增加功能
-- 理解「需求冲突」的概念：新功能的规则可能跟已有功能产生交互，需要提前想清楚
-- 理解路演不只是展示结果，而是展示「设计决策」——你为什么这样设计
+- 理解「自动化测试」的概念：不靠人工玩，让代码自己验证代码，更快更全面
+- 理解「测试覆盖」：需求文档里每一条规则，都应该有一条对应的测试
+- 理解功能扩展的增量思维：新功能只写「增量」，不重写整体
 
 **能力目标：**
-- 能独立完成「想法 → 需求文档 → 压力测试 → 生成 → 验收 → 迭代」完整流程（共创力）
-- 能在验收时主动测试功能之间的交互，发现潜在冲突（拆解力）
-- 能用 3 分钟路演清楚说明：加了什么功能、需求文档改了几版、遇到什么问题怎么解决的（表达力）
+- 能把需求文档转化为测试条件，交给 AI 生成测试脚本（拆解力）
+- 能读懂测试脚本的 ✅❌ 结果，把失败的测试溯源到需求文档（韧性力）
+- 能独立完成「需求 → 审核 → 生成 → 测试 → 修复」完整闭环（共创力）
 
 **情感目标：**
-- 体验「每个人的游戏都不一样」带来的成就感和个性化自豪感
-- 建立「我能用需求文档控制 AI 做出我想要的东西」的自信
-- 感受从「做一个大家都一样的游戏」到「做一个只属于我的游戏」的跨越
+- 体验「一键跑测试，马上知道哪里有问题」带来的效率感
+- 建立「测试通过才算完成，不是能玩就算完成」的质量意识
+- 感受从「每次手动点来点去找 bug」到「测试脚本自动找 bug」的升级
 
 ---
 
@@ -33,20 +33,22 @@
 
 | 概念 | 学生类比 | 认知层级 |
 |------|---------|---------|
-| 功能扩展 | 在基础款手机上加功能——不是重新做一台手机，而是在已有基础上增加 | 理解层 |
-| 需求冲突 | 新加了一条规则，跟原来的规则打架了——就像「所有人说话不准超过10秒」和「发言人可以不限时间」同时存在 | 应用层 |
-| 增量需求文档 | 只写「新加的部分」以及「新部分跟原有部分的交互规则」，不需要把全部需求重写一遍 | 理解层 |
-| 路演 = 决策展示 | 路演不是说「我做了什么」，而是说「我为什么这样设计」——设计背后的思考才是最有价值的 | 迁移层 |
+| 自动化测试 | 与其自己每次手动检查作业有没有写对，不如写一个「答案核对程序」，把你的答案输进去，自动判断对错 | 理解层 |
+| 测试覆盖 | 需求文档里写了10条规则，测试脚本就要测10件事——少测一条，那条出了 bug 你就不知道 | 应用层 |
+| 边界条件 | 不只测「正常情况」，还要测「极端情况」——比如方块刚好在边角旋转、同时消4行、积木堆到最顶 | 应用层 |
+| 增量需求文档 | 只写「新加的部分」，不重写整体——就像给手机升级系统，不是重新买一台手机 | 理解层 |
+| 新窗口原则 | 让同一个人既写方案又审方案，他永远找不出大问题——审核和测试必须开新窗口，让没有上下文的新 AI 来做，才能客观找出漏洞 | 应用层 |
 
 **典型误概念表：**
 
 | 编号 | 误概念 | 正确认知 | 激发策略 |
 |------|--------|---------|---------|
-| M1 | 加新功能要把整个游戏重新做一遍 | 在已有代码基础上增加功能，只需要写「新功能的需求文档」 | 演示「增量需求文档」的写法，只写新加的部分 |
-| M2 | 新功能加进去就算完成了，不用测试已有功能 | 新功能可能跟已有功能冲突，必须测试两者的交互 | 举例：加了「炸弹」，炸弹爆炸后会不会触发消行？触发的话是几分？ |
-| M3 | 需求文档越来越长越好，把所有想法都写进去 | 本次迭代只写「这次新加的功能」，保持文档聚焦 | 「这次 AI 只需要知道新加什么，不需要把整个游戏重新理解一遍」 |
-| M4 | 路演只要展示游戏好不好玩就行 | 路演的核心是展示你的思考：你加了什么、为什么加、需求文档改了几版、遇到什么问题 | 对比两种路演：一个只展示功能，一个讲设计决策，让学生投票哪个更精彩 |
-| M5 | 没写清楚的需求可以让 AI 自己发挥 | 「让 AI 自己发挥」的部分你就失去了控制，结果可能跟你想的完全不同 | 「你让 AI 自己发挥了哪里？那里 AI 做出来的跟你想的一样吗？」 |
+| M1 | 测试就是自己玩一遍，没出问题就算通过 | 手动测试只能发现你刚好测到的问题；自动测试每次都覆盖所有条件，不会遗漏 | 「你刚才玩的时候，有没有特意测『同时消4行的得分是不是800』？」 |
+| M2 | 测试脚本是程序员才会写的东西 | 把你的需求文档给 AI，AI 就能帮你把每条需求变成一个测试 | 现场演示：需求文档→AI→测试脚本，5分钟完成 |
+| M3 | 加新功能要把整个游戏重新做一遍 | 增量需求文档只写新加的部分，在已有代码上加，不是重做 | 演示增量需求文档的写法 |
+| M4 | 测试通过了就说明没有 bug | 测试只能覆盖你想到的情况；没覆盖的情况仍然可能有 bug——所以需求文档要写详细 | 「你的测试脚本有没有测『反重力期间消行』？」 |
+| M5 | 测试失败说明代码写错了 | 测试失败可能是代码问题，也可能是需求文档没说清楚——先溯源，再决定改哪里 | 展示一个「测试失败但代码没错，是需求文档漏写了」的案例 |
+| M6 | 需求审核、测试脚本生成可以在写需求的同一个窗口里做 | 上下文污染——AI 会受之前对话影响，不会客观审核自己生成的东西。审核和测试必须开新窗口 | 演示：同一窗口让 AI 审核自己写的需求，回答很保守；新窗口审核，问题暴露更多 |
 
 ---
 
@@ -59,165 +61,350 @@
 - 准备路演计时器（3分钟倒计时）
 
 **教学资源：**
-- 教师准备：「增量需求文档」提示词（见第5节）
-- 教师准备：几个功能想法的参考清单（防止学生没有灵感，见第5节）
-- 教师准备：路演结构引导卡（见第5节，路演前发给学生）
-- 学生资源：第6课完成的俄罗斯方块 HTML 文件
+- 教师准备：增量需求文档模板（见第5节）
+- 教师准备：生成测试脚本的提示词（见第5节）
+- 教师准备：一份提前生成好的测试脚本演示（包含1个 ✅ 和1个 ❌，用于导入展示）
+- 教师准备：功能灵感参考清单（见第5节）
+- 教师准备：路演结构引导卡（见第5节）
+- 学生资源：第6课完成的俄罗斯方块 HTML 文件 + Level 0 需求文档
 
 **教师备课体验任务：**
 > 备课前，教师必须亲自完成以下操作：
 >
-> 1. 选2-3个功能（比如炸弹方块、速度加成、颜色主题），各写一份增量需求文档，实际提交 Kimi 测试生成质量
-> 2. 故意在一个功能的需求文档里漏写「与消行的交互规则」，观察 AI 会怎么处理
-> 3. 练习一遍 3 分钟路演，讲「设计决策」而不只是展示游戏
+> 1. 用自己的俄罗斯方块代码 + 需求文档，让 Kimi 生成测试脚本，实际运行并记录结果
+> 2. 故意在需求文档里漏写一条规则，观察测试脚本是否能发现对应的 bug
+> 3. 准备一个演示用的「测试结果页面」，包含至少1个 ✅ 和1个 ❌，用于课堂导入
+> 4. 提前试跑「炸弹方块」功能的增量需求文档完整流程，记录 AI 审核会问什么问题
 
 ---
 
 ### 4. 教学流程
 
+---
+
 **第一幕：联系 (Connect) — 10分钟** 🔗
 
-**【环节】上节课回顾 + 功能发布 (10分钟)**
+*本幕目标：用每人的功能构想激活学生兴趣，制造「今天不只是加功能，还要学一个新技能」的认知悬念*
 
-**师：** 上节课结束前，我让你们想一个下节课要加的功能。现在每个人说出来——你想给你的俄罗斯方块加什么？
-【每人快速说一个，教师写在白板/投屏上】
+**【环节】上节课回顾 (4分钟)**
 
-**师：** 我们来看一下大家想加的功能。
-（读出清单）有没有一模一样的？
+**师：** 上节课结束前，我让你们想一个今天要加的功能，而且在出门前每人说了一句话。我们来回顾一下——上节课我们用了 Plan Mode，它有几步？谁来说？
+【诊断点：检测 Plan Mode 三步流程的记忆保持度】【识别层】
 
-**【分支A】若有学生选了相同的功能：**
-**师：** 你们选了同样的功能，但你们的需求文档可能完全不一样——因为每个人对这个功能的设计可能不同。比如同样是「炸弹方块」，炸弹爆炸多大范围？爆炸后会不会消行？这些都是你自己决定的。
+**生：** （预期：打开 Plan Mode → 写需求文档 → 让 AI 审核……）
 
-**【分支B】若所有人都选了不同的功能：**
-**师：** 大家选的都不一样——这节课结束，每个人的游戏都会跟别人的不一样。这就是今天最有意思的地方。
+**【分支A】若学生能说出三步（写文档、审核、执行）：**
+**师：** 说得很准。今天还是这三步，但是有一点不一样——今天写的是「增量需求文档」，不是重新写整个游戏。等会儿我会解释区别在哪里。
 
-**师：** 来简单说一下——你想加的功能，最难描述清楚的是哪一条规则？
-**生：** （各自说出预感最难写的部分）
-**师：** 很好，记住这个预感。等会写需求文档的时候，那条规则要特别仔细写。
-【诊断点：学生上节课课后是否真的想了，还是现在才开始想】【识别层】
+**【分支B】若学生只说出一两步：**
+**师：** 没关系，我帮你补一下。Plan Mode 三步：第一步，写需求文档，把你想做的东西说清楚；第二步，需求审核，让 AI 扮演审核工程师找漏洞；第三步，执行，生成代码。今天还是这三步，我们继续。
+
+**师：** 好，现在说说你想加的功能——每人说一个，我把它们写在黑板上。
+【每人快速说一个，教师写在白板/投屏上，列成一列】
+
+**生：** （各自说出功能：炸弹方块、速度加成、冻结方块、彩虹消行……）
+
+**师：** 大家看一下黑板——（指着功能列表）这里有六个不同的功能方向，没有两个人做一样的。你们今天各自在做一个完全不同的版本。
+
+**师：** 我们来做一件有趣的事——互相评一下别人的功能想法。你觉得黑板上哪一个功能听起来最难描述清楚？
+**生：** （讨论，指出某个功能）
+**师：** 为什么觉得难？
+**生：** （例如：「重力反转不知道要怎么写规则」「炸弹不知道爆炸范围算不算消行」）
+**师：** 你们刚才说的这些「不知道」，就是今天需求文档里必须写清楚的部分。不写清楚，AI 就会自己决定，结果可能跟你想的完全不一样。
+
+**【环节】引发认知冲突 + 悬念铺垫 (6分钟)**
+
+**师：** 我再问你们——你刚才说想加的功能，你觉得最难描述清楚的规则是哪一条？比如你想加炸弹方块，「炸弹爆炸」这件事，你要怎么告诉 AI？
+【诊断点：探测学生对「把直觉转化为精确规则」的困难点认知】【理解层】
+
+**生：** （各自说出难点——爆炸范围？爆炸后消行吗？得分怎么算？）
+
+**师：** 很好，你已经在思考这个问题了。等会儿写需求文档的时候，那条规则要特别仔细。
+
+**师：** 今天除了加功能，我们还会学一个新技能。上节课你们手动测试游戏——自己玩、自己找 bug，对吗？手动测试有一个问题，一会儿让你们自己感受。
+【故意不展开，制造悬念】
+
+**师：** 我问你们——你的游戏有5条规则，你在手动测的时候，你能保证5条都测到了吗？
+**生：** （预期：不一定……有点难……）
+**师：** 等会儿让你们亲身体验这个问题，我们先进建构。
+
+**师：** 打开你上节课的游戏文件，确认能正常运行。我们进入建构阶段。
 
 ---
 
 **第二幕：建构 (Construct) — 65分钟** 🛠️
 
-**【分段一：写增量需求文档 + 压力测试】(20分钟)**
+---
+
+**【分段一：增量需求文档 + 需求审核】(15分钟)**
+
+*本段重点：理解「增量」思维，写出可测试的需求文档，尤其是交互规则和验收标准*
 
 **预设误概念：**
-- 误概念 M1：加新功能要把整个游戏重做
-- 误概念 M3：需求文档要把所有东西都写进去
+- 误概念 M3：加新功能要把整个游戏重做
+- 误概念：验收标准可以写成「功能正常」这种模糊的话
 
 **讲解与演示 (Teach & Demo): (5分钟)**
 
-**师：** 今天写的需求文档，跟上节课不一样。上节课写的是「整个游戏的规则」，今天只写「新加的功能」。这叫增量需求文档。
-【投屏展示增量需求文档提示词，见第5节】
+**师：** 今天继续用 Plan Mode。但今天写的是「增量需求文档」——只写新加的部分，不重写整个游戏。
 
-**师：** 有一个特别重要的部分——「与原有功能的交互规则」。我举个例子：你加了一个炸弹方块，炸弹爆炸了，爆炸范围里刚好有一整行被清空了——这算消行吗？算消行的话，得多少分？
-**生：** ……这个我没想过。
-**师：** 对，这就是功能交互。新功能和原有功能之间，总会有一些「撞在一起」的情况，需要提前想清楚。
-【理解层：建立「功能之间有交互」的设计意识】
+**师：** 类比一下——你手机升级系统，是重新买一台手机，还是只更新改变的那一部分？
+**生：** （预期：只更新改变的部分）
+**师：** 对。增量需求文档就是这个意思：你的游戏核心逻辑不动，你只描述「要在这个基础上加什么」。
 
-**师：** 我来演示一次——用「炸弹方块」功能写一份增量需求文档，然后做一次压力测试。
-【教师演示：写需求 → 压力测试 → AI 提问 → 补漏洞，重点展示「交互规则」这部分】
+**师：** 增量需求文档有一个特别重要的部分，叫「与原有功能的交互规则」。我举一个具体例子——你加了炸弹方块。炸弹落地，爆炸了。爆炸之后刚好把整行都消干净了——这算消行吗？得多少分？是按炸弹规则算，还是按消行规则算，还是两个叠加？
 
-**学生实践 (Practice): (13分钟)**
+**师：** 如果你没写清楚，AI 自己决定，结果可能跟你想的完全不一样。所以交互规则必须写。
 
-1. 学生写自己的功能的增量需求文档（重点写清楚：功能规则 + 与消行/得分的交互规则）
-2. 执行「压力测试」提示词
-3. 针对 AI 提出的问题，补充完善需求文档
+**师：** 还有一个字段叫「验收标准」。它的格式是这样的：
+**「[情况] → [预期结果]」**
+比如：「炸弹落地时周围没有积木 → 爆炸动画播放，得分+50，无消行」。
+验收标准必须是可以测试的——能测试 = 说清楚了具体情况，说清楚了预期结果。不能写「功能正常运行」，那不是验收标准，那是废话。
 
-> 教师走动观察重点：
-> - 学生是否写了「交互规则」这一部分？
-> - 对于「AI 问了什么」感到最意外的问题是什么？
+**师：** 我来考考你们——以下两条验收标准，哪条是可测试的？
+- 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 压力测试问了你最意外的问题是什么？
-**生：** （分享1-2条，重点是「交互规则」相关的问题）
-**师：** 这类问题，如果不写清楚，加进去的功能会跟原来的规则「打架」，产生奇怪的结果。
+**师：** AI 审核出了什么？有没有让你意外的问题？
+**生：** （分享，例如：「AI 问我炸弹同时触发消行怎么算」）
+
+**【分支A】若学生说 AI 问出了没想到的问题：**
+**师：** 这个问题你之前有想到吗？
+**生：** 没有……
+**师：** 所以 AI 审核是真的有用的——它问的问题不是废话，是你确实需要回答的问题。
+
+**【分支B】若学生说 AI 没审出什么问题：**
+**师：** 把你的需求文档发我看一下。（观察）——你的验收标准里有没有写边界情况？比如「功能触发时恰好也消行」这种情况？如果没有，让 AI 专门针对边界情况再审一遍。
+
+**师：** 好，需求文档基本确认了，进入执行阶段。
 
 ---
 
-**【分段二：提交生成 → 测试交互 → 溯源迭代】(25分钟)**
+**【分段二：生成第一版 → 手动测试 → 感受痛点】(15分钟)**
+
+*本段重点：先让学生亲身体验手动测试的局限，再自然引出「让电脑帮我们测」的需求*
 
 **预设误概念：**
-- 误概念 M2：新功能加进去之后，只测新功能就行
-- 误概念 M5：没写清楚的部分让 AI 自己决定
+- 误概念 M1：手动玩一遍没出问题就算通过
+- 误概念：测试只需要测「好不好玩」，不需要逐条对照需求
 
-**讲解与演示 (Teach & Demo): (3分钟)**
+**讲解与演示 (Teach & Demo): (2分钟)**
 
-**师：** 把需求文档提交 Kimi，有一个特别的要求——告诉 AI 「在已有代码基础上增加功能」，而不是「重新做一个游戏」。
+**师：** 把确认好的增量需求文档提交 Kimi，基于上节课的代码增加新功能。
 【投屏展示「增量生成」提示词，见第5节】
 
-**师：** 生成之后，验收的时候要测两件事：
-- 第一：新功能有没有按需求做出来
-- 第二：原来的功能还正常吗（消行、得分、游戏结束，都要测）
+**师：** 生成之后，先手动测几条——自己玩一玩，看看新功能有没有按需求做出来。特别注意：不是随便玩，是对照着你的验收标准一条条测。
 
-**师：** 遇到不对的地方，还是同样的动作——溯源到需求文档，找到是哪条没说清楚，改需求，重新生成。
+**学生实践 (Practice): (10分钟)**
 
-**学生实践 (Practice): (19分钟)**
+1. 提交增量需求文档 + 旧代码给 Kimi，生成第一版
+2. 打开游戏，手动测试：新功能触发了吗？原有消行/得分还正常吗？
+3. 对照验收标准逐条检查，记录发现的问题
 
-1. 把需求文档提交 Kimi，基于已有代码增加新功能
-2. 验收：新功能测试 + 原有功能回归测试
-3. 记录「结果跟预期不一样」的地方
-4. 溯源到需求文档 → 修改 → 重新生成
-5. 重复迭代，直到功能符合预期
-
-> 教师走动观察重点：
-> - 新功能和消行之间的交互是否符合需求文档的设计？
-> - 是否有学生因为新功能导致原有功能出问题（回归 bug）？
-> - 学生是否在需求文档里找到了回归 bug 的根源？
+> 教师走动观察：故意不干预，让学生自己感受「手动测试的局限」。观察：是否有学生只是「玩了一会儿」而没有逐条对照验收标准？是否有学生根本没有测「新功能和消行同时触发」的边界情况？是否有学生测了3条就觉得「差不多了」？
 
 **进度同步 (Checkpoint): (3分钟)**
 
-**师：** 你加的新功能，有没有让原来的某个功能出问题？怎么溯源到需求文档的？
-【诊断点：学生是否理解「新功能可能影响旧功能」，并能溯源到需求文档里的交互规则】【应用层】
+**师：** 手动测了哪几条？对照你的验收标准，你测了几条？
+**生：** （预期：2条、3条……）
 
-**【分支A】若学生发现了回归 bug 并成功溯源：**
-**师：** 非常好！你刚才发现的问题，在需求文档里是哪条交互规则没有写清楚？
+**师：** 你的验收标准里一共有几条？
+**生：** 5条……
 
-**【分支B】若学生说「没有出问题，一切正常」：**
-**师：** 那我们来测一个边界情况——你的新功能触发的同时，刚好消了一行，得分是怎么算的？
-【主动暴露交互场景，测试是否真的没问题】
+**师：** 你测了3条，还有2条没测。你确定那2条没有问题吗？
+**生：** 不确定……
+
+**师：** 还有一个问题——就算今天你把所有5条都测了，下次你改了代码，你还要重新手动测一遍。如果你做了第二版、第三版，每次都要从头手动测一遍。需求文档越来越长，要测的条数越来越多，手动测试需要的时间也越来越长。
+
+**师：** 有没有办法，让电脑帮我们测，而且每次都自动把所有条件测完？
+
+**【分支A】若有学生说「那肯定有程序能做这个」：**
+**师：** 你说对了！这个东西叫测试脚本。我们现在就去做一个。
+
+**【分支B】若学生面面相觑，不知道答案：**
+**师：** 答案就是——用 AI 帮我们写一个测试脚本。这个脚本会自动运行你的游戏逻辑，逐条对照需求文档，告诉你哪条通过了、哪条失败了。我来给你们看一下它长什么样。
 
 ---
 
-**【分段三：路演准备】(10分钟)**
+**【分段三：AI 生成测试脚本 → 跑测试 → 修复】(25分钟)**
+
+*本段重点：生成并运行测试脚本，学会读懂 ✅❌ 结果并溯源，建立「测试才算完成」的质量意识*
 
 **预设误概念：**
-- 误概念 M4：路演只要展示游戏好不好玩就行
+- 误概念 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分钟)**
 
-**师：** 接下来每个人做一个 3 分钟路演。但我们的路演跟一般的展示不一样——不是「看，我做了个游戏」，而是「我为什么这样设计」。
-【发放路演结构引导卡，见第5节】
+**师：** 你现在有了一个测试脚本。这个测试脚本是你的「安全网」。它的具体意义是什么？
 
-**师：** 路演要说三件事：
-1. 我加了什么功能，这个功能是什么效果
-2. 我的需求文档改了几版，每次改了什么
-3. 遇到的最难的地方是什么，怎么解决的
+**师：** 没有安全网的时候，你怕改出问题，所以不敢改太多。每次改完要自己手动测半天，万一改出新 bug 还得找半天。结果是——你不敢大胆加功能。
 
-**师：** 注意第二和第三点——这才是最有价值的部分。任何人都能展示一个游戏，但你经历了哪些思考和决策，是只有你有的。
+**师：** 有了安全网之后：每次改完代码，双击 `test.html`，10秒钟看结果。全部 ✅，说明原有功能没被破坏，可以继续加。出现 ❌，马上知道哪里出问题，立刻修。这就是「安全网」的具体作用——让你敢放心改代码。
 
-**学生实践 (Practice): (7分钟)**
+**师：** 所以现在，有了安全网，我们才敢做更大胆的第二版。去做——比第一版更酷、更复杂。每加完一个功能，跑一遍测试，确认 ✅ 再继续加下一个。
 
-学生准备路演，按三点结构整理思路（不需要写逐字稿，想清楚就行）。
-教师走动帮助学生回忆「需求文档改了几版」「哪里卡住了怎么解决的」。
+**学生实践 (Practice): (5分钟)**
+
+1. 在第一版基础上继续扩展——加第二个功能，或者把第一个功能做得更完整
+2. 每次生成新代码后，跑 `test.html`，确认没有破坏原有逻辑
+3. 有余力的学生继续做第三版，目标：做出功能灵感清单里「⭐⭐⭐」的功能
+
+> 教师走动：鼓励学生跑测试，发现有学生只靠手动玩来验证时，提示：「跑一遍测试脚本，10秒就有答案，比手动玩快多了。」
+
+**进度同步 (Checkpoint): (2分钟)**
+
+**师：** 做了第二版的举手。你加了什么？跑测试了吗？结果怎样？
+【诊断点：学生是否形成「加功能 → 跑测试 → 检查结果」的迭代习惯】【应用层】
+
+**【分支A】若学生说「跑了测试，全部通过，然后继续加」：**
+**师：** 这就是正确的迭代节奏。以后做任何项目都是这个节奏。
+
+**【分支B】若学生说「加了功能但忘记跑测试」：**
+**师：** 现在跑一遍。——有没有 ❌？
+**生：** （跑完结果）
+**师：** 如果有 ❌，这就是「不跑测试的代价」——你可能在不知情的情况下，新加的功能破坏了原来的逻辑。
 
 ---
 
 **第三幕：反思 (Contemplate) — 10分钟** 🤔
 
-**【环节】成果路演 (8分钟)**
+*本幕目标：通过路演和互评，让学生反思「测试覆盖」的本质，以及「需求文档质量 = 测试质量」的核心认知*
 
-每位学生 3 分钟路演（按人数调整，6人小班每人约 1.5 分钟，重点展示设计决策）。
+**【环节】成果路演 (7分钟)**
 
-**师：** （每人路演后）你的需求文档改了几版？最关键的那次修改是什么？
+**师：** 每人1.5分钟路演（6人小班）。路演有引导卡，大家拿一张。
+【发放路演结构引导卡，见第5节】
 
-**【环节】互评 (2分钟)**
+**师：** 路演不是「打开游戏给大家看」——那只是演示，不是路演。路演要讲三件事：你加了什么功能、测试脚本发现了什么、你怎么修的。开始。
 
-**师：** 刚才大家展示的游戏里，哪个功能的需求文档你觉得写得最清楚？
-**师：** 哪个功能的设计，是你之前没想到可以这样做的？
-【诊断点：学生是否能评价「需求清晰度」，而不只是「游戏好不好玩」】
+（每人依次路演，教师计时。路演要点：）
+- 展示最终版本游戏（20秒演示）
+- 展示测试脚本的 ✅❌ 结果（告诉大家发现了几个 ❌）
+- 重点讲：最意外的那个 ❌ 是代码问题还是需求问题？怎么修的？
+- 一句话总结：「如果重来一次，需求文档哪里会写得不一样？」
+
+> 教师观察：是否有学生的路演只说了「我加了炸弹方块」，但没有说测试相关的内容？提示：「测试脚本发现了什么？」
+
+**【环节】互评与讨论 (3分钟)**
+
+**师：** 刚才大家的路演里，哪一个测试脚本发现的问题最有价值？
+**生：** （讨论）
+
+**师：** 我们来做一个结构化互评——选一位刚才路演的同学，给他的作品说「一个你觉得做得好的地方」和「一个你觉得可以改进的地方」。
+**生：** （互评，例如：「他的炸弹功能很酷，但是我觉得爆炸范围可以更大一点」）
+**师：** 「更大一点」——具体怎么大？你能告诉他怎么写到需求文档里吗？
+**生：** （尝试表达：「爆炸范围从3×3改成5×5」）
+**师：** 这就是一条可测试的需求改进建议。他可以把这条加到需求文档里，然后让 AI 重新生成。
+
+**师：** 有没有人的测试结果全是 ✅，但路演时我们发现游戏还是有问题？
+**生：** （可能有学生举手）
+**师：** 这说明什么？
+**生：** （预期：测试没有覆盖到那个情况……）
+**师：** 对。测试只能发现「你写进需求文档的问题」。你没写的，它不知道要测。这就是为什么需求文档要尽量详细——需求文档越完整，测试覆盖越全，漏掉的 bug 越少。
+
+**师：** 给今天的工作做一个评分——需求文档 100 分、测试脚本 100 分、游戏功能 100 分，你自己的三项各给多少分？
+（让学生自评，不需要出声，心里有数就好）
+
+**师：** 哪位愿意说说自己的分？
+**生：** （分享，例如：「需求文档70，测试80，功能90」）
+**师：** 三项里面，哪一项你觉得下次会做得更好？
+**生：** （分享）
+**师：** 记住这个答案。这就是你下一个项目要重点改进的地方。
 
 ---
 
@@ -225,23 +412,44 @@
 
 **【环节】抽象总结 (3分钟)**
 
-**师：** 两节课，你们从零做了一个俄罗斯方块，还加了自己设计的功能。我们用的核心方法是什么？
-**生：** 写需求文档，让 AI 做，然后验收，有问题就改需求文档……
-**师：** 对。这个流程有个名字：需求 → 设计 → 实现 → 验收 → 迭代。这是真实的工程师每天都在做的事情。
-**师：** 你们今天做的，跟真实的产品开发，步骤上是完全一样的。
+**师：** 两节课，我们走了一个完整的流程。谁来说说是哪几步？
+**生：** Plan Mode → 需求文档 → 审核 → 生成 → 测试 → 修复……
 
-**师：** 最后一个问题：如果今天你的功能需求文档第一版就做对了，是因为你运气好，还是需求写得好？
-**生：** 需求写得好？
-**师：** 对。运气不可靠，清晰的需求才可靠。这是今天最重要的一句话。
+**师：** 对。这个流程有个名字：需求 → 实现 → 测试 → 修复。真实的工程师每天都在走这个循环。
+**师：** 今天最重要的一句话：**「测试通过才算完成，不是能玩就算完成。」**
+**师：** 能玩是 60 分，测试通过是 90 分，需求文档里每一条都有测试覆盖是 100 分。
 
-**【环节】下节预告 (2分钟)**
+**师：** 还有一件事——今天你们体验了什么是「安全网」。这不只是测试脚本的概念，这是一种工作方式：在做危险操作之前，先建立一个保护机制。以后你们做任何项目，都可以问自己：「我有没有安全网？」
 
-**师：** 接下来的课程，你们会进入更大的项目。今天学到的方法——需求文档、压力测试、结果溯源——会一直用到。你们已经会了，后面只是把项目变得更复杂。
+**师：** 最后，我想让你们想一个问题——今天学到的「需求文档 → 测试 → 修复」这个流程，除了做游戏，还能用在哪里？
+**生：** （讨论：做网站？做 App？……）
+**师：** 对。你们今天走的这个流程，和真实的工程师在公司里走的流程是一样的。只不过他们的项目更大、需求文档更长、测试脚本更复杂。但方法是一样的。
+
+**【环节】下节预告 + 5分钟挑战 (2分钟)**
+
+**师：** 接下来的课程，你们会做更大的项目。今天学到的——Plan Mode、需求审核、自动测试——会一直用到，只是项目变得更复杂。你们已经有了完整的工具箱。
+
+**师：** 本周5分钟AI挑战：找到你需求文档里一条没有被测试覆盖到的规则，把它补进需求文档，然后让 Kimi 给测试脚本加上这条测试，跑一下看是 ✅ 还是 ❌。下节课说出你补的是哪条规则，测试结果是什么。
 
 ---
 
 ### 5. AI 助教使用指南
 
+**⚠️ 新窗口使用规则（必须遵守）：**
+
+```
+本课四个阶段的窗口规则：
+
+窗口 A：写增量需求文档（整理新功能需求用这个窗口）
+窗口 B：需求审核（全新窗口——AI 不会承认自己写的有问题）
+窗口 C：执行生成（全新窗口——基于原代码增加新功能）
+窗口 D：生成测试脚本（全新窗口——让新 AI 客观测试）
+
+核心原则：审核、测试必须换新窗口。在同一个窗口里又写又审
+又测，叫「上下文污染」——AI 会偏向为自己生成的内容辩护，
+找不出真正的问题。
+```
+
 **增量需求文档模板（学生填写）：**
 
 ```
@@ -261,58 +469,139 @@
 - 与得分的交互：[这个功能会影响得分吗？怎么影响？]
 - 与游戏结束的交互：[游戏结束时，这个功能有没有特殊处理？]
 
-## 验收标准
-[我怎么测试这个功能做对了？列出2-3条可以测试的情况]
+## 验收标准（每条都要能自动测试）
+1. [情况] → [预期结果]
+2. [情况] → [预期结果]
+3. [情况] → [预期结果]
 ```
 
 **「增量生成」提示词：**
 
 ```
 我已经有一个俄罗斯方块游戏（代码在下面）。
-现在我需要在这个基础上增加一个新功能，需求如下：
+现在需要在这个基础上增加一个新功能，需求如下：
 
-[粘贴你的增量需求文档]
+[粘贴增量需求文档]
 
 要求：
-1. 在已有代码基础上增加这个功能，不要改变原有功能的行为
+1. 在已有代码基础上增加，不要改变原有功能的行为
 2. 严格按照需求文档实现，不要添加文档里没有提到的内容
-3. 输出完整的 HTML 文件（内联 CSS 和 JS）
+3. 核心逻辑函数（collides、clearLines、rotate 等）必须保持独立，
+   不要把逻辑和渲染混在一起（方便后续生成测试脚本）
+4. 输出完整的 HTML 文件（内联 CSS 和 JS）
 
 已有代码：
-[粘贴你的游戏 HTML 代码]
+[粘贴游戏 HTML 代码]
 ```
 
-**功能灵感参考清单（学生没有想法时参考）：**
-
-| 功能 | 一句话说明 |
-|------|---------|
-| 炸弹方块 | 特殊方块，落地后炸掉周围一圈 |
-| 速度加成方块 | 碰到就让下落速度加快 5 秒 |
-| 冻结方块 | 碰到就让当前方块暂停 3 秒不下落 |
-| 彩虹模式 | 消行的时候屏幕闪一下彩虹色 |
-| 双人模式 | 两个人在同一个游戏区域交替操控 |
-| Boss 行 | 每隔 10 行出现一行不能被普通消行消掉的「Boss 行」 |
-| 方块预言家 | 显示接下来 3 个方块而不只是 1 个 |
-| 重力反转 | 消 4 行一次触发 5 秒重力反转，方块往上飞 |
-
-**路演结构引导卡（课前发给学生）：**
+**「生成测试脚本」提示词（本课核心）：**
 
 ```
-我的路演（3分钟）
+我有一个俄罗斯方块游戏，代码如下：
 
-1. 我加了什么功能（30秒）
+[粘贴游戏 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. 我的需求文档改了几版（1分钟）
-   → 第一版写完之后，AI 问了我什么让我意外的问题？
-   → 我改了哪里？改完之后结果有什么变化？
+2. 需求文档改了几版（20秒）
+   → AI 审核问了我什么让我意外的问题？
 
-3. 最难的地方（1分钟）
-   → 我遇到的最难描述清楚的规则是什么？
-   → 最后是怎么写清楚的？
-   → 有没有发现新功能让原来的功能出了问题？怎么解决的？
+3. 测试脚本发现了什么（30秒）
+   → 发现了几个 ❌？
+   → 最意外的 ❌ 是什么？是代码问题还是需求问题？怎么修的？
 
-4. 如果重来一次（30秒）
+4. 如果重来一次（10秒）
    → 需求文档哪里会写得不一样？
 ```
 
@@ -322,35 +611,54 @@
 
 **本课技术备注：**
 
-增量开发策略：把已有的 HTML 代码粘贴给 Kimi，让它在基础上增加功能，比重新生成稳定得多。如果 Kimi 倾向于重写整个游戏，在提示词里加「请务必基于我提供的代码修改，不要重新生成整个游戏」。
+测试脚本的原理：游戏的核心逻辑函数（`collides`、`clearLines`、`rotate`）是纯函数——给定输入，返回确定的输出，不依赖渲染。测试脚本把这些函数复制出来，构造特定的棋盘状态作为输入，调用函数，然后检查输出是否符合需求文档的描述。整个过程在浏览器里运行，不需要任何安装。
 
-功能复杂度控制：炸弹方块、速度加成、冻结方块是低复杂度功能，适合大多数学生。重力反转、双人模式是高复杂度功能，适合进度快的学生挑战。教师可以根据学生能力在发清单时口头引导。
+需求文档与测试的关系：测试脚本的质量取决于需求文档的质量。需求文档里写「消行得分」但没写具体数字，AI 就无法生成有意义的测试。这是本课的核心教学点——需求越具体，测试越有效。
+
+增量需求文档的代码实现原理：教师需要了解，增量功能是在已有代码的基础上「插入」新逻辑，而非替换。Kimi 在生成增量代码时会查找合适的插入位置（比如 `clearLines()` 函数内部）并添加新逻辑。如果原有代码结构混乱（逻辑和渲染混在一起），AI 会很难找到插入点，导致生成失败。这就是为什么第6课的「增量生成」提示词里要求「核心逻辑函数保持独立」。
 
 **常见问题 FAQ：**
 
 | 问题 | 应对 |
 |------|------|
-| 「加了新功能之后原来的功能坏了」 | 先检查需求文档里「与原有功能的交互规则」写了什么；如果没写，补上去重新生成 |
-| 「Kimi 加功能之后把整个游戏重写了，之前的功能不见了」 | 提示词里强调「在已有代码基础上修改」；或者把原有代码中关键的函数名告诉 Kimi，要求保留 |
-| 「我想要的功能 AI 做不出来」 | 先检查需求文档是否足够具体；可以要求 AI「只实现这一个功能，不要改其他任何部分」；确实做不到的记录进 Backlog 留待下次 |
-| 「路演不知道说什么」 | 引导卡上的4个问题逐一回答就够了；重点提醒「不需要说得很完整，说你觉得最有意思的那件事就行」 |
-| 「时间不够，功能还没做完」 | 没关系，路演时说「我加了什么功能、需求文档写到第几版、还差什么没完成」也是完整的路演——这本身就是真实工程师的日常 |
+| 「测试脚本打开是空白页」 | 检查 HTML 文件是否完整；让 Kimi 检查生成的代码有没有语法错误 |
+| 「测试全部 ❌」 | 很可能是函数提取时出了问题；让 Kimi「只提取 clearLines 函数写一个最简单的测试」，逐步调试 |
+| 「测试全部 ✅ 但游戏还是有 bug」 | 引导学生找到：哪条 bug 对应的规则，在需求文档里没有写到？这就是测试覆盖不足 |
+| 「Kimi 生成的测试脚本太复杂看不懂」 | 「你不需要看懂每一行代码，只需要看 ✅❌ 结果和失败原因」；理解结果比理解实现更重要 |
+| 「测试失败但不知道是代码问题还是需求问题」 | 使用「测试失败溯源」提示词，让 AI 帮你判断 |
+| 「AI 审核问了太多问题，不知道怎么回答」 | 让学生先回答最好回答的那一条，其他的暂时写「待定」，先生成第一版，跑测试的时候再补 |
+| 「增量生成后原有消行功能不见了」 | 说明 Kimi 误修改了原有逻辑；把原版代码重新提交，强调「不要改变原有功能的行为」 |
+| 「验收标准不知道怎么写」 | 用「情况 → 预期结果」句式套一遍：「[什么情况] → [应该看到什么]」；如果写不出来，说明还没想清楚这条规则 |
+| 「第二版加完功能跑测试有 ❌，但不知道是新功能的问题还是旧功能出了问题」 | 先把新功能注释掉，跑测试，确认旧功能全部 ✅；再把新功能打开，重新跑，锁定是新代码引入的问题 |
+| 「路演超时怎么办」 | 路演前说清楚：演示只需要展示「最酷的那一个功能」，不需要演示全部；测试部分只说「最意外的 ❌」 |
+
+**课堂节奏控制：**
+
+- 分段一（15分钟）：最容易超时的环节是「AI 审核」——有学生会和 AI 进行很长的对话。给学生一个限制：AI 审核最多回答3轮问题，然后就进入执行。
+- 分段二结束时，学生手动测完后，教师主动提问「你需求文档里有几条规则，你测了几条」——制造认知冲突，让学生自己感受手动测试的不完整性，再引出自动测试。
+- 分段三的核心是「看懂 ✅❌ 结果并溯源」，不是「让每个学生都把测试写完」。进度慢的学生只要跑出测试结果、理解一个 ❌ 的原因即可。
+- 分段四时间有限，对于进度慢的学生，「跑一遍测试确认第一版没问题」就算达标，不强求做第二版。
+- 路演时间（第三幕）要严格控制在1.5分钟/人。如果有学生的功能特别复杂，教师可以帮助提炼：「你只需要说最意外的那个 ❌，其他的可以跳过。」
 
 **课堂风险预案：**
-- 如果多名学生选了同一个功能（比如炸弹方块）：利用这个机会对比两个人的需求文档——相同的功能，两份需求文档有什么不同？最终生成的结果有什么不同？这是很好的教学素材。
-- 如果某个学生的功能过于复杂（比如联机对战）：引导学生做「最小可行版本」——先只实现最核心的规则，其余的加进 Backlog，下次再加。
+- 如果 Kimi 生成的测试脚本无法运行：教师用提前准备好的演示版本讲解概念，让学生理解「测试脚本是什么、能发现什么问题」即可，不强求每人都跑成功。
+- 如果学生进度差异大：进度快的学生尝试「给测试脚本加更多边界条件测试」；进度慢的学生重点完成「生成第一版 + 跑一次测试 + 理解结果」。
+- 如果网络不稳定导致 Kimi 响应慢：提前在教师电脑上缓存一份完整的增量生成 + 测试脚本生成示例，用于离线演示。
 
 ---
 
 ### 7. 5分钟日常AI挑战
 
-**本周挑战：** 再加一个功能，或者把这次没做完的功能完成
-**挑战说明：** 用同样的方法——写增量需求文档、压力测试、生成、验收——自己在家给游戏再加一个功能（或者完成这节课没完成的部分）。下节课展示。
-**下节课分享：** 选 2-3 位同学展示在家加的功能，重点说「需求文档是怎么写的」
+**本周挑战：** 给你的游戏补一条没有被测试覆盖的规则
+**挑战说明：** 找到你需求文档里一条没有被测试脚本覆盖到的规则，把它补进需求文档，然后让 Kimi 给测试脚本加上这条测试，跑一下看是 ✅ 还是 ❌。
+**下节课分享：** 说出你补的是哪条规则，测试结果是什么
 
 ---
 
 ### 8. 拓展任务
 
-**拓展一（推荐）：** 给你的游戏加一个「暂停功能」——按 P 键暂停，再按 P 键继续；暂停时显示一个半透明遮罩
-**拓展二（挑战）：** 给你的游戏写一份「完整的 Level 0 + Level 1 需求文档合并版」——把上节课的需求文档和今天的增量需求文档合并成一份完整的文档，让任何人读了都能理解整个游戏的所有规则
+**拓展一（推荐）：** 让你的测试脚本覆盖所有需求文档里的规则——对照需求文档逐条检查，补上缺少的测试。目标：测试脚本的条数 = 验收标准的条数。
+
+**拓展二（挑战）：** 在需求文档里加一个你自己想出来的「边界情况」，写清楚预期结果，让 AI 生成对应的测试，看游戏能不能通过。参考方向：「同时消4行 + 炸弹爆炸」这种极端叠加情况的得分是多少？
+
+**拓展三（超级挑战）：** 试着把你的增量需求文档写得让另一个同学能看懂——交换给同桌，让他/她用你的需求文档，在他/她的游戏上生成同样的功能。看看你的需求文档清不清楚。