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

课时, 主题, 核心能力, 核心工具, 时长, 透明化层级, 适用路线

课时	主题	核心能力	核心工具	时长	透明化层级	适用路线
6	魔幻俄罗斯方块（上）— Plan Mode 先行	提问力 拆解力	Kimi 2.5	90分钟	过程层	AICODE-06

1. 课程目标

知识目标：

• 理解「Plan Mode（计划模式）」的概念：无论做什么，都要先开启计划模式，把需求写清楚再执行
• 理解「需求质量 = 输出质量」：需求写得越详细，AI 执行越准确；需求写不清楚，执行过程中就会出问题
• 理解需求是迭代的过程，不是一次写完就能用

能力目标：

• 能通过「侦探模式」分析一个游戏的规则，并用文字描述出来（拆解力）
• 能用 AI 对话主动「压力测试」自己的需求文档，发现描述漏洞（提问力）
• 能在看到生成结果后，定位是哪条需求没说清楚，修改并重新生成（共创力）

情感目标：

• 建立「先开 Plan Mode，再动手」的习惯——这是课程中所有项目的第一步，不可跳过
• 对「自己也能做出一个游戏」产生真实的兴奋感
• 建立「结果不对 = 需求没说清楚」而不是「AI 不行」或「我不行」的归因习惯

---

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

核心概念认知层级：

概念	学生类比	认知层级
Plan Mode（计划模式）	盖房子前先画图纸——没有图纸直接开工，盖到一半发现方向错了，拆掉重来比画图纸贵十倍	理解层
需求文档	装修前给师傅的设计图——口头说「弄好看点」和给一张详细图纸，结果完全不同	理解层
需求压力测试	考试前找同学互出题——让别人挑毛病比自己检查更有效	应用层
结果溯源	菜做咸了，往回找：是盐放多了，还是酱油放多了？找到根源才能改	应用层
新窗口原则	让同一个同学既写作文又给自己改错，他永远改不出来——必须换一个人来审。审核、测试、评审全部要开新窗口，让「新的 AI」来做，才不会被原来的上下文带跑偏	应用层

典型误概念表：

编号	误概念	正确认知	激发策略
M1	直接告诉 AI「帮我做一个俄罗斯方块」就够了	不写需求文档，AI 会自己猜所有细节，结果可能跟你想的完全不同	课堂实验：先不写需求文档直接生成，再写了需求文档生成，对比两个结果的差距
M2	需求文档写完就是写好了，直接提交	写完只是第一步，要经过压力测试才能发现漏洞	用「压力测试」提示词，让 AI 提出学生自己没想到的问题
M3	AI 做出来的结果不对是 AI 的问题	结果不对说明需求里有没说清楚的地方	「你的需求文档里有没有写这一条？」——让学生自己发现根本没写
M4	需求文档要写得很长很详细	精准 > 冗长。需求要「可测试」：能说出什么情况下算做对了	「你这条需求，我怎么知道 AI 做没做对？」
M5	先动手做，遇到问题再想	跳过 Plan Mode 直接做，出了问题再改来改去，总时间反而更长	对比两种路径：「跳过计划 → 做 → 改 → 改 → 改」vs「Plan Mode → 做 → 小改」
M6	需求审核是在挑代码的问题	需求审核阶段只审需求本身——哪里没说清楚、哪里有歧义，跟代码无关	「AI 现在还没写一行代码，怎么可能审代码问题？」
M7	在同一个对话框里写需求、审核、执行、迭代全部搞定	这叫「上下文污染」——AI 会被之前的对话带着走，审核时会偏向为自己生成的内容辩护。正确做法：写需求在一个窗口，审核开新窗口，执行再开一个窗口	演示：在写了需求的窗口里让 AI 审核自己，AI 的回答会非常保守；换新窗口审核，AI 会找出更多问题

---

3. 教学准备

工具与环境：

• 每台电脑已登录 Kimi 2.5，网络正常
• 每台电脑可以正常运行 HTML 文件（浏览器打开）
• 投影可切换至任意学生屏幕

教学资源：

• 教师准备：一个真实可玩的俄罗斯方块网页版（课堂演示用，备用链接）
• 教师准备：「压力测试」提示词（见第5节，投屏展示）
• 教师准备：一份「没写需求文档」直接生成的俄罗斯方块演示（提前生成好，展示各种「AI 自作主张」的细节）
• 教师准备：Level 0 需求文档模板（见第5节，发给学生）
• 学生资源：无需提前准备

