701 lines
42 KiB
Markdown
701 lines
42 KiB
Markdown
---
|
||
课时: 7
|
||
主题: 交互产品架构设计
|
||
核心能力: [拆解力, 表达力]
|
||
核心工具: [穹狼 Code / Trae]
|
||
时长: 90分钟
|
||
透明化层级: 过程层
|
||
适用路线: 共享
|
||
---
|
||
|
||
### 1. 课程目标
|
||
|
||
**知识目标：**
|
||
- 理解"游戏核心循环"概念：玩家做什么 → 系统反馈什么 → 为什么还想玩
|
||
- 理解"需求文档"的作用：先想清楚再动手，用文字把想法固定下来
|
||
- 知道MVP（最小可玩版本）与功能优先级的关系：不是所有功能都同样重要
|
||
|
||
**能力目标：**
|
||
- 能分析一款游戏/产品的核心循环，并用一句话描述其核心玩法（拆解力）
|
||
- 能独立撰写一份"一页纸需求文档"：项目名称、目标用户、核心玩法、功能清单（表达力）
|
||
- 能将需求文档转化为AI可执行的开发指令，并验收核心玩法是否实现（拆解力+表达力）
|
||
|
||
**情感目标：**
|
||
- 建立"先想清楚再做"的产品思维——从"随便做一个"进化到"有计划地做"
|
||
- 感受"我的项目我做主"的自主感——完全开放的方向选择带来创作自由
|
||
- 体验"文档是和AI合作的最好起点"——写好文档比写好单条提示词更强大
|
||
|
||
---
|
||
|
||
### 2. 核心概念与误概念预设
|
||
|
||
**核心概念认知层级：**
|
||
|
||
| 概念 | 学生类比 | 认知层级 |
|
||
|------|---------|---------|
|
||
| 游戏核心循环 | 就像"石头剪刀布"——出招（玩家行动）→ 比大小（系统反馈）→ 不服再来（继续动力） | 识别层→理解层 |
|
||
| 需求文档 | 就像出去旅游前的"旅行计划"——去哪、玩什么、带什么，写清楚了再出发 | 理解层→应用层 |
|
||
| MVP功能优先级 | 就像做一道菜——先把主菜做好（MVP），再考虑摆盘和配菜（V2/V3） | 应用层 |
|
||
| 自选方向 | 就像自助餐——老师提供六个窗口，你选最想吃的那个 | 识别层 |
|
||
|
||
**典型误概念表：**
|
||
|
||
| 编号 | 误概念 | 正确认知 | 激发策略 |
|
||
|------|--------|---------|---------|
|
||
| M1 | **不需要写文档，直接让AI做就行** | 文档帮你理清思路、减少返工；没有文档，AI只能猜你想要什么，做出来的大概率不满意 | 对比演示：有文档vs无文档的AI产出质量差异 |
|
||
| M2 | **功能越多越好，一次全部做完** | 先做核心玩法（MVP），确认好玩了再加功能；一次塞太多功能，AI容易做乱 | 展示一个"功能太多反而什么都不好玩"的反面案例 |
|
||
| M3 | **核心循环=游戏规则** | 核心循环是"为什么你会一直玩下去"的动力机制，不只是规则说明 | 用"贪吃蛇"举例——规则是"吃豆子变长"，但核心循环是"我还能更长→贪心→撞墙→不服→再来" |
|
||
| M4 | **需求文档要写得很正式很长** | 一页纸就够了！关键是想清楚"做什么、给谁用、核心体验是什么" | 展示一页纸模板，消除"写文档很难"的恐惧 |
|
||
| M5 | **只有游戏才需要核心循环** | 任何产品都有循环——工具类是"遇到问题→使用工具→问题解决→下次还用"，创意类是"看到灵感→创作→获得反馈→想做更多" | 引导学生分析一个工具类产品的循环 |
|
||
|
||
---
|
||
|
||
### 3. 教学准备
|
||
|
||
**工具与环境：**
|
||
- AI编程工具（穹狼 Code / Trae，每位学生已在前几课完成安装配置）
|
||
- DeepSeek模型（慢思考模型，用于核心玩法开发）
|
||
- 教师演示电脑+投影
|
||
|
||
**教学资源：**
|
||
- 教师准备：3个经典游戏的"核心循环分析卡"（打印或投影）
|
||
- "一页纸需求文档"模板（打印版，每人一张）
|
||
- 六个方向的简介卡（投影展示或贴在教室墙上）
|
||
- 教师提前用需求文档生成的一个示范项目（用于演示"文档→AI开发"流程）
|
||
|
||
**教师备课体验任务：**
|
||
> 备课前，教师必须亲自完成以下操作：
|
||
> 1. 选择一个方向（建议选"动作类游戏"），自己写一份一页纸需求文档
|
||
> 2. 把需求文档交给AI开发，记录AI的产出质量和需要修改的地方
|
||
> 3. 对比测试：不写文档直接说"帮我做一个躲避游戏" vs 把写好的文档发给AI——对比两次产出的差异
|
||
> 4. 分析2-3个经典游戏的核心循环，确保自己能流畅讲解
|
||
> 5. 准备一个"功能塞太多导致混乱"的反面案例（可以故意让AI做一个功能过多的游戏）
|
||
|
||
---
|
||
|
||
### 4. 教学流程
|
||
|
||
**第一幕：联系 (Connect) — 10分钟** 🔗
|
||
|
||
**【环节】上节课回顾 (3分钟)**
|
||
|
||
**师：** 上两节课我们做了很酷的事情——第5课用一句话做出了一个可玩游戏，第6课在游戏上加了计分、倒计时、动画。谁还记得，第6课我们加功能的时候用了什么方法？【诊断点：检测"增量开发"概念的保持度】【识别层】
|
||
|
||
**【分支A】若学生回答出"一个功能一个功能加上去""在原来的基础上改"：**
|
||
**师：** 对！我们不是重新做一个，而是在已有的作品上一点一点加新功能。这叫"迭代"，也叫"增量开发"。那今天我问你们一个新问题——你们之前做的游戏，是"想好了再做的"，还是"随便先做一个再说"的？
|
||
|
||
**【分支B】若学生记忆模糊：**
|
||
**师：** 我来提醒一下。第6课我们拿到第5课的游戏之后，先加了什么？（计分）然后呢？（倒计时）最后呢？（动画）。对，一个一个功能加上去，这叫增量开发。今天我们要学一个更厉害的技能——在开始做之前，先"想清楚"要做什么！
|
||
|
||
**【分支C】若学生只记得"做了游戏"但忘了具体过程：**
|
||
**师：** 嗯，我们确实做了游戏。但今天我想问你们一个更深的问题——你们有没有想过，为什么有些游戏你玩了就停不下来，有些游戏玩两分钟就不想玩了？今天我们就要揭开这个秘密！
|
||
|
||
**【环节】情景导入 (7分钟)**
|
||
|
||
**师：** 我先问大家一个问题——你们最近最喜欢玩的游戏是什么？不限于电脑游戏，手机游戏、桌游、甚至课间玩的游戏都算！
|
||
|
||
**生：** （各种回答：我的世界、贪吃蛇、跳一跳、五子棋、抓人游戏……）
|
||
|
||
**师：** 好，我听到了很多。那我再问一个更有意思的问题——你们玩这些游戏的时候，为什么会一直想玩下去？是什么让你"停不下来"？【诊断点：激发对"核心循环"的直觉认知】【理解层】
|
||
|
||
**【分支A】若学生说出"因为好玩""因为想赢""因为想打更高分"：**
|
||
**师：** "想赢""想打更高分"——这就是关键！每个让你停不下来的游戏，都有一个"魔法循环"藏在里面。今天我们就要学会发现这个循环，然后自己设计一个！
|
||
|
||
**【分支B】若学生说"因为无聊""因为没事干"：**
|
||
**师：** 哈哈，那如果一个游戏真的很无聊，你会一直玩吗？肯定不会吧？说明让你继续玩的不只是"没事干"，一定有什么东西在吸引你。今天我们就来找到这个"东西"是什么！
|
||
|
||
**【分支C】若学生说不出来：**
|
||
**师：** 没关系，我来举个例子。你们玩过"贪吃蛇"吗？你控制一条蛇，吃豆子会变长。你为什么不吃一个就停？因为你想变得更长！但越长越容易撞到自己——所以你又紧张又兴奋，就一直玩下去了。这里面藏着一个"循环"，今天我们就来研究它！
|
||
|
||
**师：** 今天这节课非常特别。从今天开始，你们要启动一个全新的项目——不是老师指定的，是你们自己选的！但这次，我们不是上来就让AI做，而是要先"想清楚"再做。今天的目标：写一份你的项目"设计图纸"，然后让AI按图纸开工！
|
||
|
||
---
|
||
|
||
**第二幕：建构 (Construct) — 65分钟** 🛠️
|
||
|
||
**【分段一：游戏核心循环——为什么好玩的秘密】(15分钟)** ✨
|
||
|
||
**预设误概念：**
|
||
- M3：核心循环=游戏规则
|
||
- M5：只有游戏才需要核心循环
|
||
|
||
**讲解与演示 (Teach & Demo):**
|
||
|
||
**师：** 我们先来破解一个秘密——为什么有些游戏你玩了就停不下来？答案是：每个好玩的游戏里面都藏着一个"核心循环"。什么意思呢？我画给你们看。
|
||
|
||
【在白板上画一个循环图】
|
||
|
||
```
|
||
玩家做什么？
|
||
↓
|
||
系统反馈什么？
|
||
↓
|
||
为什么还想玩？
|
||
↓
|
||
（回到"玩家做什么"）
|
||
```
|
||
|
||
**师：** 这就是核心循环——三个问题不断转圈。我来用大家都知道的游戏分析一下。
|
||
|
||
**师：** 第一个例子——**贪吃蛇**。
|
||
|
||
- **玩家做什么？** 控制蛇的方向，去吃豆子
|
||
- **系统反馈什么？** 吃到豆子→蛇变长，分数增加
|
||
- **为什么还想玩？** 想变得更长！但蛇越长越难操控，随时可能撞到自己→紧张刺激→"再来一次！"
|
||
|
||
**师：** 看到了吗？这三步形成了一个循环。你吃了一个豆子，就想吃下一个；蛇变长了，难度也上去了；你撞死了，不服气，再来一次。这就是让你"停不下来"的魔法！
|
||
|
||
**师：** 再来一个——**Flappy Bird**（或者"飞翔的小鸟"，你们可能玩过类似的）。
|
||
|
||
- **玩家做什么？** 点击屏幕让小鸟飞起来，穿过管道的缝隙
|
||
- **系统反馈什么？** 穿过一个管道→加1分，撞上管道→游戏结束
|
||
- **为什么还想玩？** 上次才得了5分，这次我一定能得6分！→挑战自己→"再来一次！"
|
||
|
||
**师：** 注意——两个游戏的核心循环不一样，但结构是一样的：做动作→得反馈→想继续。【诊断点：学生是否理解"循环"不是"规则"】【理解层】
|
||
|
||
**师：** 我再问一个问题——核心循环和游戏规则，是同一个东西吗？
|
||
|
||
**【分支A】若学生说"不一样"：**
|
||
**师：** 很好！能说说哪里不一样吗？
|
||
|
||
**【分支B】若学生说"差不多吧"或"就是规则"（M3的表现）：**
|
||
**师：** 想想看——贪吃蛇的规则是"蛇吃到豆子会变长，撞到自己或墙壁就死"。但核心循环回答的是一个更深的问题——"你为什么愿意一直玩下去？"。规则告诉你"怎么玩"，核心循环解释"为什么好玩"。
|
||
|
||
**【分支C】若学生沉默：**
|
||
**师：** 我换个说法。规则就像交通法规——"红灯停绿灯行"。核心循环就像你为什么喜欢开车——"开快了有速度感→超车了有成就感→到达目的地了有满足感"。一个是规定，一个是让你上瘾的原因。明白了吗？
|
||
|
||
**师：** 好，刚才我们说了游戏的核心循环。但其实不只是游戏——任何好产品都有核心循环！比如抖音：刷视频（玩家做什么）→ 看到有趣的内容（系统反馈）→ 想看下一个（为什么还想用）。所以今天不管你选做游戏、工具还是创意作品，都可以用核心循环来设计！
|
||
|
||
**学生实践 (Practice):**
|
||
|
||
**师：** 现在轮到你们了！想一个你喜欢的游戏或者App，用核心循环三个问题分析它：
|
||
|
||
1. 玩家/用户做什么？
|
||
2. 系统反馈什么？
|
||
3. 为什么还想玩/用？
|
||
|
||
在纸上写下来，3分钟。写完后跟你旁边的同学互相分享。
|
||
|
||
【教师巡场观察，重点关注：】
|
||
- 学生选择分析的对象是什么（游戏？App？现实中的活动？）
|
||
- 三个问题是否都写了，还是漏了"为什么还想玩"
|
||
- 是否有学生把"规则"写成了"循环"（M3）
|
||
|
||
**进度同步 (Checkpoint):**
|
||
|
||
**师：** 谁来分享一下你分析的核心循环？告诉我们你分析的是什么游戏/App，三个问题分别是什么。【诊断点：学生能否区分"规则"和"循环"，能否识别出"继续动力"】【应用层】
|
||
|
||
【请2位学生分享】
|
||
|
||
**【分支A】若学生分析完整且准确：**
|
||
**师：** 非常好！你准确地找到了核心循环。特别是"为什么还想玩"这一步——你说的是"想打更高分"，这就是核心循环的发动机！
|
||
|
||
**【分支B】若学生的"为什么还想玩"写得太浅（如"因为好玩"）：**
|
||
**师：** "好玩"是对的，但我们要更具体——好玩在哪里？是因为"想打败上次的自己"？还是"想解锁新关卡"？还是"想看到新东西"？越具体，你设计自己的项目时就越知道怎么让人停不下来。
|
||
|
||
**【分支C】若学生把规则当成了循环：**
|
||
**师：** 你写的其实是游戏规则——"怎么玩"。核心循环要回答的是"为什么你玩了一局还想再玩一局"。想想看：你输了之后为什么不关掉游戏？是什么让你点了"再来一次"？
|
||
|
||
**师：** 好！现在你们知道了"核心循环"是什么。接下来我们要做一件更重要的事——用这个知识来设计你们自己的新项目！
|
||
|
||
---
|
||
|
||
**【分段二：我的项目提案——选方向、写文档】(15分钟)** ✨
|
||
|
||
**预设误概念：**
|
||
- M1：不需要写文档，直接让AI做就行
|
||
- M2：功能越多越好，一次全部做完
|
||
- M4：需求文档要写得很正式很长
|
||
|
||
**讲解与演示 (Teach & Demo):**
|
||
|
||
**师：** 上两节课，我们的项目是"老师说做什么就做什么"。但从今天开始，你的项目完全由你自己决定！我给你们六个方向可以选——
|
||
|
||
【投影展示六个方向】
|
||
|
||
```
|
||
🎮 方向一：动作类游戏 — 躲避障碍、射击敌人、跑酷闯关
|
||
🧩 方向二：益智类游戏 — 记忆翻牌、数学挑战、拼图解谜
|
||
🏰 方向三：策略类游戏 — 塔防、经营、资源管理
|
||
🔧 方向四：实用工具 — 计时器、备忘录、计算器
|
||
🎨 方向五：创意展示 — 个人主页、互动故事、作品画廊
|
||
📚 方向六：学科应用 — 英语单词、数学练习、科学模拟
|
||
```
|
||
|
||
**师：** 这六个方向随便选！你也可以选不在这里面的方向，只要你能说清楚想做什么。没有标准答案，你做什么都可以。
|
||
|
||
**师：** 但是——选好了方向之后，我们不能直接冲过去让AI做。第5课的时候我们就是这么干的——"一句话让AI做"，对吧？那时候做出来的东西好不好？
|
||
|
||
**生：** 还行 / 有些不太满意
|
||
|
||
**师：** 那时候做出来的是"最小可玩版本"——能玩，但不完美。现在我们要做一个更大的项目，如果不想清楚就开始，AI做出来的东西大概率会让你不满意。所以今天，我要教你们一个专业产品经理都在用的工具——**需求文档**。【诊断点：激发M1"不需要文档"的误概念】【理解层】
|
||
|
||
**师：** 你们觉得"需求文档"是什么？听起来是不是很吓人，很正式？
|
||
|
||
**【分支A】若有学生说"感觉要写很多"（M4的表现）：**
|
||
**师：** 哈哈，不用！我们写的是"一页纸"版本——一张纸就够了。不需要写得多，关键是想得清楚。
|
||
|
||
**【分支B】若有学生说"就是告诉AI要做什么吧"：**
|
||
**师：** 差不多！但比你之前发给AI的一句话要详细得多。它不只说"做什么"，还说"给谁用""核心体验是什么""先做什么后做什么"。
|
||
|
||
**【分支C】若学生不理解这个概念：**
|
||
**师：** 想象你要盖一栋房子。你会不会直接跟工人说"帮我盖个房子"就完了？不会吧！你得先画一张图纸——几个房间、多大面积、厨房在哪里。需求文档就是你项目的"图纸"。
|
||
|
||
**师：** 我来展示一下"一页纸需求文档"的模板——
|
||
|
||
【投屏展示模板】
|
||
|
||
```
|
||
┌──────────────────────────────────────────────────┐
|
||
│ 一页纸需求文档 │
|
||
│ │
|
||
│ 项目名称：______________________ │
|
||
│ │
|
||
│ 目标用户：这个项目做给谁用？ │
|
||
│ ________________________________________ │
|
||
│ │
|
||
│ 核心玩法一句话： │
|
||
│ "玩家/用户____（做什么），系统____（怎么反馈）， │
|
||
│ 让人想继续因为____（为什么上瘾）" │
|
||
│ │
|
||
│ 功能清单： │
|
||
│ 【MVP·必须有】（今天要完成的核心功能） │
|
||
│ □ ______________________ │
|
||
│ □ ______________________ │
|
||
│ □ ______________________ │
|
||
│ │
|
||
│ 【V2·下次加】（下一课想加的功能） │
|
||
│ □ ______________________ │
|
||
│ □ ______________________ │
|
||
│ │
|
||
│ 【V3·未来想】（以后有时间再做的） │
|
||
│ □ ______________________ │
|
||
│ □ ______________________ │
|
||
│ │
|
||
│ 视觉风格：□简洁 □可爱 □酷炫 □像素 □其他____ │
|
||
│ │
|
||
└──────────────────────────────────────────────────┘
|
||
```
|
||
|
||
**师：** 我先拿我自己的例子来填一遍。假设我选"动作类游戏——躲避游戏"：
|
||
|
||
- **项目名称：** 太空躲避大师
|
||
- **目标用户：** 课间想玩两分钟的小学生
|
||
- **核心玩法一句话：** "玩家用键盘控制飞船左右移动躲避从天上掉下来的陨石，系统会记录你存活了多少秒，让人想继续因为想打败自己上次的记录"
|
||
- **MVP功能：** ①飞船能左右移动 ②陨石从上往下掉 ③碰到就游戏结束并显示存活秒数
|
||
- **V2功能：** 计分排行榜、陨石速度递增
|
||
- **V3功能：** 道具系统（护盾、加速）、不同关卡
|
||
- **视觉风格：** 像素风
|
||
|
||
**师：** 你们注意到了吗？MVP里只有3个功能！不是什么都塞进去。先把最核心的"躲避+碰撞检测+显示时间"做好，确认好玩了再加其他东西。这就是我们第5课学的MVP精神！【诊断点：学生是否理解MVP的优先级逻辑】【应用层】
|
||
|
||
**学生实践 (Practice):**
|
||
|
||
**师：** 现在是你们的时间了！每个人做三件事：
|
||
|
||
**第一步（2分钟）：** 选方向。六个方向里挑一个，或者自己想一个。不用纠结太久，跟着感觉走！
|
||
|
||
**第二步（6分钟）：** 填写一页纸需求文档。用我发给你们的纸质模板，一项一项填。最重要的是"核心玩法一句话"——它要包含核心循环的三个要素！
|
||
|
||
**第三步（2分钟）：** 跟旁边的同学互相读一下你的需求文档。听听对方觉得"听起来好不好玩/好不好用"。
|
||
|
||
提示：如果你不知道选什么方向，可以想想——
|
||
- 你平时最喜欢玩什么类型的游戏？→ 选游戏方向
|
||
- 你觉得生活中什么事情很麻烦？→ 选工具方向
|
||
- 你有没有什么想展示给别人看的？→ 选创意展示方向
|
||
- 你哪个学科想做得更有趣？→ 选学科应用方向
|
||
|
||
开始！
|
||
|
||
【教师巡场观察，重点关注：】
|
||
- 是否有学生纠结方向选不出来 → 跟他聊天引导："你平时下课最喜欢干什么？"
|
||
- 是否有学生在"核心玩法一句话"卡住 → 给脚手架："玩家/用户做什么？系统会怎样？为什么想继续？"
|
||
- 是否有学生在MVP里塞了太多功能（M2）→ 提醒："挑最重要的3个就够了"
|
||
- 是否有学生不写文档直接打开AI工具（M1）→ 引导："先把文档写好，等会儿你会发现文档让AI做事更准"
|
||
|
||
**进度同步 (Checkpoint):**
|
||
|
||
**师：** 时间到！我来检查一下——举手告诉我，你选了哪个方向？选游戏的举手？选工具的？选创意展示的？选学科应用的？【诊断点：方向分布是否合理，是否有学生还没选】
|
||
|
||
**师：** 好，大部分人都选好了。现在谁来读一下你写的"核心玩法一句话"？只读这一句！【诊断点：一句话是否包含核心循环三要素】【应用层】
|
||
|
||
【请2-3位学生读】
|
||
|
||
**【分支A】若学生的一句话包含了"做什么→反馈→继续动力"：**
|
||
**师：** 非常完整！你把核心循环写进去了——有动作、有反馈、有继续玩的理由。这就是一个好的核心玩法描述！
|
||
|
||
**【分支B】若学生只描述了功能，没有"为什么想继续"：**
|
||
**师：** 你说了"玩家做什么"和"系统反馈什么"，很好！但是少了最关键的一步——为什么你/用户会想继续？想想刚才分析核心循环时的第三个问题。加上这句话！
|
||
|
||
**【分支C】若学生的描述太模糊（如"一个好玩的游戏"）：**
|
||
**师：** "好玩"太笼统了。具体什么操作？点击？拖动？键盘控制？系统会怎么回应你？试试用我给的句式填空："玩家____，系统____，让人想继续因为____"。
|
||
|
||
---
|
||
|
||
**【分段三：AI启动开发——文档变成代码】(20分钟)** ✨
|
||
|
||
**预设误概念：**
|
||
- M1：不需要写文档，直接让AI做就行（此处正面验证文档的威力）
|
||
- M2：功能越多越好（此处强调只做MVP）
|
||
|
||
**讲解与演示 (Teach & Demo):**
|
||
|
||
**师：** 好，文档写好了！现在到了最激动人心的环节——把你的"设计图纸"交给AI，让它帮你把核心玩法做出来！
|
||
|
||
**师：** 但注意，我们今天只做MVP——就是你文档里"必须有"那一栏的功能。V2和V3的功能先不管！就像盖房子，今天只把框架搭好，装修的事以后再说。
|
||
|
||
**师：** 我先示范一下怎么把需求文档"翻译"成AI能理解的开发指令。看好了——
|
||
|
||
【教师现场演示，在AI编程工具中输入：】
|
||
|
||
```
|
||
请帮我用HTML/CSS/JS开发一个叫"太空躲避大师"的小游戏，要求如下：
|
||
|
||
## 项目信息
|
||
- 目标用户：想在课间玩两分钟的小学生
|
||
- 视觉风格：像素风格，深蓝色太空背景
|
||
|
||
## 核心玩法
|
||
玩家用键盘左右方向键控制一架飞船在屏幕底部移动，陨石从屏幕顶部随机位置往下掉落。玩家需要躲避陨石，碰到陨石就游戏结束。
|
||
|
||
## MVP功能（只做这些）
|
||
1. 飞船可以用左右方向键移动，不能移出屏幕
|
||
2. 陨石从屏幕顶部随机位置不断掉落
|
||
3. 飞船碰到陨石→游戏结束，显示"游戏结束"和存活秒数
|
||
4. 有一个"重新开始"按钮
|
||
|
||
## 技术要求
|
||
- 单个HTML文件，内联CSS和JS
|
||
- 使用Canvas做游戏画面
|
||
- 适配电脑浏览器
|
||
```
|
||
|
||
**师：** 大家注意——我没有一句一句地跟AI聊天，而是把整个需求文档整理好，一次性发给AI！这就是需求文档的威力——你想好了所有细节，AI一次就能做出比较完整的东西，不用来来回回改。
|
||
|
||
【等待AI生成，预览效果】
|
||
|
||
**师：** 看！AI根据我的文档做出了一个基本能玩的躲避游戏。飞船能动、陨石在掉、碰到会结束、有存活时间。虽然可能不完美，但核心玩法已经有了！这就是MVP。
|
||
|
||
**师：** 如果我刚才不写文档，只说"帮我做一个太空躲避游戏"，AI可能会少做很多东西，或者做出来不是我想要的效果。文档帮AI理解了你脑子里完整的画面。
|
||
|
||
**师：** 现在轮到你们了！把你的需求文档翻译成AI能理解的开发指令。我给你们一个框架——
|
||
|
||
【投屏展示提示词框架】
|
||
|
||
```
|
||
请帮我用HTML/CSS/JS开发一个叫"[项目名称]"的[游戏/工具/网页]，
|
||
要求如下：
|
||
|
||
## 项目信息
|
||
- 目标用户：[你的目标用户]
|
||
- 视觉风格：[你选的风格]
|
||
|
||
## 核心玩法/核心功能
|
||
[把你的"核心玩法一句话"展开写，描述用户做什么、系统怎么反馈]
|
||
|
||
## MVP功能（只做这些）
|
||
1. [功能1]
|
||
2. [功能2]
|
||
3. [功能3]
|
||
|
||
## 技术要求
|
||
- 单个HTML文件，内联CSS和JS
|
||
- 适配电脑浏览器
|
||
```
|
||
|
||
**学生实践 (Practice):**
|
||
|
||
**师：** 现在动手！步骤如下：
|
||
|
||
1. 对照你的纸质需求文档，把内容填进刚才的提示词框架里
|
||
2. 用慢思考模型（因为这是个复杂任务），把提示词发给AI
|
||
3. 等AI生成完代码后，打开预览看效果
|
||
4. **关键验收**：核心玩法能跑吗？你文档里写的3个MVP功能都实现了吗？
|
||
|
||
**师：** 给大家15分钟。如果AI第一次做出来的不对，不要急着加新功能——先把核心玩法调对！用我们第4课学的Bug描述三要素来跟AI沟通修改。
|
||
|
||
开始！
|
||
|
||
【教师巡场观察，重点关注：】
|
||
- 学生是否在用需求文档框架发送，还是随便说一句话（对比文档效果的关键时刻）
|
||
- 学生是否在等待AI生成时焦虑 → 安慰："慢思考模型就是需要时间，它在认真想"
|
||
- AI生成后学生是否在验收MVP功能 → 提醒："你文档里写了3个功能，一个一个检查"
|
||
- 是否有学生一上来就要求加V2/V3的功能（M2）→ 提醒："先确认MVP好不好玩！"
|
||
- 是否有学生的核心玩法完全跑不起来 → 帮助诊断是提示词的问题还是AI的问题
|
||
- 做得快的学生 → 鼓励迭代修复细节，而不是急着加功能
|
||
|
||
**进度同步 (Checkpoint):**
|
||
|
||
**师：** 时间过半了！快速检查——你的核心玩法能跑起来了吗？举手告诉我：能玩的举手！还在调的举手！还没生成的举手！【诊断点：完成度分布——如果大部分学生还没能跑，可能需要延长时间或提供更多帮助】
|
||
|
||
**【分支A】若大部分学生核心玩法已经能跑：**
|
||
**师：** 太棒了！现在做一件事——对照你的需求文档，逐项检查：功能1实现了吗？功能2呢？功能3呢？有没有跟文档不一样的地方？如果有，用Bug描述三要素告诉AI修。
|
||
|
||
**【分支B】若有不少学生还在调试：**
|
||
**师：** 没关系！核心玩法是最难做的部分。如果AI做出来的不对，先深呼吸，然后用这个句式跟AI说："我的[项目名]有一个问题——我做了什么（操作），我以为会怎样（预期），实际怎样了（实际）。请帮我修复。"
|
||
|
||
**【分支C】若有学生完全卡住：**
|
||
**师：** 来，让我看看你的需求文档和提示词。有时候问题出在描述不够清楚——我们一起改一下。（教师一对一辅导）
|
||
|
||
---
|
||
|
||
**【分段四：验收与调整——核心体验对了吗？】(15分钟)** ✨
|
||
|
||
**预设误概念：**
|
||
- M2：功能越多越好（学生可能急着加功能而忽略核心体验）
|
||
- 审查类：能跑就行，不检查体验好不好
|
||
|
||
**讲解与演示 (Teach & Demo):**
|
||
|
||
**师：** 好！大部分人的核心玩法已经能跑了。但我要问一个关键问题——"能跑"和"好玩"，是同一回事吗？【诊断点：激发"能跑就行"的误概念】【理解层】
|
||
|
||
**生：** 不是 / 不一定
|
||
|
||
**师：** 对！一个游戏能运行不代表它好玩。一个工具能打开不代表它好用。我们需要做一件事——**验收核心体验**。怎么验收呢？回到你的需求文档，看你写的那句"核心玩法一句话"，然后问自己三个问题：
|
||
|
||
**核心体验验收三问：**
|
||
1. **动作对吗？** ——玩家/用户的操作跟你设计的一样吗？（比如：我设计的是"左右移动飞船"，现在真的能左右移动吗？操控手感顺畅吗？）
|
||
2. **反馈到位吗？** ——系统的反馈是否让你感受到了？（比如：碰到陨石后有没有明确的"游戏结束"提示？分数显示清楚吗？）
|
||
3. **想继续吗？** ——你自己玩了一轮之后，是否真的想再玩一轮？如果不想，是哪里出了问题？
|
||
|
||
**师：** 我来用我的"太空躲避大师"演示一下验收过程。
|
||
|
||
【教师打开自己的游戏，现场试玩】
|
||
|
||
**师：** 动作对吗？嗯，飞船能左右移动，但移动速度有点太快了，手指一按就飞出去半个屏幕。这个需要调。反馈到位吗？碰到陨石后确实显示"游戏结束"了，但存活时间的字太小了，我差点没看见。想继续吗？嗯……说实话，陨石掉得太慢了，不太刺激。我需要让AI把陨石速度调快一点。
|
||
|
||
**师：** 看到了吗？验收不是"能跑就打勾"，而是认真体验一遍，找出不对劲的地方。然后用精确的语言告诉AI去调整。
|
||
|
||
**学生实践 (Practice):**
|
||
|
||
**师：** 现在你们也来验收！步骤：
|
||
|
||
1. **自己玩/用你的作品至少2分钟**——认认真真地体验
|
||
2. **用"核心体验验收三问"检查**——动作对吗？反馈到位吗？想继续吗？
|
||
3. **找出最需要改的1-2个问题**——不要一次改太多，挑最影响体验的
|
||
4. **告诉AI修改**——描述清楚"现在是什么样"和"我想要什么样"
|
||
5. **改完再验收一遍**——看看是不是好了
|
||
|
||
给大家10分钟。记住——今天的目标不是功能完美，是**核心体验OK**。功能可以下节课再加，但核心体验必须今天验证通过！
|
||
|
||
【教师巡场观察，重点关注：】
|
||
- 学生是否真的在体验自己的作品，还是只看了一眼就说"好了"
|
||
- 学生的修改意见是否具体（"飞船移动太快"vs"不好玩"）
|
||
- 是否有学生开始加V2功能了（M2）→ 引导回到核心体验验收
|
||
- 做得特别好的学生 → 让他们帮助还在调试的同学
|
||
- 做得特别困难的学生 → 提供保底方案（见AI助教使用指南）
|
||
|
||
**进度同步 (Checkpoint):**
|
||
|
||
**师：** 最后一分钟！你的核心体验验收通过了吗？用手势告诉我：
|
||
- 竖大拇指👍 = 核心体验OK，基本满意
|
||
- 平手✋ = 差不多但还有问题
|
||
- 往下👎 = 还跑不起来
|
||
|
||
【快速统计】
|
||
|
||
**【分支A】若大部分学生竖大拇指：**
|
||
**师：** 太棒了！你们今天完成了一件非常了不起的事——从零开始，写文档、交给AI开发、验收核心体验。这就是真正的产品开发流程！
|
||
|
||
**【分支B】若不少学生是平手：**
|
||
**师：** 差不多了！核心玩法有了但还需要调，这非常正常。下节课的主题就是"用户体验与产品发布"——专门帮你打磨这些不完美的地方。今天最重要的是你已经有了一个能跑的核心版本！
|
||
|
||
**【分支C】若有学生往下：**
|
||
**师：** 没关系！有些项目确实更复杂一些。下节课我们会继续。今天你完成了最重要的一步——写出了需求文档，知道了自己到底想做什么。这比盲目让AI做一堆东西有价值多了。
|
||
|
||
---
|
||
|
||
**第三幕：反思 (Contemplate) — 10分钟** 🤔
|
||
|
||
**【环节】成果展示 (6分钟)**
|
||
|
||
**师：** 展示时间！今天的展示跟以前不一样——我不只想看你的作品，我还想看你的**需求文档**。请2-3位同学上来，先展示你的一页纸需求文档，再展示AI做出来的作品。告诉我们：
|
||
|
||
1. 你选了什么方向？为什么？
|
||
2. 你的核心玩法一句话是什么？
|
||
3. AI做出来的跟你文档里写的一样吗？有什么不一样？
|
||
|
||
【请2-3位学生展示，优先选择：】
|
||
- 一位文档写得特别清晰、AI产出质量高的（正面案例）
|
||
- 一位方向选择独特的（鼓励创意）
|
||
- 一位经历了修改调试过程的（体现韧性力）
|
||
|
||
**师：** 大家注意看——他/她的需求文档写得很清楚，所以AI做出来的东西基本对了。这就是"先想清楚再做"的威力！
|
||
|
||
**【环节】互评与讨论 (4分钟)**
|
||
|
||
**师：** 看了这几位同学的展示，谁有问题或建议？格式是"一个优点 + 一个建议"。
|
||
|
||
【请2-3位学生互评】
|
||
|
||
**师：** 我想问大家一个反思问题——今天的体验跟第5课"一句话做游戏"有什么不同？【诊断点：学生能否感受到"有文档"vs"无文档"的差异】【迁移层】
|
||
|
||
**【分支A】若学生说出"这次想得更清楚""做出来更接近想要的"：**
|
||
**师：** 完全正确！这就是"产品设计思维"——先想清楚再做，比随便做一个再改要高效得多。
|
||
|
||
**【分支B】若学生说"写文档有点麻烦"：**
|
||
**师：** 确实多花了10分钟写文档。但你想想——有了文档，AI一次做出来就八九不离十；没有文档，你可能要跟AI来回改五六轮。哪个更快？
|
||
|
||
**【分支C】若学生说不出区别：**
|
||
**师：** 第5课你只说了一句话，AI猜着做。今天你写了一页纸的"说明书"，AI按照说明书做。结果是不是更接近你想要的？这就是区别——说得越清楚，AI做得越准。
|
||
|
||
---
|
||
|
||
**第四幕：延续 (Continue) — 5分钟** 🚀
|
||
|
||
**【环节】抽象总结 (3分钟)**
|
||
|
||
**师：** 今天我们学了三个核心知识点，我帮你们串起来——
|
||
|
||
**第一：** 每个好产品都有一个"核心循环"——用户做什么 → 系统反馈什么 → 为什么还想用。不管是游戏、工具还是App，都有这个循环。
|
||
|
||
**第二：** 开始做项目之前，先写一份"需求文档"——想清楚做什么、给谁用、核心体验是什么、先做哪些功能。
|
||
|
||
**第三：** MVP优先——先做最核心的功能，确认体验OK了，再加其他功能。不要一口气塞太多东西。
|
||
|
||
**师：** 这三个知识点不只在AI编程里有用。以后你做任何事情——写作文、做PPT、策划活动——都可以先问自己："核心是什么？先做什么后做什么？"这就是"设计思维"。【迁移诊断】
|
||
|
||
**【环节】下节预告 + 5分钟挑战 (2分钟)**
|
||
|
||
**师：** 下节课预告——第8课的主题是"用户体验与产品发布"。你今天做的MVP版本还有很多可以优化的地方：界面美化、难度平衡、胜利/失败反馈……下节课我们会把你的作品从"能用"升级到"好用又好看"，最后做成一个可以分享给朋友的版本！
|
||
|
||
**师：** 本周的5分钟挑战来了！
|
||
|
||
**5分钟AI挑战：** 打开你今天做的项目，自己玩/用至少3分钟。然后在你的需求文档背面写下"我最想加的一个V2功能"和"为什么加这个功能能让体验更好"。拍照发到班级群。下节课你就要把这个功能真的做进去！
|
||
|
||
**师：** 记住——今天你完成了一件专业产品经理才做的事：写需求文档→交给开发团队（AI）→验收核心体验。你们不只是在学编程，你们在学"怎么把想法变成现实"！下课！
|
||
|
||
---
|
||
|
||
### 5. AI助教使用指南
|
||
|
||
**教师演示用提示词：**
|
||
|
||
**课前准备——生成示范项目（太空躲避大师）：**
|
||
```
|
||
请帮我用HTML/CSS/JS开发一个叫"太空躲避大师"的小游戏，要求如下：
|
||
|
||
## 项目信息
|
||
- 目标用户：想在课间玩两分钟的小学生
|
||
- 视觉风格：像素风格，深蓝色太空背景，白色星星点缀
|
||
|
||
## 核心玩法
|
||
玩家用键盘左右方向键控制一架飞船在屏幕底部移动，陨石从屏幕顶部随机位置往下掉落。玩家需要躲避陨石，碰到陨石就游戏结束。
|
||
|
||
## MVP功能（只做这些）
|
||
1. 飞船可以用左右方向键移动，不能移出屏幕
|
||
2. 陨石从屏幕顶部随机位置不断掉落，速度适中
|
||
3. 飞船碰到陨石→游戏结束，屏幕中央显示"游戏结束！"和存活秒数
|
||
4. 有一个"重新开始"按钮
|
||
|
||
## 技术要求
|
||
- 单个HTML文件，内联CSS和JS
|
||
- 使用Canvas绘制游戏画面
|
||
- 游戏区域800x600像素，居中显示
|
||
- 适配电脑浏览器
|
||
```
|
||
|
||
**学生保底提示词（当学生完全不知道怎么写时）：**
|
||
|
||
**保底方案A：动作游戏**
|
||
```
|
||
请帮我用HTML/CSS/JS做一个简单的躲避游戏。玩家用方向键控制一个角色在屏幕底部左右移动，障碍物从上面不断掉落，碰到就游戏结束，显示分数和重新开始按钮。单个HTML文件，使用Canvas。
|
||
```
|
||
|
||
**保底方案B：益智游戏**
|
||
```
|
||
请帮我用HTML/CSS/JS做一个记忆翻牌游戏。屏幕上有8张牌（4对），正面朝下。点击翻开一张牌，再点击翻开第二张，如果两张一样就保持翻开，不一样就翻回去。全部翻开就获胜，显示用了多少次。单个HTML文件。
|
||
```
|
||
|
||
**保底方案C：实用工具**
|
||
```
|
||
请帮我用HTML/CSS/JS做一个简单的倒计时器。用户可以设置分钟数（1-60分钟），点"开始"就倒计时，到0的时候屏幕变红色并显示"时间到！"。有暂停和重置按钮。单个HTML文件。
|
||
```
|
||
|
||
---
|
||
|
||
**进阶提示词（学有余力的学生）：**
|
||
```
|
||
在我的需求文档基础上，请帮我增加以下体验优化：
|
||
1. 添加开场画面：显示游戏名称和"按空格键开始"
|
||
2. 给核心操作添加音效反馈（用Web Audio API生成简单音效，不需要外部文件）
|
||
3. 添加简单的粒子效果（比如碰撞时的爆炸粒子）
|
||
请在现有代码基础上修改，不要重新写。
|
||
```
|
||
|
||
---
|
||
|
||
### 6. 教师指南
|
||
|
||
**本课技术备注：**
|
||
|
||
1. **Canvas游戏开发的基本原理（教师理解用）：** HTML的`<canvas>`标签提供一块画布，JavaScript通过"游戏循环"（requestAnimationFrame）每帧重新绘制画面。这是浏览器游戏的标准做法。学生不需要理解这些，只需要通过需求文档描述想要的效果。
|
||
|
||
2. **关于"单个HTML文件"的技术限制：** 单文件可以做的游戏/工具比想象的多——躲避游戏、翻牌游戏、打砖块、计算器、倒计时器、闪卡应用等都完全没问题。但复杂的策略类游戏（如塔防）在单文件中可能代码量较大，AI生成质量会下降。如果有学生选了策略类，建议引导他们先做一个极简版本。
|
||
|
||
3. **AI生成游戏常见问题：** 碰撞检测不精确（让学生描述现象，AI通常能调整）；Canvas尺寸问题（提示词中加"游戏区域固定800x600像素，居中显示"）；键盘事件失焦（提醒学生"先点一下游戏画面"）；帧率不稳（减少画面元素数量）。
|
||
|
||
4. **需求文档到提示词的转换：** 纸质文档帮学生理清思路，发给AI的提示词需更结构化。关键：①"核心玩法一句话"展开为具体交互描述；②MVP功能列表直接作为开发要求；③加上技术约束（单文件、Canvas等）。
|
||
|
||
5. **方向选择预期分布：** 大部分四年级学生会选游戏类（约60-70%），工具和学科应用各约10-15%，创意展示约5-10%。分布正常，不需要强制均衡。
|
||
|
||
**常见问题 FAQ：**
|
||
|
||
| 学生问题 | 应对方式 |
|
||
|---------|---------|
|
||
| "我不知道选什么方向" | "你课间最喜欢干什么？如果你能做一个app，你最想做什么？"——从兴趣出发引导。如果实在选不出来，建议选"动作类游戏-躲避游戏"，因为结构简单、AI生成质量高 |
|
||
| "我想做的东西AI能做出来吗？" | "你先把想法写在需求文档上，我们一起看看。如果太复杂，我们可以简化MVP——先做最核心的部分" |
|
||
| "需求文档怎么写核心玩法一句话？" | 用脚手架句式："玩家/用户（做什么动作），系统（怎么反馈），让人想继续因为（什么原因）"。先口头说一遍，然后写下来 |
|
||
| "AI做出来的跟我文档里写的不一样" | "哪里不一样？具体描述出来，然后告诉AI修。这就是验收——对照文档一项一项检查" |
|
||
| "我想加更多功能！" | "你的核心玩法好玩吗？先确认核心体验OK。就像做蛋糕——蛋糕本身不好吃，加再多奶油也救不了" |
|
||
| "能做手机游戏吗？" | "我们现在做的是网页版，在电脑浏览器里玩。但是——手机浏览器也能打开！如果你想让手机也能玩，可以在需求文档里加'适配手机触屏操作'" |
|
||
| "我的游戏/工具完全跑不起来" | 先检查：①提示词是否包含"单个HTML文件"；②是否指定了技术方案（Canvas等）；③描述是否太模糊。如果都没问题，用保底提示词重新生成一个基础版本 |
|
||
|
||
**课堂风险预案：**
|
||
|
||
- **如果AI服务不可用：** 本课前半段（分段一、二）完全不依赖AI——学生可以正常分析核心循环、写需求文档。如果后半段AI仍然不可用，将分段三改为"完善需求文档+互相审阅文档"，把AI开发推迟到下节课。
|
||
- **如果学生进度差异过大：** 快的学生进入验收和迭代阶段；慢的学生使用保底提示词快速生成基础版本。关键是每个学生都要完成需求文档——即使今天没来得及让AI开发，文档本身就是有价值的学习产出。
|
||
- **如果有学生完全不想写文档（M1顽固型）：** 让他先不写文档，直接用一句话让AI做。做完后跟写了文档的同学对比产出——用事实说服，比强制要求更有效。
|
||
- **如果AI生成的游戏/工具有严重Bug：** 这本身就是教学机会。引导学生用第4课学的Bug描述三要素来修复。如果Bug太严重无法修复，使用保底提示词重新生成。
|
||
|
||
---
|
||
|
||
### 7. 5分钟日常AI挑战
|
||
|
||
**本周挑战：V2功能提案**
|
||
|
||
打开你今天做的项目，自己认真玩/用至少3分钟。然后在你的需求文档背面写下：
|
||
|
||
1. **我最想加的一个V2功能是什么？**（只写一个！）
|
||
2. **为什么加这个功能能让体验更好？**（用核心循环的思路回答——它能让"做动作→得反馈→想继续"的循环更强吗？）
|
||
3. **这个功能用一句话怎么描述给AI？**（提前写好下节课直接用）
|
||
|
||
拍照发到班级群。下节课你就要把这个功能真的做进去！
|
||
|
||
**评选标准：**
|
||
- 功能是否真的能提升核心体验（而不是"锦上添花"）
|
||
- 描述是否清晰具体（AI看了就能做）
|
||
|
||
---
|
||
|
||
### 8. 拓展任务
|
||
|
||
**拓展一（推荐）：核心循环分析师**
|
||
|
||
选3个你喜欢的游戏或App，用"核心循环三问"分析它们：
|
||
- 玩家/用户做什么？
|
||
- 系统反馈什么？
|
||
- 为什么还想玩/用？
|
||
|
||
把三个循环写下来，对比它们的异同——不同类型的产品，核心循环有什么不一样？
|
||
|
||
**拓展二（挑战）：竞品分析**
|
||
|
||
如果你选了游戏方向，找一个跟你的游戏类似的经典游戏（比如你做躲避游戏，就找"Flappy Bird"或"太空侵略者"）。分析它的核心循环，然后思考：
|
||
|
||
- 我的游戏跟它的核心循环有什么相同？有什么不同？
|
||
- 它有哪些功能是我V2/V3可以借鉴的？
|
||
- 我的游戏有没有什么独特的地方是它没有的？
|
||
|
||
把分析结果写在需求文档后面，这就是专业产品经理做的"竞品分析"！
|