整理 | 鄭麗媛 出品 | CSDN（ID：CSDNnews）
上週，Anthropic 正式釋出了 Claude Opus 4，並將其稱之為“全球最強的程式設計模型”。當時，有不少開發者對此說法不以為然——Reddit 上一位網名為“ShelZuuz”的 C++ 大佬，或許也是其中之一。
到了本週，ShelZuuz 卻表示：他已經被 Claude Opus 4 “徹底折服”了。
ShelZuuz 可不是一般人。據他自述，他擁有 30 多年的 C++ 開發經驗的，曾在知名大廠（FAANG：Meta、亞馬遜、蘋果、網飛、谷歌）擔任過 Staff Engineer，幾乎是團隊裡的“定海神針”，別人搞不定、困擾一週的難題，最終都會找到他來解決。
但就是這樣一位大神，卻被一個困擾了他長達四年的“白鯨 Bug”折磨得夠嗆（注：一種在特定條件下會觸發渲染錯誤的 Bug，通常在大規模程式碼重構後出現）——而本週，他終於在 Claude Opus 4 的幫助下，成功解決了這個長期未解的難題！
困擾了他 4 年的“白鯨 Bug”
根據 ShelZuuz 的分享，這個 Bug 要追溯到四年前。
當時，他在重構一個有 6 萬行程式碼的專案，原本是期望透過這次重構解決老系統遺留的諸多問題，讓整個系統執行得更加順暢高效。可沒想到，這次重構卻意外引入了一個棘手的新麻煩。
具體來說，是某個特殊著色器在某些特定 GPU 設定和呼叫路徑下會出現渲染異常，導致系統出現故障。可問題在於：它不容易重現，也不會報錯，有時你連“哪裡出了問題”都說不清楚。
於是，他開始了一場沒有終點的 Bug“獵殺”。
這四年來，ShelZuuz 斷斷續續地來回找這個 Bug，估計花了至少有 200 個小時。或許研究一段底層渲染程式碼幾個小時也徒勞無功、以為找到了問題關鍵、修改後卻 Bug 依舊……正如 ShelZuuz 將其稱為“白鯨 Bug”的原因：這個 Bug像極了小說《白鯨記》裡的莫比·迪克——神出鬼沒、近在咫尺卻永遠抓不住。
而就在最近，他突然心血來潮，嘗試把這個“白鯨 Bug”丟給 Claude Opus 4 來分析。畢竟，Anthropic 能自信把 Claude Opus 4 叫做“全球最強的程式設計模型”，它總得有點東西不是？
結果，原本這個 ShelZuuz 壓根不寄予厚望、只想著隨便試試的 Claude Opus 4，真的抓到了這個“白鯨”的尾巴！
我和執行 Opus 4 的 Claude Code 一起工作了幾個小時，給了它訪問舊程式碼和新程式碼的許可權，並告訴它去找出重構中的問題所在。結果它找到了！原來，在舊程式碼中能正常執行的原因僅僅是舊架構的巧合，而當我們改變架構時，並沒有考慮到這種巧合。因此，這不僅僅是一個引入的邏輯錯誤，它還發現了更改後的架構設計沒有考慮到這個舊的邊緣情況。
更令 ShelZuuz 驚訝的是，整個過程僅用了幾個小時，一共只花了大約 30 次提示和一次重啟——要知道，在此之前他也嘗試過用 GPT-4.1、Gemini 2.5 pro 以及 Claude 3.7 來解決這個 Bug，但都沒有任何進展。
Claude Opus 4 是怎麼做到的？
許多開發者都好奇，Claude Opus 4 具體是怎麼做到的？為此，ShelZuuz 給出了詳細過程。
首先是專案結構準備。他將老版本的程式碼放入 /proj/oldsrc，新版本程式碼放入 /proj/src，統一開啟 VSCode 的 /proj 目錄。Claude 就可以在一個會話中同時看到兩份程式碼。
其次是 prompt。ShelZuuz 透露，他的初始提示詞大概只有 10 行，主要描述問題所在，並引導 Claude 去掃描整個專案（加起來約 200 萬行程式碼）。而整個過程用了約 30 條 prompt，最長的一條 prompt 超過 1500 行，多是根據 Claude 要求他插入 printf 語句後的執行日誌，以便理解程式碼流程。
準備工作完成後，Claude 便開始找這個“白鯨 Bug”：
（1）自動 grep 專案中相關函式和路徑，無需人工指定檔案；
（2）基於現象分析執行路徑，並自行在舊程式碼和新程式碼中對比找出關鍵差異；
（3）過程中 Claude 曾多次誤判路徑，但 ShelZuuz 會透過補充說明幫助它及時修正方向；
（4）最終，Claude 發現了一個由於重構導致的非顯式依賴丟失：一個函式依賴的初始化流程在新版中被移動，造成執行路徑靜默中斷。
ShelZuuz坦言，好幾次 Claude 都說“我找到問題了！”，但他都不信，因為 AI 總是這麼說。但最後一次，他跑了一下程式碼，Bug居然真的修復了，而且沒有引入其他問題。
但是，Claude 依然只是“初級開發者”
既然如此，那 AI 真的比人類還強、可以取代人類了？而對於這個問題，ShelZuuz 在評論中多次強調：雖然 Claude 解決了這個大問題，但它本質上更像是一個“能幹的初級程式設計師”。
這聽上去有點貶低？不，恰恰相反。
他舉例道：
“我最近用 Claude 做了一個全棧專案，大概花了 200 個 prompt。你可以想象一個新人程式設計師在 6 個月裡透過 200 次問題和程式碼審查來推進專案。而 Claude 只花了3天。它確實更快，但需要的‘手把手指導’的工作量其實相當。”
他指出，AI 並不是“自動完成”任務的魔法工具，它更像是你團隊中的一個“不會上廁所但一直問問題”的實習生——你得時刻關注它的方向，引導它別繞遠路、別誤刪程式碼、別浪費時間在錯的方向上。
ShelZuuz 總結道：AI 在開發中需要的指導時間，相當於團隊中有一個初級開發者，而非高階開發者。因此，如果讓他在 30 個高階程式設計師和一個 AI 之間選，他還是會毫不猶豫地選擇人類：“光從對 Tech Lead（技術主管）的負擔角度來說，我更願意管理高階開發者。”
不過，不同於 ShelZuuz 的看法，許多開發者仍認為使用 AI 比僱傭工程師的成本要低得多。
以 ShelZuuz 使用的 Claude Max 為例，其每月訂閱費為 100 美元，相較於資深工程師 200 小時工時費約 2.5 萬美元來說，至少在這件事上可以看出，AI 在提高開發效率、降低開發成本方面有著巨大潛力。
參考連結：
https://www.reddit.com/r/ClaudeAI/comments/1kvgg7s/claude_opus_solved_my_white_whale_bug_today_that/
想要學習Linux系統的讀者可以點選"閱讀原文"按鈕來了解書籍《Linux就該這麼學》，同時也非常適合專業的運維人員閱讀，成為輔助您工作的高價值工具書！