教师备课体验任务：

备课前，教师必须亲自完成以下操作：

1. 用一句话「帮我做一个俄罗斯方块」提交给 Kimi，保存生成结果，记录哪些细节是 AI 自己决定的
2. 写一份 Level 0 需求文档，走完「压力测试 → 完善 → 提交生成 → 验收 → 发现问题 → 溯源 → 修改 → 第二版」全流程，记录卡在哪里
3. 准备好 2-3 个「需求没说清楚」的典型例子（比如「消行规则写了但没写消多行的得分」）

---

4. 教学流程

---

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

本幕目标：通过「侦探模式」玩游戏，让学生主动发现俄罗斯方块的规则；展示「一句话版」对比引出 Plan Mode 的价值，建立「先写需求再动手」的第一印象

【环节】侦探模式导入 (10分钟)

师： 今天我们要做一个游戏。但在做之前，先玩两分钟。

【投屏展示俄罗斯方块，或让学生在自己电脑上打开】

师： 你们的任务不是拿高分，而是当侦探——把这个游戏所有的规则找出来，写在纸上。你能找到多少条就写多少条。两分钟，开始。

教师走动观察：学生在记录哪些规则，是停在「方块会下落」这种表层，还是注意到了「碰到边界会停」「满行才消除」这类细节规则。不要打扰，只观察。

师： 好，停。谁来说一条规则？

生： （预期：方块会往下落）

师： 好，这是一条。写得比较浅，但没错。还有呢？

生： （预期：可以左右移动，可以旋转）

师： 对，左右移动、旋转。还有没有发现更多的？

生： （预期：满一行就消掉）

师： 消行——这个很关键。消了之后上面的积木会怎样？

生： （预期：往下掉 / 往下移一行）

师： 对，会往下补。还有吗？积木碰到边界的时候会怎样？

生： （预期：停下来，不能再移了）

师： 对，碰到边界就停，不能移出去。那碰到底部呢？

生： （预期：就固定在那里了）

师： 对，固定住，不动了。那什么时候游戏结束？

生： （预期：积木堆到顶了就结束）

师： 好——你们刚才说出来的这些，就是俄罗斯方块的基本规则。你们注意没有——这些规则，全是游戏的「需求」。每一条都是「这个游戏应该怎么运行」。 【识别层：让学生意识到「游戏规则 = 需求描述」】

师： 现在我问一个问题——如果我让 AI 帮我做这个游戏，我直接说「帮我做一个俄罗斯方块」，你们觉得 AI 能做出来吗？

生： （预期：能！/ 应该能？）

师： 我们来试试。

【投屏展示教师提前生成的「一句话版」俄罗斯方块】

师： 做出来了。但你们来找找看，这个游戏里，有没有什么地方跟你心里想的「俄罗斯方块」不一样？

教师给 20 秒让学生仔细看屏幕，甚至可以让一个学生上来玩几秒

【诊断点：学生是否能发现 AI 自作主张的细节——比如得分规则、速度、旋转方向等】【识别层】

【分支A】若学生发现了不同的地方： 师： 你发现了。为什么 AI 做出来跟你想的不一样？

生： （预期：因为我没有告诉它……）

师： 对！你没说，AI 就自己猜了一个。这就是我们今天要解决的问题。

师： 从今天开始，我们做任何项目，第一步都是同一件事——开启 Plan Mode（计划模式）。Plan Mode 只做一件事：在动手之前，把你的需求写得越详细越好。需求写得越详细，AI 执行越准确；需求写不清楚，AI 就自己猜，猜出来的东西可能跟你想的完全不一样。 【识别层：建立「Plan Mode 先行」的第一印象】

【分支B】若学生觉得「都一样，没问题」： 师： 那我问你——这个游戏消一行得多少分？消四行一次呢？

生： （去看）……好像是 100 分？

师： 你想要的是这个分数吗？

生： 我没想过……

师： 你没想过，AI 就帮你决定了。Plan Mode 就是在动手之前，把所有「你没想过」的地方都想清楚，写在文档里，让 AI 按你想的来做。

---

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

本幕目标：完整走完 Plan Mode 三步——整理需求、需求审核、确认需求；再走完「提交生成 → 验收 → 结果溯源」的执行闭环；建立「需求驱动输出」的核心工作习惯

---

