顽固问题系统化调试Skill performing-systematic-debugging-for-stubborn-problems

这个技能采用修改的Fagan Inspection方法,专门用于系统化解决软件中的顽固bug和复杂问题。通过四阶段过程,包括初始概览、系统化检查、根因分析和解决方案验证,确保彻底调试。关键词:系统化调试、Fagan Inspection、顽固bug、根因分析、软件测试、代码检查。

测试 0 次安装 0 次浏览 更新于 3/20/2026

name: 顽固问题系统化调试 description: 应用修改的Fagan Inspection方法,系统化解决顽固bug和复杂问题。当多次修复尝试反复失败时使用,当处理复杂系统交互时,或当需要方法化根因分析时。不要用于简单故障排除。在同一个复杂问题上多次调试尝试失败后触发。 model: claude-opus-4-5-20251101

使用Fagan Inspection进行系统化调试

此技能应用修改的Fagan Inspection方法,用于在面对复杂问题或顽固bug,且这些bug已抵抗多次修复尝试时,进行系统化问题解决。

过程概述

按顺序遵循这四个阶段。不要跳过阶段或在完成检查前尝试修复。

阶段1:初始概览

在分析前建立对问题的清晰理解:

  • 解释问题 用简单语言,无技术术语
  • 声明预期行为 - 应该发生什么
  • 声明实际行为 - 实际发生了什么
  • 记录症状 - 错误消息、日志、可观察的失败
  • 上下文 - 何时发生、频率、在什么条件下

输出: 任何人都能理解的清晰问题陈述。

阶段2:系统化检查

作为Fagan Inspection中的“读者”角色,进行逐行走查。识别缺陷,但不要尝试修复它们 - 这是纯检查。

检查以下缺陷类别:

  1. 逻辑错误

    • 错误的条件逻辑(错误的操作符、倒置的条件)
    • 循环条件(无限循环、过早终止)
    • 控制流问题(不可达代码、错误执行路径)
  2. 边界条件

    • 差一错误
    • 边缘情况(空输入、null值、最大值)
    • 数组/集合边界
  3. 错误处理

    • 未处理的异常
    • 缺失的验证
    • 静默失败(错误被捕获但未记录)
    • 错误的错误恢复
  4. 数据流问题

    • 变量范围问题
    • 数据转换错误
    • 类型不匹配或强制转换问题
    • 状态管理(陈旧数据、竞态条件)
  5. 集成点

    • API调用(错误端点、畸形请求、缺失头信息)
    • 数据库交互(查询错误、事务处理)
    • 外部依赖(版本不匹配、配置问题)
    • 时序问题(异步/等待问题、竞态条件)

大声思考在此阶段。对于代码的每个部分:

  • 说明代码的意图
  • 识别意图与实现之间的任何差异
  • 标记假设或不清晰方面
  • 对复杂部分使用超深度思考

输出: 分类的已识别缺陷列表,带行号和具体描述。

阶段3:根因分析

识别问题后,追溯找到根本原因 - 不仅仅是症状。

五个为什么技术:

  • 反复问“为什么”(至少3-5次)以到达底层问题
  • 在分析中明确陈述每个“为什么”
  • 示例:
    • 为什么API调用失败?→ 因为请求是畸形的
    • 为什么是畸形的?→ 因为数据没有正确序列化
    • 为什么没有序列化?→ 因为序列化器期望不同的类型
    • 为什么期望不同类型?→ 因为模式已更新但代码未更新
    • 根本原因:服务之间的模式版本不匹配

考虑:

  • 环境因素(配置、依赖、运行时环境)
  • 时序和并发(竞态条件、异步问题)
  • 代码或系统设计中的隐藏假设
  • 历史上下文(最近更改、迁移、更新)

明确声明假设:

  • “我假设X是因为…”
  • “这假定Y总是…”
  • 标记任何需要验证的假设

输出: 根因的清晰陈述、导致它的推理链,以及任何需要验证的假设。

阶段4:解决方案与验证

现在为每个识别的问题提出具体修复。

对于每个提议的解决方案:

  1. 描述修复 - 需要什么代码/配置更改
  2. 解释为什么它解决根因 - 将其与阶段3分析联系起来
  3. 考虑副作用 - 这个更改可能影响什么其他方面
  4. 定义验证步骤 - 如何确认修复工作

验证规划:

  • 特定测试用例,这些用例本应捕获此bug
  • 手动验证步骤
  • 要添加的监控或日志
  • 要验证的边缘情况

输出: 结构化的修复列表,带验证步骤。

重要指南

  • 彻底完成每个阶段再移动到下一个
  • 大声思考 - 在整个过程中口头化推理
  • 明确声明假设而不是做出隐式假设
  • 标记不清晰方面而不是猜测 - 如果不确定,说出来
  • 使用可用工具 - 读取文件、搜索代码、运行测试、检查日志
  • 专注于系统化分析而不是快速修复
  • 验证标记方面 - 完成所有阶段后,重新访问任何不清晰点,并在需要时使用“超”深度思考工具来澄清它们

最终输出

完成所有四个阶段后,提供:

  1. 发现摘要 - 关键缺陷和根因
  2. 提议的解决方案 - 优先级列表与理由
  3. 验证计划 - 如何确认修复工作
  4. 下一步 - 除非用户另有指示,否则继续实施提议的解决方案

何时不应使用此技能

  • 对于简单、明显的bug,有清晰修复
  • 当第一次调试尝试仍在进行时
  • 对于新功能(这是用于调试现有代码)
  • 当问题显然是环境性的(配置、基础设施)且不需要代码检查时