Easy-Vibe 第 4 站 · 对话编程的边界，和那些被 AI 点亮的游戏 — 解读与音频稿件

来源标注：本内容改编自开源项目 Easy-Vibe（仓库 datawhalechina/easy-vibe，路径 docs/zh-cn/stage-1/ai-capabilities-through-games/index.md），为二次演绎配音版。原文作者与贡献者来自清华大学深圳国际研究生院及开源社区。本文在原文基础上做了口语化改写、结构重组与实践补充，观点与例子由演接入添加，不等同于原文表述。

• 篇目 slug：games-cases-vibe
• 所属章节：第 2 章 · 通过游戏初识 AI 能力
• 对应音频：games-cases-vibe-播客.mp3
• 字幕：games-cases-vibe-播客.srt

---

一、这一集在解决什么问题

上一集回答了「现在的 AI 能帮你做到什么程度」，但用的是课程内部的演示。这一集要回答一个更尖锐的问题：脱离教程的温室，真实世界里，普通人用对话到底做出了什么？ 原文的答案是八个全网公开的真实案例，外加四个回答零基础者概念疑问的附录。

八个案例不是随意罗列，而是一条从易到难的完整光谱：单玩法小游戏（Blooming Garden，约两小时）→ 经典复刻合集（WotAI Games，十款街机）→ 三维联机（Planet Jumper）→ 上百款量产（mini-browser-games）→ 大型复刻（CraftMine，六千八百二十行单文件）→ 玩法创新（AI 实时生成关卡的超级马里奥）→ 单提示词三维游戏（Kimi K3，约两美元）→ 官方平台（K399，几十款游戏）。

一句话概括这一集：贪吃蛇只是 AI 编程能力的冰山一角。真正决定你能做出什么的，不是工具，是把想法说清楚并愿意多轮打磨。

二、能力地图

原文的能力点散落在案例叙述与四个附录里。我按「看见 → 拆解 → 表达 → 底功」四个环节重新排列，并标注每个能力在整门课中的位置。

能力项	原文怎么说的	演接入的解读	所属环节
案例鉴赏力	八个案例的工具、规模与完成度	会看案例的「含 AI 量」，分清哪些是演示、哪些是产品	看见
规模感	从两小时到一百款到六千行单文件	对「AI 能扛多重的活」建立数量级直觉	看见
共同配方识别	说清楚想法 + 多轮对话打磨	所有案例剥到底是同一件事的重复	拆解
前端三件套概念	HTML 管有什么、CSS 管长相、JavaScript 管动作	不需要会写，需要能描述	表达
Vibe Coding 认知	Karpathy 二零二五年二月提出该词	知道范式名字，便于检索、交流与建立身份认同	表达
上下文管理	模型短期记忆、token、上限症状、成本	把上下文当稀缺资源经营	底功
指令遵循	数量准、要素全、格式对、不延伸	把指令当合同写	底功

这张表怎么用：竖着看是进阶顺序。前两行是「开眼界」，解决不敢动手的心理问题；中间两行是「会描述」，这是全课核心能力的前置；后两行是「走得远」，决定你能从演示版走向敢给别人用的东西。多数零基础者的误区是只做第一行——案例看得很爽，自己的点子一个没讲清楚。

三、八个案例全景

下表是这一集的事实底座。所有信息均出自原文，未做外部补充；在线地址与源码链接以原文为准。

#	案例	开发者	工具	规模	亮点
一	WotAI Games	未具名	Claude Code，不使用游戏引擎	十款经典街机	一个下午完成；每款可在线玩，自带排行榜
二	Blooming Garden	in0ho1no，完全零基础	Claude 纯对话	二零四八风格	约两小时；合成升级、粒子动画、音效、手机适配
三	Planet Jumper	Ricardo de Zoete，设计师	OpenAI 模型 + three.js	三维多人平台跳跃	小球状星球表面竞技；球形引力、联网同步、跳跃手感
四	mini-browser-games	wangzifan396-wzf	对话编程	一百款浏览器游戏	单文件零依赖双击即玩；MIT 协议开源；部分达产品级深度
五	CraftMine	Trent Sterling	Claude Code 纯对话	六千八百二十行单文件	四十六种方块、二十一种地狱主题方块、三十六种生物、十九种武器、五种生物群系、昼夜循环、点对点联机
六	AI 版超级马里奥	未具名	开源马里奥 + OpenAI 模型	无限模式	实时生成场景与敌人；实测连玩四十五分钟；游戏内文字改关卡
七	Kimi K3 三维游戏	Josh Simmons	Kimi K3，一个提示词	第一人称三维	一次生成可玩，两轮对话修两个错；全程约两美元
八	K399 平台	月之暗面官方	K3 模型	几十款	品类全覆盖；含完成度远超演示版的原创游戏

三个观察角度，建议听音频时留意：

