出品 | 51CTO技術(shù)棧（微信號(hào)：blog51cto）

今天，一篇Reddit上的帖子走紅了，光看題目就很有料：

Claude Opus 幫我解決了一個(gè)我四年來都找不到的“白鯨級 bug”

圖片

發(fā)帖人是一位有 30 年經(jīng)驗(yàn)的前 FAANG C++ 工程師，是團(tuán)隊(duì)里負(fù)責(zé)給bug清場的大佬級角色。

但這一次，他坦言被 Claude Opus “徹底震撼了”。

這個(gè) Bug 有多棘手？它來自 4 年前的一次架構(gòu)級重構(gòu)，涉及約 6 萬行代碼。

雖然解決了一堆歷史問題，卻也悄悄埋下了一個(gè)極邊緣的邏輯隱患：某個(gè) shader 在特定條件下無法運(yùn)行。

發(fā)帖人為此斷斷續(xù)續(xù)查了四年、投入了至少 200 小時(shí)，但始終無解。發(fā)帖人為此非常抓狂，但是又沒到為了這個(gè)bug停止其他工作的地步。

直到 Claude Opus 4 出現(xiàn)。

 他和 Claude 合作了幾個(gè)小時(shí)，總共用了大約 30 個(gè)提示詞、一次重啟——就這樣，這個(gè)被他稱作“白鯨”的 bug，被成功捕獲。

最終發(fā)現(xiàn)的問題不是代碼寫錯(cuò)了，而是：舊架構(gòu)之所以能正常工作，是因?yàn)榧軜?gòu)偶然性帶來的結(jié)果，新架構(gòu)改變了路徑，卻沒人意識(shí)這種“偶然”被打破了——新架構(gòu)根本沒有容納原本存在的那個(gè)邊緣情況。

博主表示，之前陸續(xù)嘗試過GPT-4.1、Gemini 2.5、Claude 3.7， 全部失敗。

 只有 Opus 4，找到了問題根源。

評論區(qū)有人質(zhì)疑這是編故事：哪有 AI 能跨越 6 萬行代碼找出一個(gè)架構(gòu)級的設(shè)計(jì)缺陷？

結(jié)果 OP 不僅一一回應(yīng)，還把調(diào)試過程拆解得非常專業(yè)，讓人不得不信服。

圖片

Bug 本身有多難？——一場關(guān)于“巧合依賴”的架構(gòu)謎題

發(fā)帖人沒有貼出 bug 的完整代碼，但從他的描述來看，這不是一個(gè)低級邏輯錯(cuò)誤，而是架構(gòu)重構(gòu)后遺留的語義斷裂問題。

具體表現(xiàn)是：一個(gè) shader 在舊系統(tǒng)中能正常運(yùn)行，在新系統(tǒng)中卻悄無聲息地失效了——沒有崩潰、沒有報(bào)錯(cuò)，只是“該運(yùn)行的時(shí)候沒跑起來”。

就像一位Reddit正如一位 Reddit 網(wǎng)友在評論區(qū)里說的那樣：

“你以為它正常工作的地方，其實(shí)從技術(shù)上講也沒真的工作過。”

——這種 bug才是最讓人崩潰的。

圖片

這類問題有幾個(gè)典型特征：

• 非顯性錯(cuò)誤：不會(huì) crash，不報(bào)錯(cuò)，甚至連回歸測試都可能漏掉； 
• 重構(gòu)遺留：結(jié)構(gòu)改了，但沒人意識(shí)到有些原本“剛好湊得上的邏輯”不再成立； 
• 跨模塊聯(lián)動(dòng)失效：shader、輸入數(shù)據(jù)、調(diào)用鏈、調(diào)度順序之間存在微妙的耦合關(guān)系，bug 隱藏在多層條件組合中。 

這也解釋了為什么 OP 自己斷斷續(xù)續(xù)排查了 200 小時(shí)，卻始終沒能定位。

當(dāng)然，Claude 也不是“讀完整個(gè)項(xiàng)目”后盲打命中。根據(jù) OP 后續(xù)補(bǔ)充，它一共分析了 12 個(gè)文件、約 1 萬行代碼。

