线上出问题了，怎么按流程定位原因
故障处理中最耗时间的往往不是修，而是不知道自己在看什么。先把现场固定下来，再动手改代码。
怎么做
把日志收成一条时间线
把故障时间段的日志、涉及的服务和时间范围一起给「从日志里读出故障现场」。要求它先按时间排事件链、标出第一个异常点，再把「日志直接证明的」和「推测的」分两栏，并列出还缺哪条日志才能定论。不要从第一条 ERROR 讲起。
按可能性列原因，逐条验证
按第 1 步的时间线和还缺的日志，把技术栈版本、完整堆栈和已经试过的方法交给「报错定位」。它会按可能性从高到低列原因，每条给一条命令或一段最小复现代码。已经试过的让它跳过，信息不够时它会直接说缺什么，这比继续猜有用。
写一个修复前必定失败的最小用例
把 bug 现象和相关代码给「给 bug 写最小验证用例」。只保留触发所必需的输入和状态，断言写到期望值和实际值；确认它在修复前失败、修复后通过。如果复现不了，让它列出还缺的环境条件，不要接受编造的复现步骤。
修之前先看会波及哪里
修复方案定下来后，把 diff 和依赖关系给「估算一次改动的风险面」。它会列出受影响的调用方、数据和定时任务，按影响人数和恢复难度排前三，并给回退指标。一行修复也可能改变下游的假设，这一步不能省。
把事故写成能验收的复盘
最后把时间线和处置记录交给「把事故写成站得住的复盘」。时间线只保留改变系统状态或决策的节点并统一时区；根因写到哪个机制缺失；改进项分已做和待做，每条写清负责角色、截止时间和验证方式，再单列这次运气好的地方。
用到的提示词
常见问题
线上报错，先重启还是先查日志
先保住现场。把故障时段的日志、监控指标和最近的发布记录存下来，再决定要不要重启。重启会清掉内存状态和临时日志，之后很多问题就只能靠猜。
AI 能直接告诉我 bug 在哪吗
它给的是按可能性排序的假设和验证方法，不是结论。要按第 2 步逐条验证，再用第 3 步的最小用例确认；没有复现之前不要改代码，否则你只是把故障挪了个位置。
事故修好了，复盘可以不写吗
修好只解决了这一次。复盘的价值是把「哪条假设不成立、哪个机制缺失」变成有负责人和验证方式的待做项。只写「加强监控」「提高意识」的复盘，等于没有复盘。