日志多、报错杂时，最容易犯的错是把全部内容丢给 AI，期待它一次猜中根因。日志中的大部分内容只是背景，真正有价值的是错误发生前后的时间线、关联请求和状态变化。把范围缩小、把假设写清，再让 AI 协助归类，排障会更快也更可复盘。
先锁定“哪一次失败”
记录用户看到的问题、发生时间、环境、请求标识和最近变更。不要从全天日志开始读；先选故障前后几分钟，再沿着同一个请求、会话或任务编号扩展。缺少这些上下文时，AI 往往会把无关告警误判为根因。
| 阶段 | 要收集的信号 | 下一步 |
|---|---|---|
| 界定 | 时间窗口、环境、请求标识 | 排除无关日志 |
| 筛选 | 错误码、堆栈、超时、状态变化 | 形成可验证假设 |
| 验证 | 复现条件、对照请求、监控数据 | 确认或推翻假设 |
| 修复 | 改动、测试和回归结果 | 记录预防措施 |
让 AI 做归类和提问助手
向 AI 提供已脱敏的片段、时间线和系统边界，请它按“观察到的事实、可能假设、还缺哪些证据”输出。要求它不要把推测写成结论。好的提问包括：这个错误出现前有哪些状态转换？哪条日志与同一请求关联？还需要哪项指标排除某个假设？
用最小实验验证根因
每个假设都应有一条可观察的预测。例如怀疑配置未加载，就在相同环境核对配置版本并发起一次最小请求；若现象不符合预测，立即记录并放弃该假设。修复前后的代码检查，可衔接 AI 辅助修复 Bug 的验证流程，避免只修表象。
把修复记录写给下一个人
记录故障影响、时间线、已排除的可能性、根因证据、修复改动、回归范围和预防动作。下一次再遇到类似问题时，这份记录比一段笼统的“已修复”更有价值。
