笨 AI 解决不了的编程问题，为什么换一种协作方式就解决了？
你有没有遇到过这种情况？
用 AI 编程，明明只是一个看起来不复杂的 Bug，却反复修不好。
改了一个地方，另一个地方又出问题；增加一个判断，问题暂时消失，过一会儿又复现；修复了五六次，代码越来越复杂，Bug 却依然存在。
最后，你开始怀疑：是不是这个 AI 太笨了？
其实，还有一种方法，可能比不断换模型更有效。
让当前的 AI 描述问题，再把这份描述交给另一个更擅长分析的 AI，让它负责诊断。
一、为什么 AI 会陷入反复修 Bug 的循环？
以我开发 Godot 引擎的自定义 Dock 系统为例。
我给编辑器增加了类似 Qt-ADS 的自动隐藏侧栏功能。侧栏可以固定、取消固定，还需要与原有的编辑器布局协同工作。
开发过程中，陆续出现了几个问题：
- 菜单图标运行一段时间后消失；
- 侧栏隐藏后，主界面仍然留有空白；
- 侧栏按钮被 Dock 区域遮挡；
- 修复一个状态后，又可能影响另一个状态。
AI 并不是完全不会写代码。它可以修改函数、增加条件、调整布局参数。
但问题在于：这些现象可能并不是独立的 Bug。
它们可能共同来自几个更深层的原因：
- 节点的父子关系发生了变化；
- 布局状态与可见状态没有同步；
- 绘制顺序与实际坐标被混为一谈；
- 对象销毁后，管理列表没有及时更新。
如果 AI 每次只盯着当前现象，就容易陷入一种循环：
发现症状 → 修改代码 → 暂时改善 → 出现新问题 → 再次修改。
这不是简单地多写几行代码就能解决的。
二、一个关键转变：让 AI 先描述问题，而不是继续改代码
当问题反复出现时，可以改变工作方式。
不再要求当前 AI 立即修复，而是让它先整理一份完整的问题报告，包括：
- 项目的整体架构；
- 相关组件之间的关系；
- Bug 的具体表现；
- 已经尝试过的修复；
- 每次修复的结果；
- 仍然无法解释的现象；
- 最值得进一步检查的代码路径。
这样做的意义，是把散落在代码、日志和多轮对话中的信息，变成一份结构化的诊断材料。
尤其重要的是，必须保留失败的修复记录。
如果只告诉第二个 AI“这里有一个 Bug”，它可能重新提出已经失败过的方法。
如果告诉它“这里已经修过八次，哪些方法有效，哪些方法无效”，它就能更有针对性地寻找根因。
三、再让更擅长诊断的 AI 做一次独立分析
把问题报告交给另一个 AI，并明确要求它：
- 先检查问题之间是否存在共同根因；
- 区分已确认事实与待验证假设；
- 不要直接叠加补丁；
- 优先分析架构、状态转换和对象生命周期；
- 给出验证方法，再提出最小修复方案。
例如，侧栏被遮挡，不一定是绘制顺序的问题，也可能是布局位置错误。
侧栏隐藏后仍有空白，也不一定是可见性设置失败，还可能是主容器仍然保留了固定偏移。
当 AI 开始区分这些可能性，而不是立即修改代码时，诊断质量就可能出现明显提升。
这里有一个重要区别：
第一个 AI 可能一直在回答“怎样让这个现象消失”，第二个 AI 则可能开始追问“究竟是什么机制导致了这个现象”。
这才是协作真正产生价值的地方。
四、最有效的方式，不一定是让聪明 AI 重写整个项目
更合理的分工可以是：
第一步：执行 AI。
负责理解项目、修改代码、运行测试、记录问题。即使它暂时找不到答案，也可以帮助收集现场信息。
第二步：诊断 AI。
负责独立分析架构、审查历史修复、识别潜在根因，制定排查顺序。
第三步：执行 AI。
根据诊断方案修改代码，再通过编译和测试验证结果。
第四步：必要时再次会诊。
如果验证失败，就把实际结果、日志和新发现补充进问题报告，再让诊断 AI 重新判断。
这相当于建立一个反馈闭环，而不是让两个 AI 各自猜测。
当然，如果执行 AI 本身已经足够强，或者它拥有完整的源码上下文，也可以直接完成全部工作。多模型协作不是越多越好，而是在反复试错成本已经很高时，引入独立诊断。
五、为什么这种方法可能节省成本？
因为复杂 Bug 的成本，不只在于写代码，还在于反复尝试错误的修复方向。
假设一次错误修改需要十分钟，而你连续尝试十次，就可能花掉一百分钟，还留下更多需要维护的代码。
如果先花几分钟整理问题，再通过独立分析排除几个错误方向，即使第二个 AI 不能直接给出答案，也可能减少后续试错。
但这并不意味着第二个 AI 一定正确。更强的模型同样会误判，也可能根据不完整的描述得出错误结论。
因此，真正重要的不是盲目相信更聪明的 AI，而是让它提出可以被源码、日志和测试验证的假设。
诊断提供方向，证据决定方向是否正确。
六、这套方法还可以推广到 AI 编程以外
它其实符合一个更普遍的问题解决规律：
- 执行者负责收集现场信息；
- 分析者负责寻找因果关系；
- 执行者根据方案采取行动；
- 结果反馈给分析者，修正原来的判断。
在软件开发中，这可以是两个不同模型之间的协作。
在其他领域，也可以是一个人负责实践，另一个人负责审查；或者同一个人先记录事实，再换一个角度独立复盘。
不同视角的价值，不在于它们一定更聪明，而在于它们可能摆脱之前形成的思维惯性。
结语
以后遇到 AI 反复修不好的 Bug，不要只想着换一个模型，也不要急着继续增加补丁。
可以先问它：
“请停止修改代码。把当前架构、问题现象、历史修复、失败原因和待验证假设整理成一份完整报告，让另一个 AI 能够独立诊断。”
然后再让更擅长分析的 AI 审查问题，并要求它先找根因、再给修复方案。
AI 编程的进步，不只是让 AI 更聪明，也包括学会怎样组织 AI 的工作。
当一个 AI 暂时解决不了问题时，它仍然可能有价值：它可以帮你把问题描述清楚，让另一个 AI 更有机会解决问题。