用途：面向缺陷、偶发失败和性能回退的排查流程。核心规则是不先提理论，而是先构建一个能针对用户实际症状变红的反馈回路。适用于测试、命令、请求或 UI 流程失败，行为不正确但原因未明，缺陷间歇或对时序敏感，以及需要先测量再优化的性能回退。仅靠代码审查、未复现症状时不应宣称已诊断。
主要能力与流程：一、脱敏并收集上下文，先对命令、日志、截图、追踪和环境输出中的密钥脱敏，阅读项目说明、术语表、ADR、issue 与近期变更，记录确切的用户可见症状。二、构建紧凑反馈回路，优先选择最小、可无人值守、走真实路径并断言症状的命令，如失败的单测/集成/端到端测试、curl 或 HTTP 脚本、CLI 夹具对比、浏览器脚本、请求或追踪回放、最小 harness、属性或模糊测试、二分或差分回路；通过缓存准备、收窄断言、固定时间与随机性、隔离文件系统来收紧回路。若无法构建可变红的回路，应停止并报告尝试内容，索取脱敏追踪、日志、HAR、核心转储、带时间戳录屏或复现环境，而非猜测。三、复现并最小化，确认失败原因，间歇缺陷需重复或加压直到复现率可用，逐个移除输入、调用方、配置或步骤，直到移除任一剩余元素回路即通过。四、列出 3–5 个可证伪假设，每个须预测可观察结果，先给用户看排序以便补充领域证据，再逐个探测，优先调试器或 REPL，其次在边界加带唯一前缀（如 [DEBUG-1234]）的临时日志；性能问题先测基线并用 profiler 或计时工具。五、在修复前加回归测试，将最小复现转为暴露真实缺陷的最高接口测试，观察预期失败，应用最小修复，再跑测试与原始未最小化回路；若不存在正确接缝，记录架构缺口作为后续改进，不宣称强回归覆盖。六、清理与验证：原始复现不再失败、回归测试通过、临时调试代码已移除、一次性 harness 与敏感产物已删除或脱敏、根因与验证命令记入提交或 PR、更广测试与 lint/类型检查通过或报告确切阻塞。
常见陷阱：先理论后复现、修错失败、单一假设、调试日志考古、虚假回归信心、性能猜测。验证清单包括敏感输出已脱敏、已运行能对确切症状变红的命令、复现已最小化、考虑多个可证伪假设、回归测试覆盖真实行为或记录缺失接缝、运行原始回路与更广检查、移除临时日志与产物。限制：资料未提供具体平台、收费、价格或安装命令等信息。