AI 做游戏开始跨越玩法设计门槛

让 AI 做出一个能运行的小游戏，已经不稀奇。Simon Willison 在这篇文章里提出了更进一步的判断：2026 年 10 月，模型开始能把游戏做得真正好玩，尤其是 Claude Opus 5.5，连模糊的「再好玩一点」都可能转化成有效改进。

支撑这个判断的是四个浏览器游戏，从一次生成的找不同，到支持多人联机的 RTS。对前端开发者，值得看的既有 three.js 的表现，也有作者反复试玩后暴露的问题：画面、玩法、任务能否完成，仍然是三件不同的事。

从能运行到好玩，作者看到了什么变化

作者把 2025 年 11 月视为编程代理的一个转折点：Opus 4.5 和 GPT-5.1 让相应工具变得足以承担工程师的日常工作。到了 2026 年 10 月，他认为游戏开发也出现了类似变化。

这一次，他强调的是游戏设计能力。模型过去就能生成像游戏的东西，困难在于让玩家愿意继续操作，逐步学会规则，并获得恰当的挑战和奖励。

作者所谓的拐点，是模型开始能改善游玩体验，而不只是补齐功能。

最小的例子是 Tree Appreciator。作者在普通 Claude 聊天界面里输入了这段提示，没有使用 Claude Code，也没有追加修改：

Build a three js game called "Tree appreciator" - it shows you two algorithmically generated trees and the game mechanics is about appreciating the differences between them. Think hard about how to make sure it is both fun and beautiful.

这段提示把「欣赏两棵树的差异」变成了可操作的游戏。要留意最后一句：作者只要求兼顾好玩和漂亮，没有指定找不同、收藏系统或具体交互。

模型交付了一个适配手机的 3D 找不同游戏。玩家可以旋转、放大两棵树，寻找差异，完成后把树收进植物标本集。找不同提供短期目标，收藏提供持续反馈，合起来形成了作者觉得放松、满足的体验。

更复杂的 Emberwick 则展示了边界。作者先要求生成倾斜俯视角的幻想村庄，角色带着一两名同伴移动，进入建筑后，遮挡视线的墙壁变透明；随后加入地形起伏、相连的地下室，以及住着沉睡巨魔的山洞。

直到场景成立，他才要求把可玩区域扩大到原来的四倍，加入玩法、魔法、剧情和转折，并提出「不要太俗套」。

最终游戏有约 15 分钟的完整故事，还有实验性的关卡编辑器。但它并非一次生成就完成：某个剧情事件让 NPC 换了位置，另一个任务却仍然依赖原来的位置，玩家就可能无法推进。

这里最有参考价值的，是作者持续试玩并修复任务问题。生成完整剧情，不等于生成了始终一致的任务状态。

四款游戏里，最强的证据和反例都是什么

最能支持作者判断的是 Battle Drones。这是一款类似 Command & Conquer 的即时战略游戏，机器人军队采集废料、生产单位、争夺地盘。

它最早在 7 月由 Claude Fable 5 做成了可运行的 2D 版本，但作者觉得不好玩。后来，他让 Opus 5.5 执行「Make it a LOT more fun」，再要求「Port this game to three.js」，才得到了明显更满意的结果。

现在它支持 2–4 人联机，通过另一个由 AI 编写的 WebSockets 中继服务器通信，并具备勋章、回放、七张地图、随机地图生成器，以及改变规则的 mutators。

它还允许不同 LLM 对战：游戏每推进五秒便暂停，让模型读取状态、安排下一组命令。原文展示的是 Claude Haiku 5.5 对 GPT-6 Luna 的回放。

作者以 Apache 2.0 License 开源后，Gabriel Turpin 又做出了 Panache 分支，把世界观改成 1900 年代法国美好年代的蒸汽朋克风格，替换模型、音乐，并加入动画开场。这个案例说明，成果已经能被别人接手改造，而不只是留在一次聊天里。

不过，最能提醒读者冷静的也是作者自己的项目。

Quarter Sun Cove 来自他居住地 Half Moon Bay 的南瓜节与巨型南瓜称重比赛。玩家全年照顾巨型南瓜，同时种植普通南瓜，赶在 10 月销售旺季成熟，再参加称重比赛。

