整个生成器分为两大核心模块，二者如同 “设计蓝图” 与 “施工工具” 的关系，缺一不可。其一为游戏编辑器，负责承载创作环节：设计人员可通过它可视化地搭建游戏场景、塑造人物形象、撰写剧情脉络、设定任务体系，最终将所有创意转化为符合特定格式的游戏资源文件。其二是游戏解释器，承担着体验落地的功能：它能够加载编辑器输出的资源文件，解析其中预设的游戏逻辑，让玩家在剧情推进中做出选择，并最终走向不同的结局。
然而，这款产品的商业化之路注定漫长，两个核心难题始终横亘在前。一方面是剧情素材的匮乏，作为技术开发者，我并不擅长剧情创作与素材制作，目前用于测试的素材极其简陋，远不能满足正式产品的需求；另一方面则是无法省略的真人测试，在实际开发中我发现，游戏产品最耗时的环节并非编码，而是测试 —— 游戏体验涉及情感共鸣、操作流畅度等主观感受，很多问题根本无法通过自动化测试发现，必须依赖真人反复试玩、反馈、优化。
从当前进度来看，解释器的开发已完成约 70%，只要再补充对多媒体素材的支持，就能达到基本可用的状态；与之形成鲜明对比的是编辑器，目前仅有一个功能粗糙的简化版本，完成度最多只有计划的 10%，后续还需投入大量精力完善。
分享这个尚在雏形的项目，难免有 “立 flag” 的嫌疑，毕竟开发过程中随时可能出现意外，最终无法交付也并非没有可能。但我始终认为，亲自探索 AI 编程的能力边界，哪怕最终失败，将过程中踩过的坑、遇到的问题分享出来，对其他尝试用 AI 开发的人而言，或许也能提供一些参考。
而最近，我就遭遇了一个极具代表性的 AI 开发难题 —— 在游戏运行过程中，明明应该在特定场景触发的剧情，却始终没有响应。
第一次遇到这类问题时，我本能地寻求 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 开发中同样适用，直到让 AI 不得不直面核心问题。
第三，聚焦核心问题，用简洁方案解决。解决问题时，要优先选择最优雅、最简洁的方式修复核心漏洞，而非依赖 “补丁” 掩盖问题。只有这样，才能保证产品架构的可靠性与可扩展性，为后续的迭代打下坚实基础。
当然，我并不否认 “兜底方案” 的价值。在实际开发中，面对一些极难重现、暂时无法定位根源的问题，适当采用补丁方案应对突发情况，同时强化日志输出以捕捉异常，也是必要的妥协。但对于那些完全可重现的问题，我们必须坚持找到根源 —— 只要方法得当，精准定位并解决核心问题，往往并不困难。
AI 确实为编程提供了高效的工具，但它并非万能。在 AI 开发的道路上，开发者的主动思考、逻辑判断与 “死磕” 精神，依旧是决定产品成败的关键。
本文来自微信公众号：caoz的梦呓 （ID：caozsay）