Claude Code Bug Prompt 常见错误

很多 Claude Code 修 bug 失败，不是工具完全没用，而是 prompt 从一开始就让它盲猜。新手常把“页面有问题”“代码报错了”“帮我修一下”扔给工具，却没有复现步骤、错误原文、预期结果和安全边界。结果工具只能大范围搜索和尝试，风险自然上升。

下面按常见错误拆解。建议搭配 Claude Code Bug Prompt 检查清单 和 Bug 修复交付说明模板 使用。

适合谁

适合已经尝试用 Claude Code 修 bug，但经常得到不稳定结果的新手。你可能发现工具有时很准，有时却改错方向。

也适合接到客户报错后，需要先整理信息再开始排查的人。客户材料越零散，越要先转成结构化 prompt。

不适合谁

不适合高风险生产问题。涉及付款、密钥、真实用户数据、管理员后台或安全漏洞时，普通 prompt 不够，需要明确授权和更严格复核。

也不适合没有任何错误信息的需求。客户只说“系统不好用”，这还不是 bug prompt，而是需求澄清。

具体步骤

错误一：没有复现步骤。修正方式是写出打开页面、点击位置、输入内容、错误出现时机。如果不能复现，先不要要求工具修复。

错误二：没有预期结果。工具需要知道原本应该发生什么。否则它只能猜哪个行为算正确。

错误三：只贴截图不贴文字。截图有帮助，但错误原文更适合检索和定位。截图里如果有敏感信息，必须先遮挡。

错误四：直接贴客户敏感资料。修正方式是脱敏：密钥用 sk-***，邮箱用 user@example.com，订单用测试编号，后台链接用占位符。

错误五：要求工具一次性大范围修改。修正方式是先让它列出可能原因和相关文件，再确认最小修改方案。

错误六：没有要求测试证据。prompt 里应该明确：修改后列出需要运行的检查，并说明未覆盖范围。

风险提醒

不要把 prompt 当成交付说明。prompt 是给工具看的，交付说明是给客户看的。交付说明要更简洁、更可验证，并且不包含敏感信息。

不要让工具替你决定客户责任。账号权限、平台规则、生产数据、付款状态等事项，需要客户自己确认或提供授权，不能由模型猜测。

修正模板

我之前的 prompt 缺少：
- 复现步骤：
- 预期结果：
- 错误原文：
- 运行环境：
- 安全边界：

修正后 prompt：
- 先分析，不直接大改。
- 只处理目标问题。
- 修改后列出检查命令。
- 不确定事项单独列出。

复盘建议

每次工具猜错，都回头看 prompt 缺了什么。是没有错误原文，还是没有环境，还是你没有限制修改范围？把原因记下来，下一次 prompt 会明显更稳。

好的 prompt 不是一次写成的。它来自多次排错记录：哪些信息真正帮助定位，哪些信息其实多余，哪些信息不能出于安全原因放进去。

最小修改原则

prompt 里最好明确“只做最小修改”。客户要修一个报错，就先修报错；客户要解释构建失败，就先解释构建失败。不要让工具顺手重构、升级依赖、改命名或调整无关样式。

最小修改能降低风险，也方便交付说明。你能清楚说出本次改了什么、为什么改、如何验证。如果工具改得太多，你很难证明每一处都必要。

失败时怎么收尾

如果 prompt 没有得到可用结果，可以把本次输出转成问题清单：缺少什么信息、下一步需要客户提供什么、是否需要测试环境。这样即使没有修复，也没有白做。

交付前检查

发送给客户前，把工具输出改成客户能读懂的话。不要保留大量模型推理，也不要贴无关日志。客户需要知道的是：问题可能在哪里、你做了什么、怎么验证、还缺什么信息。

如果没有验证，就明确写“未验证”。这个词比含糊地写“应该可以”更安全。新手项目练习时，清楚的不确定性比漂亮但不可靠的承诺更有价值。

免责声明

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

CTA：写 prompt 前先用 Claude Code Bug Prompt 检查清单 过一遍；修完后用 /templates 里的交付说明模板补齐验证结果。