【分段一：开启 Plan Mode — 第一步：整理需求】(20分钟)

本段重点：学习 Plan Mode 三步总览，填写 Level 0 需求文档模板，建立「需求可测试性」的直觉

预设误概念：

• 误概念 M1：「帮我做俄罗斯方块」就够了，不需要 Plan Mode
• 误概念 M4：需求文档要写得很长很全面

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

师： 现在我们正式开启 Plan Mode。Plan Mode 分三步走，我们先把三步过一遍，再动手。

师： 第一步——整理需求。 把你想要的游戏写成一份需求文档。这一步的目标是：把你脑子里「模糊的感觉」变成「具体可以测试的文字」。就像设计师画图纸——不是说「大概这个形状」，而是标出每个尺寸。

师： 第二步——审核需求。 写完不等于写好。让 AI 扮演一个审核工程师，专门找你文档里没说清楚的地方。它不帮你回答，只问问题——「这里如果出现了 XXX 情况，怎么处理？」

师： 第三步——确认需求。 把审核工程师问的问题，一条条回答，补充进你的文档。这样你的需求文档才是「经过压力测试的版本」，可以提交给 AI 执行了。

师： 三步走完，才动手生成。听起来麻烦？我来给你算一笔账——

【投屏展示对比】

路径一（跳过 Plan Mode）：
说一句话 → AI 做出来 → 不对 → 让 AI 改 → 还不对
→ 再改 → 加乱了 → 从头来 → 又不对……（无限循环）

路径二（Plan Mode 先行）：
写需求文档 10分钟 → 压力测试 5分钟 → AI 做出来
→ 小幅微调 → 完成！

师： 路径一的「快」是假的快，路径二的「慢」是真的快。

师： 好，现在进入第一步。我给你们一个 Level 0 需求文档模板，里面有 5 个必须填的部分。

【投屏展示 Level 0 需求文档模板，见第5节】

师： 这 5 个部分，每一个都是 AI「必须知道才能做对」的信息。我带你们看一遍每个字段是什么意思——

师： 第一部分「游戏区域」——游戏画面有多大？10列×20行是经典俄罗斯方块的标准尺寸，你可以改，也可以保持默认。这条如果不写，AI 可能给你做个 6×6 的迷你版，也可能做个 20×40 的超高版。

师： 第二部分「方块移动规则」——注意这里有一个关键字段：「碰到左右边界」。这条要写清楚。什么意思？就是方块走到最边上了，再按左/右键，会发生什么？

生： （预期：就停下来不动 / 不能再往那边移了）

师： 对。但如果你不写，AI 可能给你做出一个方块可以穿过边界、从另一侧出来的效果——像贪吃蛇穿墙那种。你想要这个效果吗？

生： （预期：不想！/ 哦那要写清楚）

师： 所以每一条都得写。第三部分「消行规则」，这里特别要注意「验收标准」这个概念——每条需求，你都要能说出「什么样的结果算做对了」。

师： 比如「消行规则：横向填满一整行就消除」——我怎么测试这条需求 AI 做没做对？

生： （预期：把一行填满，看它有没有消掉）

师： 对。能被测试的需求，才是写清楚了的需求。反过来，「游戏体验要流畅」——这条能测试吗？

生： （预期：不能……怎么叫流畅？）

师： 对，「流畅」是感受，不是能测试的需求。如果要写，你得改成「初始速度每800毫秒下落一格」——这才是可以测试的。 【理解层：建立「需求可测试性」的直觉】

学生实践 (Practice): (11分钟)

师： 现在开始填。5 个部分，把模板里的空格全填上。不确定的地方保持默认值也可以，但不能空着不填。

教师走动观察重点：

• 是否有学生在「移动规则」里只写了「可以左右移动」，但没写「碰到边界怎么处理」？
• 是否有学生在「消行规则」里写了消行但没写「消多行的得分是否不同」？
• 是否有学生把「游戏体验流畅」这类不可测试的需求填进去了？
• 这些漏洞先不要直接告诉学生，留给下一步「压力测试」去发现

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

师： 5个部分都填完的举手。

师： 好，先不着急提交。我来问你一个问题：按照你写的需求，一个不认识这个游戏的人拿到这份文档，能不能把一局游戏从头玩到结束——开始游戏、移动方块、消行、游戏结束？这个流程能跑通吗？

生： （预期：能？/ 好像……方块怎么消行没写清楚？/ 游戏结束之后怎么重新开始没写）