發(fā)帖人是怎么用 Claude 做到這一切的？——30余次prompt驅(qū)動(dòng)的工程探索

Claude Opus 能做到這件事，離不開這位資深工程師一次次精確引導(dǎo)、取舍信息和及時(shí)的重啟。

圖片

評論區(qū)里有網(wǎng)友拋出了幾個(gè)關(guān)鍵問題，發(fā)帖人也一一回應(yīng)，我們得以看到他和 Claude 合作的完整路徑。

圖片

1.您最初是如何向Claude提出問題的？在每個(gè)階段共享了哪些代碼塊或文件？

我最開始的 prompt 大概就 10 行，簡要描述了這個(gè)問題的背景。

 然后我把 Claude 指向頂層代碼文件夾，里面有大約 100 萬行代碼。如果算上舊版本項(xiàng)目，整個(gè)目錄下大約是 200 萬行——我把舊代碼復(fù)制到同一個(gè)工程目錄下的 oldsrc/，這樣 Claude 就能同時(shí)訪問新舊架構(gòu)。

后續(xù) prompt 數(shù)量在 30 個(gè)左右，從 1 行到 1500 行不等，有些是 Claude 要我抓的日志（這些日志是它在代碼中加了一堆 printf 后生成的，目的是更好地理解代碼的執(zhí)行流程），有些則是它分析邏輯、發(fā)現(xiàn)矛盾、糾正路徑的結(jié)果。

除去日志類的提示詞，我是這么寫prompt的細(xì)節(jié)：“你現(xiàn)在走錯(cuò)方向了——僅僅把這個(gè)條件代碼 <插入的代碼> 限制在部分輸入數(shù)據(jù)集上是沒幫助的，因?yàn)?<解釋原因>；還有這個(gè)條件 <插入的代碼> 和那個(gè)條件 <插入的代碼> 在 <解釋某種數(shù)據(jù)場景> 下其實(shí)并不是互斥的，但你現(xiàn)在的假設(shè)是它們是互斥的。”

因?yàn)镃laude有許多解決問題的路徑，我之前已經(jīng)嘗試過了，而它也想嘗試這些，但我知道那些路是死胡同。

2.Claude 是自動(dòng)分析，還是靠你一步步帶著？

A：Claude Code 會(huì)自動(dòng)用 grep 找出它需要查看的文件。我根本不需要引導(dǎo)它，甚至連函數(shù)名都沒說。

我通常會(huì)確保 VSCode 啟動(dòng)時(shí)所有文件都是關(guān)閉狀態(tài)，否則它會(huì)過度集中在你打開的文件上，而不是做全面搜索。

3.關(guān)鍵突破的那一刻發(fā)生了什么？

A：它在真正找到問題之前嘗試過很多方向。像所有 AI 一樣，它經(jīng)常說“我找到了！”但大部分時(shí)候是錯(cuò)的。

直到有一次它的修改既沒有引入新問題，又解決了癥狀。我才回頭仔細(xì)比對它改了什么，才發(fā)現(xiàn)：它識(shí)別出舊架構(gòu)下能跑通的邏輯是“誤打誤撞”，而新架構(gòu)改變后這條路徑就斷了。

4.Claude 跑偏了怎么辦？“重啟”是如何操作的？

A：我中間有一次重啟，是因?yàn)樗蝗慌苋ァ绊槺阈迯?fù)”著色器里的矩陣乘法相關(guān)部分，我真不想花整天時(shí)間去算線性代數(shù)來驗(yàn)證那東西對不對。更何況問題的本質(zhì)并不是這個(gè) shader 表現(xiàn)不好，而是根本沒有執(zhí)行。

所以我就重啟了它，并把它之前識(shí)別出問題相關(guān)的結(jié)果再喂給它。雖然我沒特別告訴它“別動(dòng) GLSL（著色器語言）”，但之后它就確實(shí)沒再碰了。

不搞神化：AI 依然相當(dāng)于一個(gè)“高效但話多”的實(shí)習(xí)生

