从错误消息定位根本原因并提出解决方案

从错误消息定位根本原因并提出解决方案

从错误信息中识别根本原因，预测解决时间，提出经过验证的解决方案。学习类似错误的模式，立即提供合适的处理方法。

使用方法

/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: 根本原因分析

1. 整理表面症状

   • 错误信息的准确内容
   • 发生时机和模式
   • 确定影响范围

2. 识别深层原因

   • 应用 5 Whys 分析
   • 追踪依赖关系
   • 确认环境差异

3. 验证假设

   • 创建最小重现代码
   • 执行隔离测试
   • 缩小原因范围

阶段 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 个条件下允许
  1. 生产环境紧急响应 (24 小时内必须根本解决)
  2. 外部服务故障 (等待恢复期间的替代手段)
  3. 已知框架 bug(等待修复版本发布)
• 建议事项: 优先识别根本原因，避免表面修复

最佳实践

1. 完整信息收集: 确认错误信息从头到尾
2. 确认重现性: 优先创建最小重现代码
3. 渐进式方法: 从小修复开始验证
4. 文档化: 记录解决过程以便知识共享

常见陷阱

• 处理症状: 表面修复忽略根本原因
• 过度泛化: 将特定案例的解决方案广泛应用
• 省略验证: 不确认修复后的副作用
• 知识孤岛: 不记录解决方法

相关命令

• /design-patterns : 分析代码结构问题并提出模式建议
• /tech-debt : 从技术债务角度分析错误的根本原因
• /analyzer : 需要更深入的根本原因分析时使用