wasabeef 從錯誤訊息定位根本原因並提出解決方案
從錯誤訊息中識別根本原因，預測解決時間並提出經過驗證的解決方案。學習類似錯誤的模式，立即提供適當的處理方法。
使用方法
/fix-error [選項]
選項
- 無 : 標準錯誤分析
--deep: 深度分析模式 (包括依賴關係・環境因素)--preventive: 重視預防措施的分析--quick: 僅提供立即可用的修復方案
基本示例
# 標準錯誤分析
npm run build 2>&1
/fix-error
"分析建置錯誤並提出修復方法"
# 深度分析模式
python app.py 2>&1
/fix-error --deep
"包括環境因素在內分析錯誤的根本原因"
# 即時修復重視
cargo test 2>&1
/fix-error --quick
"提供可立即應用的修復方法"
# 預防措施重視
./app 2>&1 | tail -50
/fix-error --preventive
"提出錯誤修復和未來的預防措施"
與 Claude 的協作
# 錯誤日誌分析
cat error.log
/fix-error
"識別錯誤的根本原因，提出修復方法"
# 測試失敗的解決
npm test 2>&1
/fix-error --quick
"分析失敗的測試，提出可立即應用的修復方案"
# 堆疊追蹤的解析
python script.py 2>&1
/fix-error --deep
"從這個堆疊追蹤中定位問題，包括環境因素一起分析"
# 批次解決多個錯誤
grep -E "ERROR|WARN" app.log | tail -20
/fix-error
"按優先順序分類這些錯誤和警告，分別提出解決方法"
錯誤解決時間預測
🚀 即時修復 (5 分鐘以內)
├─ 拼字錯誤、import 遺漏
├─ 環境變數未設定
├─ 未定義變數的參照
└─ 預測時間: 2-5 分鐘
⚡ 快速修復 (30 分鐘以內)
├─ 依賴關係不一致
├─ 設定檔錯誤
├─ 型別不匹配
└─ 預測時間: 10-30 分鐘
🔧 需要調查 (2 小時以內)
├─ 複雜的邏輯錯誤
├─ 非同步處理競爭
├─ API 整合問題
└─ 預測時間: 30 分鐘-2 小時
🔬 深度分析 (半天以上)
├─ 架構起因
├─ 多系統連接
├─ 效能劣化
└─ 預測時間: 4 小時-數天
類似錯誤模式資料庫
頻發錯誤與即時解決方案
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
📊 "Cannot read property 'X' of undefined/null" (頻度: 極高)
├─ 主要原因: 物件的 null 檢查不足
├─ 解決時間: 5-10 分鐘
└─ 處理方法: 添加 Optional chaining (?.) 或 null 檢查
📊 "ECONNREFUSED" / "ENOTFOUND" (頻度: 高)
├─ 主要原因: 服務未啟動或 URL 設定錯誤
├─ 解決時間: 5-15 分鐘
└─ 處理方法: 確認服務啟動，檢查環境變數
📊 "Module not found" / "Cannot resolve" (頻度: 高)
├─ 主要原因: 套件未安裝，路徑指定錯誤
├─ 解決時間: 2-5 分鐘
└─ 處理方法: 執行 npm install，確認相對路徑
📊 "Unexpected token" / "SyntaxError" (頻度: 中)
├─ 主要原因: 括號・引號不一致，使用保留字
├─ 解決時間: 2-10 分鐘
└─ 處理方法: 確認語法高亮，執行 Linter
📊 "CORS policy" / "Access-Control-Allow-Origin" (頻度: 中)
├─ 主要原因: 伺服器端 CORS 設定不足
├─ 解決時間: 15-30 分鐘
└─ 處理方法: 伺服器 CORS 設定，代理設定
📊 "Maximum call stack size exceeded" (頻度: 低)
├─ 主要原因: 無限迴圈・遞迴，循環參照
├─ 解決時間: 30 分鐘-2 小時
└─ 處理方法: 確認遞迴結束條件，解除循環參照
錯誤分析的優先順序矩陣
| 優先順序 | 圖示 | 影響範圍 | 解決難度 | 回應期限 | 說明 |
|---|---|---|---|---|---|
| Critical | 🔴 緊急回應 | 廣 | 低 | 15 分鐘內著手 | 系統全面停止，資料遺失風險 |
| High Priority | 🟠 早期回應 | 廣 | 高 | 1 小時內著手 | 主要功能停止，多數使用者影響 |
| Medium | 🟡 計畫回應 | 窄 | 高 | 當日回應 | 部分功能限制，有迴避方案 |
| Low | 🟢 過程觀察 | 窄 | 低 | 下次修改時 | 輕微不良，對 UX 影響小 |
分析流程
階段 1: 錯誤資訊收集
🔴 必須執行:
- 完整取得錯誤訊息
- 確認堆疊追蹤
- 確定發生條件 (可重現性)
🟡 早期執行:
- 收集環境資訊 (OS，版本，依賴關係)
- 直接變更歷程 (git log，最近提交)
- 確認相關日誌
🟢 額外執行:
- 系統資源狀況
- 網路狀態
- 外部服務狀態
階段 2: 根本原因分析
整理表面症狀
- 錯誤訊息的正確內容
- 發生時間和模式
- 確定影響範圍
確定深層原因
- 應用 5 Whys 分析
- 追蹤依賴關係
- 確認環境差異
驗證假設
- 建立最小重現程式碼
- 執行隔離測試
- 縮小原因範圍
階段 3: 解決方案實作
🔴 即時處理 (熱修復):
- 抑制症狀的最小修復
- 應用暫時迴避方案
- 準備緊急部署
🟡 根本解決:
- 針對原因的本質修復
- 新增測試案例
- 更新文件
🟢 預防措施實作:
- 強化錯誤處理
- 設定監控・警報
- 改善 CI/CD 管線
輸出範例
🚨 錯誤分析報告
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
📍 錯誤概要
├─ 類型: [編譯/執行時/邏輯/環境]
├─ 緊急度: 🔴 高 / 🟡 中 / 🟢 低
├─ 影響範圍: [功能名/元件]
└─ 重現性: [100% / 間歇性 / 特定條件]
🔍 根本原因
├─ 直接原因: [具體原因]
├─ 背景因素: [環境/設定/依賴關係]
└─ 觸發器: [發生條件]
💡 解決方案
🔴 即時處理:
1. [具體修復指令/程式碼]
2. [暫時迴避方案]
🟡 根本解決:
1. [本質修復方法]
2. [必要的重構]
🟢 預防措施:
1. [錯誤處理改善]
2. [測試新增]
3. [監控設定]
📝 驗證程序
1. [修復套用後確認方法]
2. [測試執行指令]
3. [動作確認項目]
錯誤類型別分析技法
編譯/建置錯誤
# TypeScript 型別錯誤
必須確認 (高):
- tsconfig.json 設定
- 型別定義檔 (.d.ts) 的存在
- import 陳述句的正確性
# Rust 生命週期錯誤
必須確認 (高):
- 所有權移動
- 參照的有效期間
- 可變性衝突
執行時錯誤
# Null/Undefined 參照
必須確認 (高):
- 可選鏈結不足
- 初始化時機
- 非同步處理的完成等待
# 記憶體相關錯誤
必須確認 (高):
- 取得堆積傾印
- 分析 GC 日誌
- 偵測循環參照
依賴關係錯誤
# 版本衝突
必須確認 (高):
- lock 檔案的一致性
- peer dependencies 要求
- 傳遞性依賴關係
# 模組解析錯誤
必須確認 (高):
- NODE_PATH 設定
- 路徑別名設定
- 符號連結
注意事項
- 絕對禁止: 僅憑錯誤訊息的一部分判斷，未驗證就套用 Stack Overflow 解決方案
- 例外條件: 暫時迴避方案僅在以下 3 個條件下允許
- 生產環境緊急回應 (24 小時內根本解決必須)
- 外部服務故障 (復原等待中的替代手段)
- 已知框架錯誤 (等待修正版本發布)
- 建議事項: 以根本原因確定為最優先，避免表面修復
最佳實務
- 完整資訊收集: 從頭到尾確認錯誤訊息
- 確認重現性: 最優先建立最小重現程式碼
- 階段性方法: 從小修復開始驗證
- 文件化: 記錄解決過程進行知識分享
常犯錯誤
- 處理症狀: 遺漏根本原因的表面修復
- 過度一般化: 廣泛套用特定案例的解決方案
- 省略驗證: 不確認修復後的副作用
- 知識個人化: 不將解決方法文件化
相關指令
/design-patterns: 分析程式碼結構問題並提出模式建議/tech-debt: 從技術債務觀點分析錯誤的根本原因/analyzer: 需要更深入根本原因分析的情況