寫代碼容易，找bug難。這是每個(gè)程序員都懂的痛。最近有人做了個(gè)有趣的測試：把同一段故意埋了三個(gè)邏輯陷阱的Python游戲代碼，分別丟給Claude、ChatGPT和Gemini，看誰能真正抓出所有問題。

測試用的項(xiàng)目是作者用Pygame庫寫的平臺(tái)跳躍游戲"Captain Hat"。他在三處關(guān)鍵位置動(dòng)了手腳：第一處把重力常數(shù)換成了條件表達(dá)式，導(dǎo)致玩家往右走時(shí)重力歸零，角色會(huì)飄向空中；第二處把移動(dòng)平臺(tái)的坐標(biāo)軸交換了，水平動(dòng)量被當(dāng)成垂直動(dòng)量算，角色站在滑動(dòng)的平臺(tái)上會(huì)鬼畜抖動(dòng)；第三處最隱蔽——把墻體碰撞的邏輯取反，玩家撞到墻不會(huì)被擋住，反而會(huì)瞬間穿到障礙物的另一側(cè)。

prompt極簡："這個(gè)平臺(tái)游戲的移動(dòng)有問題，能找到并修復(fù)嗎？請(qǐng)?jiān)敿?xì)說明問題所在。"零提示詞工程，零上下文鋪墊，純裸考。

ChatGPT 5.5找出了兩個(gè)。它準(zhǔn)確識(shí)別了坐標(biāo)軸交換的問題，指出垂直和水平增量被調(diào)包了；也抓到了條件重力的陷阱，發(fā)現(xiàn)向右移動(dòng)時(shí)重力被清零導(dǎo)致角色下不來。但它在墻體碰撞上交了白卷，完全沒有發(fā)現(xiàn)玩家穿墻是因?yàn)榕鲎策壿嫳蝗》础?/p>

Gemini 3.1的表現(xiàn)更慘淡。它只定位到一個(gè)bug，就是坐標(biāo)軸交換那個(gè)。對(duì)于重力問題和穿墻問題，它要么沒提，要么給出了錯(cuò)誤的診斷。

Claude Sonnet 4.6是唯一滿分的。它不僅找全了三個(gè)bug，還準(zhǔn)確描述了每個(gè)問題的技術(shù)細(xì)節(jié)：坐標(biāo)軸交換導(dǎo)致動(dòng)量計(jì)算錯(cuò)位、條件重力破壞了速度累積、反轉(zhuǎn)的碰撞檢測把"阻擋"變成了"傳送"。

這個(gè)測試結(jié)果有點(diǎn)反直覺。三家都是頂尖模型，日常寫代碼都能唬住外行，但一到真正的debug場景，差距就拉開了。Claude的優(yōu)勢可能在于它對(duì)代碼結(jié)構(gòu)的"空間感"更強(qiáng)——穿墻bug本質(zhì)上是個(gè)邊界條件問題，需要同時(shí)理解碰撞檢測的數(shù)學(xué)表達(dá)和游戲物理的語義意圖，而不是單純做模式匹配。

對(duì)普通開發(fā)者來說，這意味著什么？如果你在用AI輔助寫游戲或者做物理模擬，別指望一個(gè)模型能包辦所有。復(fù)雜的邏輯錯(cuò)誤往往需要人工復(fù)核，尤其是涉及坐標(biāo)變換和狀態(tài)機(jī)的地方。Claude目前確實(shí)是debug環(huán)節(jié)的更優(yōu)選擇，但即便如此，把它當(dāng)唯一防線依然危險(xiǎn)。

vibe coding（氛圍編程）這個(gè)詞最近很火，說的是不懂代碼的人靠AI描述需求就能出作品。但這個(gè)測試提醒我們：生成代碼只是第一步，當(dāng)東西跑起來不對(duì)勁的時(shí)候，你仍然需要能讀懂bug的人——或者一個(gè)真的能讀懂bug的AI。