code-error-fixer
📖 技能介紹
name: code-error-fixer description: | Systematic code error diagnosis and fix skill. Handles compilation errors, runtime exceptions, type errors, logic bugs, crash analysis, dependency conflicts, and unexpected behavior. TRIGGER when: user reports an error/exception/bug/crash, build or test failures, unexpected behavior in code, type errors, runtime stack traces, dependency resolution failures, or asks "why is this not working" / "fix this error" / "debug this". DO NOT TRIGGER when: user asks for code review without errors, general architecture questions, feature requests without error context, or "how would I implement X" (use appropriate dev skill). description_zh: 程式碼報錯自動診斷與修復技能 description_en: "Code error auto-diagnosis & fix skill (compiler/runtime/logic bugs)" version: 1.0.0 allowed-tools: Read,Bash,Glob,Grep,Edit,Write,WebSearch metadata: category: debugging version: "1.0.0" sources: - Rubber Duck Debugging principle - Root Cause Analysis (RCA) methodology - Scientific Method for debugging - The Debugging Mindset (Andy Oram & Greg Wilson) - Why Programs Fail (Andreas Zeller)
Code Error Fixer — 程式碼報錯自動修復技能
系統化診斷和修復各類程式碼錯誤的工作流。遵循 復現 → 定位 → 理解 → 修復 → 驗證 五步法，避免憑直覺猜測式改程式碼。
五步修復工作流（強制遵循）
使用者報錯 → [Step 1 復現] → [Step 2 定位] → [Step 3 理解] → [Step 4 修復] → [Step 5 驗證] → 結案
↑_____________ 證據不足時回到 Step 1 _____________↓
Step 1: 復現 (Reproduce)
目標：穩定復現問題，收集完整錯誤上下文。
必須收集的資訊（缺一不可，逐項核對）：
- [ ] 完整錯誤訊息 — 不要摘要，擷取完整堆疊/日誌
- [ ] 觸發條件 — 什麼操作/輸入/資料會觸發？是否必現？
- [ ] 環境資訊 — 語言/執行時版本、作業系統、依賴版本、Node/Python/Go 等版本
- [ ] 相關程式碼 — 出錯的原始檔、最近修改的檔案、配置檔案
- [ ] 復現步驟 — 使用者能否提供最小復現？如果不能，自己構造
執行動作：
1. 讀取報錯檔案內容（Read）
2. 檢查執行環境（node --version, python --version, go version 等）
3. 嘗試在本地復現（執行構建/測試/啟動命令）
4. 如果錯誤依賴特定輸入，引導使用者提供或構造最小復現用例
5. 如果無法復現，要求使用者提供更多上下文並不能繼續修復
產出： 清晰的錯誤描述 + 可復現的步驟
Step 2: 定位 (Isolate)
目標：縮小問題範圍，找到根因所在的精確位置。
定位策略（優先順序從高到低）：
| 策略 | 適用場景 | 方法 |
|---|---|---|
| 二分法 | 大段程式碼/多檔案 | 註釋掉一半程式碼，看錯誤是否消失；重複直到定位 |
| 堆疊追蹤 | 執行時異常/崩潰 | 從棧頂往棧底讀，找到第一個你自己的程式碼 |
| 差異對比 | 之前能工作現在不行 | git diff，git blame 找到最近修改 |
| 最小化輸入 | 輸入資料導致異常 | 逐步縮小輸入，找到觸發異常的精確資料 |
| 斷言/日誌 | 邏輯錯誤/靜默失敗 | 在關鍵路徑插入臨時日誌或斷言 |
| 依賴分析 | 編譯/執行時依賴錯誤 | 檢查 package.json / go.mod / requirements.txt 版本約束 |
執行動作：
1. 讀取報錯檔案中涉及的檔案（從堆疊/報錯行號開始）
2. 追蹤變數/函式的源頭和流向
3. 用二分法註釋無關程式碼縮小範圍
4. 必要時插入臨時 console.log / print / fmt.Println
5. 檢查版本相容性和最近變更
🔴 鐵律：在沒有定位到具體哪一行/哪個變數前，禁止進行修復。
Step 3: 理解 (Understand)
目標：徹底理解根因——回答"為什麼會產生這個錯誤"。
- 檢視相關 API / 函式文件
- 理解預期行為 vs 實際行為的差異
- 檢查邊界條件、空值、型別不匹配、競態條件等常見根因
- 對不確定的根因，查閱 Web 搜尋確認（庫的已知 issue、API 變更等）
🔴 鐵律：不能解釋根因，就不能開始修復。
Step 4: 修復 (Fix)
目標：最小改動、精準修復。
- 最小改動原則 — 只改導致問題的地方，不順便重構
- 避免"霰彈式修改" — 一次只改一個地方，驗證後再改下一個
- 先考慮修復方案對現有邏輯的影響（迴歸風險）
- 處理邊緣情況：空值、邊界值、型別轉換、非同步時序
- 新增必要的防禦性檢查（但不濫用）
Step 5: 驗證 (Verify)
目標：確認修復有效且沒有引入新問題。
- [ ] 運行復現步驟確認錯誤消失
- [ ] 執行現有測試套件
- [ ] 檢查相關功能的冒煙測試
- [ ] 檢查是否引入了新的 TypeScript / linter 錯誤
- [ ] 如果影響面大，建議使用者 review
如果驗證失敗 → 回到 Step 1。
常見錯誤型別與診斷策略
1. 編譯/語法錯誤
| 型別 | 快速定位技巧 |
|---|---|
| 型別錯誤 (TypeScript) | 從第一個錯誤開始修復（後續往往只是級聯） |
| 語法錯誤 | 檢查括號/引號/逗號配對，模板字串中的反引號 |
| 匯入錯誤 | ImportError / ModuleNotFoundError — 檢查路徑、大小寫、__init__.py |
| 連結錯誤 | 檢查庫版本、ABI 相容性、連結庫路徑 |
2. 執行時異常
| 異常 | 常見根因 |
|---|---|
NullPointerException / Cannot read property of undefined |
非同步資料未載入、可選鏈缺失、初始值未設 |
TypeError: X is not a function |
匯入錯誤、變數覆蓋、呼叫時機過早 |
IndexError / IndexOutOfBounds |
off-by-one 錯誤、空列表、邊界條件 |
StackOverflow |
無限遞迴、事件迴圈、迴圈依賴 |
OutOfMemoryError |
記憶體洩漏、大物件未釋放、資料量超出預期 |
3. 邏輯 Bug
| 型別 | 診斷方法 |
|---|---|
| 條件分支錯誤 | 列出所有分支 + 輸入組合，逐一驗證 |
| 迴圈/遍歷錯誤 | 追蹤迴圈變數變化，檢查邊界條件 |
| 非同步/併發錯誤 | 檢查 race condition，新增鎖或原子操作 |
| 狀態管理錯誤 | 追蹤狀態變更鏈路，檢查不可變性 |
| 浮點精度 | 不直接比較浮點數，使用 epsilon 或 Decimal |
4. 依賴/環境問題
想要更強大的技能外掛，就來小蔥技能站7w4.net看看吧。
| 問題 | 診斷方法 |
|---|---|
| 版本衝突 | npm ls <pkg>, go mod graph, pipdeptree |
| 環境差異 | 對比開發/測試/生產環境的 .env 和配置檔案 |
| 快取問題 | 清除快取：node_modules, pip cache, Go build cache |
| 平臺差異 | 路徑分隔符、換行符（CRLF vs LF）、檔案許可權 |
5. 資料/API 錯誤
| 問題 | 診斷方法 |
|---|---|
| API 返回值異常 | curl / 瀏覽器檢查真實響應，驗證介面文件 |
| 資料格式不對 | 檢查 JSON Schema、邊界型別（空陣列/null/缺失欄位） |
| 編碼問題 | UTF-8 vs GBK、BOM、特殊字元轉義 |
核心原則
1. 一次只改一個問題
不要同時修復多個無關問題。每個修復獨立驗證，否則無法確定哪個改動有效。
2. 證據驅動
每個結論必須由資料支援：堆疊、日誌、變數值、測試結果。禁止腦補根因。
3. 先檢查最簡單的可能性
- 拼寫錯誤？大小寫？路徑分隔符？
- 快取需要清除？
- 服務需要重啟？
- 配置檔案生效了嗎？
4. 最小復現原則
如果能構造最小復現（Minimal Reproducible Example），優先用它除錯。MRE 本身往往就已經揭示了根因。
5. 回退總比亂改好
如果問題複雜且時間緊迫，回退到上次正常工作的版本好過胡亂修復引入更多問題。
技術棧快速參考
JavaScript / TypeScript / Node.js
# 檢查 Node 版本和型別定義
node --version && npx tsc --version
# 檢查依賴版本衝突
npm ls <package-name> # 已安裝的版本樹
npm outdated # 可更新的包
npx synp --source-file # yarn.lock ↔ package-lock.json 轉換檢查
# 清除快取
rm -rf node_modules && npm install
# 或
npm cache clean --force
Python
# 檢查 Python 版本和虛擬環境
python --version && which python
pip list | grep <package>
# 依賴樹
pipdeptree -p <package>
# 重新安裝
pip install --force-reinstall <package>
Go
go version
go env GOPATH GOROOT
go mod graph | grep <package>
go mod tidy
Rust
rustc --version && cargo --version
cargo tree -p <crate>
cargo clean && cargo build
對話模板
當用戶報告錯誤時，按以下結構回覆：
- 錯誤復現 — 確認收到的錯誤資訊 + 環境資訊（如已提供）
- 缺失資訊 — 如果缺少關鍵資訊，列出需要補充的內容
- 定位計劃 — 簡要說明打算如何排查
- 發現 — 定位過程中的發現/新資訊
- 根因 — 確定根因時的明確宣告
- 修復方案 — 具體修改內容 + 預期效果
- 驗證結果 — 驗證結論
禁止做的事
- ❌ 不收集完整錯誤資訊就開始猜
- ❌ 不確認根因就改程式碼（霰彈式修改）
- ❌ 一次改多個無關問題
- ❌ 修復後不驗證
- ❌ 對不確定的問題直接建議"升級依賴"或"重灌"而不分析根因
- ❌ 複雜問題不嘗試構建最小復現
🤖 AI 評測
這個 Skill 質量不錯，採用了科學嚴謹的除錯方法論，結構清晰、覆蓋面廣。它的五步修復流程能幫助系統化地解決程式碼問題，避免盲目改程式碼。錯誤分類詳細、診斷策略實用，還有常見程式語言的技術參考。不過它偏理論化，缺乏實際案例演示，對於複雜場景的指導可以更深入一些。
