CCClaude Code中文喂饭教程

让 Claude Code 根据日志排查问题

Claude Code 日志排查教程：教你如何把报错、日志、复现步骤和环境信息整理给 CC，让它先分类、定位、验证假设，而不是直接猜修复。

日志排查不是把一段报错丢给 Claude Code，然后问“怎么修”。

如果缺少上下文，CC 只能猜。猜对了是运气，猜错了就可能把简单问题改成复杂问题。

正确做法是：把日志、复现步骤、环境信息和最近改动一起给它，让它先分类，再定位。

需要准备哪些信息

排查前尽量准备：

信息为什么重要
完整错误日志避免只看最后一行，漏掉真正原因。
复现步骤判断问题是否稳定复现。
发生环境本地、测试、生产、CI 的原因可能不同。
最近改动很多问题和最近一次提交有关。
期望行为明确修复后应该是什么结果。
已尝试操作避免重复做无效尝试。

不要只截一小段错误。很多报错真正关键的信息在前面。

第一步：让 CC 先分类

提示词：

请根据下面的日志先做问题分类，不要修改文件。

环境：
【本地 / 测试 / 生产 / CI】

复现步骤：
1. 【步骤一】
2. 【步骤二】
3. 【错误现象】

日志：
【粘贴完整错误日志】

最近改动：
【如果知道，写最近改了什么；不知道就写不确定】

要求：
1. 先判断这是依赖、配置、代码、数据、权限、网络还是构建问题。
2. 找出日志里最关键的 3 行。
3. 给出最可能原因和备选原因。
4. 说明需要继续查看哪些文件。
5. 不要直接修改。

这一步能让 CC 从“猜修复”变成“先诊断”。

第二步：让 CC 只读定位相关文件

分类后，再让它看文件：

请根据刚才的问题分类，只读定位相关文件。

要求：
1. 找到最可能相关的入口、配置、调用链或异常处理位置。
2. 说明每个文件为什么相关。
3. 不要修改文件。
4. 如果信息不足，请列出还需要我提供什么。

如果 CC 还没看懂，不要急着让它改。先补信息。

第三步：验证假设

让 CC 列假设：

请基于日志和相关文件，列出排查假设。

格式：
1. 假设是什么。
2. 支持这个假设的证据。
3. 反驳这个假设的可能证据。
4. 如何用最小动作验证。
5. 如果成立，最小修复方案是什么。

这个动作很重要。它会让排查更像工程诊断，而不是试错。

第四步：最小修复

确认假设后再改：

按已确认的最可能原因做最小修复。

要求：
1. 只修改和该问题直接相关的文件。
2. 不要顺手重构。
3. 不要吞掉异常或简单注释掉错误。
4. 修改后解释为什么能修复日志中的错误。
5. 给出复现路径和验证方式。

日志排查里最危险的修法，是把错误提示藏起来。错误消失不等于问题解决。

常见日志类型

构建日志

重点看：

提示词：

请分析这段构建失败日志。

重点判断：
1. 第一处真实错误在哪里。
2. 后续错误是否是连锁反应。
3. 是否和依赖版本、路径大小写、环境变量有关。
4. 最小修复方案是什么。

运行时日志

重点看：

提示词：

请分析这段运行时错误日志。

重点判断：
1. 错误发生在哪个调用链。
2. 输入数据是否符合预期。
3. 是否缺少空值、异常或权限处理。
4. 修复后要验证哪些正常和异常路径。

线上日志

线上日志要更谨慎。

不要让 CC 直接大改，先让它做风险评估：

这是线上日志，请只做分析和风险评估，不要直接给大改方案。

要求：
1. 判断影响范围。
2. 判断是否需要先止血。
3. 给出临时规避方案和长期修复方案。
4. 标出需要人工确认的数据和权限信息。
5. 不要建议删除数据或重启关键服务，除非说明风险。

给日志时要避免什么

不要把这些内容直接发给 CC：

可以先脱敏：

我会把敏感信息替换为 [TOKEN]、[USER_ID]、[DB_URL]，请基于脱敏日志分析。

完整排查模板

/debug

请根据日志帮我排查问题，但先不要修改文件。

环境：
【本地 / 测试 / 生产 / CI】

复现步骤：
1.
2.
3.

期望结果：
【应该发生什么】

实际结果：
【现在发生什么】

日志：
【完整日志，敏感信息已脱敏】

最近改动：
【最近改了什么，不确定就写不确定】

要求：
1. 先分类问题。
2. 找出关键日志行。
3. 列出最可能原因和备选原因。
4. 只读定位相关文件。
5. 给出验证假设的最小动作。
6. 等我确认后再修改。

验收结果

学完后，应该能做到：

上一篇：Bug 排查通用流程下一篇：CI 失败排查