從錯誤訊息定位根本原因並提出解決方案

從錯誤訊息中識別根本原因，預測解決時間並提出經過驗證的解決方案。學習類似錯誤的模式，立即提供適當的處理方法。

使用方法

bash
/fix-error [選項]

選項

• 無 : 標準錯誤分析
• --deep : 深度分析模式 (包括依賴關係・環境因素)
• --preventive : 重視預防措施的分析
• --quick : 僅提供立即可用的修復方案

基本示例

bash
# 標準錯誤分析
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 的協作

bash
# 錯誤日誌分析
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
"按優先順序分類這些錯誤和警告，分別提出解決方法"

錯誤解決時間預測

text
🚀 即時修復 (5 分鐘以內)
├─ 拼字錯誤、import 遺漏
├─ 環境變數未設定
├─ 未定義變數的參照
└─ 預測時間: 2-5 分鐘

⚡ 快速修復 (30 分鐘以內)
├─ 依賴關係不一致
├─ 設定檔錯誤
├─ 型別不匹配
└─ 預測時間: 10-30 分鐘

🔧 需要調查 (2 小時以內)
├─ 複雜的邏輯錯誤
├─ 非同步處理競爭
├─ API 整合問題
└─ 預測時間: 30 分鐘-2 小時

🔬 深度分析 (半天以上)
├─ 架構起因
├─ 多系統連接
├─ 效能劣化
└─ 預測時間: 4 小時-數天

類似錯誤模式資料庫

text
頻發錯誤與即時解決方案
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

📊 "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: 錯誤資訊收集

bash
🔴 必須執行:
- 完整取得錯誤訊息
- 確認堆疊追蹤
- 確定發生條件 (可重現性)

🟡 早期執行:
- 收集環境資訊 (OS，版本，依賴關係)
- 直接變更歷程 (git log，最近提交)
- 確認相關日誌

🟢 額外執行:
- 系統資源狀況
- 網路狀態
- 外部服務狀態

階段 2: 根本原因分析

1. 整理表面症狀

• 錯誤訊息的正確內容
• 發生時間和模式
• 確定影響範圍

1. 確定深層原因

• 應用 5 Whys 分析
• 追蹤依賴關係
• 確認環境差異

1. 驗證假設

• 建立最小重現程式碼
• 執行隔離測試
• 縮小原因範圍

階段 3: 解決方案實作

bash
🔴 即時處理 (熱修復):
- 抑制症狀的最小修復
- 應用暫時迴避方案
- 準備緊急部署

🟡 根本解決:
- 針對原因的本質修復
- 新增測試案例
- 更新文件

🟢 預防措施實作:
- 強化錯誤處理
- 設定監控・警報
- 改善 CI/CD 管線

輸出範例

text
🚨 錯誤分析報告
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

📍 錯誤概要
├─ 類型: [編譯/執行時/邏輯/環境]
├─ 緊急度: 🔴 高 / 🟡 中 / 🟢 低
├─ 影響範圍: [功能名/元件]
└─ 重現性: [100% / 間歇性 / 特定條件]

🔍 根本原因
├─ 直接原因: [具體原因]
├─ 背景因素: [環境/設定/依賴關係]
└─ 觸發器: [發生條件]

💡 解決方案
🔴 即時處理:
1. [具體修復指令/程式碼]
2. [暫時迴避方案]

🟡 根本解決:
1. [本質修復方法]
2. [必要的重構]

🟢 預防措施:
1. [錯誤處理改善]
2. [測試新增]
3. [監控設定]

📝 驗證程序
1. [修復套用後確認方法]
2. [測試執行指令]
3. [動作確認項目]

錯誤類型別分析技法

編譯/建置錯誤

bash
# TypeScript 型別錯誤
必須確認 (高):
- tsconfig.json 設定
- 型別定義檔 (.d.ts) 的存在
- import 陳述句的正確性

# Rust 生命週期錯誤
必須確認 (高):
- 所有權移動
- 參照的有效期間
- 可變性衝突

執行時錯誤

bash
# Null/Undefined 參照
必須確認 (高):
- 可選鏈結不足
- 初始化時機
- 非同步處理的完成等待

# 記憶體相關錯誤
必須確認 (高):
- 取得堆積傾印
- 分析 GC 日誌
- 偵測循環參照

依賴關係錯誤

bash
# 版本衝突
必須確認 (高):
- lock 檔案的一致性
- peer dependencies 要求
- 傳遞性依賴關係

# 模組解析錯誤
必須確認 (高):
- NODE_PATH 設定
- 路徑別名設定
- 符號連結

注意事項

• 絕對禁止: 僅憑錯誤訊息的一部分判斷，未驗證就套用 Stack Overflow 解決方案
• 例外條件: 暫時迴避方案僅在以下 3 個條件下允許

1. 生產環境緊急回應 (24 小時內根本解決必須)
2. 外部服務故障 (復原等待中的替代手段)
3. 已知框架錯誤 (等待修正版本發布)

• 建議事項: 以根本原因確定為最優先，避免表面修復

最佳實務

1. 完整資訊收集: 從頭到尾確認錯誤訊息
2. 確認重現性: 最優先建立最小重現程式碼
3. 階段性方法: 從小修復開始驗證
4. 文件化: 記錄解決過程進行知識分享

常犯錯誤

• 處理症狀: 遺漏根本原因的表面修復
• 過度一般化: 廣泛套用特定案例的解決方案
• 省略驗證: 不確認修復後的副作用
• 知識個人化: 不將解決方法文件化

相關指令

• /design-patterns : 分析程式碼結構問題並提出模式建議
• /tech-debt : 從技術債務觀點分析錯誤的根本原因
• /analyzer : 需要更深入根本原因分析的情況