Claude Code Bug Prompt 检查清单

写 bug prompt 前先检查信息是否完整。Claude Code 不是靠一句“帮我修”就能稳定工作，它需要复现步骤、错误原文、环境、预期结果和安全边界。清单的作用，是让你在工具动手前把问题变成可验证任务。

建议先读 Claude Code 修 bug 的 prompt 怎么写，再配合 Claude Code 自动化人工审核清单 和 /templates 使用。

适合谁

适合正在整理 bug 信息、准备让 Claude Code 分析或修改的新手。你可能有一段报错、一张截图或客户描述，但还没形成可执行的排查任务。

也适合项目前确认客户材料是否足够的人。客户说“坏了”，不等于你可以开始修；你要先把缺失信息问清楚。

不适合谁

不适合需要完整客户权限才能判断的问题。涉及密钥、生产数据、付款、管理员后台、安全漏洞时，不要只靠普通 prompt 处理。

也不适合把客户原始资料整包复制给工具。需要什么给什么，不需要的敏感信息先删掉。

具体步骤

1. 是否有复现步骤？至少写清打开哪里、点击什么、输入什么、看到什么。
2. 是否有错误原文？终端、浏览器控制台、接口响应、构建日志都可以，但要脱敏。
3. 是否写清环境？本地、测试、预览、生产，以及框架、Node 版本、部署平台。
4. 是否写清预期结果？工具需要知道原本应该发生什么。
5. 是否写清实际结果？实际错误、页面状态、返回值要具体。
6. 是否说明最近改动？新依赖、新配置、新部署、新提交都可能相关。
7. 是否限制修改范围？要求先分析，再做最小改动。
8. 是否要求列出验证命令？例如 lint、build、测试、页面手测。
9. 是否删除敏感信息？密钥、邮箱、订单、客户数据、后台链接要替换。
10. 是否准备交付说明？修完后要能写清修改、测试和未覆盖范围。

Prompt 模板

请根据下面 bug 信息先分析，不要直接大范围修改。

复现步骤：
错误原文：
运行环境：
预期结果：
实际结果：
最近改动：
已尝试操作：

请输出：
1. 可能原因。
2. 相关文件。
3. 最小修改方案。
4. 需要运行的检查。
5. 不确定或需要客户确认的事项。

风险提醒

不要在 prompt 中放完整密钥、客户订单、后台截图或私有链接。排错常常只需要错误码、路径和脱敏上下文。输入越干净，后续交付越安全。

不要让工具一次性做完分析、修改、重构和交付。新手更适合分步：先分析，再确认方案，再小改，再检查，再写说明。

验收记录

prompt 只是第一步。修完后记录：工具分析是否正确、实际修改了什么、运行了什么检查、客户还要确认什么。这个记录能变成你的交付说明，也能帮助下次改进 prompt。

如果工具没有定位到问题，也要记录失败原因。失败记录能告诉你缺少的是日志、环境、复现步骤还是项目权限。

客户确认问题

如果客户只给出一句“功能坏了”，可以先问：在哪个页面坏了，之前是否正常，最近是否部署过，是否有截图或日志，是否能用测试账号复现。不要急着让工具猜。

如果客户不愿提供信息，可以把任务定义成诊断，而不是修复。诊断交付包括已知信息、缺失信息、可能方向和下一步材料。这比无证据承诺更专业。

发送前自问

prompt 里有没有任何客户敏感信息？是否要求工具先分析再修改？是否限制了修改范围？是否要求输出检查命令？如果这些问题没有答案，先补 prompt，不要开始执行。

复盘问题

每次排查结束后，回看这次 prompt 哪一项最有用。是错误原文帮助定位，还是复现步骤帮助缩小范围，还是最近改动说明了原因？把有效信息记下来，下次优先收集。

也要记录缺失项。如果工具一直猜错，通常说明缺少环境、日志或预期结果。把这些缺口写进客户问题清单，会让下一次沟通更快。

免责声明

本文仅供学习和排错流程参考，不构成安全、法律、财务或平台合规建议。Claude Code 功能和项目规则可能变化，发布前需要人工复核。处理客户材料时，请遵守授权、脱敏和最小权限原则。

CTA：把这份清单复制到 bug 排查笔记里；需要解释错误时用 /tools/error-explainer，需要交付模板时去 /templates。