Claude Code 自动修 Bug 教程：从报错日志到代码修改全流程

Claude Code 可以读取项目、分析报错、修改文件并运行测试，因此很适合辅助修 Bug。但”自动修 Bug”不是把日志一贴就等结果，而是把排查流程结构化：先收集足够信息，再让 Claude Code 定位根因，确认修改计划后生成最小 diff，最后通过测试和人工审查验证。

本文会用从报错日志到代码修改的完整链路，讲清 Claude Code 修 Bug 的正确用法。还没完成安装配置的读者，可以先看本站 安装部署教程 和 环境配置教程；如果你已经能运行 Claude Code，可以把本文作为日常 问题排查教程 和 实战工作流 的模板。

摘要

Claude Code 自动修 Bug 的推荐流程是：先保存报错日志、错误栈、复现步骤、当前分支、依赖版本和期望结果；在项目根目录启动 Claude Code，要求它先只读分析，不要立即改文件；把日志和复现路径交给它，让它搜索相关代码并输出根因假设；确认它找对调用链后，再要求它给最小修改计划；修改前检查权限请求，避免删除文件、改配置或引入无关依赖；修改完成后查看 git diff，运行单元测试、lint、构建或手动复现；最后让 Claude Code 总结根因、改动文件、验证方式和剩余风险。整个流程可以自动化一部分，但最终审查必须由开发者完成。

正文

自动修 Bug 前先明确边界

Claude Code 能执行真实代码修改，也能运行命令。正因为它能力强，使用时更要明确边界：本次只修哪个 Bug，允许改哪些目录，不能改哪些文件，是否允许新增依赖，是否可以运行测试命令。没有边界的修复，很容易变成大范围改动。

建议每次任务开头都加一句：”先只读分析，不要修改文件”。等它输出定位计划后，再决定是否允许编辑。

第一步：收集报错日志

日志越完整，Claude Code 越容易定位根因。至少准备四类信息：错误栈、复现步骤、实际结果、期望结果。如果问题和环境有关，还要补充分支、运行命令、依赖版本、浏览器或系统版本。

日志示例可以这样整理：

问题：点击保存按钮后页面报错，数据没有提交。
复现步骤：
1. 打开 /settings/profile
2. 修改昵称
3. 点击保存
实际结果：页面弹出 TypeError，接口没有发送成功。
期望结果：保存成功并显示 toast。
报错日志：
TypeError: Cannot read properties of undefined (reading 'id')
    at buildProfilePayload (src/features/profile/utils.ts:42)
    at handleSave (src/features/profile/ProfileForm.tsx:88)
当前分支：feature/profile-edit
最近改动：昨天调整过 user 对象结构。

第二步：在项目根目录启动 Claude Code

进入项目根目录启动 Claude Code，让它能读取完整代码结构。启动前建议先看 git 状态，避免 AI 修改和你已有未提交改动混在一起。

cd your-project
git status
claude

如果只是想让 Claude Code 对日志做一次非交互分析，官方 CLI 也支持 print 模式和管道输入，例如把日志文件通过命令传给 Claude Code 分析。但实际修复代码时，交互模式更适合逐步确认计划和权限。

cat error.log | claude -p "请分析这个报错可能来自哪里，先不要修改文件"

第三步：让它先只读定位

把日志交给 Claude Code 后，不要马上让它改。先让它搜索相关文件、解释调用链、列出根因假设和验证方式。

请先只读分析这个 Bug，不要修改文件。
请根据报错日志：
1. 找到相关文件和调用链
2. 说明最可能的根因
3. 列出还需要确认的信息
4. 给出最小修改计划
5. 给出建议运行的验证命令

如果它没有找对文件，可以补充关键词、组件名、接口名或错误行号。不要在错误定位基础上继续改代码。

第四步：要求它解释调用链

Bug 修复的关键是调用链。你需要知道错误从哪里触发、数据在哪里变形、哪个函数没有处理边界情况。可以要求 Claude Code 按入口、处理函数、数据转换、接口调用、错误处理的顺序解释。

请按调用链解释这个 Bug：
- 用户操作入口在哪里
- 哪个函数首先接收数据
- 数据在哪一步变成 undefined
- 哪个文件应该负责兜底
- 为什么这个修改是最小范围

第五步：确认修改计划和权限

