Opus 5 游戏提示词爆火:24 小时重现 3A 级作品
一个 Opus 5 游戏提示词在社区爆火,开发者在 24 小时内做出高完成度可玩作品。本文拆解 Challenge Loop、多 Agent 验收流程与社区案例,并介绍如何在 Dobby 上使用 Opus 5。
编者按:本文根据 Chimin 于 2026 年 7 月 31 日在 GitHub Daily / Medium 发表的文章 “Opus 5 Game Prompt Goes Viral, 3A Masterpiece Recreated in 24 Hours” 改编整理。文中的项目效果、制作时长与模型表现来自原作者及相关开发者的公开分享;“3A 级”描述的是目标与观感,并不等同于完整商业 3A 游戏的制作规模。
最近,一套面向 Opus 5 的游戏开发提示词在 X 上迅速走红。最吸引眼球的案例,是开发者 Anshu 在 24 小时内做出了科幻探索游戏 The Long Silence:玩家可以在浏览器里行走、驾驶飞船并探索星球。与此同时,Matt Shumer 展示了第一人称射击原型,其他开发者则做出了卡丁车和赛博朋克风格的游戏。

真正值得研究的,不是“输入一句话就得到 3A 游戏”,而是提示词背后的组织方式:主 Agent 拆解任务,多个子 Agent 并行制作,再由独立的评审 Agent 检查结果并要求返工。它把一次性生成,变成了一个持续运行的工程闭环。

关键不是一句提示词,而是 Challenge Loop
Matt Shumer 把这套方法称为 Challenge Loop(挑战循环)。提示词会先定义一个很高的目标,例如制作具有现代商业游戏观感的第一人称射击体验;随后要求模型逐项迭代画面、动画、声音、性能和交互,并为视觉验收安排专门的子 Agent。
其核心可以压缩为四步:
- 明确目标与硬约束:游戏类型、玩家动作、技术栈、帧率、画面气质和可运行平台都要说清楚。
- 拆分并行生产:由主 Agent 规划架构,再把建模、关卡、灯光、控制器、音效和性能等任务交给不同子 Agent。
- 独立验收:评审 Agent 不参与生产,只负责用截图、参考作品、性能数据和清单检查结果。
- 不合格就返工:评审标准不能在过程中偷偷降低,直到达到门槛或用户决定停止循环。

这种设计的特别之处在于增加了一个相对独立的“质量门”。普通多 Agent 工作流常常只关注谁来做什么,却没有一个有权否决结果的角色。Challenge Loop 强迫系统把“看起来完成了”与“真的达到标准”分开,并用并排比较、盲测和定量指标减少自我满意。
当然,当前模型还不能真正复制商业 3A 团队数百人的长期产出。严格循环如果没有预算、时间和停止条件,也会不断消耗上下文与算力。因此,人仍然要负责选择方向、调整优先级,并在收益开始递减时结束任务。
24 小时做出 The Long Silence
Anshu 的目标是用 Three.js 做一款浏览器中的太空探索游戏。他只先给出少数不可妥协的要求:玩家能步行和驾驶飞船,画面不能有廉价塑料感,并尽量稳定在 60 FPS。世界观、技术架构和大量实现细节则交给 Opus 5 决定。

第一阶段:先建立可玩的骨架
模型先完成移动、飞船驾驶、场景加载和浏览器渲染等基础系统。需要 3D 素材时,Claude Code 通过 Blender MCP 寻找并调用建模工具。这个阶段追求的是端到端可运行,而不是一开始就把每个细节磨到极致。

第二阶段:连续迭代视觉与性能
有了第一个可玩版本后,Anshu 让系统继续运行 24 小时,集中提升画面。多个子 Agent 并行工作,评审 Agent 则把游戏截图与《星空》等太空游戏的画面逐项比较,检查构图、光照、材质、曝光和帧率,未达标的部分重新进入制作队列。

第三阶段:人工调度、收尾并沉淀 Skill
自动化并不意味着人完全离场。Anshu 会通过手机查看进度;当模型在行星场景上投入过多时间时,他会重新排列优先级。停止长循环后,再用其他 Claude 会话修复渲染问题、清理代码并完成部署。最后,他要求 Opus 5 总结整个过程,生成可复用的 Skill 并上传到 GitHub。
原文称,Opus 5 在验收过程中还为自己制作了一套包含 17 项强制检查的工具:自动截取不同场景、保存对比图、统计帧率并分析曝光数据。这一点比漂亮的演示画面更重要,因为它把主观的“感觉不错”变成了可以重复执行的质量流程。

完成后的 The Long Silence 可以直接在浏览器里试玩。它更准确的定位是高完成度原型:足以证明长时间自主迭代能把一个模糊想法推进到可体验的产品,但仍需要人工导演和工程收尾。
社区开始“交作业”
提示词公开后,更多开发者把同样的结构迁移到不同题材。Ryan Campbell 用它迭代卡丁车游戏,重点改进本地渲染、移动端性能、操控和镜头;Yogi Suria 则尝试了名为 Claudepunk 2077 的赛博朋克原型。原文也提到,将相同思路迁移到 GPT-5.6 Sol 后同样能得到不错的结果,只是作者主观认为仍略逊于 Opus 5。



这套方法真正教会我们的事
第一,提示词正在变成系统设计。高质量结果不再只依赖优美措辞,而依赖角色分工、反馈回路、可观察指标、资源上限和停止条件。
第二,评审 Agent 往往比更多生产 Agent 更有价值。如果没有稳定的质量标准,再多并行执行也只是更快地产生不合格结果。
第三,人类的角色从逐行实现转向导演。你要决定什么值得做、哪些约束不能妥协、何时改变优先级,以及什么时候“已经足够好”。
第四,可复用的产物不只是游戏。验收脚本、对比基准、自动截图流程和总结出的 Skill,都会让下一次开发更快。一次实验因此可以变成持续改善的工程资产。
在 Dobby 上用 Opus 5 创建自己的游戏
想复现文中的游戏,或者把自己的创意做成可玩原型,可以前往 Dobby Agent,选择 Opus 5,把游戏设定、核心玩法、画面风格、技术栈和验收标准直接作为提示词交给它。你可以从一个小场景开始,再让 Dobby 持续修改代码、测试玩法、修复问题和迭代素材。
对中国用户,Dobby 提供无需翻墙即可使用的 OpenAI 与 Anthropic 领先模型,并支持微信支付和支付宝。这让没有海外信用卡、又不想搭建复杂代理和开发环境的创作者,也能尝试 Opus 5 以及其他前沿模型。
一个实用的起点是:先写清楚“玩家能做什么、在哪里运行、什么叫合格”,再加入独立评审和返工循环。不要从“做一款 3A 游戏”开始,而要从一个可以在浏览器里验证的 5 分钟体验开始。
原文作者:Chimin;原文发表于 GitHub Daily / Medium。本文为中文改编与评论,并补充了 Dobby 的使用说明。版权归原作者所有。