师： 对，就检查这一件事——游戏流程能不能跑通。先别想加什么特殊功能，那是后面的事。

【诊断点：学生的需求是否覆盖了「开始→玩→消行→升级→结束」这个基础流程】【理解层】

---

【分段二：Plan Mode 第二步：需求审核】(20分钟)

本段重点：用 AI 扮演审核工程师对需求做压力测试，区分「审需求」和「审代码」，发现自己看不见的漏洞

预设误概念：

• 误概念 M2：需求文档写完就可以直接提交执行了
• 误概念 M6：需求审核是在挑代码的问题

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

师： 需求文档写完了，进入 Plan Mode 第二步——需求审核。在做这一步之前，我要告诉你们一个非常重要的规则：审核必须在新窗口进行。

师： 为什么一定要新窗口？因为 AI 有一个特质——它不会主动承认自己的问题。你在同一个窗口里跟它说「帮我看看需求有没有问题」，它会被之前的对话「污染」，倾向于觉得「之前做得挺好的」。这叫上下文污染。

师： 打个比方——让同一个同学既写作文又给自己改错，他永远改不出大问题。必须换一个没看过你作文的同学来审，他才会发现真正的漏洞。换新窗口，就是换一个「什么都不知道」的新 AI 来看，它没有偏见，才会客观地找出问题。

师： 记住这条规则，以后做任何项目都要遵守：写需求——一个窗口；审核需求——新窗口；执行生成——再新一个窗口。 不同阶段，不同窗口，互不干扰。 【投屏展示「需求审核」提示词，见第5节】

师： 现在的操作是：复制你的需求文档内容，打开一个全新的 Kimi 对话，把审核提示词粘贴进去。注意——审核的不是代码，是需求本身。审核工程师只负责问问题，不帮你回答，不帮你修改。

师： 我来演示一次。我把自己的需求文档粘贴进去，看 AI 会问什么问题。

【教师用自己的需求文档执行审核，投屏展示 AI 提出的问题列表】

师： 你们看，AI 问了我这些问题——我们一起来分析分析：

师： 第一个问题：「方块旋转到边界时，如果旋转后的形状超出边界，是直接禁止旋转，还是自动向内移动？」——我的文档里有没有写这条？

生： （看文档）……没有……

师： 对，我没写。这个「踢墙旋转」问题我根本没想到。接着看——

师： 第二个问题：「如果方块落下时速度极快（玩家按了加速键），落地瞬间玩家还没松开方向键，方块会继续移动吗？」——我的文档里呢？

生： 也没写……

师： 再看第三个——「当积木消除多行时，是一行一行消，还是同时消除？视觉效果有没有要求？」——我写了得分，但消除的视觉顺序有没有说清楚？

生： 没说……

师： 最后一个——「游戏结束画面，除了「游戏结束」和得分，还需要「重新开始」按钮吗？」——这条很关键，游戏结束了玩家怎么重玩？

生： 对！要有重新开始。

师： 你看——四个问题，我的文档里一条都没写。这不是 AI 在刁难我，是它在帮我找漏洞。这就是「需求审核」的价值。 【识别层：直观感受审核的价值，澄清 M6 误概念——这些问题全是「需求层面」，跟代码无关】

学生实践 (Practice): (12分钟)

1. 学生把自己的需求文档粘贴进「压力测试」提示词，提交 Kimi
2. 把 AI 提出的问题复制下来
3. 逐条读问题，判断哪些问题「我真的没想到」，哪些「我已经写了但 AI 没看清楚」
4. 对「真的没想到」的问题，写上自己的回答，补充进需求文档

教师走动观察重点：

• 学生是否对某个问题感到惊讶——「这个我真的没想过」是好的信号，主动靠近问「这个问题你打算怎么回答？」
• 学生是否对 AI 的问题感到不耐烦「这些问题没必要」——这是 M6 误概念的表现，需要介入
• 学生是否在逐条认真回答，还是全部跳过直接提交——走过去让学生读出一条来分析

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

师： AI 审核出来，问了你最意外的问题是哪条？谁来说说？

生： （预期 A：「方块落到底部前能不能再移动」我没想到）

生： （预期 B：「游戏结束要不要有重玩按钮」）

师： 很好。这就是 Plan Mode 第二步的价值——你自己看不出来的漏洞，让 AI 来挖。

