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 秒，让兴奋感发酵】

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

【投屏展示代码片段】

// 角色数据写死在代码里
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 获胜

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