整理 | 鄭麗媛

出品 | CSDN（ID：CSDNnews）

上周，Anthropic 正式發布了 ，并將其稱之為“全球最強的編程模型”。當時，有不少開發者對此說法不以為然——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 個小時?；蛟S研究一段底層渲染代碼幾個小時也徒勞無功、以為找到了問題關鍵、修改后卻 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/

2025 全球產品經理大會

2025 年 8 月 15–16 日

北京·威斯汀酒店

2025 全球產品經理大會將匯聚互聯網大廠、AI 創業公司、ToB/ToC 實戰一線的產品人，圍繞產品設計、用戶體驗、增長運營、智能落地等核心議題，展開 12 大專題分享，洞察趨勢、拆解路徑、對話未來。

更多詳情與報名，請掃碼下方二維碼。