让 CC 分析复杂报错日志

进阶实战教程：面对多段日志、多服务、CI 和线上混合错误时，让 Claude Code 先拆分事件链、识别第一处真实错误和连锁反应。

普通日志排查看一段错误就够了。

复杂报错日志不一样。它可能包含多服务、多时间点、多次重试、CI 输出、前端错误、后端异常、数据库错误混在一起。

和让 Claude Code 根据日志排查问题相比，这里处理的是复杂日志。重点不是急着定位单点，而是先拆事件链。

复杂日志的典型表现

请分析这组复杂日志，但不要直接给修复方案。

请先拆分：
1. 日志来源：前端、后端、数据库、CI、外部服务。
2. 时间顺序。
3. 第一处真实错误。
4. 后续哪些错误可能是连锁反应。
5. 哪些信息缺失。
6. 哪些结论不能确定。

日志如下：
【粘贴脱敏后的多段日志】

关键是找“第一处真实错误”，不是被最后一行带跑。

请把日志整理成事件链。

格式：
时间点
发生了什么
证据日志
可能原因
是否为根因候选

复杂日志不要直接猜根因，要先还原事件。

复杂日志经常来自不同系统，格式不统一。分析前先让 CC 统一口径：

提示词：

请先统一这批日志的分析口径。

输出：
1. 每段日志的来源。
2. 时间格式和时区是否一致。
3. 是否能通过 request id / trace id 串联。
4. 哪些日志只是重试或连锁失败。
5. 当前不能确定的地方。

口径不统一时，后面的根因判断很容易错。

请把这些错误分成三类：

1. 根因候选：可能真正导致问题。
2. 连锁错误：由前面错误引发。
3. 噪音或无关警告：暂时不影响本次问题。

每项都说明依据。

这一步能减少误修。

请为前三个根因候选设计最小验证动作。

要求：
1. 每个验证动作成本尽量低。
2. 不修改生产数据。
3. 不执行高风险命令。
4. 能确认或排除一个假设。
5. 说明验证结果如何解读。

复杂日志不要一次改多个点。先验证假设。

复杂日志里最后一个错误经常只是结果，不是原因。

比如：

可以明确限制：

不要只根据最后一行错误给修复方案。
请找出日志中最早出现的异常信号，并说明它和最终错误之间的关系。

这个限制非常重要，能少走很多弯路。

如果日志不足，不要让 CC 硬猜。让它列缺口：

补信息提示词：

当前日志不足以确定根因时，请只列还需要补充的信息。

要求：
1. 按优先级排序。
2. 说明每项信息能验证哪个假设。
3. 不要编造根因。
4. 不要直接建议改代码。

让 CC 对齐：

提示词：

请根据 request id / trace id / 时间戳，对齐这些多服务日志，找出同一次请求的完整链路。

请把复杂日志分析整理成排查报告。

结构：
1. 问题概述。
2. 日志来源。
3. 事件链。
4. 根因候选。
5. 连锁错误。
6. 缺失信息。
7. 最小验证动作。
8. 暂不建议做的修改。

学完后，应该能做到：