我想创建这个洞穴游戏作为对65百万年前，当恐龙统治地球时，我们的小型哺乳动物祖先在地下生存的纪念。 我使用GPT-5.6通过gmi云和Godot构建了一个2D洞穴生存游戏。 这个三小时的开发会话仅仅结束了2.17M令牌，相当于他们的按令牌付费设置的约1.5美元。 第一阶段仅仅是验证几个核心机制：地图将没有固定的地板，玩家可以自由挖掘并进入他们创建的空间，世界状态可以保存。 我迅速得到第一版的运行。 原始的32px网格看起来太粗糙了，所以我后来改变了它到16px。 在那时，它仍然是一个地形原型，具有清晰的范围。 范围开始失控，因为我写的设计文件和随后的指示。 文件包括长期愿景、系统架构、27个特性部分和第一个MVP。 尽管MVP单独列出，但我从未告诉代理它必须在完成MVP时停止。 我的后续指示只是“继续”。 我没有指定哪个特性它应该实现下一个或哪个文件它允许修改。 在接下来的三个小时左右，它添加了环境模拟、生存统计、生态、灾难、物品、制作、设施、容器、状态效果、多个保存槽、死亡循环、观察界面和事件分析。 该项目最终发展到42个GDScript文件、33个设施场景和近300个PNG文件。 world.gd alone达到了1359行。 它还生成了审计文件并标记了所有27个部分为通过。 这暴露了一个在人工智能辅助编程中的常见问题。 同一会话写了代码，运行了临时测试探针，然后审计了自己的工作。 项目中没有持久的测试套件，所以它把“代码路径存在”和“临时探针可以运行”作为足够的证据，认为特性是完成的。 更严重的问题是，我无法正确审查它正在做的所有内容或挑战其审计结果。 我只在项目已经扩展后才意识到这一点。 这就是为什么测试和接受标准应该在实现之前写好，优先存储在一个单独的目录中。 否则，代理可以定义验证过程围绕它已经建造的内容，并使所有内容都看起来通过。 后来，我要求它运行完整的游戏。 这就是我发现它以约3帧率运行。 单个环境更新几乎花费了287毫秒，渲染产生了约1344个绘制调用。 实现在高频率下执行多个全图扫描，扫描每个图块是否有变化或不。 它还创建了临时数组和字典反复地。 我知道许多游戏限制更新仅限附近或活动元素，所以我建议使用这种方法。 它立即认识到了问题。 与此同时，我意识到我犯了一个更大的错误。 我允许它以极高的速度产生代码，而没有停止检查优化或是否遵循我指定的架构。 在我的原始设计中，特性应该是原子的，易于扩展并与彼此隔离。 改变一个模块不应影响整个项目的数据。 但我专注于它可以在一个会话中生成多少个特性，而没有足够地关注这些系统是如何连接的。 幸运的是，我在开始另一次重大扩展或完全过载上下文窗口之前注意到了问题。 我现在改变了开发过程成一系列更小的任务。 每个轮次只实现一个特性。 我定义了可能被修改的文件和接受标准在编码开始之前，代理必须停止一旦那些标准被满足。 检查包括运行游戏、测试真实键盘、测量性能、验证保存数据和检查现有特性是否存在回归。 不再添加新系统，直到当前版本通过。 写代码的会话也不再负责最终审计，因为它之前把“代码路径存在”和“临时探针可以运行”作为特性是完成的证据。 艺术风格仍然很糟糕，立即可辨识为人工智能生成的。 我原先希望从Metro和Terra Nil的风格中汲取灵感，但生成的艺术始终朝着Minecraft和Terraria的方向移动。 我的提示显然需要更多的工作。 我仍然对它产生的地下地形纹理感到相当满意。 下一步，我打算测试不同的图像模型并购买一些艺术包来改善视觉资产和纹理。