出品 | 51CTO技術棧（微信號：blog51cto）

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

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

圖片

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

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

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

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

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

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

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

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

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

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

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

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

圖片

Bug 本身有多難？——一場關于“巧合依賴”的架構謎題

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

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

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

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

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

圖片

這類問題有幾個典型特征：

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

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

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

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

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

圖片

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

圖片

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

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

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

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

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

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

2.Claude 是自動分析，還是靠你一步步帶著？

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

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

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

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

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

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

A：我中間有一次重啟，是因為它突然跑去“順便修復”著色器里的矩陣乘法相關部分，我真不想花整天時間去算線性代數(shù)來驗證那東西對不對。更何況問題的本質(zhì)并不是這個 shader 表現(xiàn)不好，而是根本沒有執(zhí)行。

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

不搞神化：AI 依然相當于一個“高效但話多”的實習生

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

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

圖片

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

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

圖片

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

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

他舉了一個真實例子：

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

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

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

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

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

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

因為從 技術帶頭人（tech lead）角度來看，AI 所需的管理成本，和一個新人的訓練周期是同量級的。

4.寫在最后：AI立大功將會越來越常見

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

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

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

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

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

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

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

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

圖片

在AI不斷進化的當下，AI 不僅是在“加速我們”，還要求我們必須適應新技術下的協(xié)同工作。

那么，AI有沒有曾幫你解決過“白鯨級”的bug？如果你有 6 個月的項目期，是會選 30 個實習生，還是一個 Claude Opus 4？

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

本文轉載自??51CTO技術棧??，作者：伊風