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

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

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

圖片

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

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

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

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

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

直到 Claude Opus 4 出現。

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

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

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

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

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

結果 OP 不僅一一回應，還把調試過程拆解得非常專業，讓人不得不信服。

圖片

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

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

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

就像一位Reddit正如一位 Reddit 網友在評論區里說的那樣：

“你以為它正常工作的地方，其實從技術上講也沒真的工作過?！?/p>

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

圖片

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

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

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

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

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

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

圖片

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

圖片

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

圖片

發帖人在評論區坦言：

“在編寫新代碼這件事上，它頂多算是一個初級開發者?！?/p>

圖片

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

他說得很直白：“你可以想一想，一個新人會多頻繁跑來問你問題、發 Slack、被打回代碼審查……Claude 也一樣?！?/p>

他舉了一個真實例子：

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

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

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

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

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

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

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

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

評論區不少人分享和發帖者相似的經歷。

一位網友寫道：

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

我們一開始調查后，以為找到了根本原因，結果繼續深挖，竟然又發現了三個額外的根本原因。

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

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

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

 我已經迫不及待想看看 Claude 4 會怎么評價這個離譜現場了。

圖片

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

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

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