【诊断点：学生能否说出「因为 AI 问了这个问题，我补充了 XXX 这条需求」】【理解层】

【分支A】若学生能说出具体被触发的漏洞： 师： 对，你补充了这条之后，需求文档就更完整了一步。这就叫「需求迭代」——不是一次写完，是一次次补充完善。

【分支B】若学生说「AI 问的问题我都已经写了，没有漏洞」： 师： 好，那你现在需求文档里，有没有写「方块旋转到边界时怎么处理」？ （引导学生发现一个真实存在的漏洞，避免学生误以为文档已经完整）

【分支C】若学生觉得「AI 问的这些问题都不重要，不影响游戏」： 师： 我们来测试一下——现在先不补充这条，等 AI 做出来，如果这个情况出现，游戏会怎样？ （用结果验证的方式让学生自己发现「小漏洞可以让整个游戏崩掉」）

师： 现在进入第三步：回答这些问题，把需求补充完整，然后提交生成。

---

【分段三：提交生成 → 验收 → 结果溯源】(20分钟)

本段重点：建立「按需求逐条验收」的习惯；发现问题时用「结果溯源」找需求根源，而非直接改代码

预设误概念：

• 误概念 M3：生成完了就算完成了，不需要验收
• 误概念 M3：结果不对直接改代码

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

师： 需求文档完善好了，现在提交给 Kimi 生成。但是——生成完不等于完成。生成完之后要做一件事：按需求文档逐条验收。

师： 验收方法：你需求文档里写了什么，就测什么。比如你写了「满一行消除」，就在游戏里把一行填满，看它消没消。比如你写了「碰到边界停止移动」，就在游戏里把方块推到最边上，按方向键，看它有没有停。

师： 我来示范验收清单是什么样的。你们跟着我一起来建——

【投屏在白板/文档上逐条写出来，让学生也在自己文档里写】

师： 第一条——「方块能左右移动」。怎么测？

生： 运行游戏，按左右键，看方块有没有动。

师： 对，动了就打勾，没动就标叉，写上「实际表现：XXX」。第二条——「方块能旋转」。第三条——「方块碰到左边界就停」。第四条——「满一行自动消除」。第五条——「消行后上方积木下移」。

师： 5条验收清单。注意——每条都要你真的去操作，不能只是「看起来好像对」。 看起来对，跟测试过是对，是不一样的。

师： 验收清单怎么记录？用三列格式：需求描述 → 实际结果 → 通过/不通过。比如：

消行规则：横向填满整行就消除
→ 实际测试：把最下一行填满，方块消失了，上方积木下移了
→ 通过 ✓

碰到左边界停止移动
→ 实际测试：方块移到最左边，继续按左键……还能继续移出去
→ 不通过 ✗ → 需要溯源

师： 写「不通过」的时候，把你看到的现象写清楚——「方块能移出边界」比「边界有问题」好得多，因为这是下一步溯源的线索。

【理解层：建立「验收 = 逐条测试」的意识，不是「感觉还行」】

师： 遇到「结果跟预期不一样」时，先不要让 AI 改代码。先做一个动作：找回需求文档，找到是哪一句话没说清楚。这叫结果溯源。

师： 我给你们看一个具体例子——假如我测到这条：「方块可以移出右边界，一半跑出屏幕了」。我怎么溯源？

师： 打开需求文档，找「移动规则」这一节，看「碰到左右边界」这条。

【投屏展示需求文档】

师： 发现了——我写的是「碰到边界停止」，但没说「停止」是指什么——是方块的中心碰到边界停，还是方块的边缘碰到边界停？AI 理解成了方块中心碰到边界才停，所以有半个方块出界了。

师： 这就是溯源的结果：找到了是需求里的哪句话没说清楚。现在怎么修？

生： （预期：把那条需求改得更清楚）

师： 对，把需求改成「方块的任意一侧碰到边界就停止移动，不能超出游戏区域」，然后重新提交生成。不需要动代码，需求说清楚了，AI 会自己重新做对的。 【应用层：掌握「结果 → 溯源 → 修改需求 → 重新生成」的完整闭环】

学生实践 (Practice): (12分钟)

1. 把完善后的需求文档提交 Kimi 生成游戏
2. 运行游戏，对照刚才建立的 5 条验收清单逐条测试
3. 遇到「结果跟预期不一样」时：
   • 回到需求文档
   • 找到是哪条需求没说清楚，或者根本没写
   • 在文档里标注「这里有问题，原因：___」
   • 修改需求文档，重新提交生成第二版

