关于 principle-fix-root-causes
Fix Root Causes 是面向开发者的调试原则技能,引导从可见症状追查到最早出错的决策,修复故障本身,而不是掩盖问题。
主要功能
- 01修改前先复现
- 02逐步追查因果
- 03检查实际错误与状态
- 04判断状态是否合法
- 05搜索重复出现的故障模式
- 06重启后故障时检查持久化状态
适用场景
- 01追查故障的根源
- 02诊断在其他位置重现的缺陷
- 03调查重启后出现的故障
安装
复制下面的命令,在终端中运行。
$
npx skills add https:/ / github.com/ backnotprop/ pstack --skill principle-fix-root-causes安装后在 Claude Code 中输入/principle-fix-root-causes确认已加载。
详细介绍
修复根本原因
调试时,要修复故障,而不是故障显现的位置。症状是错误状态变得可见的地方。根本原因是系统首次做出不该做的操作,或未能处理本应处理的状态的地方。
原因: 修复症状会掩盖证据,让故障有机会在别处显现。每次这样的修复都会让系统更难理解,因为代码中会留下一个没人指出其所修复问题的变通方案。
模式:
- 先复现问题。
- 每一步都问“为什么”,直到答案指向代码中的错误决策,而不是更早错误决策导致的结果。
- 遇到困难时,添加检测手段。读取实际错误和实际状态,不要猜测。
- 判断触发症状的状态是否合法。如果系统可能处于这种状态,那么在这种状态下出错的代码就是根本原因,在该处处理这种状态才是正确的修复。如果这种状态本不该存在,那么在出错处添加检查只会掩盖错误。找到产生这种状态的原因。保护性检查、重试、吞掉错误、钳制数值和丢弃状态,通常都是掩盖错误的手段。
- 如果问题只在重启后出现,优先怀疑持久化状态:配置文件、缓存、锁文件、序列化状态。
- 检查这种模式,而不只是单个实例。找出所有存在相同故障的地方,并全部修复。
- 如果某个变通方案需要一段很长的注释来解释,那么代码就是错的。修复代码,而不是注释。
- 如果要费很大劲才能找到用于判断的关键信息,就提出一种成本低、始终开启的信号,让人一眼就能看出问题。
评论
支持 Markdown