核心概述
debug-methodology 是一套面向生产环境的系统化故障诊断与修复方法论，核心价值在于强制根因修复、杜绝 workaround 依赖。该技能通过结构化流程阻止常见的"补丁链"（patch-chain）、"醉汉随机修复"（drunk man fixes）等反模式，确保每次修复都指向真正的问题根源。
核心用法
技能激活触发条件明确：
- 遭遇意外错误、服务故障、回归 bug、部署问题
- 修复尝试失败两次以上
- 任何修复方案提出前，必须通过"根因关卡"验证
五阶段排查流程
| 阶段 | 关键动作 | 目的 |
|------|---------|------|
| **STOP** | 记录精确症状、最后正常时间、服务启动方式 | 防止盲目操作 |
| **Hypothesize** | 按优先级形成单一假设（自身变更→环境→外部输入→新 bug） | 避免同时多变量 |
| **Test** | 单次变更→测试→失败则回滚→新假设 | 禁止变更堆叠 |
| **Patch-Chain Detection** | 两次失败则全量回滚，重返 Phase 1 | 打破修复螺旋 |
| **Post-Fix Verification** | 验证原始问题解决、无回归、移除修复后 bug 复现 | 确认因果性 |
根因关卡（Root Cause Gate）
修复前的强制检查：
1. 实际问题是什么？
2. 为什么发生？（非仅"什么"发生）
3. 修复是否消除该"为什么"？
Workaround 识别测试："若移除我的修复，bug 是否重现？"是 → workaround；否 → 真正修复。
部署安全流程（Hardened SCP Flow）
禁止服务器直接编辑，强制七步安全部署：PULL → EDIT → VERIFY (node -c) → BACKUP → PUSH → RESTART → HEALTH
.js文件必须经过node -c语法检查 +node -e "require()"模块加载验证- 复杂多行变更必须本地编辑后
scp上传，禁止 `sed` 多行插入（易静默损坏换行符）
显著优点
- 反模式识别全面：明确定义 workaround 成瘾、醉汉随机修复、路灯效应（只在熟悉处查找）、 cargo cult（盲目复制）等六种常见陷阱
- 强制根因思维："5 Whys" 方法与 workaround 识别测试形成双重保险
- 生产级安全约束：Hardened SCP Flow 将人为失误风险降至最低
- 决策树清晰：提供从问题出现到各分支场景的快速判断路径
潜在局限与风险
- 流程 overhead 较高：简单问题可能感觉繁琐，但复杂生产事故的收益显著
- 依赖执行纪律：若绕过 VERIFY 步骤直接重启，安全机制失效
- Workaround 例外需显式批准：紧急情况下可能延缓响应，但设计上宁可慢也要对
- 未覆盖特定技术栈细节：通用方法论，需使用者结合具体语言/框架知识
适合人群
- SRE/DevOps 工程师：处理生产事故、部署故障
- 后端开发者：排查服务异常、性能回归、依赖冲突
- 全栈开发者：部署流程规范化，避免"改完刷新试试看"的坏习惯
- 技术团队负责人：建立团队级故障响应标准
常规风险评估
| 维度 | 评估 |
|------|------|
| 执行风险 | 低 — 方法论本身安全，风险来自**不遵循** |
| 误用风险 | 中 — 可能被误解为"禁止所有临时方案"，实际允许显式标记的临时 workaround |
| 覆盖完整性 | 高 — 涵盖诊断、修复、验证、部署全生命周期 |
| 学习曲线 | 中 — 流程记忆需练习，但决策树和检查清单降低认知负荷 |
总结建议
该技能应作为任何修复操作的强制前置检查，尤其适合高压故障场景下的认知卸载（cognitive offloading）。建议团队将其纳入 on-call 手册与 code review checklist，核心关注"两次失败即回滚"与"node -c 先于 restart"两条红线。