教师走动观察重点：

• 学生测试完一条直接跳过 → 走过去问「这条算做对了吗？你的需求是怎么写的？对比一下」
• 学生说「不对」但直接让 AI 改代码 → 叫停，引导回到需求文档：「先找找是哪条需求没说清楚，找到了再来修改」
• 学生说「全部都对了！」但第一版生成很少能完全通过 → 走过去追问「你测了消行那条了吗？消两行得分对不对？」

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

师： 谁的第二版比第一版有改善？具体改了什么，改完效果怎样？

【诊断点：学生是否能量化进步——不是「感觉好多了」，而是「之前 XXX 不对，改了需求之后 XXX 对了」】【应用层】

【分支A】若学生能说出具体改善： 师： 你找到了根源，改了需求，结果变对了——这个进步不是运气，是因为你走了溯源流程。记住这个感觉——这就是需求驱动输出。需求写清楚了，AI 就做对了。

【分支B】若学生说「改了但没变化，还是不对」： 师： 说明改的地方不是真正的根源。我们再来找——你改了哪条需求？游戏里不对的现象是什么？一起来对照看看——你改的那条，跟这个现象有没有直接关系？ 【帮学生重新溯源，找到真正对应的需求字段】

【分支C】若学生说「我全部验收通过了，没有问题」： 师： 很厉害！那我问你——你验收的是哪 5 条？能说一遍吗？ （让学生逐条念，引导回顾验收过程，确认是真的测试过还是只是「感觉对」） 师： 如果真的都通过了，你现在已经有一个基础版可玩的俄罗斯方块了！那你可以进下一段——想想你想给它加什么功能，留到下节课来做。

---

【分段四：自由探索 + 下节课铺垫】(10分钟)

本段重点：在基础版可玩的基础上，允许学生做少量视觉微调；同时引导学生开始想下节课的扩展功能。只有基础版已经跑通的学生才进入本段，进度慢的学生继续完善分段三的最小闭环

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

游戏基本跑起来了之后，学生自由探索：

• 改一下游戏配色，让它更好看
• 或者调整一下速度和得分规则

师： 你现在手上有一个可以玩的俄罗斯方块了。下节课，你们可以给它加一个你自己想要的功能。现在开始想——你想给你的游戏加什么？

【诊断点：观察学生自然产生的功能需求，作为下节课教学素材】

学生说出 1-2 个想加的功能（不要求写清楚，只是发散）：

• 「我想加个炸弹，可以炸掉一行」
• 「我想让方块会变色」
• 「我想加个 Boss」

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

师： 说说你想加什么，一句话就行。

（每人说一个，教师快速记录在白板/投屏上）

师： 下节课，你们每个人选一个功能，用今天学到的方法——写需求文档、压力测试、生成、验收——把这个功能加进去。

---

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

本幕目标：通过成果展示和互评，让学生复述 Plan Mode 流程，并从「需求层面」评价他人作品，而非只评价游戏好不好玩

【环节】成果展示 (6分钟)

师： 谁来展示一下你今天做的游戏？不只是展示游戏——要说三件事：

（投屏列出三个展示要点）

1. 你的需求文档里，有没有加什么你自己特别设计的规则？
2. AI 压力测试问了你什么最意外的问题？你最后怎么回答的？
3. 你第一版和第二版有什么不同？是溯源到了哪条需求？

（邀请 2 名学生上来展示，每人约 2-3 分钟）

师： （第一位展示后）你刚才说需求审核问了你「方块是否能踢墙旋转」——你怎么回答这个问题的？

生： （预期：我写了「不可以踢墙，碰到边界就禁止旋转」）

师： 好，你做了一个具体的设计决定。有没有人觉得另一种方案——可以踢墙——更好玩？

（让其他学生发表意见，引出「需求可以有不同的设计选择」这个意识）

【环节】互评 (4分钟)

师： 看完 XXX 同学的游戏，我想让你们不只评价「好不好玩」，而是看他的需求文档——能不能找出还有没说清楚的一个地方？

【诊断点：学生是否建立了「挑剔工程师」的眼光，能从需求角度评价作品】【应用层】

生： （预期：「他的需求文档里消多行的得分没写具体」/ 「游戏暂停功能没有需求描述」）

