Vibe Coding 游戏开发失败记：我让 AI 做一个苹果，最后得到了一套验收系统

我最近尝试用 Vibe Coding 做一款 Apple TV 体感切水果游戏。

目标说起来很简单：水果飞出来，玩家挥手切开，屏幕上出现漂亮的切面、飞溅的果汁，以及让人想再来一刀的反馈。

折腾很久以后，我拥有了 Blender 自动生成脚本、USDZ 导出流程、PRD 素材清单、哈希校验、真机截图、FPS 日志、内存数据，还有一个独立的资源验收页面。

唯独没有一个真正好看的苹果。

如果以最初的目标衡量，这次尝试失败了。它也让我看清了一种很容易发生的偏移：AI 不断完成可验证的任务，我却逐渐忘了检查，这些任务有没有让游戏更好。

从“做个苹果”到“建设资产管线”

最初的问题很具体：苹果模型不好看。

AI 给出的方案也很合理：从产品需求文档（PRD）提取参考图片，建立参考素材清单（reference manifest），用 Blender Python 参数化建模，生成完整苹果和预切开的两半，再导出 USDZ，放进 RealityKit 真机渲染，记录性能，比较参考图与最终效果。

每一步单独看，都有道理。串在一起执行时，任务的重心却悄悄变了。

我们花越来越多的时间，证明资产被正确生成、导出和加载；而那个最初的问题——苹果到底好不好看——始终没有解决。

管线越来越完整，苹果却依然不好看。

我当时陷入的误判是：

工程正在变得更完整，所以产品一定正在变得更好。

这次经历说明，至少在这个项目里，两者并没有同步发生。

一、技术合法，不等于视觉成功

旧版苹果的问题，人眼一秒钟就能看出来：上下都是尖的，像个陀螺；叶子像绿色塑料片；切面平得像纸板；纹理到了 RealityKit 里，还被横向拉伸了。

但开发过程中，另一类结果不断给我安慰：

• usdchecker Success!
• USDZ 可以加载，左右两半节点都存在。
• App 构建成功，资源正确打进安装包。
• 一次真机运行记录到 49.5 FPS、214 MB 内存占用。

这些检查有价值，但它们回答的是文件、构建和运行层面的问题。一次性能记录也不能代替对完整游戏稳定性的判断。

它们更无法回答：这个苹果是否达到了我想要的视觉质量？

一个丑苹果，也可以拥有完美的文件结构。 塑料感十足的切面，同样可以顺利通过技术检查。

问题不在于做了验证，而在于我把验证通过，当成了视觉目标正在实现的证据。

二、局部修补，未必能挽救整体方向

第一版苹果像陀螺，于是修改径向轮廓。

叶子悬空，于是调整坐标。

果梗在 Blender 里看得见，到了 RealityKit 里却消失，于是把曲线转换成网格。

种子出现在切面的背面，于是修正法线方向和偏移符号。

切面缺少结构，于是增加果核囊。

每一次修复都能说清楚原因，也确实解决了局部问题。但整体效果始终没有接近参考图。

在这次协作中，只要现有方案还有参数可调、代码可改，AI 就会继续沿着它往前走。而我也不断用“继续优化”推动下一轮，却很少重新审视：这条路线，是否适合当前的视觉目标？

参数化建模可以生成稳定、可复现的几何结构。但我当时采用的模型、材质和纹理方案，没有表现出参考图里的那些细节：不规则果形、细密果皮、叶片脉络、湿润高光，以及自然的果肉纤维。

这不意味着参数化方法做不到高质量资产。它意味着，继续给当前方案增加参数，未必是最有效的选择。我们本该更早比较其他路线，例如手工修形、采用成熟资产，或重新制作材质。

结果却是：我花了大量时间，让一个尚未证明可行的方向变得更可靠。

三、验收项很多，停止条件却不明确

项目有不少验收项，却缺少真正能约束迭代的视觉标准。

“苹果要好看”是一种愿望，还不是可执行的判断。至少还有几件事没有说清楚：

• 在实际游戏镜头下，什么样的轮廓和材质才算过关？
• 切面只要能看到果肉与种子就够了，还是必须接近参考图的质感？
• 连续两轮真机效果不理想后，应该继续微调，还是更换路线？
• 第一颗水果最多允许投入多少时间？

这些判断未必都能变成数值，但可以用同机位对照图、明确的缺陷清单和人的审核来落实。