Claude Code 可能会请求读取文件、编辑文件或运行命令的权限。Anthropic 官方安全说明强调，涉及编辑文件、执行测试或运行命令时需要权限确认。你应该看清它准备做什么，尤其是写文件、安装依赖、删除文件、修改配置、运行脚本这类操作。

确认修改计划时重点看四点：是否只改相关文件，是否保留原接口，是否避免无关重构，是否有验证命令。如果计划太大，可以要求缩小范围。

请缩小修改范围：
- 只修复当前 Bug
- 不要引入新依赖
- 不要重构组件结构
- 不要修改接口字段
- 修改后运行相关测试

第六步：让 Claude Code 生成最小修改

确认计划后，再允许它编辑文件。这里的关键词是”最小修改”。最小修改并不是临时补丁，而是只改解决问题所必需的代码，避免把 Bug 修复和重构、样式调整、依赖升级混在一起。

可以按刚才计划修改文件。
要求：
1. 只做最小必要修改
2. 保留现有接口和调用方式
3. 修改后解释每个 diff 的原因
4. 运行相关测试或说明无法运行的原因

第七步：检查 git diff

修改完成后，第一件事不是看 AI 总结，而是看实际 diff。

git diff

重点检查：是否改了无关文件，是否删除了原有校验，是否把异常吞掉，是否引入硬编码，是否改变公共函数行为，是否影响其他模块。对看不懂的 diff，要求 Claude Code 逐行解释。

第八步：运行测试和复现检查

修 Bug 必须验证。可以运行单元测试、lint、构建命令，也要按原来的复现步骤手动检查一次。自动测试通过但手动复现失败，说明问题仍然没有解决。

npm test
npm run lint
npm run build

第九步：失败时让它继续基于当前上下文修正

如果测试失败，不要立刻重开会话。把失败日志继续贴给 Claude Code，让它基于当前上下文修正。

测试失败了，下面是新的日志。
请先解释失败原因，不要马上扩大修改范围。
如果需要继续改，请说明要改哪些文件，以及为什么。

官方 CLI 支持继续最近会话，例如 claude -c 或 –continue。对于同一个 Bug，保留会话上下文通常比重新开始更稳定。

第十步：让 Claude Code 输出修复总结

验证通过后，让 Claude Code 输出一份修复总结，便于提交代码和后续复盘。

请总结这次 Bug 修复：
1. 根因是什么
2. 改了哪些文件
3. 每个文件改动的目的
4. 已运行哪些验证命令
5. 原复现步骤是否通过
6. 是否还有剩余风险
7. 建议的 commit message

完整提示词模板

下面是一段可以直接复制的自动修 Bug 模板：

请帮我修复一个 Bug，但先只读分析，不要修改文件。

Bug 现象：
【写清楚实际问题】

复现步骤：
1. 【步骤一】
2. 【步骤二】
3. 【步骤三】

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

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

报错日志：
【粘贴错误栈、终端输出、测试失败信息】

限制：
- 只修复当前 Bug
- 不要引入新依赖
- 不要重构无关代码
- 不要修改接口字段

请先输出：
1. 相关文件和调用链
2. 最可能根因
3. 最小修改计划
4. 需要我确认的权限
5. 验证命令
等我确认后再修改。

什么时候不要让它自动修

如果 Bug 涉及生产数据库、支付、权限绕过、删除数据、密钥泄露、线上事故或合规风险，不建议直接让 Claude Code 自动修改。可以让它只读分析、列排查清单、解释日志，但最终修复方案需要人工主导。更多高风险问题处理方式，可以阅读本站 问题排查教程。

FAQ

Claude Code 可以完全自动修 Bug 吗？

它可以自动分析、修改和运行测试，但不建议完全无人审查。开发者必须确认权限、检查 diff、运行测试并复现问题是否消失。

只贴一段报错日志够不够？

通常不够。最好同时提供复现步骤、期望结果、实际结果、相关页面或命令、最近改动和环境信息。日志只是定位入口，不是完整上下文。

Claude Code 修复后测试失败怎么办？

把新的失败日志继续交给它，让它解释失败原因并缩小修改范围。不要直接要求大范围重构，也不要忽略失败测试。

自动修 Bug 时可以允许它运行命令吗？

可以，但要看命令内容。运行测试、lint、构建通常比较合理；删除文件、安装依赖、修改配置、执行未知脚本要谨慎确认。

怎么避免 Claude Code 改太多文件？

在提示词里明确写：只做最小必要修改、不要引入新依赖、不要重构无关代码、修改范围外文件必须先说明原因并等待确认。