AICODE2026/3-lessons/AICODE-06/AICODE06-11 涂鸦PK（四）— 班级锦标赛.md

---
课时: 11
主题: 涂鸦PK（四）— 班级锦标赛
核心能力: [表达力, 共创力]
核心工具: [Trae IDE, Kimi]
时长: 90分钟
透明化层级: 结果层
适用路线: AICODE-06
---

### 1. 课程目标

**知识目标：**
- 理解「数据驱动设计」的核心思想：角色数据与游戏代码分离，加新角色只需加文件，代码不用改
- 理解角色选择界面是「数据读取 + UI 展示」的组合，而非把所有角色写死在代码里
- 理解路演的核心是「设计决策」而非「功能列表」：说清楚「为什么这样做」比「做了什么」更有价值

**能力目标：**
- 能用增量需求文档描述 roles 系统，并经过窗口B审核、窗口C执行（共创力）
- 能在班级锦标赛中用语言分析胜负原因，做出有依据的复盘（表达力）
- 能按「展示角色→设计意图→精彩瞬间→设计复盘」结构完成3分钟路演（表达力）

**情感目标：**
- 感受到「自己的角色和全班的角色一起对战」的真实社交激励
- 建立「输了是迭代的起点」而非「输了说明设计失败」的成长心态
- 对「数据和代码分离」产生直觉性认同——这是真实工程师的设计方式

---

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

**核心概念认知层级：**

| 概念 | 学生类比 | 认知层级 |
|------|---------|---------|
| 数据驱动设计 | 游戏皮肤系统——你换皮肤不需要重新下载整个游戏，皮肤是「数据」，游戏逻辑是「代码」，两者分离 | 理解层 |
| 硬编码 | 把菜单直接印在餐厅墙上——想加一道菜要重新刷墙 | 识别层 |
| roles 系统 | 班级花名册——班里来了新同学，只需要在花名册上加一行，不需要改班级的所有规则 | 理解层 |
| 增量需求 | 在已有房子里加一个房间——不是推倒重建，而是在现有结构上扩展 | 应用层 |
| 路演设计决策 | 苹果发布会不说「这个手机有摄像头」，而是说「为什么这个摄像头改变了拍照方式」 | 应用层 |

**典型误概念表：**

| 编号 | 误概念 | 正确认知 | 激发策略 |
|------|--------|---------|---------|
| M1 | 加新角色需要改代码 | 数据驱动设计：加一个 json 文件 = 加一个角色，代码不用改 | 演示：不改一行代码，只在 roles/ 文件夹里加一个新 json，新角色就出现在选择界面 |
| M2 | 路演就是说「我做了什么功能」 | 路演要说「我为什么这样设计」——设计决策比功能列表更有价值 | 类比苹果发布会：发布会不说「手机有摄像头」，而是说「为什么这颗摄像头改变了拍照方式」 |
| M3 | 属性随便分的角色不可能赢认真分的 | 「奇怪」的属性分配有时会产生意外的克制效果；游戏平衡比绝对强度更重要 | 展示一个「全部堆 HP」的坦克型角色用消耗战赢了「全部堆 ATK」的爆发型角色 |
| M4 | 输了说明自己设计失败了 | 输了是迭代的起点；「如果重来属性怎么分」才是最有价值的问题 | 强调：世界上最厉害的游戏设计师也在持续迭代，没有「一次设计就完美」的 |

---

### 3. 教学准备

**工具与环境：**
- 每台电脑已安装 Trae IDE，第10课的战斗游戏项目可以正常运行
- 每台电脑有学生自己的角色图片（.png）和角色数据（.json）
- 投影可切换至任意学生屏幕，用于锦标赛投屏
- 教师电脑预建好 `roles/` 文件夹结构（用于演示数据驱动）

