项目一 · 已完结
魔法竞技场
项目一：把PVP竞技场搭起来——好的部分和卡住的部分
好的部分：学生在没人提"prompt engineering"这个词的情况下，自己撞上了它。第一次写"帮我做计分系统"，AI给了一个泛泛的方案；改成"帮我做命令方块计分系统，杀死对方加1分，记分板显示在屏幕右边，到5分显示胜利信息"，立刻好了一档。我没解释，他自己说："哦怎么问决定了答案的质量。"
第一次让他debug：一开始的描述方式是"它不行""有bug"。我让他换成"我期望X但实际是Y，操作步骤是Z"——再扔给AI，立刻能修。这是项目一最值得记录的一个能力转化点。
Lesson
Debug就是描述差异——"期望X / 实际Y / 怎么复现"是个万能模板。学生学到的不是Minecraft，是怎么把模糊不满意翻译成可操作信号。
遇到的坑 · 项目一最大痛点
手动debug循环——AI不能自我闭环
整个项目一的工作流是：跟AI描述 → AI给命令 → 学生手动复制进MC → 进游戏测 → 出错 → 把报错手动转述给AI → 改 → 又复制回去……每个循环少则2分钟多则10分钟，注意力和耐心是被这个循环吃掉的，不是被MC吃掉的。
到项目一后半段，学生已经开始烦躁地说"我又得复制一遍"。这是项目设计里没充分预料到的成本。
解决方案在项目二的pipeline里：让AI能直接发命令进游戏，无需人工搬运。
"我不是不想测，是测一遍要复制四次。"
— 学生，项目一后期
项目二 · 已完结
僵尸围城
项目二：做得偏快，但 RCON pipeline 立住了
坦白说，项目二做得比设计书里赶——3-session的plan被压成了1-2次。学生对"做一个新的游戏模式"的兴趣没我预想得高，所以我没硬撑足时长。但这个项目的核心价值不在游戏模式本身，在于它把项目一那个手动循环换掉了——这个目标达到了。
新pipeline的三件套：Cursor（AI辅助IDE）+ 本地MC Java dedicated server（脱离单机）+ RCON / mcrcon（AI能直接发命令进游戏、读回执）。
关键发现：原版MC dedicated server 原生支持RCON——只要在 server.properties 里改两行配置即可，不需要Fabric mod loader。这一发现把整个pipeline的复杂度砍掉一半，也是这个项目能压缩到很短的原因。
现场惊喜 · 留作反复使用的素材
Agent 自己识别并修了 JDK 版本问题
Pipeline搭建过程中，AI agent最初装了JDK 21，跑MC server失败。它自己读了报错，自己判断需要切到JDK 25，自己重装并重试成功——整个过程没有人介入。
这一刻比任何PPT解释"什么是autonomous debugging"都直观。已留作之后讲解的核心案例——它会反复在P3、P4里被引回来。
事后反省
如果重做P2，我会更尊重学生当下的兴趣信号——他对"自己设计游戏模式"没那么大热情时，应该更快切到下一个项目，而不是按plan走。设计书是骨架，不是时刻表。
项目三 · 进行中
我的AI队友 · Mindcraft 探索周
项目三：AI 走进游戏的那一刻——也是科学方法浮现的那一刻
P3启动方式跟P1、P2很不一样：我先布置了一个Mindcraft 探索周——一份 A-E 五部分、3-5小时的自主任务文档，让弟弟用Cursor自己读bot的codebase、改它、跟它玩、做实验。我退后一步，不在场。
这个赌注是：给一个真实的开源项目（不是练习题）+ 一个能解释代码的AI助手（Cursor）+ 几个具体的小问题，看学生能走到哪。
作业回收 · 弟弟的实测
一周之内他确实走完了核心：自己用Cursor逛了codebase（找到了 main.js 是入口、profiles/ 是bot性格、 actions.js 是命令）、做了"押韵bot"的人格实验、自己加了一条 !goToBed 命令让bot天黑能自动睡觉、跑了基础任务。这跟一周前的他比，是有跨度的。
"达到了预期，说话确实押韵了。不会破功——我让他介绍自己他依旧押韵，但是如果我给他不押韵的指令他就不会押韵了。"
— 弟弟，关于他设计的押韵bot
这条观察其实非常细：他自己注意到了人格设定有作用域——只在自我表达时生效，被指令覆盖时不生效。这是个很真的现象，也是LLM行为里一个有意思的点。我没教过他这个，他自己看出来了。
现场debug · 上周一起干的事
Bot 总是卡在墙里——发现问题 · 提出猜想 · 修
探索周里他注意到了一个反复出现的故障：bot执行 "帮我挖到铁矿" 时，会传送到铁矿位置但卡死在墙里走不动。一周后我们一起在Cursor里debug——他描述现象，Cursor帮他定位逻辑，我们顺着代码走了一遍寻路-挖路那一段，最后找到问题并修了。
这一段对我来说是这门课目前为止最值的一次教学时刻。原因不在bug本身——而在他经历的那个完整循环：
观察现象 → 形成可检验的猜想 → 用工具(Cursor)验证 → 动手改 → 看结果
已修复 · 被记入教学日志，作为P3"科学方法在AI项目里自然浮现"的核心样本。
设计层的新发现
这门课原本只是"教怎么驾驭AI"。但P3里浮现了一个隐藏副产品——它顺便在教科学方法。Mindcraft是个有bug、行为不完美的真实开源项目，正因为它"不完美"，它给了学生反复练 发现问题 → 提出猜想 → 验证 → 解决 的机会。这是练习题给不了的。我之后会更主动地往这个方向倾斜P3的设计。
还在路上的事：profile setups我们一起探索了几个（生存模式 vs 上帝模式 vs 助手模式的行为差异）；DeepSeek多模型对比还没系统做；两个bot协作还没实测；C3那个 thinking 参数小坑还没碰。这些都是接下来session的素材。
横向观察 · 持续
关于学生本人
意外的提前到达：他自己在做"拆解"和"提问"
按设计书，decomposition应该在P2中段冒出来。但P1末期他已经在自然拆任务——"我先做计分，搞定再做倒计时"。科学方法本来根本不在课程图谱里，但P3里他自己就开始用了。
教学者的调整
学生提前到的，就在那个当下命名、当下承认那是真东西。我越来越倾向于把"课程结构"当骨架而不是时刻表——他比我设计的速度快的时候，让他过去；慢的时候，停下来等。这种flexibility本身就是这门课的形式选择。