` 元素来做粒子。如果学生的游戏明显卡顿，检查是否有粒子数组无限增长的问题（每帧加粒子但不清除），引导学生告诉 AI「粒子消失后从数组里删除」。
+
+**常见问题 FAQ：**
+
+| 问题 | 应对 |
+|------|------|
+| 「动画代码加进去之后，血条不显示了」 | 很可能是 Canvas `clearRect` 的调用顺序被改了，告诉 AI：「加了动画代码后血条不显示，请检查 clearRect 和绘制顺序是否被修改」 |
+| 「音效能响但是每次攻击响很多次」 | `playSound_attack` 函数被错误地放在了 `requestAnimationFrame` 里，每帧都在调用；告诉 AI「音效每次行动只应该播放一次」 |
+| 「死亡动画结束后角色还留在屏幕上」 | 死亡动画只改了透明度，没有在动画结束后将角色标记为「已死亡」并停止绘制；引导学生告诉 AI「动画结束后停止绘制该角色」 |
+| 「特技粒子效果触发一次后就一直在了」 | 粒子系统的「存活时间」逻辑没有实现，粒子永远不消失；告诉 AI「每个粒子有3秒存活时间，时间到了就从数组里移除」 |
+| 「我的重击蓄力动画太慢了游戏变拖沓」 | 这是审美判断问题，直接让学生告诉 AI：「蓄力时间改成 150ms，冲刺时间改成 80ms，感觉更爽快」 |
+| 「Chrome 没有声音」 | 先确认系统音量；再确认是否先点击了游戏页面；最后检查 `AudioContext` 是否在按钮点击后创建 |
+
+**课堂风险预案：**
+- **如果 Kimi 返回的代码加进去运行报错：** 让学生把报错信息复制给 Kimi，提示词格式：「我按你说的把代码加进去了，运行时出现了这个报错：[报错信息]，原来的代码是 [原代码]，请帮我找到原因并给出修正后的代码」
+- **如果学生进度差异过大（有人全部做完有人还没做动画）：** 做完的学生进入拓展任务（给特技加粒子效果 + 调平衡性）；做到一半的学生优先完成动画，音效用保底提示词一步到位
+- **如果整体时间不够（25分钟建构还剩两段没做完）：** 合并分段二和分段三，音效只做三种基础音效（攻击/受击/胜利），特技视觉效果作为课后挑战
+
+---
+
+### 7. 5分钟日常AI挑战
+
+**本周挑战：** 给你的一个特技，设计一个全新的视觉特效
+
+**挑战说明：**
+选你游戏里你最喜欢的一个特技，想象它触发时应该「看起来像什么」——可以是粒子爆炸、颜色变化、屏幕震动、时间静止特效……只要用感觉语言描述出来，告诉 AI 实现。要求：这个特效必须和课上做的不一样，完全是你自己的设计。
+
+**下节课分享：** 下周课上选 2-3 位同学展示特技特效挑战成果，说明自己是怎么描述感觉的，AI 实现了几轮才满意。
+
+---
+
+### 8. 拓展任务
+
+**拓展一（推荐）：屏幕震动特效**
+重击时，不只是角色抖动——整个游戏画布轻微震动一下（Canvas 偏移 ±5 像素，持续 200ms）。这种效果叫「屏幕震动（Screen Shake）」，是格斗游戏的经典手法。用感觉描述让 AI 实现：「重击时整个画面抖一下，像相机被猛地推了一把」。
+
+**拓展二（挑战）：行动预判音效**
+在角色攻击「蓄力」阶段播放一个低频「嗡——」的充能音效，攻击命中时再播放冲击音效——两段音效组合，制造出「蓄力→爆发」的完整听觉体验。提示：需要两个 Web Audio 函数，第一个在蓄力开始时调用，第二个在命中时调用，注意时机控制。
+
+---
+
+### 附：本课核心教学框架速查
+
+**四幕时间分配（合计 90 分钟）：**
+
+| 幕 | 内容 | 时长 |
+|----|------|------|
+| 联系 Connect | 对比演示无动画 vs 有动画，引出「游戏感」 | 10 分钟 |
+| 建构 · 分段一 | 感觉语言描述动画，写增量需求 | 20 分钟 |
+| 建构 · 分段二 | 用代码合成音效，整合进战斗行动 | 20 分钟 |
+| 建构 · 分段三 | 特技视觉标记完善 + 平衡性微调 | 15 分钟 |
+| 反思 Contemplate | 成果展示 + 感觉描述回顾 + 互评 | 10 分钟 |
+| 延续 Continue | 抽象总结三件事 + 预告班级对战 + 挑战发布 | 5 分钟 |
+
+**本课核心能力训练路径：**
+
+```
+审美力路径：
+无动画体验（识别层）
+→ 用感觉描述动画/音效需求（理解层）
+→ 对比 AI 输出和自己预期，定位差距（应用层）
+→ 精准迭代修改，达到满意（迁移层）
+
+提问力路径：
+理解增量需求的必要性（识别层）
+→ 只写新增部分的提示词，不重写全局（理解层）
+→ 在已有代码基础上定向追加功能（应用层）
+```
+
+**关键词速查（下课前可口头检查学生是否能解释）：**
+- 游戏感（Game Feel）：每次操作都有视觉/听觉反馈，让玩家感受到行动生效
+- 增量需求：在已验收代码基础上只描述新增部分，避免 AI 误改
+- Web Audio API：浏览器内置音频引擎，用代码合成声音，无需音频文件
+- 感觉语言：用描述体验和画面感的词汇提需求，而非技术参数
diff --git a/3-lessons/AICODE-06/AICODE06-11 涂鸦PK（四）— 班级锦标赛.md b/3-lessons/AICODE-06/AICODE06-11 涂鸦PK（四）— 班级锦标赛.md
new file mode 100644
index 0000000..c13cb20
--- /dev/null
+++ b/3-lessons/AICODE-06/AICODE06-11 涂鸦PK（四）— 班级锦标赛.md
@@ -0,0 +1,599 @@
+---
+课时: 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 的 `