25ec5f0c9c
- 新增 AICODE06-08~11 完整逐字稿教案（每课600+行） - 涂鸦PK主题：画图工具→基础对战→动画音效→班级锦标赛 - 核心工程思维：需求驱动→测试验证→增量迭代→数据驱动 - 更新 AICODE-06 课程大纲，追加第8-11课内容 - 新增 demo-pk/ 目录（画图工具/对战/动画三个demo） Co-Authored-By: Claude Sonnet 4.6 (1M context) <noreply@anthropic.com>
670 lines
38 KiB
Markdown
670 lines
38 KiB
Markdown
---
|
||
课时: 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 能不能做出来
|
||
**拓展二（挑战）：** 给你的游戏加一个「最高分记录」功能——玩完之后会记住历史最高分，下次打开还在
|