AI 无法解决问题的 Case 案例

AI 很强大，但不是万能的。以下是实践中遇到的 几个 AI 无法独立解决或容易出错的典型案例。了解这些边界情况，可以帮助你在使用 VibeCoding 时做出更好的决策——什么时候该坚持、什么时候该换思路、什么时候该人工介入。

Case 1：需要调试分析代码才能解决的问题

1 AI 总是解决不了的 Bug

现象：遇到复杂 Bug 时，AI 给出的修改方案反复无效，问题始终无法解决。

原因：这类问题通常涉及到代码逻辑层面的深层矛盾，仅靠描述报错信息不足以让 AI 定位根因。AI 缺乏对整个代码库的全局理解。

✅ 解决方案：先花时间熟悉代码逻辑（可借助 AI 代码解读功能），然后再向 AI 描述具体的问题场景和代码位置。了解代码逻辑后，让 AI 分析解决问题的效率会大幅提升，特别是在 AI 出现幻觉的情况下。

💡 关键启示：对于反复出现的 Bug，先理解再修复，比盲目尝试更有效。

2 多轮修改未果，熟悉代码后快速解决

现象：游戏退出功能异常 —— seat 被销毁后判断条件导致 handleLeaveTable 未执行，造成 lockedAmount 释放不了。

// 研发 Prompt（原始问题描述）:

离开游戏的时候，因为 seat 被销毁了，判断 (seat?.stack || 0) > 0，造成 gameFlowIntegration.handleLeaveTable 没有被执行到。每次退出都需要保证都执行到。

// AI 的首次回复（未完全解决）:

明白了！问题是 seat 可能在判断之前就被移除或者 stack 已经为 0，但 blockchain leaveTable 仍然需要执行来释放 lockedAmount。让我修复这个逻辑...

// 进一步追问（发现更深问题）:

未完成游戏时点击退出按钮，离开游戏，settleGame 方法也没有被执行到，造成 lockedAmount 释放不了...

✅ 解决方案：这个问题最终是通过多轮深入追问 + 让 AI 熟悉完整代码上下文解决的。单一 Prompt 往往只能解决表面问题，需要持续跟进直到根因被找到。

3 AI 总认为代码调用方式不对

现象：游戏加载器是通过打开⽂件打开器关联扩展名打开的，AI ⼀直认为这是代码调⽤打开的，一直在修改未被调⽤的相关代码，怎么改都没用。

原因：AI 基于"最常见的情况"做假设，而没有考虑到项目的特殊启动方式。这是一种典型的 AI 幻觉 —— 它编造了一个看似合理但实际不符合项目事实的解释。

✅ 解决方案：在 Prompt 中明确说明文件是如何被加载的（通过文件关联扩展名 → 触发特定打开器），纠正 AI 的错误假设。必要时提供实际的启动日志或堆栈跟踪作为证据。

4 修改了 lib 但总不生效

现象：AI 修改了 lib 库中的某个⽅法，但无论怎么改都不生效。

原因：实际 app 使⽤的是 release 版本的 lib 库，但调试时用的是 debug 版本。修改的代码没有编译到正确的版本中，所以看起来怎么改都没效果。

✅ 解决方案：确认构建配置和依赖路径，确保修改的是正在使用的那个版本的代码。这是一个典型的环境配置问题，不是代码逻辑问题。

AI 是强大的协作者，但它也有边界。了解这些边界，你就能更好地发挥它的优势，同时在它力不从心的时候及时补位。Vibe Coding 的精髓在于"人机协作"而非"完全依赖 AI"。