**教师备课必做（课前）：**
> 1. 提前向每位学生收集角色文件（角色名.png + 角色名.json），放入教师电脑 `roles/` 文件夹
> 2. 在教师电脑上跑一遍 roles 系统生成流程，确保角色选择界面正常读取所有角色
> 3. 准备好「花名册投屏」：一个展示全班角色名字 + 特技的页面或截图
> 4. 准备好锦标赛对阵表（单淘汰制，根据班级人数提前画好括号）
> 5. 备用方案：如果 roles 系统生成失败，手动在代码里加角色选择下拉菜单（15分钟内可完成）

**教学资源：**
- 教师准备：全班 roles/ 文件夹（含所有 png + json）
- 教师准备：锦标赛对阵表（投屏用）
- 教师准备：保底提示词（见第5节）
- 学生资源：第10课的战斗游戏项目文件（index.html）

---

### 4. 教学流程

---

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

*本幕目标：用「角色花名册」制造全班兴奋感，引出数据驱动概念，建立「今天是全班大乱斗」的期待*

**【环节】角色花名册 + 今日导入 (10分钟)**

**师：** 课前我收集了大家的角色文件。我现在打开，给大家看看今天的「选手花名册」。

【投屏展示花名册——所有角色的名字、HP/ATK/DEF/SPD 属性、特技名称】

**师：** 你们来数一数，今天一共有多少个角色参赛？

**生：** （数人数）……XX 个！

**师：** XX 个角色，今天全部都要上场对战。谁是最强的？我们今天锦标赛见真章。

【停顿 3 秒，让兴奋感发酵】

**师：** 但我现在遇到一个问题。大家的游戏现在只能用「硬编码」的两个角色。什么叫硬编码？就是角色数据直接写死在代码里，像这样——

【投屏展示代码片段】

```javascript
// 角色数据写死在代码里
const player = { name: '章鱼怪', hp: 80, atk: 15, def: 5, spd: 8 };
```

**师：** 这种写法，想换一个角色，要去代码里改数字。想加一个新角色，要再写一段代码。如果班里有 8 个角色要互相打，要改多少次代码？
【识别层：让学生感受到硬编码的局限性】

**生：** （预期：很多次……要改来改去）

**师：** 对，非常麻烦。今天我们要做一件事——用「数据驱动」的方式重新设计这个系统。做完之后，加新角色只需要加一个 json 文件，代码一行都不用改。我们先做好这个系统，然后——锦标赛开始。

【诊断点：学生是否感受到「数据驱动」和「硬编码」的差别，还是觉得无所谓】【识别层】

**【分支A】若学生问「数据驱动是什么意思」：**
**师：** 你知道游戏皮肤吗？比如王者荣耀，你换一个皮肤，不需要重新下载整个游戏对吧？皮肤就是「数据」，游戏逻辑是「代码」，两个东西分开存放。我们今天就是要把角色数据从代码里分离出来，放进独立的 json 文件。

**【分支B】若学生觉得「改代码也没什么，反正能跑」：**
**师：** 如果你做的游戏将来要卖给别人，需要经常更新角色，每次更新都要改代码，那维护成本是很高的。数据驱动就是为了让「扩展」变得简单——这是真实游戏公司的标准做法。

---

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

*本幕目标：完成 roles 系统（数据驱动角色选择）；举办班级锦标赛*

---

**【分段一：roles 系统——数据驱动设计实战】(20分钟)**

**预设误概念：**
- 误概念 M1：加新角色需要改代码（核心要破除的误概念）
- 学生可能认为「从文件夹读取 json」很难实现，需要很复杂的代码

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

**师：** 现在我们用三个窗口来完成这个系统。还记得三窗口原则吗？

**生：** （预期：窗口A写需求，窗口B审核，窗口C执行）

**师：** 对。今天的需求是「增量需求」——不是从头做，而是在现有战斗游戏上加一个新模块。我先给大家看增量需求文档长什么样。

【投屏展示增量需求文档内容，逐条讲解】

