AICODE2026/3-lessons/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行 + 炸弹爆炸」这种极端叠加情况的得分是多少？

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