写代码容易，找bug难。这是每个程序员都懂的痛。最近有人做了个有趣的测试：把同一段故意埋了三个逻辑陷阱的Python游戏代码，分别丢给Claude、ChatGPT和Gemini，看谁能真正抓出所有问题。

测试用的项目是作者用Pygame库写的平台跳跃游戏"Captain Hat"。他在三处关键位置动了手脚：第一处把重力常数换成了条件表达式，导致玩家往右走时重力归零，角色会飘向空中；第二处把移动平台的坐标轴交换了，水平动量被当成垂直动量算，角色站在滑动的平台上会鬼畜抖动；第三处最隐蔽——把墙体碰撞的逻辑取反，玩家撞到墙不会被挡住，反而会瞬间穿到障碍物的另一侧。

打开网易新闻 查看精彩图片

prompt极简："这个平台游戏的移动有问题，能找到并修复吗？请详细说明问题所在。"零提示词工程，零上下文铺垫，纯裸考。

ChatGPT 5.5找出了两个。它准确识别了坐标轴交换的问题，指出垂直和水平增量被调包了；也抓到了条件重力的陷阱，发现向右移动时重力被清零导致角色下不来。但它在墙体碰撞上交了白卷，完全没有发现玩家穿墙是因为碰撞逻辑被取反。

Gemini 3.1的表现更惨淡。它只定位到一个bug，就是坐标轴交换那个。对于重力问题和穿墙问题，它要么没提，要么给出了错误的诊断。

Claude Sonnet 4.6是唯一满分的。它不仅找全了三个bug，还准确描述了每个问题的技术细节：坐标轴交换导致动量计算错位、条件重力破坏了速度累积、反转的碰撞检测把"阻挡"变成了"传送"。

这个测试结果有点反直觉。三家都是顶尖模型，日常写代码都能唬住外行，但一到真正的debug场景，差距就拉开了。Claude的优势可能在于它对代码结构的"空间感"更强——穿墙bug本质上是个边界条件问题，需要同时理解碰撞检测的数学表达和游戏物理的语义意图，而不是单纯做模式匹配。

对普通开发者来说，这意味着什么？如果你在用AI辅助写游戏或者做物理模拟，别指望一个模型能包办所有。复杂的逻辑错误往往需要人工复核，尤其是涉及坐标变换和状态机的地方。Claude目前确实是debug环节的更优选择，但即便如此，把它当唯一防线依然危险。

vibe coding（氛围编程）这个词最近很火，说的是不懂代码的人靠AI描述需求就能出作品。但这个测试提醒我们：生成代码只是第一步，当东西跑起来不对劲的时候，你仍然需要能读懂bug的人——或者一个真的能读懂bug的AI。