312 lines
8.0 KiB
Markdown
312 lines
8.0 KiB
Markdown
## Error Fix
|
||
|
||
從錯誤訊息中識別根本原因，預測解決時間並提出經過驗證的解決方案。學習類似錯誤的模式，立即提供適當的處理方法。
|
||
|
||
### 使用方法
|
||
|
||
```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. **整理表面症狀**
|
||
- 錯誤訊息的正確內容
|
||
- 發生時間和模式
|
||
- 確定影響範圍
|
||
|
||
2. **確定深層原因**
|
||
- 應用 5 Whys 分析
|
||
- 追蹤依賴關係
|
||
- 確認環境差異
|
||
|
||
3. **驗證假設**
|
||
- 建立最小重現程式碼
|
||
- 執行隔離測試
|
||
- 縮小原因範圍
|
||
|
||
#### 階段 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` : 需要更深入根本原因分析的情況
|