Vibe Debug 的做法：

請注意以下的 console 錯誤訊息。我注意到到了是 path/to/some/file.jsx 中第 x 行到 y 行間，沒有正確呼叫 api, 請再詳細閱讀我對於 API 的規範，看 path/to/the/api/doc.md ，裡面有顯示 response 的資料結構。另外，我注意到這個檔案有太多複雜的 if else，我想以 Strategy pattern 重構，並依循 DRY 的原則，將它拆成小檔。

請不要直接開始改我的檔案，先了解一下他的父、子元件，給我一份 Problem / Solution with Step by Step 的計畫表，我同意之後，依照你的計畫執行

原始 Facebook 貼文：連結

# Claude 贊日

協霆的「Vibe Debug」方法論代表了一種截然不同的 AI 輔助除錯思路。傳統的除錯流程是「報錯→搜尋解決方案→試著修改」，這種方式容易走入死胡同，特別是在複雜的應用中。協霆的方法反而要求 AI 在動手前先「理解系統」，再提出計畫。

他要求 AI 完成的三個步驟特別精妙。首先，「詳細閱讀 API 規範」確保 AI 真正理解了系統的契約（contract）。許多 bug 的根源就在於對接口的誤解——例如參數類型、回傳結構、邊界條件等。AI 如果只看錯誤訊息，往往會基於表面症狀去修改，反而可能改壞。

其次，「閱讀父、子元件關係」這一步至關重要。在現代前端框架中（React、Vue 等），組件間的資料流往往是 bug 的真正來源。協霆要求 AI 先繪製心智地圖，確保改動不會影響其他元件。

最後，「先提計畫再執行」是最有智慧的一步。許多 AI 在代碼生成時會過度自信，直接修改檔案。但實際上，人類的核准步驟才是品質控制的關鍵。協霆透過要求「Problem / Solution with Step by Step」，強迫 AI 變得更謹慎、更透明。

「Strategy pattern 重構」與「DRY 原則」的提及，說明協霆不只想修復 bug，還想透過這個機會改進代碼品質。這是一個很棒的示範：bug 修復不是目的，改進架構才是長期價值。

在臨床軟體開發中，類似的方法論也很適用。修改患者資料相關的代碼時，更應該要求完整的理解→計畫→核准→執行的流程。

結構化 Debug 的核心要點：

1. 理解上下文優於盲目搜索
2. 架構視角比症狀修復更重要
3. 人類核准是確保品質的最後防線