拿到 bug 报告后的第一个动作
翻最近三次调试记录。你拿到 bug 报告后第一件事是什么？
如果是打开编辑器开始看代码——规则还没进来。排障的起手是先确认症状、确认复现、确认自己对系统的理解。键盘上的第一个动作应该是写下问题描述，不是开始改代码。
你还在同时改多个东西吗
回想上一次调试。你有没有"顺手"一起改了两处以上？
一次改一个变量不是效率低——是保护因果关系的底线。如果你发现自己仍然忍不住一次改多处，这条规则还停在"知道"层面，没有变成本能。
调试记录能还原当时的过程吗
随便打开最近一次的调试记录——如果有的话。能不能看出当时试了什么、每步观察到什么、结论基于哪条证据？
如果记录只有最终结果没有过程，"保留审计轨迹"还是摆设。记录的标准不是写了没有，是一周后你自己能不能看懂。
最近三个月被"最蠢的原因"坑过几次
最近有没有调了半天，最后发现是配置文件错了、环境变量没设、服务没重启这类原因？
如果有——你在排障起手阶段是不是跳过了"检查插头"？如果已经没有了——要么你养成了先排除简单原因的习惯，要么你还没意识到自己跳过了这步。
卡住的时候你怎么办
调试卡住超过半小时。你的下一步是什么？
继续死磕同一个方向——"换个视角"这条规则还没启动。去找个人讲一遍问题，或者站起来走一圈——这才是规则生效的信号。不一定需要对方给答案，你在讲的过程中经常自己就找到了盲点。
修好了，还是看起来好了
改了代码，测试过了，部署上线。你做了哪些验证？
如果只是"跑了一遍没报错"，Agans 的最后一条规则还没到位。到位的标准：你能说清根因、能解释为什么修复有效、能回答"同类问题还会不会出现"。修好和"看起来好了"之间的差距，就是这条规则守住的距离。