CCClaude Code中文喂饭教程

实战：排查构建失败

Claude Code 构建失败排查教程：构建失败不要马上乱改，先判断错误类型、定位相关文件，再做最小修复和复验。

直接复制

构建失败时，最容易犯的错是只复制最后一行。真正的根因经常在日志中间或第一处 error。

/debug

构建失败了，请帮我排查。

错误信息：
【粘贴完整错误】

要求：
1. 先判断错误类型，不要立刻修改。
2. 找到最可能相关的文件。
3. 给出最小修复方案。
4. 只修复和这次构建失败直接相关的问题。
5. 修复后重新执行必要检查并解释结果。
6. 如果是历史问题，请说明，不要顺手修复。

日志应该怎么给

尽量给 CC 这些信息：

这是构建失败信息，请先只读分析。

执行动作：
【例如 npm run build / npm test / npm run lint】

失败位置：
【本地 / CI / 服务器】

最近改动：
【简单描述刚才改了什么】

完整错误：
【从第一处 error 开始粘贴】

请先分类，不要直接改。

常见错误类型

可以让 CC 先按表格分类，避免一上来乱修：

类型日志里常见信号常见修复方向
语法错误Unexpected token、missing、parse error回到对应文件修语法
类型错误Property does not exist、not assignable修类型定义、空值判断、字段名
依赖错误Cannot find module、peer dependency确认依赖和 lock 文件
路径错误Module not found、case mismatch修导入路径和文件大小写
环境错误Node version、env missing确认版本和环境变量
配置错误config、plugin、loader查构建配置，不改业务代码

看 CC 有没有跑偏

修复前让它给判断

请先不要修改。

请输出：
1. 第一处真正错误在哪里。
2. 这个错误属于哪一类。
3. 最可能相关的文件。
4. 是否和本次修改有关。
5. 最小修复方案。
6. 如果需要运行检查，需要执行哪个最小命令。

如果日志很长，可以让 CC 先抽取关键段：

这段日志比较长，请先只做日志定位。

请找出：
1. 第一处 error。
2. 最相关的文件路径。
3. 最相关的错误行。
4. 后续错误是否可能只是连锁反应。
5. 暂时不要修改文件。

批准修复时怎么说

可以按最小方案修复构建失败。

限制：
1. 只修复当前构建错误。
2. 不要升级依赖，除非先说明没有替代方案。
3. 不要格式化无关文件。
4. 不要顺手修历史问题。
5. 修复后重新执行同一个检查并解释结果。

依赖相关错误要更谨慎：

如果你认为需要改依赖，请先不要改。

请说明：
1. 是否有不改依赖的修复方式。
2. 当前 lock 文件和 package 配置是否一致。
3. 升级、降级或新增依赖分别有什么风险。
4. 为什么这是最小必要方案。
5. 在我确认前不要修改依赖文件。

如果修了一个又冒出另一个

构建错误可能是串联的。第一处修完后，第二处才会暴露。让 CC 继续按“小步分类”的方式排查。

现在出现了新的构建错误，请继续按同样方式排查。

要求：
1. 判断这是新暴露的问题，还是刚才修复引入的问题。
2. 不要扩大到无关重构。
3. 继续只做最小修复。
4. 每修一次都重新运行同一个检查。

构建修复的完成标准

检查项标准
原命令同一个构建或检查命令通过
相关性修复文件和错误日志能对应上
范围没有升级依赖、格式化全项目或重构无关代码
解释能说明第一处错误和修复原因
遗留新错误、历史错误或环境限制讲清楚

最后可以追问：

请总结构建失败修复结果：
1. 第一处真正错误是什么。
2. 本次改了什么。
3. 原检查是否通过。
4. 是否还有历史问题或未验证项。
5. 是否可以继续提交前检查。

验收结果

下一篇：截图反馈修 UI