1. 為什么我把 Claude Code 當(dāng)調(diào)試工具用1.1 一個(gè)被低估的定位它不是補(bǔ)全器是排查搭子大部分人第一次接觸 Claude Code腦子里想的都是幫我寫個(gè)函數(shù)幫我生成個(gè)組件把它當(dāng)成一個(gè)更聰明的代碼補(bǔ)全。我一開始也是這么用的直到有一次線上一個(gè)偶發(fā)的空指針問題折騰了我整整一個(gè)下午我抱著試試看的心態(tài)把報(bào)錯(cuò)棧和幾段相關(guān)代碼丟給它讓它幫我梳理調(diào)用鏈結(jié)果它給出的排查路徑比我自己的思路還清晰。從那天起我對這個(gè)工具的定位就變了——它最大的價(jià)值不在寫而在查。調(diào)試這件事本質(zhì)上是一個(gè)信息收斂的過程。你手里有一堆線索報(bào)錯(cuò)信息、日志、堆棧、變量狀態(tài)、復(fù)現(xiàn)步驟然后你要在這些噪聲里找到那個(gè)真正的因。人做這件事的瓶頸在于當(dāng)代碼量大、調(diào)用鏈深的時(shí)候你的工作記憶會不夠用容易在某個(gè)分支上鉆牛角尖。而 Claude Code 這類工具的優(yōu)勢恰恰在于它可以一次性吞下大量上下文幫你把散落的信息串成一條線并且不會因?yàn)榭戳巳齻€(gè)小時(shí)代碼就疲勞走神。我現(xiàn)在的習(xí)慣是遇到那種看起來很簡單但就是找不到原因的問題先自己排查十五分鐘如果沒頭緒就把現(xiàn)場信息整理一下交給它。這個(gè)十五分鐘是個(gè)經(jīng)驗(yàn)值太早交給它你自己還沒建立對問題的基本認(rèn)知它給的方向你也沒法判斷對錯(cuò)太晚交給它你已經(jīng)陷進(jìn)去了反而容易被自己的假設(shè)帶偏。1.2 它到底能幫你查什么類型的問題不是所有 bug 都適合交給它。我踩過一段時(shí)間的坑之后總結(jié)出它最擅長的幾類場景調(diào)用鏈追蹤類一個(gè)函數(shù)返回了意料之外的值你想知道這個(gè)值是從哪一層傳進(jìn)來的。這種問題人查起來要來回跳轉(zhuǎn)它查起來很快。報(bào)錯(cuò)信息解讀類尤其是那種框架拋出的、嵌套了好幾層的異常原始信息里全是內(nèi)部類名它能把關(guān)鍵的那一層挑出來。邏輯矛盾類代碼讀起來沒問題但行為和預(yù)期不符。這種往往是某個(gè)邊界條件或者狀態(tài)時(shí)序的問題它逐行推演的能力比人強(qiáng)。配置與環(huán)境類依賴版本沖突、環(huán)境變量沒生效、路徑不對這類問題它結(jié)合報(bào)錯(cuò)和配置文件能給出很具體的猜測。反過來性能問題和并發(fā)問題它給的建議就要打個(gè)折扣。這兩類問題高度依賴真實(shí)的運(yùn)行時(shí)數(shù)據(jù)光看代碼很難定位它給的方向往往比較泛還是得靠 profiler 和日志。我一般不會在這兩類問題上對它抱太高期望。1.3 一個(gè)關(guān)鍵前提你得會喂上下文這是我想強(qiáng)調(diào)的第一件事也是很多人用了覺得也就那樣的根本原因。Claude Code 的調(diào)試能力七分靠它三分靠你怎么喂信息。你只丟一句這段代碼報(bào)錯(cuò)了幫我看看它只能瞎猜你把報(bào)錯(cuò)棧、相關(guān)代碼、你的復(fù)現(xiàn)步驟、你已經(jīng)排除掉的可能性都給它它的命中率會高得嚇人。我一般會準(zhǔn)備一個(gè)固定的現(xiàn)場包包含四樣?xùn)|西完整的報(bào)錯(cuò)信息不要截?cái)?、出錯(cuò)位置上下各三十行左右的代碼、能穩(wěn)定復(fù)現(xiàn)的最小操作步驟、以及我已經(jīng)試過但沒用的排查方向。最后這一條特別重要它能避免它重復(fù)走你走過的死路。2. 調(diào)試場景下的核心用法拆解2.1 從報(bào)錯(cuò)棧反推調(diào)用鏈先講最基礎(chǔ)也最常用的一個(gè)用法。假設(shè)你拿到一段報(bào)錯(cuò)類似這樣TypeError: Cannot read property id of undefined at getUserOrder (order.js:42:18) at processPayment (payment.js:88:7) at handleCheckout (checkout.js:15:3)人看這個(gè)棧第一反應(yīng)是去 order.js 第 42 行看發(fā)現(xiàn)是user.id報(bào)錯(cuò)然后往上找 user 是從哪來的。這個(gè)過程本身不難但如果調(diào)用鏈有十幾層中間還夾著異步回調(diào)人查起來就很煩。我的做法是把整個(gè)棧和相關(guān)函數(shù)一起丟給它然后問一個(gè)很具體的問題user 這個(gè)變量在到達(dá) order.js:42 之前經(jīng)過了哪些賦值和傳遞哪一步最可能讓它變成 undefined注意這個(gè)問法我沒有問怎么修而是問哪一步最可能出問題。這個(gè)區(qū)別很關(guān)鍵問怎么修它會直接給你一個(gè) try-catch 或者可選鏈治標(biāo)不治本問哪一步出問題它會幫你把數(shù)據(jù)流梳理一遍你才能找到真正的根因。實(shí)測下來它在處理這種數(shù)據(jù)流追蹤時(shí)表現(xiàn)相當(dāng)穩(wěn)。它會明確告訴你比如user 在 payment.js:88 是從 cache 里取的如果 cache miss 且沒有 fallback這里就會是 undefined這種結(jié)論往往就是你要找的東西。2.2 用假設(shè)-驗(yàn)證的方式縮小范圍調(diào)試最怕的是漫無目的地試。我摸索出一個(gè)和它配合的高效模式叫假設(shè)-驗(yàn)證。具體做法是我不讓它直接給答案而是讓它列出所有可能的原因然后我們一個(gè)一個(gè)排除。比如一個(gè)接口偶爾返回 500我會這樣問這個(gè)接口偶發(fā) 500可能的原因有哪些按可能性從高到低排列并說明每個(gè)原因?qū)?yīng)的驗(yàn)證方法。它會給我一個(gè)列表比如數(shù)據(jù)庫連接池耗盡、某個(gè)第三方調(diào)用超時(shí)、并發(fā)寫沖突等等每個(gè)都配上怎么驗(yàn)證。然后我拿著這個(gè)列表去實(shí)際驗(yàn)證驗(yàn)證完一個(gè)就把結(jié)果告訴它讓它更新判斷。這個(gè)過程就像有個(gè)經(jīng)驗(yàn)豐富的同事在旁邊跟你一起排查他不會替你動手但會幫你把思路理清楚。我印象很深的一次一個(gè)偶發(fā)超時(shí)問題它列了六個(gè)可能我排除了前四個(gè)到第五個(gè)連接池在高峰期被慢查詢占滿的時(shí)候一查監(jiān)控果然如此。提示這個(gè)模式的關(guān)鍵是交互式排查不要指望一次問答就解決。把它的輸出當(dāng)成排查清單而不是最終答案。2.3 讓它讀日志而不是你讀日志分析是另一個(gè)高價(jià)值場景。尤其是那種幾萬行的日志文件人肉翻找效率極低。我現(xiàn)在的做法是把日志文件直接給它然后描述我要找的模式。比如這個(gè)日志里從 14:23 開始服務(wù)變慢幫我找出這之后所有耗時(shí)超過 1 秒的請求以及它們共同的特征。它會幫你把符合條件的行挑出來并且嘗試歸納共性。我遇到過一次它發(fā)現(xiàn)所有慢請求都集中在某個(gè)特定的用戶 ID 段順著這條線查下去發(fā)現(xiàn)是那個(gè)用戶的數(shù)據(jù)量異常大觸發(fā)了全表掃描。這里有個(gè)技巧日志文件如果太大不要一次性全塞進(jìn)去先按時(shí)間窗口切一段給它。我一般切問題發(fā)生前后各五分鐘這個(gè)窗口通常足夠覆蓋因果鏈又不會讓上下文過載。2.4 復(fù)現(xiàn)步驟的梳理與最小化有時(shí)候問題不是找不到原因而是復(fù)現(xiàn)不穩(wěn)定。這種偶發(fā)問題最折磨人。我會讓它幫我做一件事根據(jù)我描述的復(fù)現(xiàn)過程反推可能的觸發(fā)條件并幫我設(shè)計(jì)一個(gè)最小復(fù)現(xiàn)用例。舉個(gè)例子一個(gè)前端頁面偶發(fā)白屏我描述的操作是打開列表頁快速滾動到底部點(diǎn)擊某條數(shù)據(jù)偶爾白屏。它會分析這個(gè)流程里哪些環(huán)節(jié)有時(shí)序依賴比如滾動到底部觸發(fā)了懶加載點(diǎn)擊時(shí)數(shù)據(jù)可能還沒加載完于是渲染了一個(gè)空對象。然后它會建議我構(gòu)造一個(gè)點(diǎn)擊時(shí)數(shù)據(jù)未就緒的場景來穩(wěn)定復(fù)現(xiàn)。這個(gè)能力我覺得是它最被低估的地方。人面對偶發(fā)問題容易陷入再試一次的循環(huán)而它能幫你從流程里找出那個(gè)不穩(wěn)定因素把偶發(fā)變成必現(xiàn)。3. 完整實(shí)操流程一次真實(shí)的排查記錄3.1 問題背景與現(xiàn)場信息整理講一個(gè)我上個(gè)月實(shí)際處理的案例完整走一遍流程。背景是一個(gè) Node 服務(wù)某個(gè)定時(shí)任務(wù)偶爾會漏執(zhí)行不是每次都漏大概一周漏一兩次。日志里沒有任何報(bào)錯(cuò)任務(wù)就是靜默地沒跑。我先自己查了半小時(shí)看了 cron 配置、看了任務(wù)隊(duì)列、看了進(jìn)程狀態(tài)都沒發(fā)現(xiàn)問題。然后我開始整理現(xiàn)場包定時(shí)任務(wù)的調(diào)度代碼約 80 行任務(wù)執(zhí)行前后的日志片段連續(xù)三天的漏執(zhí)行那天的完整日志我已經(jīng)排除的cron 表達(dá)式?jīng)]問題、進(jìn)程沒重啟、隊(duì)列沒積壓3.2 第一輪提問與方向收斂我把這些信息給它問的是這個(gè)定時(shí)任務(wù)偶爾漏執(zhí)行日志無報(bào)錯(cuò)。請分析調(diào)度代碼找出可能導(dǎo)致任務(wù)被跳過但又不報(bào)錯(cuò)的路徑。它讀完代碼后給了三個(gè)方向任務(wù)執(zhí)行時(shí)間超過了調(diào)度間隔導(dǎo)致下一次調(diào)度被跳過很多調(diào)度庫有這種防重入機(jī)制任務(wù)內(nèi)部有提前 return 的分支某個(gè)條件不滿足時(shí)靜默返回調(diào)度器本身在某個(gè)時(shí)間點(diǎn)被阻塞這個(gè)回答質(zhì)量很高因?yàn)樗苯又赶蛄遂o默跳過這個(gè)特征。我順著第一條去查發(fā)現(xiàn)任務(wù)執(zhí)行時(shí)間確實(shí)波動很大正常幾百毫秒但偶爾會到幾秒。而調(diào)度間隔是固定的。3.3 關(guān)鍵代碼的逐行推演我把調(diào)度庫的相關(guān)代碼也找出來給它讓它確認(rèn)防重入邏輯。它指出這個(gè)庫在任務(wù)未完成時(shí)會跳過本次調(diào)度并且默認(rèn)不打印日志。這就解釋了為什么漏執(zhí)行但無報(bào)錯(cuò)。到這里根因基本清楚了但我還想確認(rèn)為什么任務(wù)偶爾會執(zhí)行幾秒。我讓它分析任務(wù)代碼里哪些操作可能耗時(shí)。它指出其中有一個(gè)同步的文件讀取操作文件大小不定大文件時(shí)會阻塞。查了一下那個(gè)文件確實(shí)會周期性變大。3.4 驗(yàn)證與修復(fù)方案驗(yàn)證很簡單我在任務(wù)里加了耗時(shí)打點(diǎn)跑了一天果然抓到了幾次超過調(diào)度間隔的執(zhí)行。根因確認(rèn)任務(wù)偶發(fā)耗時(shí)超過調(diào)度間隔被調(diào)度器靜默跳過。修復(fù)方案它給了兩個(gè)一是把同步文件讀取改成異步二是給任務(wù)加超時(shí)和告警。我兩個(gè)都做了前者治本后者兜底。改完之后跑了兩周沒再漏過。整個(gè)排查過程我自己動手的部分主要是驗(yàn)證思路梳理和方向收斂基本是它帶著走的。這就是我說的調(diào)試搭子的價(jià)值。4. 常見問題與避坑經(jīng)驗(yàn)4.1 它給的方向不對怎么辦這是最常見的問題。它給了一個(gè)看起來很合理的方向你查了半天發(fā)現(xiàn)是死路。我的經(jīng)驗(yàn)是不要自己悶頭查及時(shí)把此路不通反饋給它。很多時(shí)候它給的方向是基于不完整的信息你反饋之后它會修正判斷。我遇到過一次它堅(jiān)持認(rèn)為是緩存問題我查了緩存配置沒問題告訴它之后它重新分析發(fā)現(xiàn)是另一個(gè)模塊的初始化順序問題。所以關(guān)鍵是保持對話而不是把它當(dāng)一次性問答機(jī)。4.2 上下文給多了反而變差這個(gè)坑我踩過。有一次我把整個(gè)項(xiàng)目的相關(guān)文件都塞給它結(jié)果它的分析變得很泛抓不住重點(diǎn)。后來我明白了上下文不是越多越好而是要精準(zhǔn)。給多了噪聲會稀釋信號。我現(xiàn)在的原則是只給和當(dāng)前問題直接相關(guān)的代碼最多往外擴(kuò)一層調(diào)用。如果它需要更多信息它會主動問那時(shí)候再給。4.3 不要讓它直接改代碼調(diào)試階段我強(qiáng)烈建議不要讓它直接改代碼。原因有兩個(gè)一是它改的代碼你可能沒完全理解埋下新問題二是調(diào)試的核心是理解問題直接改代碼會跳過理解這一步。我的做法是讓它給修復(fù)思路和關(guān)鍵代碼片段我自己動手改。改的過程中如果有疑問再問它。這樣既保證了理解又保證了代碼質(zhì)量。4.4 敏感信息要脫敏這個(gè)必須強(qiáng)調(diào)。調(diào)試時(shí)你給它的日志和代碼里可能包含密鑰、用戶數(shù)據(jù)、內(nèi)部地址。給之前一定要脫敏。我一般會把密鑰替換成占位符用戶 ID 做哈希處理內(nèi)部域名改成示例域名。這個(gè)習(xí)慣一定要養(yǎng)成不然遲早出事。4.5 常見問題速查表問題現(xiàn)象可能原因排查方向它給的方向明顯不對上下文不足或有誤導(dǎo)補(bǔ)充信息明確說明已排除項(xiàng)分析結(jié)果很泛抓不住重點(diǎn)上下文給太多精簡到只給相關(guān)代碼反復(fù)給同一個(gè)錯(cuò)誤方向你的描述有歧義換個(gè)角度重新描述問題對性能問題建議很空這類問題依賴運(yùn)行時(shí)數(shù)據(jù)結(jié)合 profiler 數(shù)據(jù)再問對并發(fā)問題判斷不準(zhǔn)時(shí)序問題難以靜態(tài)分析補(bǔ)充日志時(shí)序信息5. 把它用成習(xí)慣之后的一些體會5.1 調(diào)試效率的提升是復(fù)利的剛開始用的時(shí)候你可能覺得整理現(xiàn)場包、組織提問挺麻煩的還不如自己查。但用久了你會發(fā)現(xiàn)這個(gè)整理現(xiàn)場的過程本身就在幫你理清思路。很多時(shí)候我在整理現(xiàn)場包的過程中自己就把問題想明白了。而且它有個(gè)隱性價(jià)值它會逼你把問題描述清楚。人自己排查時(shí)思路是跳躍的、模糊的但你要跟它描述就必須把問題結(jié)構(gòu)化。這個(gè)結(jié)構(gòu)化的過程往往就是破局的關(guān)鍵。5.2 它不能替代基本功這一點(diǎn)我必須說清楚。它能幫你梳理調(diào)用鏈、分析日志、收斂方向但它不能替代你對系統(tǒng)的基本理解。如果你連自己系統(tǒng)的架構(gòu)都不清楚它給的方向你也沒法判斷對錯(cuò)。我見過有人完全依賴它結(jié)果被它帶偏了還渾然不覺。工具是放大器你的基本功是底數(shù)底數(shù)是零放大多少倍還是零。5.3 一個(gè)我常用的提問模板最后分享一個(gè)我用了很久的提問模板基本覆蓋了調(diào)試場景的通用需求問題現(xiàn)象[一句話描述] 報(bào)錯(cuò)信息[完整報(bào)錯(cuò)沒有就寫無] 相關(guān)代碼[出錯(cuò)位置及上下文] 復(fù)現(xiàn)步驟[能穩(wěn)定復(fù)現(xiàn)就寫不能就描述頻率] 已排除[我試過但沒用的方向] 我的猜測[如果有的話] 請幫我[具體想要它做什么比如梳理調(diào)用鏈/列出可能原因/分析日志]這個(gè)模板的好處是它強(qiáng)制你把信息組織完整同時(shí)最后一行明確了你的訴求避免它答非所問。我用這個(gè)模板命中率比隨便問高很多。調(diào)試這件事說到底是個(gè)信息處理問題。Claude Code 在這件事上的價(jià)值不是替你思考而是幫你把思考的素材整理好、把可能的路徑列出來、把噪聲過濾掉。剩下的判斷還是得你自己來。但就是這一點(diǎn)輔助在那些卡殼的下午往往能幫你省下幾個(gè)小時(shí)。