Easyuseaide complex debugging

复杂故障排查

目标不是快速制造看似有效的补丁，而是形成可重复证据、定位根因并验证修复。

与已有调试框架配合

如果其他插件、Skill 或项目规则已经指定通用调试流程，以该流程作为根因调查主流程。本 Skill 只补充间歇性、并发、性能、资源泄漏、失败恢复和反复复发场景的专项检查。

复用已有故障描述、复现步骤、假设记录、测试和日志证据，不重新创建第二套调查流程。两个流程要求真正冲突时，遵循用户当前指令和项目规则；仍无法解决时先报告差异，不默默选择。

1. 定义故障

开始复杂故障调查时，读取 assets/incident-investigation.md，根据当前项目情况创建调查记录，并在排查过程中持续更新。

记录：

• 预期行为；
• 实际行为；
• 首次出现时间和变化；
• 稳定复现还是间歇出现；
• 影响范围；
• 当前已有证据；
• 已尝试方案及结果。

区分事实、推断和未知。

2. 建立最小复现

优先获得：

• 最小输入；
• 最小环境；
• 稳定命令；
• 失败日志、错误码或指标；
• 修改前必然失败的测试。

不能稳定复现时，先增加必要的可观测性，不盲目修改核心逻辑。

3. 缩小范围

按证据逐层排除：

• 输入与配置；
• 调用链与数据流；
• 边界条件；
• 外部依赖；
• 并发与事务；
• 超时、重试和部分失败；
• 缓存和状态；
• 资源释放；
• 环境和版本差异。

每次只验证一个主要假设，并记录结果。

4. 选择验证工具

按问题使用：

• 单元或集成测试；
• 日志和结构化事件；
• Trace；
• 指标和性能剖析；
• 数据库执行计划、锁和事务视图；
• 网络抓包或请求录制；
• 线程、进程、内存和文件句柄分析；
• 二分定位；
• 故障注入；
• 并发或压力测试。

没有基准时不声称性能提升。

5. 修复原则

• 修复根因，不只屏蔽症状；
• 保持改动最小；
• 不删除测试或放宽断言；
• 证据不足时不进行大规模重构；
• 多次修补仍反复出现时，重新检查领域模型、数据流和设计边界。

6. 验证修复

确认：

• 原始复现不再失败；
• 修改前失败、修改后通过；
• 相邻正常场景未受影响；
• 必要回归测试已增加；
• 并发、重复、失败恢复或资源释放得到与风险匹配的验证；
• 未验证内容和剩余风险明确记录。

7. 沉淀

记录根因、关键证据、修复、回归测试和长期改进。临时调试流水不全部写入长期项目文档。

长期项目中，将依据 assets/incident-investigation.md 完成的调查记录保存到项目 docs/ 下，并在 project-status.md 中引用，不在状态文件中复制完整调查内容。