第一，看工具分布。 八个案例里，Claude 系工具出现三次，OpenAI 系出现两次，Kimi K3 出现两次。没有一个案例依赖某个「秘密工具」。这从侧面印证上一集的判断：入门阶段挑一个顺手的用下去，比反复横比重要。

第二，看开发者背景。 有程序员，有完全不懂编程的日本开发者，有设计师，有给侄子做游戏的叔叔，还有官方团队。背景不是门槛，表达才是。

第三，看完成度的天花板。 原创完成度最高的两个案例——一百款合集与官方平台——都不是「一个提示词的奇迹」，而是持续打磨的产物；CraftMine 也是单文件但功能极其密集。这恰好复刻了原文的边界判断：AI 负责从零到一，人负责从一到稳。

四、共同配方：剥开八个案例

原文在案例末尾给出了总结，音频里我用「配方」来转述。八个案例的共同点只有两条：

1. 把想法说清楚。 每个案例的作者都必须先把「做什么、长什么样、怎么算完成」讲成 AI 能执行的话；
2. 愿意多轮对话去打磨。 Blooming Garden 的两个小时是打磨出来的，CraftMine 的六千行是打磨出来的，K399 的完成度更是打磨出来的。唯一接近「一把梭」的 Kimi K3 案例，也还补了两轮对话修错误。

同时要清醒：这些案例是上限的证据，不是边界的反证。它们全部落在「小而清晰」或「持续打磨的中等复杂度」区间，没有一个敢声称端到端交付了商用系统。这与上一集的三层信任划分完全一致——看见上限，同时守住边界，两个认知缺一不可。

五、附录概念：零基础的四块地基

本章附录是整门课被低估的部分。口播稿讲了四块，这里补全细节。

前端三件套（附录一）

原文用「房子」比喻三种代码：HTML 管页面上有什么，好比盖房先画图纸；CSS 管长什么样，好比刷墙、摆家具；JavaScript 管怎么动，好比电灯开关，一按就亮。浏览器的工作顺序是先搭骨架、再装修、最后通电。React、Vue 这类框架是「盖复杂网页的预制板工具」，零基础者不需要会，知道是帮手就行。前端与后端的划分也值得知道：前端是用户能看到、点到的所有内容，后端是运行在服务器上的数据处理，比如分数存储、登录验证、关卡内容分配。在 Vibe Coding 里，这些概念的价值不是让你写代码，而是让你能描述代码。 原文给的描述示例是：「用 React 做个排行榜：右侧分数列表，点一行下方显示玩家详情，风格简洁现代。」——注意这句话里出现了具体技术名，但不妨碍你照葫芦画瓢。

到底什么是 Vibe Coding（附录二）

计算机科学家 Andrej Karpathy（OpenAI 联合创始人之一、特斯拉前 AI 负责人）于二零二五年二月提出 vibe coding 一词，指一种依赖大模型的编码方法：允许通过自然语言描述而不是手动编写代码，来生成可工作的代码。 它的工作循环是三件事——说清楚要做什么、看到结果后判断哪里不对、再提出新的修改。语法错了编译器会告诉你，需求模糊了 AI 只会给你一个模糊的东西，所以难点从「语法」换挡到了「表达」。原文还教了一个实用技巧：遇到看不懂的段落，直接复制给 AI，请它用「完全小白能看懂」的方式再解释一遍。

模型上下文（附录三）

上下文是 AI 的短期记忆，指一次对话中模型能看到和记住的所有文本。每个模型有有效上下文长度，以 token（可粗略理解为字词片段）计，主流模型目前多在 32k～128k 之间。接近上限的典型症状有三个：遗忘前面长文本中的细节、话题偏离最初目标、对同一材料的不同问答引用不一致。这不是模型变笨，是容量将满。 经营上下文的三条策略出自原文：真正需要长期保留的信息提炼后再给；不再需要的细节不要一遍又一遍原样塞入；长期记忆交给外部知识库，而不是全塞进对话。同时要意识到，上下文越长，占用的算力与费用也越高，设计应用时需要在「看得足够多」与「控制成本」之间做平衡。

指令遵循能力（附录四）

指模型理解指令后能否准确、完整地执行。原文给出四个特征：按要求的数量输出（要三个要点就不给五条）、覆盖所有指定要素（要作者时间事件就不遗漏）、遵守指定格式与语气（要正式就不口语化）、不做不必要的额外延伸（只让翻译造句就不附赠解释）。它的价值在稳定性、可复现性与系统集成。对工业级应用来说，稳定准确地执行指令，往往比偶尔一次惊艳的回答更重要。 这句话对零基础者同样是选工具的金标准：把「听话」排在「聪明」前面。

六、审查清单

把 AI 生成的游戏或小工具分享给别人之前，拿这张清单过一遍。条目源自原文的边界讨论与案例细节：

通用项（任何产物都查）

• 能打开吗？在浏览器里实际点过一遍吗？
• 核心功能按预期工作吗？还是只是没报错？
• 报错是否完整丢回给 AI 并确认修复，而不是刷新一下假装没问题？

