结论先说

2026 年 10 月,用提示词做游戏这件事,第一次跨过了「能跑起来」到「真的好玩」中间那道坎。Simon Willison 给出的判据很朴素:他在几周内做了四款游戏,每一款自己都真心愿意玩下去,而**单个项目的个人投入没有超过四小时**(剩下是模型自己跑的时间)。他上一次给出这种判断,是 2025 年 11 月的编码 Agent 拐点。

拐点到底变在哪

他点名的模型是 Claude Opus 5.5,进步集中在三件做游戏必需的事上:

过去一年多,模型早就能做出「看起来像游戏」的东西:有场景、有 UI、有操作。卡住的地方始终是为什么玩家要继续玩下去——难度曲线、正反馈节奏、关卡递进,这些是手艺,不是代码量。

他试的办法非常不体面:直接对 Opus 5.5 说一句「把它做得**好玩很多**」。结果是真的变好玩了。

四个项目,按投入从少到多

两个能直接抄的做法

1. **从浏览器开始**:全部是 HTML + JavaScript,静态托管(GitHub Pages 或 Cloudflare Pages)就够。手机浏览器跑起来和原生几乎分不出差别。

2. **提示词模板**:先用一句 `Build a mobile-friendly three.js game where...`,在普通对话里验证想法;等项目过了原型阶段再切到 Claude Code 这类编码 Agent。不好玩就补一句 `Make it a LOT more fun`。

一个容易忽略的细节:试玩本身就是提示词

这四个项目里,真正卡时间的不是写代码,是**发现哪里不好玩**。Emberwick 反复迭代,问题集中在玩法而不是画面:某个 NPC 因为剧情推进被移到了别处,玩家到不了交付任务的正确位置。Battle Drones 最早是今年七月用另一个模型做出来的 2D 原型,能玩但不好玩,直到那句「做好玩很多倍」再加上「移植到 three.js」,才彻底换了副样子。

这给日常协作一个很实际的提示:模型负责产能,人负责品味和验收标准。与其花力气描述实现细节,不如把「哪里不对」说准——节奏太慢、反馈太迟、奖励太薄,这些判断目前还是人的活。反过来,如果连自己都说不出哪里不好玩,再多的提示词也只是让一个平庸的设计跑得更快。

还有一条硬约束值得记住:低风险是这条路能成立的前提。个人项目里出个 bug,最坏结果是白玩半小时;他自己就提过,音频联机的实验让家人头疼了一下午。放到有真实用户、真实交易的产品上,同一套「不看代码只管提需求」的做法就不能照搬。

也得说清楚的代价

他自己承认两件事。一是**版权与观感**:vibe 游戏把 AI 生成的图、乐、文、码四样叠在一起,游戏社区对 AI 素材的反感是真实存在的,他不会拿这些作品去参加传统 game jam。二是**差距仍然存在**:同样的提示词交给 GPT-6 Pro,画面更漂亮,但可玩性明显不如;GPT-6 Astra 能建出游戏,但对「什么算好玩」的把握还差一截——他预计年底会追上来。

真正值得抄的不是那几个游戏,而是那句反问:如果一个只投了几小时、没什么品味积累的人都能做出这种东西,那么认真投入创意、反复试玩迭代的人,能做出什么?

阅读原文 → 返回 AI 技术文档

内容与图片版权归原作者所有 · 原文: https://simonwillison.net/2026/Oct/28/vibe-game-development/