诊断硬bug

硬 bug 为什么难查

第一眼看不出原因、偶发抖动、在两个已知的好状态之间悄悄回归——这类 bug 的共同点是：没有任何东西"看起来明显坏了"。你会本能地开始猜：时区？竞态？缓存？但猜测没有反馈，只能靠反复手动复现，等它再出现的时候早已没了现场。

核心纪律：先建反馈环

这个技能把调试的第一原则定为：在拥有一条能变红、秒级、可无人值守跑的命令之前，不臆测原因。这条命令就是紧致反馈环，构建顺序是从便宜到昂贵的接缝：

• 在触及 bug 的接缝上写失败测试（单元 / 集成 / e2e）
• 对开发服务发 HTTP 请求脚本、带固定输入的 CLI 调用并 diff 输出
• 无头浏览器断言 DOM / console / 网络，或回放抓到的 trace
• 属性 / fuzz 循环、git bisect run 二分、旧版与新版差异循环
• 最后手段：结构化脚本驱动人工点击

有了环就收紧信号；非确定 bug 的目标是提高复现率而不是干净复现。建不出环，就停止并如实列出尝试与所需资源。

六阶段流程

1. 建反馈环——本 skill 的灵魂，未满足不进下一阶段
2. 复现 + 最小化——一次砍一个输入 / 调用方 / 配置 / 数据，直到移掉任一元素环就转绿
3. 假设——生成 3~5 个可证伪的排序假设（"若 X 是原因，则改 Y 会让 bug 消失 / 更糟"），先给用户看再测
4. 插桩——每个探针映射一个预测，一次只改一个变量，日志带唯一前缀（如 [DEBUG-a4f2]），结束一处 grep 清理
5. 修复 + 回归测试——写回归测试在修复之前，修完重跑阶段 1 的环确认转绿
6. 清理 + 复盘——确认原复现不再现、删掉全部 [DEBUG-] 与 throwaway 沙箱，提交信息里写明被验证的假设；再问"什么能预防此 bug"，架构级问题移交 improve-codebase-architecture

适用边界

• 反馈环建不起来时，停止并如实说明，不臆测
• 不负责"顺手改一堆"——只锁住本 bug
• 没有正确测试接缝本身就是发现，记入诊断工件而非强行造测试