游戏类专项

• 手感过了自己这关吗？移动、跳跃、反馈延迟能接受吗？
• 极端情况试过吗？快速连点、刷新页面、断网重连？
• 手机上能玩吗？还是只在你的电脑上好看？

分享与开源前

• 复刻经典 IP 时，是否留意了版权边界？（原文案例多为个人学习用途）
• 若要开源，是否明确了协议？（mini-browser-games 采用 MIT 协议，是可参考的做法）
• 是否标注了「AI 辅助制作」？诚实标注是这类作品的基本礼貌。

面向真实用户前

• 架构是否有人看得懂、接得住、改得动？
• 是否引入了严格的审查与测试流程？没有就停。

七、约束说明

内容约束：本集八个案例的全部事实（开发者、工具、规模、时间、费用）均出自原文，未做外部补充；比喻、串联与行动建议为演接入添加，已与原文表述区分。案例的在线地址与源码链接见原文，产品状态可能随时间变化，以各项目官方信息为准。

能力约束（源自原文，务必牢记）：

1. 贪吃蛇只是冰山一角，但冰山一角也是有限的——当前 AI 适合从零到一，不适合端到端交付商用系统；
2. 所有「很快做出」的案例都建立在多轮打磨之上，不存在纯粹的「一个提示词定终身」；
3. 复刻商业 IP 的案例多为个人学习用途，分享与商用前需自行评估版权风险；
4. 零基础者不补任何概念也能起步，但补上「三件套 + Vibe Coding + 上下文 + 指令遵循」四块地基，会明显提高描述需求的精度。

使用约束：本集案例的看点不是「复刻一个同款」，而是识别共同配方。照抄案例清单不会长本事，把配方用在自己的点子上才会。

八、给零基础者的行动建议

第一周，开眼界。 每天精读一个案例，回答三个问题：它用了什么工具、作者是什么背景、最难的可能是哪个系统。一周后，你会对「AI 能扛多重的活」有数量级直觉。

第二周，用配方。 挑一个自己的点子，严格按两条配方走：先用三句话讲清楚（做什么、长什么样、怎么算完成），再至少打磨三轮。每轮只改一个点，改完记录 AI 的理解偏差。

贯穿两周的底功。 每次开新对话前，用一句话写下这次的目标；每次觉得 AI「变笨」时，检查是不是上下文快满了；每次收到不合格产出，先反思指令是否写清了数量、要素、格式。

九、实践提示

提示1 · 用「含 AI 量」拆解一个案例

选八个案例里你最眼红的一个，逐项标注：哪些部分可能是 AI 一把生成的，哪些一定是多轮打磨的。比如 CraftMine 的六千行不可能一次生成，点对点联机一定是反复调试的结果。练的是：把「惊艳」还原成「流程」，惊艳就不能骗你了。

提示2 · 给自己做一次「规模阶梯」测试

用同一个点子，按四个规模各做一版：一句话版、半页需求版、带编号的完整需求版、再加验收标准版。对比四版的质量差。判断标准：如果第三版开始你能预判 AI 的输出结构，说明「描述的具体程度」这项能力已经入门。

提示3 · 用「房子比喻」向 AI 描述一个网页需求

把附录一的比喻用起来。对 AI 说：这个页面分三层，结构上要有……，长相上要……，动作上要……。说的时候强制自己分开说，不要混。为什么有效：三层分离的描述，恰好对应前端三种代码的分离，AI 出错时你也更容易定位是哪层的问题。

提示4 · 建一份「上下文预算表」

开一次长对话前，先写三行：这次要保住的核心信息是什么、哪些细节可以随时丢、超过多少轮就该总结重启。练的是：把上下文当稀缺资源。表格不用复杂，写在你自己的笔记里就行。

提示5 · 把指令当合同写一次

给 AI 派一次活，指令里必须写清四件事：数量、要素、格式、不要出现什么。然后检查产出是否四条全中。复盘要点：没中的那条，就是你下次写指令时要补的洞。这个习惯会直接决定你未来用 AI 协作的下限。

十、音频与字幕说明

• 本集口播稿按 9 个段落组织，段名仅作结构标记，合成时会被剥离，不进入朗读。
• 口播正文约 4,623 字符（不含段名与空白），按实测语速约 314 字每分钟估算，成片时长约 15 分钟。
• 字幕文件随音频一并生成，段落边界与口播稿段名对应，便于按章节跳转。
• 所有数字在口播稿中均已改为中文读法（如「二零二六年」「六千八百二十行」），TTS 无需额外做数字归一化。
• 所有英文缩写均改为分读写法或中文译名（如「A I」「H T M L」「C S S」「M I T」），平台与产品名保留原文拼写。

---

来源：Easy-Vibe（datawhalechina/easy-vibe）stage-1/ai-capabilities-through-games。本内容为二次演绎配音版，解读部分由演接入添加。