最近，我在用 AI，依然是零代码模式，开发一款新的游戏，其实更准确地说，是开发一款新的，养成类游戏生成器。
那么这个产品有两大部分组成，一部分是游戏的编辑器，就是如何设计场景，人物，剧情，任务，以及最终的多结局选择。方便设计人员灵活地设计剧情养成游戏 （目前只考虑单机版），并通过编辑器做出符合特定格式要求的游戏资源文件；第二部分是游戏的解释器，也就是加载前面所说的游戏资源文件，然后执行资源文件里设定的游戏逻辑，让玩家可以进行游戏的体验，在剧情中做出选择，并基于选择实现不同结局。
这个产品化的进度不会很快，因为有几个制约，第一是需要大量的剧情素材，而我自己不擅长制作素材，目前测试可以说是非常简陋的。第二是测试过程还是无法省略，实际上我发现，游戏产品，最消耗时间的是测试，游戏体验必须是真人寻找某些感觉，自动测试很多问题是无法确认的。
目前的进度是解释器部分已经完成了差不多 70%，增加一些多媒体素材的支持基本上就是可用版本了；但编辑器只有一个非常粗糙的简化版本，可以说最多只完成了计划的 10%。
讲这个其实有点立 flag 的感觉，总觉得后续很容易翻车，到最后无法交付，不过为了让读者更好的理解 AI 编程的能力边界，我觉得还是自己要多探索，就算失败，把过程中踩过的坑分享也是有意义的。
那么这个背景里，游戏资源文件会存在一些剧情任务，是携带比较复杂的条件来触发，而解释器需要利用合理的规则，对处于不同条件，优先级的任务和事件，也可以说是剧情，进行推进和展示。
然后最近就遇到一个问题，就是我认为明明应该在特定场景触发的剧情，没有触发。最开始遇到这类问题，让 AI 解决，AI 认为它的设计没有问题，然后提供了一个所谓兜底方案，在无法正确触发应有任务的情况下，设计了额外的中间任务进行任务传递。我当时也是偷懒了，发现不管怎样，至少剧情跑通了，就没有深究。
然后今天再度遇到类似的问题，又出现了明明应该触发的剧情没有触发，AI 再次认为自己的设计没有问题，再次给出了所谓的兜底方案，也就是通过优先级的调整确保任务触发，但是且慢，我就觉得不对劲，我就让 AI 详细解释它的触发条件和优先级策略，然后我觉得没理由，因为我想不通有什么高优先级的任务会阻塞这一场景。但 AI 只提供了触发因果的介绍，却拒绝承认自己哪里有问题。
这时候怎么办呢，首先，我让它在游戏中建立了一个数据调试页面，因为很多游戏数据是隐藏显示的，我在触发场景时打开数据调试页面，核对触发的数值，和 AI 给出的数值触发公式对比，发现这里没有问题。
然后，我让 AI 输出触发前判断的日志，然后再度进入该场景，查看日志输出，结果发现，这段代码的判断逻辑执行了，也生效了，并且认为这个事件值得触发，也写入了触发队列。这个发现过程也不是我自己确认的，是我把它生成的日志扔回给 AI，AI 自己基于日志给我的解读。
但还是没有触发，再往后，我继续要 AI 输出日志，我让它把所有触发的列表和记录都展示出来，然后继续把这段日志扔给 AI，并询问为什么没有触发前面已经判断应该触发的场景任务。然后 AI 再给我解释，说是因为前面有一个全局事件连续唤醒了多次，塞满了队列的触发池，才导致我说的这个任务事件没被触发，这时候，经过我不断地要求细分日志，不断地把日志赛回给他，AI 才真的知道问题在哪里，但它还只是装无辜地给我解释。
然后我就很气愤了，我告诉 AI，这个全局事件根本不应该连续被唤醒和触发，这难道不是 bug 么，AI 这才恍然大悟，并且承认了自己的错误。这个问题解决后，我再测试的时候，就特意多测试了一些其他场景，注意到之前的那个问题也随之解决了，之前 AI 设计的所谓的中间过渡任务属于脱裤子放屁，多此一举，完全可以取消了。
那么在这个过程中，我不断地要求 AI 解释它的触发逻辑和流程，不断地询问它相关的问题，同时 AI 也不断地给我各种不靠谱的建议和临时解决方案，那么基于我对逻辑的理解和技术的认知，大部分都被我直接否决，否决的原因很简单，没有定位到真正原因。
回避问题，试图通过各种奇怪的方式来让当下的流程跑通，但根源没有解决，那么一个核心逻辑是跑不通的，以后整个系统就会不断地为此增加各种奇怪的补丁。而解决完真正的问题后，流程通畅了，逻辑简洁，对于剧情设计和编辑器来说，也省了很多本不该有的麻烦。
这也是今天想跟一些通过 AI 编程的同学分享的新鲜案例。你不死磕，它就逃避，很多所谓兜底方案，中间方案，都是回避问题，都只是为了让你特定目标满足，而无视根源上的缺陷。这种问题不解决，最终的麻烦就会没完没了，无穷无尽。所以如果需要做一个可以持续维护，持续发展的产品，面对这类问题，需要死磕，需要让 AI 真正找到原因并修复。
而这个死磕的过程，第一，你要不断让 AI 解释它的逻辑和流程，并且基于你的逻辑感去判断，去辨别，去核对。第二，在 AI 无法确认自身问题的时候，让它输出日志，输出关键数据，然后不断基于数据和日志追问，让出现问题的潜在范围不断缩小 （经典的调试思维），直到 AI 真正能发现，或者解释出它的核心问题所在。第三，解决核心问题，用最优雅最简洁的方式来解决核心问题，而不是各种乱打补丁，这样的架构才是可靠的，可持续的。
当然，我也承认，有时候，非常难确认的问题，做一些兜底方案，一些补丁方案，也是有用的，我自己也有过这样的经历，但是，至少，在完全可重现的问题上，尽量定位到根源问题；以前，遇到一些非常难重现的问题，我也是没办法做到精确的调试和定位，只能一边用兜底方案应对，一边强化日志输出争取捕捉到异常；但如果是可完全重现的问题，那么基本上找到根源问题还是能做到的。