Opus 4 的強(qiáng)大無可否認(rèn)，但這次案例真正震撼人的地方，不在于它“替代了誰”，而在于它如何協(xié)助一位資深工程師完成了一次精度極高的協(xié)作式調(diào)試。

“對于那些指導(dǎo)自己在做什么的人來說，人工智能是一個(gè)新同事。”

圖片

發(fā)帖人在評論區(qū)坦言：

“在編寫新代碼這件事上，它頂多算是一個(gè)初級開發(fā)者。”

圖片

無論是 AI 還是人類實(shí)習(xí)生，本質(zhì)上都需要一位資深工程師持續(xù)陪跑。關(guān)鍵差別，不在于誰聰明，而在于誰更省你的時(shí)間。

他說得很直白：“你可以想一想，一個(gè)新人會(huì)多頻繁跑來問你問題、發(fā) Slack、被打回代碼審查……Claude 也一樣。”

他舉了一個(gè)真實(shí)例子：

我最近做了一個(gè)全棧網(wǎng)站項(xiàng)目，總共用了大概 200 條 prompt。這和我?guī)б粋€(gè)初級開發(fā)者是一樣的預(yù)期——只是這個(gè)“200 次互動(dòng)”，如果是初級開發(fā)者，可能會(huì)分布在 6 個(gè)月，而和 AI，只用了 3 天。

所以從速度上看，AI 無疑是更快的，但從“需要 tech lead 付出的指導(dǎo)精力”來說，和初級開發(fā)者并無二致。

所以 AI 的優(yōu)勢確實(shí)存在——速度快、響應(yīng)快、不怕你煩它。

但開發(fā)者提出一個(gè)更令人深思的問題：

如果你是 tech lead，要擴(kuò)大自己的能力范圍，假設(shè)你有 6 個(gè)月做一個(gè)項(xiàng)目，你是愿意帶 30 個(gè)初級開發(fā)者，還是一個(gè)不限次數(shù)提問的 AI 代理？你可能覺得這兩種都可以選對吧？

那如果換成是 30 個(gè)高級開發(fā)者 vs. 一個(gè) AI 呢？我肯定選 30 個(gè)高級開發(fā)者。我想不出誰會(huì)在這種情況下還選 AI。

因?yàn)閺?技術(shù)帶頭人（tech lead）角度來看，AI 所需的管理成本，和一個(gè)新人的訓(xùn)練周期是同量級的。

寫在最后：AI立大功將會(huì)越來越常見

評論區(qū)不少人分享和發(fā)帖者相似的經(jīng)歷。

一位網(wǎng)友寫道：

最近在一次產(chǎn)品上線中發(fā)現(xiàn)了一個(gè)嚴(yán)重的 bug，它直接導(dǎo)致我們發(fā)給客戶的結(jié)果變得毫無意義。

我們一開始調(diào)查后，以為找到了根本原因，結(jié)果繼續(xù)深挖，竟然又發(fā)現(xiàn)了三個(gè)額外的根本原因。

 也就是說，軟件一共有四處邏輯錯(cuò)誤，但它們原本剛好組合在一起“跑得很正常”——純屬巧合。

這次上線只是復(fù)制了其中三個(gè) bug，而不是四個(gè)，于是整個(gè)邏輯就崩了，哈哈哈。

修復(fù)起來不輕松，但 Claude 3.7 幫了我不少忙。

 我已經(jīng)迫不及待想看看 Claude 4 會(huì)怎么評價(jià)這個(gè)離譜現(xiàn)場了。

圖片

在AI不斷進(jìn)化的當(dāng)下，AI 不僅是在“加速我們”，還要求我們必須適應(yīng)新技術(shù)下的協(xié)同工作。

那么，AI有沒有曾幫你解決過“白鯨級”的bug？如果你有 6 個(gè)月的項(xiàng)目期，是會(huì)選 30 個(gè)實(shí)習(xí)生，還是一個(gè) Claude Opus 4？

參考鏈接：https://www.reddit.com/r/ClaudeAI/comments/1kvgg7s/claude_opus_solved_my_white_whale_bug_today_that