Opus 5狂烧6.9亿token做游戏，GPT-5.6用5美元复刻了

《仅需》 6.9亿个token、423美元和1条提示词，就能做出一款火遍全网的美式水上快艇竞速游戏。

美式卡通风格、复古街机快艇竞速玩法，有完整的倒计时、圈数和排名系统。

连UI也全部做了统一的硬核街头赛车仪表盘设计，玩起来还挺带感的。

这是用 Opus 5 、 单提示词 直出的效果。不得不说Opus 5你还是有点东西。

结果还没高兴两天，另一位网友就在Codex里用 GPT-5.6 Sol 复刻出来了。

网友Vyom做的这款水上竞速游戏，叫 《INK TIDE》 。

画面是美式卡通风格，当操控船只航行的时候，整个船体的俯仰、侧倾都做得很逼真。

屏幕右下角是一个仪表盘，右上角是小地图和实时排名板。

蓄力、加速都有明显的动效，如果走错路或者跟敌方的船撞到了一起，画面上也有明确提示。

美中不足的是， 3个AI对手太弱了 ，我随便跑跑就第一了。

作者Vyom表示，这款游戏只用了 一条提示词、one-shot 生成。

是单提示词没错，但你也没说这提示词长达2000字啊…

游戏使用Vite、TypeScript和Three.js开发，完全不使用任何外部资源，所有模型、纹理和声音都由代码生成。

也难怪一次就能生成这么精美的demo，这已经不是提示词了，这就是一份全面的需求文档。

里面的分层结构非常清晰：先定义硬约束，再定义视觉标准，再定义功能需求，再定义开发流程，最后定义交付标准。

从中也能破解，为什么这款游戏的水面效果做得这么好。提示词里给水面系统单独起了一章。

值得注意的是，提示词里还有一段相当详细的 「子Agent分工」 。

作者要求Claude先定义一套共享架构，再把项目拆给多个子Agent：

有人负责水面，有人负责卡通渲染，有人负责赛艇物理，还有人分别处理AI对手、角色动画、视听系统和性能，彼此并行开发。

在多Agent工作流中，每个子Agent会拿到一个范围更窄的任务，在相对独立的上下文里集中处理自己的模块，最后再由主Agent负责统筹和整合。

这套安排，主要是为了对抗大型任务中的 「注意力稀释」 。

如果把水面、渲染、物理、AI、UI和音频一股脑交给同一个Agent，它很容易写着写着写岔了。

比如改水面时碰坏物理，做UI时忘掉性能，前面定好的接口到了后面又被推翻。

作者为此给不同子Agent划定了明确的职责，甚至规定各自只能修改哪些文件。先把边界钉死，再让它们并行开工。

更进一步看，作者还专门给这支Agent团队配了一名 「质检员」 。

他要求Claude先做一个截图harness，再跑一个视觉评审子Agent，让它盯着截图挑刺，每个子系统循环迭代直到评审无话可说。

这相当于让AI自己当质检员，每完成一个模块，都要实际运行、截图验收，再根据画面里的具体问题返工。

我又深扒了一下项目的Github仓库， 终于知道为什么3个AI对手这么弱了 。

3个NPC的参数直接在代码里写死了，其中跑得最快的KAIRA，也只比理论最佳速度快0.5%。

只要玩家正常走线+漂移加速，就能轻松甩开这个差距。

而另一个对手PIP，每圈都被设置了2-3次失误，一会儿跑宽，一会儿收油，一会儿又冲出赛道。

可能作者也是想设计得简单点，以此吸引更多玩家吧…

总的来说，作为demo而言，这款游戏足够精美完整，但更进阶的操作、玩法也还没有，撞栏或撞人也没什么后果。

网友Anul Agarwal，用Codex做出了一个类似游戏， 一共花了约5个小时、输入2个提示词 。

等等，开香槟之前，你会发现两份作业的完成度其实并不在一个水平线上。

虽然还原了原作最醒目的几个元素，同样是在海面上驾驶赛艇，同样有卡通渲染风格的水面、绿色赛道、竞速UI和多艘赛艇同场比赛。

但真摆在一起，很显然上面的水面细节、角色表现和画面统一性都相对粗糙。

另外，5美元也不是严格成本，主要来自订阅套餐的额度折算，并非API产生的独立账单。

作者表示，他觉得 GPT-5.6 Sol非常适合拿来做游戏 。

这个5美元平替版做下来， 也只花了周限额的20%左右 。如果只是拿来做个MVP，的确挺划算。