互玩与迭代 · 从游戏到项目

串门时间！

Peer Playtest

现在：

不要继续玩自己的游戏了！

我们会给每组分配另一个小组的作品。

尽量保证：

你试玩的项目和自己的基础游戏不一样。

例如：

🐍 贪吃蛇组 → ✈️ 飞机大战组

💣 扫雷组 → 🔢 2048组

复制对方的 Gitee 仓库地址。

把下面这段提示词交给 Kimi Code：

现在我要试玩另一个小组制作的小游戏。

这是他们的 Gitee 仓库：

【粘贴对方仓库地址】

请：

1. 把这个仓库克隆到一个新的文件夹；
2. 不要修改任何代码；
3. 阅读项目；
4. 告诉我怎样运行；
5. 帮我启动或者打开这个小游戏。

接下来我要自己试玩。

暂时不要评价和修改他们的作品。

试玩规则

前一分钟：

不要问作者怎么玩。

自己试/问AI。

看看：

• 我能不能看懂？
• 哪个东西最吸引我？
• 哪里让我觉得奇怪？
• 有没有什么意外行为？

然后给对方三个反馈：

我最喜欢的一点： 我有点没看懂 / 觉得奇怪的一点： 如果让我再增加一个功能，我会增加：

如果有兴趣～

还可以直接到对方的 Gitee 仓库：

创建一个 Issue。

教程如下：

这里举一个建议的例子：

## 建议：增加连续得分奖励

试玩的时候发现，连续命中以后目前没有额外反馈。

如果连续成功 5 次以后进入短暂的“狂暴模式”，感觉可能更好玩。

恭喜。

你刚刚已经完成了一次非常简单的：

真实开源项目反馈。

第二次魔改！

回到自己的项目。

看看别人给你的反馈。

你：

不需要全部接受。

自己判断：

“这个建议我喜欢吗？”

如果喜欢：

挑一个。

然后告诉 Kimi Code：

刚才另一个玩家试玩了我的游戏。

他给我的建议是：

【复制建议】

我觉得这个想法不错。

请你先结合当前项目，分析这个建议是否适合实现。

如果适合：

1. 给我一个最简单的实现方案；
2. 不要破坏当前已有玩法；
3. 尽量控制改动范围；
4. 完成以后帮我重新运行验证。

我们现在开始第二轮迭代。

小知识点

这一刻你其实已经完成了：

想法 ↓ 做出来 ↓ 别人试玩 ↓ 得到反馈 ↓ 自己判断 ↓ 再修改

这就是：

## 项目迭代。

如果程序突然炸了怎么办？

非常正常。

可能会出现：

• 页面白屏；
• 按钮点不动；
• 游戏规则突然坏了；
• 控制台出现一大片红字；
• AI 说“完成了”，但是实际上完全不能玩。

这时候：

不要慌！

也不要第一句话就只说：

“帮我修。”

可以告诉 Kimi Code：

我刚才修改以后出现了问题。

现在的现象是：

【描述你看到的现象 / 粘贴报错】

请先不要修改代码。

先帮我分析：

1. 这个问题可能是什么原因；
2. 和刚才的哪次修改有关；
3. 你准备检查哪些文件。

先解释清楚。

然后我们再一起修。

小知识点

Bug 不是项目失败。

它只是：

下一轮对话的输入。

游戏->项目

刚刚我们只用了几十分钟。

但是可以想一下：

如果不是几十分钟，而是两个星期呢？ 如果不局限于做一个小网页呢？

这也是后面的“AI+项目式学习”课程要继续做的事情。

接下来会发生什么？

本次先导课结束以后：

线上课程

我们会举办线上课程，大家根据我们发放的教程自行完成学习，

并在线上打卡提交。

线下沙龙

我们会举办：

方向沙龙 + Social + 项目组队

邀请不同方向的嘉宾分享项目方向。

同时开放：

线下交流组队

和

线上组队渠道。

组队以后

大家合理安排时间，充分沟通交流，根据自己的专业背景，合理使用AI工具，打磨自己的idea和项目。

后续课程

进入真正的：

Project Day

不再由老师一直讲课。

主要是：

大家自己做。

每队配备的老师为大家：

• 答疑；
• 帮忙砍需求；
• 帮忙解决卡点。

最后：

Demo Day

把真正做出来的项目展示给大家。

Workshop 总结

