Claude Code 48小时造出完整游戏

作者用 Claude Code 花了不到一个周末，从零做出一款能玩的平台跳跃游戏。更扎眼的是成品质量——画面、物理、敌人 AI 全在线，完全不像"AI 随便糊出来的 demo"。

这事本身不算新闻。但作者的身份特殊：他不是程序员，而是把自己定位为"协作伙伴"，只在关键节点做微调。这种模式下，大型语言模型（LLM，Large Language Model）的产出效率和质量，可能比我们想象的更激进。

一次"最小上下文"压力测试

作者管这叫"最小上下文基线"实验。他给 Claude 的 Sonnet 4.6 版本扔了一段自然语言描述，要求用 Python 3 和 Pygame 做一款平台游戏。主角是只会跳的猫，敌人是"海盗猫"，要在平台上巡逻，还有移动平台和弹射物战斗系统。

这段提示词看起来啰嗦，但作者说这是反复测试后的"甜蜜点"——细节不够，模型会自由发挥到离谱；细节太多，又变成人工写伪代码。Sonnet 4.6 的第一次输出是个骨架：能跑、能跳、能死、能赢，但角色只是色块。

物理、AI、胜负条件全对，只有美术是 placeholder。

这个起点已经比大多数"AI 写代码"的 demo 扎实。作者之前的测试里，Claude 在这种"零 hand-holding"场景下表现最好，这次也没翻车。

从骨架到成品：协作而非代劳

真正的变量是第二阶段。作者没有继续当甩手掌柜，而是介入微调——改动画、调手感、修 bug。这种"人机结对"的模式，和完全自动化生成是两回事。

结果是游戏完成度远超预期：重力跳跃有惯性反馈，敌人 AI 会巡逻和追击，移动平台的节奏和关卡设计配合到位。最意外的是视觉风格——作者用 AI 图像工具做了像素风素材，最终成品看起来像是小型独立游戏团队的周末项目，而非"vibe coding"的粗糙实验。

「很难把这种流畅的游戏体验归因于一个没写过一行代码的人。」作者在复盘里写道。

"Vibe coding"的边界在哪里

这个词最近很火，指用自然语言和 AI 协作写代码，而非手工敲击语法。支持者的论点是民主化——不懂 Python 的人也能做游戏。怀疑者则指出，调试和架构能力仍是瓶颈，AI 只是换了个界面包装复杂度。

这个案例的特殊之处在于：作者明确承认自己做了"meticulous fine-tuning"（细致微调）。他没有假装这是全自动魔法，反而暴露了 vibe coding 的真实成本——你需要知道哪里该干预，以及怎么干预。

换句话说，这更像"AI 放大了合格产品经理的产出"，而非"零门槛全民开发"。作者的产品经理背景可能是隐形变量：他懂游戏设计的基本语法，只是不懂 Python 语法。

Claude 的意外领先

作者同期测试了多个 LLM 编程工具，包括 OpenAI 的 Codex 和 Google 的 Antigravity。Claude Code 在"有限上下文启动项目"这个细分场景下胜出，这本身值得注意。

Sonnet 4.6 的表现暗示：Anthropic 在代码生成的"首次响应质量"上下了功夫。不是指最终代码多优雅，而是指从自然语言到可运行骨架的转化率。对于游戏这种需要快速验证玩法的领域，"先能玩"比"代码漂亮"重要十倍。

作者没有公开具体对比数据，但提到 Claude 在"零 hand-holding"条件下的稳定性是选择它的主因。其他模型可能需要更多轮对话才能达到同等起点。

一个被忽略的细节

游戏最终的美术和音效并非 Claude 生成。作者用了独立的 AI 图像工具做素材，这意味着完整 pipeline 涉及多个模型协作。vibe coding 的叙事往往聚焦于"一句话出代码"，但真实生产链路更碎片化。

这也解释了为什么成品"不像 vibe coding"——它本来就是混合工作流的结果。代码层用自然语言驱动，资产层用图像生成，调试层用人工判断。三层叠加，才抹掉了 AI 生成物的典型粗糙感。

作者最后抛出的问题是：当非程序员能用周末做出可玩的原型，游戏行业的"想法验证"成本会降到多低？以及，那些依赖"执行门槛"保护创意的中间层开发者，还能守住多久的护城河？