**师：** 这份需求文档有四条核心要求。我来念一遍：
第一，从 roles/ 文件夹读取所有 .json 文件，每个文件包含 name、hp、atk、def、spd、skill 字段。
第二，显示角色选择界面：左边选玩家角色，右边选 AI 角色，每个角色显示名字和属性。
第三，有「开始战斗」按钮，点击后进入战斗，加载选中角色对应的同名 .png 作为 Spritesheet。
第四，不需要重写整个游戏——只增加角色选择这一层，原来的战斗逻辑不动。

**师：** 注意最后一条——「不重写整个游戏」。这就是增量需求的核心。我们不推倒重来，我们在现有基础上扩展。

现在我演示一下最重要的一步——数据驱动设计的关键代码思路。

【投屏展示两种写法对比】

```
硬编码方式（现在）：
代码里直接写 { name: '角色A', hp: 80, atk: 15 ... }
→ 想加角色：改代码

数据驱动方式（今天要做）：
读取 roles/角色A.json → 代码只负责读取，不存储数据
→ 想加角色：在 roles/ 文件夹里加一个新 json 文件，代码不变
```

**师：** 看到区别了吗？现在窗口A的需求文档大家已经看到了，我们直接去窗口B审核。

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

【教师打开窗口B（新的 Kimi 对话），投屏展示审核提示词】

**师：** 窗口B的提示词是——

```
你是一个严格的需求审核工程师。我有一份增量需求文档，请找出其中可能的漏洞和没说清楚的地方。每个问题单独列出来，只问问题，不给解决方案。

需求文档：
[粘贴增量需求内容]
```

**师：** 大家现在把窗口B打开，把这个提示词加上你自己的增量需求，提交审核。我来演示一遍，你们同步做。

> 教师同步演示窗口B审核过程，投屏展示 AI 找出的问题（如：roles/ 文件夹里没有 png 文件只有 json 怎么处理？同一个角色能选两次吗？）

**师：** AI 找到了这几个问题。大家对照一下，你的窗口B找到了什么问题？

**生：** （预期：找到类似问题，或发现自己的需求文档有遗漏）

**师：** 好，把 AI 问的问题答案补充进需求文档。然后开窗口C执行。窗口C的提示词见屏幕。

【投屏展示保底提示词，学生复制使用】

> 教师巡视：谁的屏幕 3 分钟没变化就主动过去。重点关注窗口C是否用了「只输出新增/修改的代码」指令，避免 AI 重写整个游戏。

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

**师：** 谁的角色选择界面已经出来了？截图或者展示屏幕。

【让 1-2 位学生展示屏幕】

**师：** 你试试——现在不改一行代码，把一个新的 json 文件放进 roles/ 文件夹，刷新页面，新角色出现了吗？
【诊断点：验证学生是否真正实现了数据驱动，而不只是在选择界面里把角色名字硬编码进去】【应用层】

**【分支A】若角色自动出现了：**
**师：** 这就是数据驱动。你的代码现在可以无限扩展角色，不需要碰代码本身。这是真实游戏公司的标准做法。