1. AI Coding 的起点不是“会不会写代码”，而是“我到底想做什么”。今天大家从同样的几个小游戏出发，却可以通过不同脑洞做出完全不同的作品。
2. 面对一个陌生项目，不一定需要先把所有代码看懂。可以先让 Kimi Code 帮你阅读项目、理解结构，再决定从哪里开始修改。
3. 一次不要做太多。先让一个最小的变化跑起来，再继续增加功能。很多项目就是这样一点点长出来的。
4. AI 说“完成”不代表真的完成。每次修改之后都应该自己运行、试玩和验证。
5. Bug 并不可怕。报错和异常也是信息，可以把它交给 AI 分析，但最好先理解发生了什么，再决定如何修改。
6. 项目不是一个人关起门来一次做完的。让别人使用你的作品、听取反馈、自己判断哪些建议值得接受，再进行修改，本身就是项目开发的一部分。
7. Gitee/GitHub 不只是“存代码的网站”。今天大家已经体验了 clone、push、Issue 和作品共享，这些都是以后参与开源、竞赛、科研和团队项目会反复遇到的协作方式。
8. 一个几十分钟的小玩具，也可能成为真正项目的种子。项目往往不是一开始就宏大，而是在一次次修改中逐渐长出来。

这场 Workshop 的设计思路

• 为什么不让大家从零开始写一个项目？
• 我们希望大家熟悉诸如clone之类的一些基础git指令，了解它们的功能，并借助AI工具提高效率。
• 一个已经能够运行的小游戏提供了明确的起点，让同学可以直接进入最有趣的部分：

> - “我希望它变成什么？” > >

• 降低第一次 AI Coding 的门槛，让更多同学在一节课内真正获得一个能够运行的结果。
• 为什么选择简单 HTML 小游戏？
• 大多数小游戏玩法非常直观，不需要复杂背景知识。
• 修改结果具有非常强的视觉和交互反馈。
• HTML / CSS / JavaScript 项目一般体量较小，AI 更容易快速阅读和修改。
• 不依赖数据库、复杂后端等环境，可以把课堂时间更多留给创作。
• 同一个基础游戏可以衍生出非常多不同版本，适合开放式创作。
• 为什么提供脑洞，但不设置统一任务？
• 脑洞用于帮助同学跨过“我不知道做什么”的第一道门槛。
• 但项目式学习最重要的能力之一仍然是：

> - 形成自己的想法。 > >

• 因此提供示例，但不把示例变成标准答案。
• 为什么设置 10 Minute Checkpoint？
• 大家可能一开始就提出一个过大的需求，然后长时间停留在设计、重构或者报错阶段。
• 要求十分钟内至少产生一个明显变化，是希望同学体验：

> - 先完成最小可运行版本，再继续增加功能。 > >

• 为什么设置交换试玩？
• 一个项目是否好用，不能只靠作者自己判断。
• 让另一个同学在“作者暂时不解释”的情况下直接试玩，可以很快发现：
• 哪些设计足够直观；
• 哪些功能没人注意；
• 哪些地方产生了意外效果。
• 让同学第一次体验：

> - “别人真正使用我的作品”是什么感觉。 > >

• 为什么让大家用 Gitee？
• 作品需要一种简单、统一的共享方式。
• 同时可以借这个自然场景，让大家接触真正项目开发中会使用的 clone、push、Issue 等概念。
• 不单独把 Git 讲成一门枯燥的工具课，而是在“我真的需要分享和试玩项目”的时候自然使用它。
• 为什么线下不系统讲 Prompt、Debug、Git？
• 本场 Workshop 最重要的是：

> - 体验和兴趣。 > >

• 过多工具细节会打断创作节奏。
• 更系统的 AI Coding 工作流、Prompt、Debug 和 Git 内容，直接复用此前活动已有资料。
• 等同学在真正项目中产生需求以后，再回头学习这些内容，理解会更加自然。
• 为什么最后一定要展示？
• Demo 是项目的自然终点之一。
• 它会迫使我们把“我脑子里有一个想法”变成“我现在真的有一个东西可以给别人看”。
• 同时也让大家看到：

> - AI 工具降低了实现门槛，但真正决定作品差异的依然是人的想法。 > >

拓展部分：AI 到底是在“帮我写代码”，还是“帮我做项目”？

今天看起来，我们一直在和 Kimi Code 聊天。

但是它其实做了很多不同类型的事情：

• 阅读项目；
• 搜索文件；
• 修改代码；
• 执行命令；
• 使用 Git；
• 读取报错；
• 再根据反馈继续行动。

所以一个 AI Coding Agent 并不只是：

“会写代码的大语言模型。”

它更像是：

模型 + 项目环境 + 工具 + 多轮反馈

今天大家只是用它魔改了一个小游戏。

但是同样的方式以后也可以用于：

• SRTP；
• 科研；
• 竞赛；
• 网站；
• 数据分析；
• 自动化工具；
• AI 应用；
• 开源项目。

小游戏只是：

第一次把手放到方向盘上。

附录一

这个报错是因为你的账户安全评价较低，绑定一个可靠的第三方账户（如QQ）即可解决：

1.打开gitee，点击头像->个人主页

2.打开“个人设置”

3.绑定QQ账号

到这里，问题一般就解决啦。

如果绑定了第三方账号以后还是不行，你也可以尝试在手机上安装Google Authenticator来扫码提高账号安全等级，具体步骤你可以问Kimi Code~