师： 很好！这不是在批评他，这是工程师的职业习惯——总是看「还有什么没说清楚」。你刚才找到的这条，就是下节课可以迭代的方向。

师： 互评用一个结构：一个优点——需求文档里什么地方写得很具体、很清楚？一个建议——需求层面（不是游戏体验），还有什么地方可以更精准？

师： 今天最难描述清楚的规则是什么？你最后是怎么写清楚的？

---

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

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

师： 今天我们用了一个贯穿整个课程的核心流程——Plan Mode。谁来说说 Plan Mode 的三步是什么？

生： （预期：整理需求、审核需求、确认需求……）

师： 对。从今天开始，无论做什么项目，第一步永远是开启 Plan Mode。不管你多想直接动手，都先走这三步。

师： 为什么？因为需求写得越详细，AI 执行越准确。需求写不清楚，执行过程中就会出问题，改来改去反而更慢。

师： 今天做游戏是这样，以后做任何东西——网页、工具、应用——都是同一个流程。Plan Mode 是你跟 AI 合作的基础动作。

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

师： 下节课，每人选一个你想加的功能，用同样的方法——写需求文档、压力测试、生成、验收——把它加进你的俄罗斯方块里。你的游戏会跟任何人的都不一样。

师： 本周5分钟挑战：想好你下节课要加的功能是什么，在脑子里想一想：这个功能如果要写需求文档，最难描述清楚的是哪一条？不用写，想一想就行，下节课说给我听。

---

5. AI 助教使用指南

Level 0 需求文档模板（发给学生填写）：

# 我的俄罗斯方块 · Level 0 需求文档

## 游戏区域
- 宽：___列（默认10）× 高：___行（默认20）

## 方块移动规则
- 左移：按___键
- 右移：按___键
- 旋转：按___键
- 快速下落：按___键
- 碰到左右边界：___（停止/不能再往那边移）
- 碰到底部或其他方块：___（固定在原地）

## 消行规则
- 触发条件：___（横向填满整行）
- 消行后上方积木：___（全部下移一行）
- 消1行得___分，消2行得___分，消4行一次得___分

## 关卡与速度
- 初始速度：每___毫秒下落一格（默认800）
- 每消___行升一级
- 每升一级速度加快___毫秒

## 游戏结束条件
- 什么时候结束：___（积木堆到顶部）
- 结束后显示：___（游戏结束画面 + 最终得分）

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

本课三个阶段的窗口规则：

第一步：整理需求 → 窗口 A（写需求文档用这个窗口）
第二步：需求审核 → 窗口 B（全新窗口，不要用窗口A！）
第三步：执行生成 → 窗口 C（全新窗口）

原因：AI 不会承认自己的问题。在同一个窗口里审核，AI 会受
到之前对话的影响（上下文污染），很难客观找出真正的漏洞。
换新窗口 = 换一个全新的 AI 来看，没有偏见，更客观。

Plan Mode 第二步：「需求审核」提示词：

我写了一份俄罗斯方块的需求文档，内容如下：

[粘贴你的需求文档]

请你扮演一个需求审核工程师，读完这份文档后，
找出所有你觉得「没有说清楚」「可以有多种理解」「遇到特殊情况不知道怎么处理」的地方。

注意：你审核的是需求本身，不是代码。现在还没有任何代码。
请用问题的形式列出来（每条一行，以问号结尾）。
不要帮我回答这些问题，不要帮我修改文档，只负责提问。

「结果溯源」引导提示词（发现结果不对时使用）：

我的游戏运行结果和我的预期不一样。
具体表现：[描述不对的现象]
我预期应该是：[描述你想要的结果]
我的需求文档里关于这个功能写的是：[粘贴相关需求]

请帮我分析：是需求描述不够清楚，还是需求里根本没写这条规则？
不要帮我修改代码，只帮我找出需求文档里的问题。

「提交生成」提示词（正式版）：

请根据以下需求文档，用单个 HTML 文件（内联 CSS 和 JS）做一个俄罗斯方块游戏。
要求：严格按照需求文档实现，不要添加文档里没有提到的功能。

需求文档：
[粘贴你的完整需求文档]

---

6. 教师指南

本课技术备注：

单文件 HTML 策略：所有代码写在一个 index.html 文件里，CSS 和 JS 全部内联。学生双击就能运行，不需要任何服务器或安装。Kimi 2.5 生成单文件俄罗斯方块稳定性高，是这门课的最佳选择。