**【分支B】若角色没有自动出现（角色名写死在选择界面里）：**
**师：** 看一下你的选择界面代码，角色名是直接写在 HTML 里还是从文件里读的？如果是写在 HTML 里，说明还是硬编码，需要让 AI 改成读取 json 文件的方式。提示词这样说：「我的角色选择界面现在是把角色名硬编码在 HTML 里的，请改成从 roles/*.json 文件里读取，动态生成选择列表。」

**【分支C】若 AI 把整个游戏重写了：**
**师：** 这是常见的情况——AI 有时候会把整个代码重写一遍。发现这个情况后，告诉 AI：「请不要重写整个游戏，只输出 roles 系统的新增部分，我自己复制进去。」然后把新增部分手动粘贴到原来的代码里。

---

**【分段二：班级锦标赛——全班大乱斗】(30分钟)**

**预设误概念：**
- 误概念 M3：属性随便分的角色不可能赢认真分的
- 误概念 M4：输了说明自己设计失败了

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

**师：** roles 系统已经完成了。现在游戏可以选任意角色对战了。我们正式开始今天的班级锦标赛！

【投屏展示锦标赛对阵表】

**师：** 规则说明。单淘汰赛制。每场对战：一方选自己的角色，另一方选自己的角色，战斗5回合。5回合后谁 HP 多谁赢；如果有一方 HP 归零，提前结束。每场大约 2-3 分钟。赢的人晋级，输的人直接进入路演准备。

**师：** 在每场开始之前，我会给大家介绍两个角色的属性和打法，然后问你们——你们觉得谁会赢？

**师：** 有没有问题？

> 如果学生有问题，简短回答；如果没有，直接开始第一场

**学生实践 (Practice): (25分钟)**

【锦标赛主持逐字稿，每场 2-3 分钟】

**第一场开始前：**

**师：** 第一场对阵：[角色A] vs [角色B]。我来介绍一下这两位选手——

[角色A] 是 [学生名] 设计的，[角色名]，属性是 HP[数字]、ATK[数字]、DEF[数字]、SPD[数字]，特技是[特技名]。从属性看，这是一个[分析：高ATK爆发型 / 高HP坦克型 / 高SPD速攻型]的角色。

[角色B] 是 [学生名] 设计的，[角色名]，属性是 HP[数字]、ATK[数字]、DEF[数字]、SPD[数字]，特技是[特技名]。这是一个[分析]的角色。

你们觉得谁会赢？举手投票——投 [角色A] 的举手……投 [角色B] 的举手……

好，开始！

【由第一个出战的学生上台操作，或者由教师代操，全班围观投屏】

**战斗进行中（教师解说）：**

**师：** 第 1 回合，[角色A] 先手——攻击了 [数字] 点伤害。[角色B] 现在剩 HP [数字]。

**师：** [角色B] 反击……特技触发了！[特技效果]。现在形势[分析]。

**师：** 大家注意这一回合——[角色A] 的 DEF 是 [数字]，所以对方每次攻击被减了 [数字] 点。这就是 DEF 的价值。

**战斗结束后：**

**师：** [赢方角色] 赢了！[学生名] 晋级。

**师：** 分析一下——[赢方角色] 赢的原因是什么？是属性设计好，还是特技时机对，还是单纯运气？

**生：** （预期：因为 HP 多扛住了 / 因为特技打了两次 / 因为 ATK 高秒杀了）

**师：** 对。[具体分析赢的原因]。[输方角色] 输了——如果重来，你觉得属性怎么分会更好？

**生（输方学生）：** （预期：我应该把 DEF 加高一点 / 我应该多加 SPD 先手）

**师：** 这个分析很好。记住这个想法，等会儿路演的时候说出来。

【继续下一场，同样流程】

**半决赛/决赛前：**

**师：** 现在进入[半决赛/决赛]！[角色A] 和 [角色B]，这两位已经赢过了[X]场。来介绍一下他们的战绩——

**师：** [角色A] 在上一场用[什么策略]赢了[谁]。[角色B] 在上一场用[什么方式]赢了[谁]。这场对阵，你们觉得——

**决赛结束后：**

**师：** 恭喜[冠军角色]！[学生名] 拿到今天锦标赛冠军！

**师：** 但我要说一件事——今天冠军不是「最聪明的人」，而是「今天这个对阵顺序下最幸运的人」。如果换一个对阵顺序，冠军可能完全不同。游戏平衡性比绝对强度更重要——这是游戏设计师最核心的命题。

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

**师：** 锦标赛结束了。在进入路演之前，我问大家一个问题：你们觉得，今天的冠军角色「设计得最好」吗？

【诊断点：学生是否理解「赢得比赛」和「设计得好」是两件事，随机因素（对阵顺序）影响结果】【理解层】

**【分支A】若学生说「冠军设计最好」：**
**师：** 如果把今天的对阵顺序换一下，让冠军第一场就对上另一个强角色，他还会赢吗？不一定。所以赢比赛不等于设计最好——游戏平衡设计是一门科学，不是谁 ATK 最高谁就赢。

**【分支B】若学生说「运气成分很大」：**
**师：** 对，你说到一个重点。同样属性的两个角色打十场，赢的次数可能各五场。所以好的游戏设计要让不同风格的角色都有赢的可能，而不是让一种打法通吃所有。这叫「策略多样性」。

---

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

*本幕目标：每人完成3分钟路演，训练「说设计决策」而非「说功能列表」*

**【环节】班级路演 (15分钟)**

**师：** 现在进入路演环节。每个人 3 分钟，包括展示和提问。路演有四段固定内容：

【投屏展示路演结构】

```
第1段（30秒）：展示角色
  说：「我的角色叫 XX，是一个 XX 型，属性分配是……」

第2段（30秒）：设计意图
  说：「我选这个打法是因为……我觉得用 XX 特技可以克制……」

第3段（60秒）：精彩瞬间
  说：「最让我印象深刻的是和 XX 的对战，那一场……」

第4段（60秒）：设计复盘
  说：「如果重来，我会把 XX 调低一点，把 XX 调高……因为我发现……」
```

**师：** 注意——路演不是说「我的角色有什么功能」。路演是说「我为什么这样设计」。这两件事差很多。我来举个例子：

错误示范：「我的角色叫章鱼怪，它有 HP 80、ATK 15、DEF 5、SPD 8，特技是连击。」
正确示范：「我叫它章鱼怪，我把 HP 设高是因为我想让它能扛住对方的连续攻击，用消耗战的方式赢。特技选连击是因为连击在对方 HP 低的时候效果最好，可以一次清掉。」

看到区别了吗？第一个说了什么，第二个说了为什么。

**师：** 好，谁先来？

【6-8人小班建议全员路演；学生逐一路演，教师计时，到 3 分钟给提示】

**路演示例（教师可以第一个先做一遍示范，30秒内）：**

**师：** 我先给大家示范一遍格式。如果我设计了一个角色，我会这样路演——

「我的角色叫石甲龟，是一个防御型角色。HP 设了 100，DEF 设了 20，ATK 只有 5——我知道这样攻击力很弱，但我的想法是：用超高的防御力把对方的输出全部挡掉，靠持久战赢。特技我选了「反弹」——把对方一部分伤害反还给它。最让我印象深刻的是和高 ATK 角色对战，那一场打了整整 5 回合，对方 ATK 30 打在我身上每次只剩 10 点，我靠反弹慢慢把它磨死了。如果重来，我会把 SPD 调高一点，因为我发现先手权在某些情况下比防御更重要——有几场因为后手被秒杀了。」

看到了吗？每一个数字背后都有理由，每一个设计决策都可以说出来。好，现在轮到大家了。谁第一个？

【学生逐一路演，教师计时，到 3 分钟给提示】

**每位学生路演后，教师引导互评：**

**师：** [学生名] 路演完了。谁来给一个「一个优点 + 一个改进建议」？

**生：** （预期：优点是……建议是……）

**师：** 好。[学生名]，你对这个建议怎么看？如果你的下一个版本按照这个建议改，你觉得会怎样？

**生：** （预期：可能会更好 / 但是我担心……/ 我觉得还有另一个问题是……）

**师：** 好，这就是设计思维——不是「改了一定变好」，而是「改了会带来什么新的权衡」。

**学生路演引导词（当学生卡壳时使用）：**

若学生在「设计意图」卡壳：
**师：** 你当时为什么把 HP 设成这个数字？是随机的还是有理由的？

若学生在「精彩瞬间」卡壳：
**师：** 锦标赛里你最紧张的是哪一场？或者最意外的是哪一场？就说那一场。

若学生在「设计复盘」卡壳：
**师：** 你输的那场，对方哪个属性让你最难受？如果把你的属性分配改一下，能不能针对性地克制它？

若学生整体准备不足：
**师：** 好，我给你 30 秒想一下。有一个问题你一定能回答：你和谁打的那一场，最让你印象深刻？说那一场就行。

**路演结束后的整体反思问题：**

**师：** 好，大家都路演完了。我有一个问题——你们今天路演，最难说的是哪个部分？是「展示角色」还是「设计意图」还是「设计复盘」？
【诊断点：学生是否认为「说为什么」比「说是什么」更难，反映其对设计思维的认知层级】【理解层】

**【分支A】若学生说「最难的是设计复盘」：**
**师：** 对，复盘最难。因为复盘要求你承认「我的设计有问题」，然后还要找到具体是什么问题，还要想出怎么改。这个能力叫「反事实推理」——世界上所有的工程师和设计师都在练这个能力。你们今天已经开始练了。

**【分支B】若学生说「最难的是设计意图，因为我当时随便分的」：**
**师：** 没关系，随便分也有设计意图——「我不知道怎么分，所以平均分」本身就是一个决策。下一次你设计角色的时候，在分属性之前先写一句话：「我要做一个什么风格的角色，要克制什么打法」，有了这句话，属性分配就有了方向。

---

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

**【环节】四课主线总结 (3分钟)**

**师：** 最后一个问题——锦标赛结束后，你们觉得游戏平不平衡？有没有某种打法「必赢」？

**生：** （预期：有一点不平衡 / 感觉高 ATK 的更容易赢 / 感觉差不多）

**师：** 游戏平衡是永远做不到「完美」的——哪怕是王者荣耀这种级别的游戏，每个版本也要出「平衡性调整」。你们今天做的游戏也一样，会有某些打法偏强。这是正常的。重要的是你们发现了这个问题，发现了就可以迭代。

好，进入总结。

**师：** 今天是涂鸦 PK 系列的最后一课。我们来回顾一下这四课做了什么——

【投屏展示四课主线总结】

```
第8课：需求文档 → 画图工具
  你用工程流程做了一个工具

第9课：需求文档 → 战斗系统 + 测试验证
  你用数据验证了你设计的规则

第10课：增量需求 → 动画 + 音效
  你用「感觉描述」扩展了系统

第11课：数据驱动 → 角色系统 + 锦标赛
  你让系统可以无限扩展
```

**师：** 但这四课里，你们学到的不是游戏。

你们学到的是——如何把一个想法，变成可以被验证、可以被扩展、可以被迭代的系统。

需求文档让你在动手之前想清楚。
测试验证让你知道自己做的对不对。
增量需求让你在已有基础上扩展，而不是推倒重来。
数据驱动让你的系统可以无限成长，不被代码本身限制。

**师：** 这四件事，就是工程师做事的方式。你们今天用这个方式，做出了一个可以全班对战的游戏。

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

**师：** 下节课，我们开始新的项目。你们在前面学到的这些能力——需求文档、增量迭代、数据驱动——会在接下来的项目里继续用到。

**师：** 本周 5 分钟 AI 挑战——给你的角色设计一个「2.0 版本」：改变属性分配，写下这次你要克制哪种打法，以及你的设计理由。不需要改代码，只需要改 json 文件里的属性数值，然后写一段话说清楚「我为什么这样改」。下节课分享。

---

### 5. AI助教使用指南

**窗口A——增量需求文档模板（教师投屏用）：**

```
增量需求文档 v1.0
项目：涂鸦PK战斗游戏
新增功能：roles 角色选择系统

1. 从 roles/ 文件夹读取所有 *.json 文件
   - 每个 json 包含字段：name, hp, atk, def, spd, skill
   - 如果文件夹为空或读取失败，显示提示信息「暂无角色，请检查 roles/ 文件夹」

2. 战斗开始前显示角色选择界面
   - 左侧：玩家角色列表（从 json 文件读取，动态生成）
   - 右侧：AI 对手角色列表（同上）
   - 每个角色显示名字 + HP/ATK/DEF/SPD 数值
   - 两侧可选同一个角色（允许镜像对战）

3. 选择确认
   - 点击「开始战斗」按钮进入战斗
   - 战斗时加载对应的同名 .png 文件作为角色图片
   - 如果 .png 不存在，使用默认占位图

4. 不修改原战斗逻辑
   - 只新增角色选择这一层
   - 原来的战斗循环、伤害计算、特技逻辑保持不动
```

**窗口C——保底执行提示词（学生直接使用）：**

```
我已有一个 Phaser.js 战斗游戏，两个角色数据现在是硬编码的。
现在我要加角色选择系统：

1. 从 roles/ 文件夹读取所有 *.json 文件
   （每个文件包含 name/hp/atk/def/spd/skill 字段）
2. 显示角色选择界面：左边选玩家角色（列表），右边选 AI 角色（列表）
3. 每个角色显示名字和属性数值
4. 选好后点「开始战斗」进入游戏，加载对应的同名 .png 作为角色图片
5. 如果 .png 不存在，显示默认占位图

只输出新增/修改的代码部分，不要重写整个游戏。
在代码里加注释说明每段新增代码的作用。
```

**路演辅助提示词（给路演准备不足的学生）：**

```
我的游戏角色数据是：
名字：XX
HP=[数字], ATK=[数字], DEF=[数字], SPD=[数字]
特技：[特技描述]

在班级锦标赛中，我赢了[X]场，输了[X]场。

帮我用 3 个问题引导我做「设计复盘」——只问问题，不给答案。
```

**进阶提示词（给完成基础任务、想进一步扩展的学生）：**

```
我的角色选择系统已经完成了。现在我想加一个「角色详情」功能：
点击角色卡片时，弹出一个详情面板，显示：
1. 角色大图（放大版的 .png）
2. 属性条形图（HP/ATK/DEF/SPD 各用一条进度条表示，满分100）
3. 特技说明（从 json 里读取 skill 字段，格式化显示）
4. 「选择此角色」按钮

只输出新增代码，不改变现有的选择界面逻辑。
```

---

### 6. 教师指南

**本课技术备注：**

**关于浏览器无法直接读取本地文件夹的问题：**

浏览器出于安全原因，无法用 `fetch('roles/角色.json')` 直接读取本地文件夹（会报 CORS 错误）。解决方案：
- 方案A（推荐）：用 Trae IDE 的本地服务器功能启动项目（Trae 内置 Live Server，自动解决 CORS 问题）
- 方案B：让 AI 生成一个简单的 Node.js 本地服务器（`node server.js`），在本地 8080 端口提供文件服务
- 方案C（备用）：改为手动列出所有角色文件名，用 `Promise.all` 批量 fetch（避免了「自动扫描文件夹」的需求，但需要每次加新角色时在列表里加一个文件名）

**备课时务必先在 Trae 里跑通，确认本地服务器正常。**

**关于 Phaser.js 动态加载 Spritesheet：**

Phaser 的 `this.load.spritesheet()` 需要在 `preload()` 阶段调用，不能在游戏运行时动态加载。如果 AI 生成的代码在 `create()` 里加载图片，会报错。解决方案：提示词加上「角色图片需要在 preload 阶段加载，请用 scene.restart() 重新启动场景来实现动态切换角色」。

**锦标赛组织 FAQ：**

| 问题 | 应对 |
|------|------|
| roles 系统没做好，无法进行锦标赛 | 退回到手动改代码换角色，每场由教师提前改好对应角色的数据，坚持锦标赛进行 |
| 某位学生的角色文件损坏/无法加载 | 临时用教师提前准备的备用角色文件替换 |
| 6人以下小班（如只有4人）| 改为双败赛制（输两场才淘汰），增加对战场次 |
| 学生对结果强烈不满（认为Bug导致输了）| 认可情绪，说「你可以在5分钟挑战里设计2.0版本，下次来复仇」 |
| 路演时学生只说功能不说设计意图 | 用引导词打断：「等等，你刚才说了做了什么。现在告诉我，你为什么这样做？」 |

**路演控时技巧：**
- 用手机计时，3分钟倒计时给学生看
- 到2分30秒时轻声提醒：「还有30秒」
- 如果学生还没到「设计复盘」环节，可以跳过「精彩瞬间」直接问：「如果重来你会怎么改？」
- 互评限时 30 秒：「一个优点，一个建议，简短说」
- 路演顺序建议：冠军最后一个路演，制造节奏感；输了第一场的同学第一个路演，减少等待焦虑

**关于「数据驱动设计」的深度追问（给理解快的学生）：**

如果有学生问「为什么要把数据和代码分开，直接写在代码里不是更方便吗？」，这是一个很好的问题，可以这样回答：

「当你只有 2 个角色的时候，写死在代码里确实更方便。但当你有 100 个角色的时候呢？当别人也要给你的游戏加角色的时候呢——你要让他改你的代码吗？数据和代码分离，是为了让扩展和维护变得容易。这个原则不只在游戏里，几乎所有的软件系统都在用——数据库、配置文件、皮肤系统，都是同一个思路。」

**锦标赛后的班级文化建立：**

锦标赛不是为了分出高下，是为了制造「真实战斗测试」的场景。建议在锦标赛结束后强调：
- 不设「最强角色」称号，只设「冠军」（今日锦标赛冠军，不代表绝对最强）
- 鼓励「最有创意设计」：给属性分配最特别、最有设计理由的角色点名表扬
- 鼓励「最佳复盘」：在路演中，给复盘最到位、最有具体改进方案的同学点名表扬

**课堂风险预案：**
- 如果 Trae 本地服务器启动失败：切换到 Kimi 直接生成 HTML，不依赖本地服务器
- 如果锦标赛时间不够（roles 系统做得慢）：缩减锦标赛场次，只打半决赛 + 决赛（两场）
- 如果进度差异过大（有学生roles系统5分钟做完，有学生20分钟还没做好）：先完成的学生做进阶任务（角色详情弹窗），帮进度慢的学生看报错

---

### 7. 5分钟日常AI挑战

**本周挑战：** 给你的角色设计「2.0 版本」

**挑战说明：**
打开你角色的 json 文件，修改属性数值，设计一个新版本。要求写一段话（3-5句）说清楚三件事：
1. 你改了哪些属性，改成了什么数字
2. 这次你想克制哪种打法（比如：克制高 ATK 爆发型 / 克制高 SPD 速攻型）
3. 你觉得这样改会带来什么新的弱点

不需要跑代码验证，只需要写出「设计意图」。

**下节课分享：** 下周课上选 2-3 位同学分享「我的 2.0 设计方案」，其他同学判断：这个改动真的能克制目标打法吗？

---

### 8. 拓展任务

**拓展一（推荐）：角色详情卡**

在角色选择界面里，给每个角色加一个「详情」功能：点击角色名字时，弹出一个小面板，用条形图显示 HP/ATK/DEF/SPD 的比例关系（满分100的进度条），让玩家在选角色前能直观对比属性强弱。

提示：条形图可以用 HTML 的 `<progress>` 标签，或者用 CSS 的 `width` 百分比实现。

**拓展二（挑战）：战斗回放摘要**

每场战斗结束后，自动生成一段「战斗日志」：记录关键回合（如特技触发、HP 归零）的文字摘要。格式参考：

```
第3回合：章鱼怪特技「连击」触发，对火焰鸟造成双倍伤害 28 点
第5回合：火焰鸟 HP 归零，章鱼怪以 HP 34 获胜
```

这个功能需要在战斗循环里加「事件记录」逻辑，是真正的功能扩展挑战。