缺少边界时，下一轮工作总能找到理由：再调一次参数，再修一个细节，再截一张图。每一轮都有新的产出，却没有人负责宣布当前方法已经不值得继续。

我需要给 AI 的，不只是继续工作的指令，还有一个明确的失败出口：

如果第二轮真机结果仍未达到约定的视觉质量，请停止微调，列出主要差距，评估当前路线是否需要替换，再决定下一步。

这不是把审美判断交给 AI，而是让它在约定的节点，把路线选择重新交回我手里。

四、生产设施，掩盖了产品进度

这次开发留下了不少成果：参考图索引和哈希、模型与纹理生成脚本、USDZ 文件、对照图、验收页面、真机自动截图、性能日志，以及包内资源检查。

它们都能帮助后续生产。但回到游戏本身，另一份清单仍然摆在那里：

• 正式玩法还没有替换成新模型。
• 切割物理没有完整接入。
• 果汁粒子没有围绕新资产调校。
• 碰撞、对象池和水果生成逻辑仍使用旧方案。
• 苹果的最终美术质量没有通过，其他水果也还没完成。

我已经搭起了不少生产设施，却还没有产出第一颗合格的水果。

在有明确分工的团队里，制作人、美术负责人或里程碑评审可能会提醒这种偏移。一个人用 AI 开发时，我同时承担产品、开发和验收的角色。只要注意力被技术细节吸走，就很容易把“今天完成了很多任务”理解成“游戏取得了很大进展”。

五、游戏体验，需要持续回到真实画面

普通软件也需要体验判断，只是在这次游戏开发里，这种判断的缺位尤其明显。

水果模型结构正确，不代表它有重量感；切割逻辑正确，不代表切起来爽；动画按时播放，也不代表画面和声音有节奏。

自然不自然、有没有生命感、切下去是否有冲击力、玩家愿不愿意再玩一次——这些问题，很难仅靠单元测试、文件检查和性能日志回答。

它们需要在真实镜头里观察，在真实设备上操作，然后做出取舍。

AI 能帮助实现、排查和迭代，但这次经历让我意识到：如果我没有持续盯住实际体验，开发就会自然滑向那些更容易描述、执行和验证的任务。

技术上的问题越来越少，体验上的问题却可能原封不动。

下一次，我会怎样开始

首先，先完成一颗苹果的最小垂直切片：

1. 一个达到视觉质量线的整果。
2. 一个可信的切开状态。
3. 一个实际游戏中的镜头。
4. 一次包含动作、果汁、声音和反馈的切割。
5. 一次真机试玩。

这个闭环通过以后，再考虑怎样批量生产其他水果。管线应该从成功案例里提炼，而不是在成功案例出现以前，就按二十种水果的规模设计。

其次，提前约定检查点和投入上限。每轮都用相同镜头比较效果；连续两轮没有解决关键视觉缺陷，就暂停当前路线，比较替代方案。时间预算也要提前设定，避免无限微调。

第三，把验收优先级写清楚。对这个项目，我会按下面的顺序分配注意力：

1. 好不好看。
2. 切起来爽不爽。
3. 真机运行是否稳定。
4. 资产结构是否规范。
5. 自动化流程是否完善。

这些工作当然可以交叉进行，但后面的进展不能抵消前面的失败。资产检查全绿，也不能替一个仍然难看的苹果过关。

最后，Vibe Coding 并不意味着可以放弃判断。

AI 可以写代码、跑命令、生成模型、分析日志，也可以辅助比较视觉差异。但“这个苹果是否已经值得放进游戏”，仍需要我根据真实画面和试玩体验作出决定。

玩家只会看到那个苹果

这次尝试并非毫无收获。

我确认了 Blender 与 RealityKit 的表现差异，打通了 USDZ 导出和 Apple TV 真机验证，也积累了性能检查与资源打包的经验。

但按最初的目标衡量，它仍然失败了。

玩家不会看到 reference manifest、哈希校验，也不会因为一句 usdchecker Success! 就觉得切水果更好玩。

玩家只会看到那个苹果。

而它还不够好。

这次 Vibe Coding 最值得我警惕的地方，就是它制造进展感的速度：代码在增加，工具在完善，日志在变长，任务不断被标记为完成。

直到我抬起头，重新看了一眼真正的游戏，才发现自己离最初想做出的体验，还很远。