القائمة
log/錯誤快速定位（搭配 filesystem.grep、audit.log_query）。當使用者遇到系統問題或錯誤時，快速診斷和定位問題。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
在使用者要設計網站、Web App 或元件介面時使用。常見觸發像「做 landing page」「設計 dashboard」「規劃 component UI」。輸出可上線介面與設計系統；不取代產品策略或純品牌研究。
在使用者要把模糊想法整理成可開發 spec 時使用。常見觸發像「整理需求成 spec」「補驗收條件」「拆分階段開發計畫」。輸出技術規格、白話規格與可直接貼用於 Codex / Claude Code 的分階段 instructions；不直接代替正式文件發布。
在非程式開發者要用 vibe coding 與 coding agent 協作時使用。常見觸發像「幫我整理開發準則」「定義交付邊界」「規劃驗證方式」。輸出需求表達、邊界與風險控管準則；不直接取代實作。
當使用者要拆解大型、混亂、跨部門、反覆卡關或高不確定性的難題，或明確要求做問題拆解、issue tree、根因與對策分層時使用。先分清楚現象、目標落差、真正問題與根因假設，再判斷問題是範疇型、分析型、動態系統型、研究型或交付型，最後用 issue tree/MECE、WBS、系統思考、驗收標準、依賴排程、資源分派與流動指標，產出可執行的問題拆解報告、工作包、關鍵路徑、並行策略與 PDCA 回饋節奏。
當使用者要替代解法、不同思路、更簡單或更穩定做法時使用。將現有方案重構成結構問題，提出多條可落地方案與最低摩擦解。
建立定期任務（每日晨報、每週回顧）。當使用者需要設定自動化的、定期執行的任務時使用。
| name | incident-triage |
| description | log/錯誤快速定位（搭配 filesystem.grep、audit.log_query）。當使用者遇到系統問題或錯誤時，快速診斷和定位問題。 |
本技能旨在提供一個標準化的方法來快速診斷和定位系統問題，包括日誌分析、錯誤追蹤和根本原因分析。
filesystem.grep: 搜尋日誌檔案中的特定模式audit.log_query: 查詢審計日誌與使用者溝通，快速收集關於問題的基本信息。
初始信息收集清單:
優先級分類:
| 優先級 | 特徵 | 響應時間 |
|---|---|---|
| P1 (關鍵) | 系統完全不可用，影響所有使用者 | 立即 (15 分鐘) |
| P2 (高) | 主要功能不可用，影響多個使用者 | 1 小時 |
| P3 (中) | 部分功能受影響，影響單個或少數使用者 | 4 小時 |
| P4 (低) | 次要功能受影響，無明顯業務影響 | 24 小時 |
進行快速的系統健康檢查，確定問題的範圍。
健康檢查清單:
健康檢查命令範例:
# 檢查進程狀態
ps aux | grep [service_name]
# 檢查網絡連接
ping [host]
curl -I [service_url]
# 檢查磁碟空間
df -h
# 檢查 CPU 和記憶體
top -b -n 1 | head -20
free -h
# 檢查資料庫連接
mysql -u [user] -p [password] -e "SELECT 1;"
# 檢查最近的日誌
tail -100 /var/log/syslog
收集與問題相關的所有日誌檔案。
日誌收集清單:
日誌位置參考:
| 日誌類型 | 常見位置 |
|---|---|
| 系統日誌 | /var/log/syslog, /var/log/messages |
| Apache 日誌 | /var/log/apache2/, /var/log/httpd/ |
| Nginx 日誌 | /var/log/nginx/ |
| 應用程式日誌 | /var/log/app/, /opt/app/logs/ |
| 資料庫日誌 | /var/log/mysql/, /var/log/postgresql/ |
| 認證日誌 | /var/log/auth.log |
使用 grep 和其他工具搜尋日誌中的錯誤和異常。
日誌搜尋策略:
日誌搜尋命令範例:
# 搜尋錯誤日誌
grep -i "error\|exception\|failed" /var/log/app.log
# 搜尋特定時間範圍的日誌
grep "2024-02-09 14:" /var/log/app.log
# 搜尋特定的錯誤代碼
grep "500\|502\|503" /var/log/nginx/error.log
# 統計錯誤頻率
grep -i "error" /var/log/app.log | wc -l
# 查看錯誤的上下文
grep -B 5 -A 5 "error message" /var/log/app.log
# 使用 awk 提取特定欄位
awk '{print $1, $2, $9}' /var/log/nginx/access.log | grep "500"
分析日誌，識別錯誤的模式和可能的根本原因。
錯誤分析步驟:
根本原因分析方法:
使用「5 Why」方法逐層深入分析：
問題: 應用程式崩潰
為什麼 1: 記憶體不足
為什麼 2: 記憶體洩漏
為什麼 3: 某個功能未正確釋放記憶體
為什麼 4: 代碼中缺少清理邏輯
為什麼 5: 開發人員未進行充分的記憶體管理測試
根本原因: 代碼中的記憶體洩漏，由於缺乏適當的測試
進行更深入的診斷，隔離問題的具體原因。
診斷技術:
診斷命令範例:
# 進行網絡追蹤
tcpdump -i eth0 -w capture.pcap
# 進行性能分析
perf record -g ./application
perf report
# 檢查開啟的檔案
lsof -p [PID]
# 檢查網絡連接
netstat -tuln | grep LISTEN
ss -tuln
# 進行堆棧追蹤
strace -e trace=file ./application
將所有診斷結果整理成一份清晰的報告。
診斷報告結構:
# 事件診斷報告
## 事件摘要
- **事件 ID**: [ID]
- **報告時間**: [時間]
- **優先級**: [P1/P2/P3/P4]
- **狀態**: [已解決/進行中/待命]
## 問題描述
[使用者報告的問題詳細描述]
## 影響範圍
- 受影響的系統: [系統列表]
- 受影響的使用者: [數量]
- 業務影響: [詳細說明]
## 時間線
| 時間 | 事件 |
|------|------|
| 14:30 | 首次報告問題 |
| 14:35 | 開始診斷 |
| 14:45 | 識別根本原因 |
| 15:00 | 實施修復 |
| 15:15 | 驗證修復 |
## 根本原因分析 (RCA)
### 直接原因
[問題的直接技術原因]
### 根本原因
[深層的根本原因]
### 相關因素
- [因素 1]
- [因素 2]
## 日誌分析結果
### 關鍵日誌條目
[時間戳] [級別] [訊息] 2024-02-09 14:32:15 ERROR Database connection timeout 2024-02-09 14:32:16 ERROR Failed to execute query
### 錯誤統計
- 總錯誤數: [數量]
- 錯誤類型分布: [分布]
- 錯誤頻率: [頻率]
## 修復方案
### 臨時修復
[立即採取的臨時措施]
### 永久修復
[長期解決方案]
### 驗證步驟
- [ ] 步驟 1
- [ ] 步驟 2
- [ ] 步驟 3
## 預防措施
[防止類似問題再次發生的措施]
## 後續行動
- [ ] 實施永久修復
- [ ] 更新監控警報
- [ ] 更新文件
- [ ] 進行事後檢討
## 附錄
- 完整的日誌輸出
- 詳細的技術分析
- 相關的配置檔案
根據診斷結果實施修復，並驗證問題已解決。
修復和驗證清單:
快速響應: 根據優先級快速響應，優先處理關鍵問題。
系統化診斷: 按照邏輯順序進行診斷，避免遺漏。
詳細記錄: 記錄所有診斷步驟和發現，便於後續參考。
根本原因分析: 不要只修復症狀，要找到並解決根本原因。
預防措施: 實施措施防止類似問題再次發生。
溝通: 定期更新利益相關者關於問題狀態的信息。
事後檢討: 事件解決後進行檢討，學習經驗教訓。
常見原因: 記憶體洩漏、未處理的異常、資源耗盡 診斷步驟: 檢查應用程式日誌、檢查系統資源、進行堆棧追蹤
常見原因: 資料庫服務停止、網絡問題、認證失敗 診斷步驟: 檢查資料庫服務狀態、測試網絡連接、驗證認證憑證
常見原因: 無限迴圈、記憶體洩漏、過度計算 診斷步驟: 進行性能分析、識別消耗資源的進程、檢查代碼
常見原因: 資料庫查詢緩慢、網絡延遲、伺服器過載 診斷步驟: 分析 API 日誌、進行資料庫查詢分析、檢查伺服器負載
常見原因: 日誌檔案過大、臨時檔案堆積、資料庫增長 診斷步驟: 檢查磁碟使用情況、識別大檔案、清理不需要的檔案