用途：针对难以定位的 Bug、异常行为和不稳定测试，提供一套假设驱动的调试流程，用纪律化的循环逐步收敛到根因，替代“先猜一个原因就直接改”的做法。
主要能力：流程包含六步——先写下具体假设（明确执行路径各步的预期状态）；设计针对性埋点（只在能验证假设的 2-3 个决策点加日志或断言，优先记录返回值、载荷内容、流类型、消息体、环境状态等数据，而非仅记录代码路径是否执行）；验证数据能否被采集到（防 stderr 被丢弃、进程未刷新即被杀、日志目录不存在、输出被截断、看到的是上次运行的日志）；运行并逐行阅读真实输出，数据与假设冲突时以数据为准；在侧记文件中记录结果（引用具体日志行、确认与否定项、更新后的假设）；据此迭代，每轮缩小搜索空间。
使用方式：对预期超过一轮的 Bug，在项目惯用的笔记位置建立侧记文件作为调查日志，跨回合甚至跨会话持久保存；每次运行后更新，进入新一轮前先重读。修复前需在侧记中写明根因、证据（具体日志行）与改动理由，确认后应用修复、移除埋点并用一次干净运行验证。若三轮无进展，应回退并质疑自己的假设，考虑尚未检查的层。
适用场景：非平凡缺陷、不稳定测试、持久化状态（缓存、会话录制、消息队列、临时文件、数据库行）引发的“不可能”Bug，以及用户报告与本地复现不一致的情形——此时差异本身即证据，应先列出两环境差异（TTY 与管道、终端模拟器、shell、locale、环境变量、先前状态、构建产物），对模糊症状先问一个消歧问题。
要避免的失败模式：无证据就跳到修复；归咎外部系统（模型幻觉、API 不稳定、库有 Bug），应先检查其实际收到的输入；只查代码路径不查数据；用重新解释用户报告取代调查；跨尝试丢失上下文。
限制：资料未提供安装命令、依赖、版本信息与具体代码示例；该方法论本身不自动执行调试，需人工遵循流程。