调试取证与现实冲突

用于失败、退化或设计与实际不符的情况。顺序是复现 → 定量测量 → 定位 → 修改 → 证明修改有效，而不是猜一段代码反复试。

选择最短取证路径

先盘点两三种直接观测手段，例如已有失败测试、请求与错误日志、最小命令或隔离脚本，选步骤最少且能区分假设的一种。不强制新写探针，已有证据足够时复用。

• 复现固定版本、输入、配置与依赖状态，记录预期和实际结果。
• 测量对应症状的量：错误码与次数、耗时分位数、行数或资源占用，不凭“感觉快了”。
• 沿调用边界缩小范围，一次改变一个可疑条件，区分业务、配置、权限、网络和依赖能力问题。
• 观测不足时才写最小探针，例如绕过业务层直接调用测试端点。限制调用量、脱敏输出，避免真实扣款和生产写入。

探针证明的是特定环境行为，不能自动证明根因或推广到其他版本。待验假设配具体操作，例如“相同输入直接调用锁定版本 SDK，对比错误码”。

处理设计反证

原接口、时序或容量假设不成立时，更新共同记录中的决定与证据。范围内可纠正的实现继续自治；改变业务承诺、重要范围、安全或不可逆操作时，给出事实、影响与选项，请用户确认，只暂停相关操作。

不得吞掉异常、伪造响应或硬编码样例绕过验证。测试替身可隔离依赖，但需明确标注，不把替身通过称为真实集成通过。

证明修复与止损

用原复现动作和相同测量条件对照修复前后，再检查相邻路径。报错消失不能独自证明没有数据丢失或重复副作用。

同一思路两次不奏效，或连续两轮没有新证据，停止盲改，整理已证实与未证实项及来源，换观测手段或请求补充关键输入。保留必要现场，不把凭证、用户数据和完整敏感报文写进共同记录。