Vibe Coding 方法論 · 第 5 節
除錯鐵律：先 Log 再改碼
AI 遇到報錯的第一反應是猜一個原因改改看，不行再猜一個。這一節立最核心的一條規矩：禁止猜測性修復。下面兩個演示，親手對比兩條修 Bug 路徑。
核心條款
禁止猜測性修復。無法確認根因時，必須先透過 Log、斷點或測試腳本驗證假設，禁止「試著改一下看看」。後端在終端打詳細日誌，前端在瀏覽器 Console 打日誌，無論什麼問題，第一步都是加 Log。
互動演示一 · 同一個 Bug，兩條修法
Bug 現場：聊天輸入框在中文輸入法下，使用者按回車確認候選詞時，半截拼音被當成訊息直接發了出去。
點選一條路徑，觀察修復過程。右側計數器記錄輪數和累計改動行數。
0
修復輪數
0
累計改動行數
待演示
Bug 狀態
猜測性修復 · 戰績
尚未演示
先 Log 再改 · 戰績
尚未演示
互動演示二 · 修復前三問自查器
新 Bug 到達：使用者刪除一條聊天記錄後，會話列表上的未讀數沒有更新。
規則要求修 Bug 前必須回答三個問題。依次點開三問，全部看完才解鎖「開始修復」按鈕。
鏈路是 刪除訊息 → 更新會話摘要 → 重算未讀數 → 推送列表重新整理。排查發現「重算未讀數」只在收到新訊息時觸發，刪除路徑根本沒有走到它。只盯著報錯點看不到這條鏈路。
重算時機改動會波及 會話列表、App 角標、多端訊息同步 三處。理解上下游依賴再動手，避免按下葫蘆起了瓢。規則同時建議：優先啟動 SubAgent 並行調研影響範圍，確認安全後再修改。
有。「標記已讀」和「撤回訊息」 走的是同一條更新鏈路，同樣漏了觸發重算。同一個坑往往不止一處，這次一起修乾淨。
前置調研完成，允許動手。修復完成後還有最後一步：宣告影響範圍，讓人知道該回歸測試哪些地方。
⚡ 影響範圍：會話列表未讀數、App 角標、標記已讀、撤回訊息
交付線 · 兩道硬性檢查
禁止 Mock 繞過真實 AI 介面
凡涉及 AI 模型呼叫的功能，交付前必須確認介面真的打得通。使用者沒給 API Key 時必須停下來要，禁止硬編碼假響應或本地模擬繞過真實呼叫。Key 到位後先發一次測試請求驗證可用性，再繼續開發。
單元測試不過，不得交付
核心業務邏輯、API 介面、資料處理函式、邊界條件都要覆蓋。測試檔案統一放 tests/，命名 test_{模組名}.py，Python 專案用 pytest。除錯用的臨時腳本，用完自行刪除。
本節要點
證據先行。加 Log 的 2 分鐘，買斷的是猜錯三輪的返工和被掩蓋的根因。修復後用 ⚡ 影響範圍：XXX、YYY、ZZZ 的格式宣告影響面，交付前過真實介面和單元測試兩道線。
素材來源：本節內容整理自開源倉庫 itshen/xs_vibe_rules 的 rule-opensource.mdc 第八章「除錯與日誌規範」。