俄罗斯方块核心数据结构（教师理解用，不讲给学生）：游戏核心是一个二维数组代表游戏区域，每个格子存 0（空）或颜色值（有方块）。方块用形状矩阵 + 当前位置表示。学生不需要理解这些，只需要知道「我的需求文档决定了游戏的行为」。

「踢墙旋转」技术说明（教师理解用）：标准俄罗斯方块有「超级旋转系统（SRS）」，允许方块在边界旁旋转时自动内移。让 AI 默认生成的版本通常不包含这个细节。如果学生需求里没写，AI 可能实现的是「碰到边界禁止旋转」或「可以踢墙」两种之一，建议教师在压力测试环节主动提示学生考虑这条规则。

常见问题 FAQ：

问题	应对
「Kimi 生成的代码打开没有反应」	检查文件是否保存为 .html 格式；用浏览器（不是记事本）打开
「方块可以移动出边界」	需求文档里「碰到边界怎么处理」这条没写清楚，引导学生溯源并补充「方块任意一侧碰到边界就停止移动，不能超出游戏区域」
「消行了但积木没有下移」	需求文档里「消行后上方积木全部下移一行」没有写，或者 AI 理解成消行后积木消失但不下移，引导溯源并在需求里明确写出「消行后上方所有积木整体下移填补空位」
「游戏结束了但还能继续操作」	需求文档里游戏结束条件对应的处理没写「结束后禁止玩家操作」，引导补充
「我想直接改代码」	「你能看懂这段代码是做什么的吗？如果不能，改了可能引发新的问题。先改需求文档，让 AI 重新生成更安全。」
「AI 审核出来问了很多问题，我不知道怎么回答」	先问学生「这些问题里，哪一条你有自己的想法？」——通常能说出 2-3 条，剩下的保持默认值，在需求文档里写「保持默认行为」也是合法的回答
「需求文档写了但 AI 生成的完全没有按需求来」	检查提交时有没有把需求文档完整粘贴；也可能是 Kimi 单次生成的结果质量波动，重新提交一次，如果还不行，引导学生检查需求是否有歧义
「我的游戏做好了，同学的还差很多，我要做什么」	可以进入分段四自由探索，或者帮教师整理一份「你发现的 AI 自作主张细节」作为下节课的展示素材
「旋转之后方块超出边界怎么回事」	这是「踢墙旋转」的问题，引导学生在需求文档里补充「旋转后如超出边界，禁止该次旋转」或「旋转后自动内移一格」，选择哪个方案让学生自己决定
「游戏跑起来了但速度太快，根本玩不了」	引导溯源：「你的需求文档里初始速度写的是多少毫秒？」——如果填了 100 毫秒（很快），改成 800 毫秒（默认值）；如果没填，这就是漏洞，补充进去

课堂节奏控制（重要）：

本课的核心节奏：先做出基础可玩版本，再做扩展。教师要守住这条线，不能让学生在第一版都没跑通的情况下就开始想「加炸弹」「加 Boss」。

具体做法：

• 分段三开始前，教师快速巡场确认每个学生的需求文档覆盖了基础流程（开始→移动→消行→结束）
• 发现学生需求里加了复杂功能（比如道具、反重力）：引导他先注释掉，等基础版跑通再加
• 分段四的自由探索，只有基础版已经可玩的学生才能进入

课堂风险预案：

• 如果 Kimi 一次生成就完全符合预期：恭喜学生，但仍要做需求审核——「这次 AI 猜对了，你能保证下次加新功能时也能猜对吗？」
• 如果学生进度差异很大：进度快的学生进入分段四自由探索；进度慢的学生只要完成「基础版可玩 + 发现一个需求漏洞 + 修复」这个最小闭环即可，不强求扩展功能。

---

7. 5分钟日常AI挑战

本周挑战： 想好下节课要加的功能 挑战说明： 不用动手，只是想一想：你的俄罗斯方块下节课要加什么功能？这个功能最难描述清楚的是哪一条规则？在脑子里想好，下节课说给老师和同学听。 下节课分享： 课前每人说出自己想加的功能，以及预感最难写清楚的那条需求

---

8. 拓展任务

拓展一（推荐）： 给你的游戏加一个「下一个方块预览」功能——把这个功能写成需求文档，测试一下 AI 能不能做出来 拓展二（挑战）： 给你的游戏加一个「最高分记录」功能——玩完之后会记住历史最高分，下次打开还在