用途：当出现与预期不符的观察行为（无论是否已能可靠复现）、间歇性失败（flaky）、部署后回归，或带具体症状（超时、报错、卡顿）的性能退化时启用。若系统本身运行正常、只是为优化而优化，应改用性能工程类技能；若生产环境信号不足，可结合可观测性类技能。
流程：先记录预期行为、观察行为、确切环境和最后出现的时间与频率；建立可靠复现，或至少建立与故障相关的可重复观察信号（日志、指标、追踪）；逐步缩减输入、涉及组件与时间窗口至最小复现用例；按“易测试且概率高”而非“最有趣”排序可证伪假设；在能区分假设的边界埋点；定位根因、影响范围与症状产生的具体机制；获授权后应用移除根因的最小改动，并加入在无修复时必定失败的回归测试。
原则：一次只改一个候选原因；区分时间相关性与因果性；重启或清理状态前先保存日志、状态、转储等证据；系统性对比好环境与坏环境，每次只变一个因子；把 flakiness 视为并发、时序、共享状态或外部依赖问题的症状而非“多跑一次”。结论前清理临时、冗长或敏感（个人数据、密钥）的埋点；用机制层面描述原因，例如“X 与 Y 之间的竞态使读取早于写入完成”，而非“有时会失败”。
反模式：没有假设就先加 print 再跑；修正错误首次出现的位置而不验证其是否为源头；手动复现一次不失败就宣称“已修复”；把不稳定测试当作无关噪声直接忽略。
验证：修复前复现确定性地失败、修复后在同环境确定性地通过；回归测试在回滚修复时因正确原因失败；检查修复路径周边场景的副作用；留下简短的机制、证据与预防措施（测试、不变量、告警）记录。未取得该证据前不得宣称根因“已解决”。相关技能包括技术调研、可观测性、性能工程与代码评审；可参阅 references/standards.md 了解复现与隔离技术、常见 flakiness 原因、各环境工具及官方来源。分类：按诊断调试用途归入测试与质量。