它有动物居民、恶作剧浣熊、把南瓜滚回海里的港海豹，以及偶尔应验的种植迷信。作者用「surprise and delight the user frequently」要求模型不断制造惊喜，确实得到了大量细节。

但作者明确说，它还没有 Battle Drones 好玩。玩家必须安排播种时间，让成熟期对上 10 月客流最多的周末，机制已经相当复杂。

细节丰富和玩法成立，是两个需要分别验证的目标。

这也是四个案例中很关键的反证：同一个模型能把场景做得热闹、有个性，却未必能把经营决策做得清楚、有趣。

前端开发者为什么容易复现这条路线

四个项目都使用 HTML 和 JavaScript，游戏运行在浏览器里。作者通常用 GitHub Pages 或 Cloudflare Pages 做静态托管。

这条路线减少了安装、打包和分发环节。对个人实验来说，先让别人打开页面试玩，比先完成一套原生应用发布流程更直接。作者认为，他尝试的这些游戏在移动浏览器里的体验已接近原生；这个判断仅限于他的游戏类型，不能扩展到所有游戏。

three.js 还有另一个作用：Claude 没有自己的图像生成模型，却能通过程序构建彩色 3D 模型。作者认为，这种方式得到的树木、村庄和机器人效果很好。原文也提到模型熟悉 Phaser，但具体案例主要围绕 three.js 展开。

起步甚至不需要完整编程代理。作者建议在 chatgpt.com 或 claude.ai 输入：

Build a mobile-friendly three.js game where...

这句提示用于快速建立可试玩原型。要留意 mobile-friendly：它把手机操作列为起始要求，而不是等桌面版完成后再补。

等概念验证通过，再切到 Codex 或 Claude Code 持续开发。原文最后用「老鼠躲猫」分别测试了 Claude Opus 5.5 Extra 和 GPT-6 Extra High，但没有提供足以比较两者的系统评估。

成本也需要分清。作者说，每个项目占用他本人的时间都没有超过四小时，但模型还会自行工作更久。Quarter Sun Cove 使用 Opus 5.5 Ultracode，消耗了数百万 tokens，运行近两天。

「人工投入少」成立，「总耗时少、费用低」则缺少账单和统一统计。

我的判断

我认同作者对探索门槛的判断。浏览器技术、程序化 3D 和模型生成能力结合，确实让一个想法更容易变成可试玩的东西。尤其有价值的是，作者把自己是否愿意继续玩当作标准，而不只展示截图。

但「2026 年 10 月出现拐点」仍是经验判断。四个项目都由作者选题、试玩、评价，没有公开统一的乐趣评分、玩家留存或成本对照。他在 Foo Camp 遇到其他人的相似经历，也只能算补充观察。

模型排名同样要保留前提。作者认为 GPT-6 Astra 的趣味设计不及 Opus 5.5，但承认没有做全面研究；他用相同的初始提示让 GPT-6 Pro 制作 RPG，觉得画面好、可玩性较弱，也不能据此推导所有游戏任务的胜负。至于 OpenAI 会在年底追上，是预测。

相比传统的手写代码、现成素材和人工设计，这条路线的优势在于快速探索，代价是生成结果需要靠试玩筛选，复杂状态仍会出错。原文甚至记录了音频联机实验让作者妻子头痛的情况，个人小游戏的低风险也有具体边界。

作者还承认，这类作品把 AI 代码、美术、音乐和文字争议叠在了一起。他不会拿这些作品参加传统 game jam 或比赛。工具扩大了创作入口，并没有替玩家或社区决定什么作品值得接受。

能拿来做什么

• 先做一个规则单一的浏览器原型，例如 Tree Appreciator 那样的找不同，用普通聊天界面验证是否值得继续玩，再投入代理开发时间。
• 提示里写清设备和空间需求，例如手机操作、倾斜俯视角、进入建筑后墙壁透明，让 three.js 场景服务于实际操作。
• 每增加剧情或经营规则，就完整试玩一次，重点检查 NPC 移动、任务条件和时间推进是否互相冲突。
• 分开记录人工时间、模型运行时间和 tokens 消耗；评价成果时，也把画面完成度与玩法体验分开记录。