name: 顽固问题系统化调试 description: 应用修改的Fagan Inspection方法,系统化解决顽固bug和复杂问题。当多次修复尝试反复失败时使用,当处理复杂系统交互时,或当需要方法化根因分析时。不要用于简单故障排除。在同一个复杂问题上多次调试尝试失败后触发。 model: claude-opus-4-5-20251101
使用Fagan Inspection进行系统化调试
此技能应用修改的Fagan Inspection方法,用于在面对复杂问题或顽固bug,且这些bug已抵抗多次修复尝试时,进行系统化问题解决。
过程概述
按顺序遵循这四个阶段。不要跳过阶段或在完成检查前尝试修复。
阶段1:初始概览
在分析前建立对问题的清晰理解:
- 解释问题 用简单语言,无技术术语
- 声明预期行为 - 应该发生什么
- 声明实际行为 - 实际发生了什么
- 记录症状 - 错误消息、日志、可观察的失败
- 上下文 - 何时发生、频率、在什么条件下
输出: 任何人都能理解的清晰问题陈述。
阶段2:系统化检查
作为Fagan Inspection中的“读者”角色,进行逐行走查。识别缺陷,但不要尝试修复它们 - 这是纯检查。
检查以下缺陷类别:
-
逻辑错误
- 错误的条件逻辑(错误的操作符、倒置的条件)
- 循环条件(无限循环、过早终止)
- 控制流问题(不可达代码、错误执行路径)
-
边界条件
- 差一错误
- 边缘情况(空输入、null值、最大值)
- 数组/集合边界
-
错误处理
- 未处理的异常
- 缺失的验证
- 静默失败(错误被捕获但未记录)
- 错误的错误恢复
-
数据流问题
- 变量范围问题
- 数据转换错误
- 类型不匹配或强制转换问题
- 状态管理(陈旧数据、竞态条件)
-
集成点
- API调用(错误端点、畸形请求、缺失头信息)
- 数据库交互(查询错误、事务处理)
- 外部依赖(版本不匹配、配置问题)
- 时序问题(异步/等待问题、竞态条件)
大声思考在此阶段。对于代码的每个部分:
- 说明代码的意图
- 识别意图与实现之间的任何差异
- 标记假设或不清晰方面
- 对复杂部分使用超深度思考
输出: 分类的已识别缺陷列表,带行号和具体描述。
阶段3:根因分析
识别问题后,追溯找到根本原因 - 不仅仅是症状。
五个为什么技术:
- 反复问“为什么”(至少3-5次)以到达底层问题
- 在分析中明确陈述每个“为什么”
- 示例:
- 为什么API调用失败?→ 因为请求是畸形的
- 为什么是畸形的?→ 因为数据没有正确序列化
- 为什么没有序列化?→ 因为序列化器期望不同的类型
- 为什么期望不同类型?→ 因为模式已更新但代码未更新
- 根本原因:服务之间的模式版本不匹配
考虑:
- 环境因素(配置、依赖、运行时环境)
- 时序和并发(竞态条件、异步问题)
- 代码或系统设计中的隐藏假设
- 历史上下文(最近更改、迁移、更新)
明确声明假设:
- “我假设X是因为…”
- “这假定Y总是…”
- 标记任何需要验证的假设
输出: 根因的清晰陈述、导致它的推理链,以及任何需要验证的假设。
阶段4:解决方案与验证
现在为每个识别的问题提出具体修复。
对于每个提议的解决方案:
- 描述修复 - 需要什么代码/配置更改
- 解释为什么它解决根因 - 将其与阶段3分析联系起来
- 考虑副作用 - 这个更改可能影响什么其他方面
- 定义验证步骤 - 如何确认修复工作
验证规划:
- 特定测试用例,这些用例本应捕获此bug
- 手动验证步骤
- 要添加的监控或日志
- 要验证的边缘情况
输出: 结构化的修复列表,带验证步骤。
重要指南
- 彻底完成每个阶段再移动到下一个
- 大声思考 - 在整个过程中口头化推理
- 明确声明假设而不是做出隐式假设
- 标记不清晰方面而不是猜测 - 如果不确定,说出来
- 使用可用工具 - 读取文件、搜索代码、运行测试、检查日志
- 专注于系统化分析而不是快速修复
- 验证标记方面 - 完成所有阶段后,重新访问任何不清晰点,并在需要时使用“超”深度思考工具来澄清它们
最终输出
完成所有四个阶段后,提供:
- 发现摘要 - 关键缺陷和根因
- 提议的解决方案 - 优先级列表与理由
- 验证计划 - 如何确认修复工作
- 下一步 - 除非用户另有指示,否则继续实施提议的解决方案
何时不应使用此技能
- 对于简单、明显的bug,有清晰修复
- 当第一次调试尝试仍在进行时
- 对于新功能(这是用于调试现有代码)
- 当问题显然是环境性的(配置、基础设施)且不需要代码检查时