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 分钟
└─ 处理方法: 可选链式调用 (?.) 或添加 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% / 间歇性 / 特定条件]
└─ 预测解决时间: [2-5 分钟 / 30 分钟-2 小时 / 4 小时+]
🔍 根本原因
├─ 直接原因: [具体原因]
├─ 背景因素: [环境/设置/依赖关系]
├─ 触发器: [发生条件]
└─ 类似模式: [已知错误类型 / 首次发生]
💡 解决方案
🔴 即时处理 (预计: X 分钟):
1. [具体修复命令/代码]
2. [临时解决方案]
🟡 根本解决 (预计: Y 小时):
1. [本质修复方法]
2. [必要的重构]
🟢 预防措施:
1. [错误处理改进]
2. [测试添加]
3. [监控设置]
📋 风险评估
├─ 修复失败风险: [低/中/高]
├─ 副作用影响: [无/有限/广泛]
└─ 回滚计划: [简单/复杂/不可能]
📝 验证步骤
1. [修复后的确认方法]
2. [测试执行命令]
3. [功能确认项目]
4. [性能影响检查]
错误类型别分析方法
编译/构建错误
# TypeScript 类型错误
必须确认 (高):
- tsconfig.json 设置
- 类型定义文件 (.d.ts) 存在
- import 语句的准确性
# Rust 生命周期错误
必须确认 (高):
- 所有权转移
- 引用的有效期
- 可变性冲突
运行时错误
# Null/Undefined 引用
必须确认 (高):
- 可选链不足
- 初始化时机
- 异步处理的完成等待
# 内存相关错误
必须确认 (高):
- 获取堆转储
- 分析 GC 日志
- 检测循环引用
依赖关系错误
# 版本冲突
必须确认 (高):
- lock 文件的一致性
- peer dependencies 的要求
- 传递依赖关系
# 模块解析错误
必须确认 (高):
- NODE_PATH 设置
- 路径别名设置
- 符号链接
注意事项
- 绝对禁止: 仅凭部分错误信息判断、未经验证就应用 Stack Overflow 的解决方案
- 例外条件: 临时解决方案仅在以下 3 个条件下允许
- 生产环境紧急响应 (24 小时内必须根本解决)
- 外部服务故障 (等待恢复期间的替代手段)
- 已知框架 bug(等待修复版本发布)
- 建议事项: 优先识别根本原因，避免表面修复
最佳实践
- 完整信息收集: 确认错误信息从头到尾
- 确认重现性: 优先创建最小重现代码
- 渐进式方法: 从小修复开始验证
- 文档化: 记录解决过程以便知识共享
常见陷阱
- 处理症状: 表面修复忽略根本原因
- 过度泛化: 将特定案例的解决方案广泛应用
- 省略验证: 不确认修复后的副作用
- 知识孤岛: 不记录解决方法
相关命令
/design-patterns: 分析代码结构问题并提出模式建议/tech-debt: 从技术债务角度分析错误的根本原因/analyzer: 需要更深入的根本原因分析时使用