告别瞎猜式修 bug
告别瞎猜式修 bug
superpowers 核心技能 · systematic-debugging
一句话: 修 bug 别"我觉得是 X 改改试试". 先查清根因再动手 —— 系统化比瞎试快得多(15-30 分钟 vs 2-3 小时).
场景: 用户付了钱, 订单却没更新
线上偶发问题: 用户支付成功, 但订单状态还停在"待支付", 客服天天接投诉. 不是每次都复现, 你盯着代码看半天没头绪. 这种"偶发 + 多环节(支付 -> 回调 -> 订单服务 -> 数据库)"的 bug, 最忌讳上来就猜着改.
怎么对 AI 说
让它先查根因, 别让它瞎改:
用 systematic-debugging 排查这个偶发 bug: 用户支付成功但订单状态没更新.
先别改代码 —— 读日志, 想办法稳定复现, 在 支付/回调/订单服务 每层边界打日志,
定位断在哪一层, 再给我修法.
| ❌ 差的说法 | ✅ 好的说法 |
|---|---|
| 估计是回调没收到, 你加个重试 | 先定位到底断在哪层, 再决定修哪 |
| 多改几处试试哪个管用 | 一次只动一处, 说清你的假设 |
| (改第 3 次还偶发)再试 | 修 3 次还偶发, 是不是架构有问题(比如没做幂等) |
把"现场证据"喂给它: 报错日志, 一笔出问题订单的完整链路记录, 比"它有时候不更新"有用一百倍.
它会怎么跟你走
它先读日志, 想办法稳定复现(偶发的就去找触发条件: 并发下单? 回调超时?). 在 支付回调 -> 订单服务 -> 数据库 每个边界打日志, 跑一次看数据断在哪 —— 比如发现"回调到了, 但订单更新时被另一个请求覆盖了"(并发写问题). 找到根因后先写一个能复现的失败测试, 再一次只改一处(比如加乐观锁), 跑测试确认修好且没影响别的.
一句话记住
systematic-debugging = 让 AI 先查清根因再动手. 偶发/多环节的 bug 尤其别让它猜着改: 让它打日志锁定哪层坏的, 修 3 次不好就质疑架构.