零基础6周做出可玩游戏：Opus 5.5 + Godot实战拆解

一位没有任何编程和游戏开发背景的独立开发者，用约六周时间把自己的手绘稿和点子变成了一个可玩的原型。这个项目把《仙境传说》和《怪物猎人》的玩法揉在一起，开发主力是 Claude Code 搭配 Opus 5.5，订阅的是 Claude Max 20×。原始分享来自 Reddit，作者表示这只是系列第一部分，后续还会继续更新。

从零到可玩：6周做了什么

这个项目没有固定 scope。每个功能都从想法和研究开始，实现后进入实际游戏里测试和调整。开发者把注意力放在一次只做一个小功能，先看它「长什么样、手感如何」，再决定是否继续推进。

这种做法和传统游戏开发流程有明显差异。通常人们会先写设计文档、定框架，再逐步填充内容；而这里更像是在 AI 辅助下高频试错，用可玩性反馈替代文档推演。对一个没有代码基础的人来说，这降低了起步门槛，也避免了在抽象设计阶段卡死。

美术风格的一致性从哪来

真正让这个项目出挑的是视觉统一度。开发者专门做了一个 skill 来描述游戏的美术方向，每一张成功的图片 prompt 都会存成 JSON，用来引导后续生成。每个新资产在开工前都先确定好视觉目标。VFX 和 shader 在 Obsidian 里也有独立拆解，记录特效如何分层，保证规模变大后外观不跑偏。

这套流程本质上是把「美术指导」从人的直觉变成了可检索的资产库，对没有美术团队的独立开发者来说，是一个值得借鉴的思路。

文中的「skill」指 Claude Code 这类 AI 编程代理中的可复用指令模块：通常以 Markdown 文件形式存放，内含角色设定、操作步骤与约束条件，代理在相关任务中自动加载执行。它不同于一次性 prompt，而是把反复使用的工作方法固化成可调用资产。同理，「prompt 存成 JSON」是把有效的图像生成提示词按结构化字段（风格、材质、光照、镜头）保存，便于检索、复用与批量微调，从而在多轮生成中维持一致的视觉语言。

三个自定义 Claude skill 是核心

整套工作流里最有参考价值的是三个自定义 skill。

route：按任务复杂度分派模型

「route」会评估任务，把合适的工作分给 Sonnet 或 Haiku，再由 Opus 审阅结果。这样能在保留质量的前提下省 token。对于长期用高配模型跑项目的开发者，这个设计直接控制了成本。

Claude 的模型家族目前分为 Opus、Sonnet、Haiku 三个层级：Opus 能力最强但单 token 成本最高，Sonnet 在能力与成本之间折中，Haiku 最轻量、响应最快、价格最低。所谓「token 成本」，指模型按输入与输出的 token 数量计费，长上下文与长输出会显著放大开销。把简单任务（格式整理、命名、小段样板代码）下放给 Haiku/Sonnet，只让 Opus 处理架构决策与代码审阅，是 AI 辅助开发中常见的成本优化策略，代价是需要额外的分派逻辑与质量兜底。

handoff：上下文满了就换新会话

「handoff」用同样的配置和继续所需上下文开一个新会话。当上下文快满时，工作流不会中断。这对长时间迭代的项目很实用，因为长会话中上下文衰减是常见痛点。

大语言模型的上下文窗口是一次会话中可容纳的 token 总量上限，包含系统提示、历史对话、文件内容与模型输出。当对话不断累积接近上限时，模型对早期信息的注意力会被稀释，出现「上下文衰减」——忘记早前约定、重复犯错或忽略关键约束。handoff 的思路是把当前进度、已定决策和待办事项结构化写入一份交接文档，在新会话中以精简上下文重启，从而在不丢失关键状态的前提下重置窗口，这也是长周期 AI 协作项目常见的工程手段。

Re-searcher：把研究结论沉淀下来

「Re-searcher」负责核验研究中的断言，并把结论存进 Obsidian。这样原始研究会一直保留，而不是一步步缩水成「摘要的摘要」。这个 skill 解决的是 AI 辅助开发里一个隐蔽的问题：多轮对话后，早期结论会被不断压缩、失真。

为什么选 Godot 和这些工具

Godot 被选中的原因很具体：开源、容易为它构建自定义工具、支持 headless 运行脚本，这些特性让它和 AI 协作更顺手。headless 执行意味着 AI 可以直接跑脚本验证，而不必每次都手动点编辑器。

3D 资产方面，较大的资产由 Tripo P2 从参考图生成；较小的采集物在 Blender 里建模，再用匹配的参考图在 Tripo 里贴图以压低成本。Tripo 订阅大约每月 20 美元。这套组合把「生成」和「手工控制」分开，既控制成本，也保证关键资产不失控。

Godot 是一款 MIT 协议的开源游戏引擎，支持 2D 与 3D，脚本以 GDScript 为主，也可用 C#。它的 headless 模式指不打开图形界面、仅以命令行运行引擎，可用于跑测试、导入资源、执行构建脚本，非常适合让 AI 直接调用并读取输出结果做自动验证。相比 Unity 与 Unreal，Godot 的编辑器扩展与插件体系更轻量，用 GDScript 就能编写自定义工具面板，这使得「为 AI 工作流量身定制工具」的门槛明显更低。

值得借鉴的几点

这个案例的价值不在于「6 周做出游戏」这个噱头，而在于它展示了一套可复用的 AI 辅助开发流程：用 skill 管理模型分工、用 handoff 对抗上下文衰减、用 Obsidian 沉淀研究、用 JSON prompt 库锁定美术风格。开发者本人也表示没有固定 scope，靠的是逐个功能验证手感。

提一嘴，这些细节来自一次访谈分享，目前只有单一来源，实际效果和可复制性还有待更多开发者验证。作者提到这只是系列第一部分，后续如果放出更多实现细节，这类工作流的参考价值会更高。