Claude Code Bug Prompt 项目前怎么判断范围

客户发来一个 bug，说“你用 AI 帮我修一下”。新手不要马上报价。先判断你能不能写出合格的 Claude Code bug prompt：有没有复现步骤、错误原文、运行环境、预期结果、权限边界和验收方式。如果这些信息不齐，就先做诊断，不要直接承诺修复。

这篇适合和 Claude Code Bug Prompt 检查清单、Claude Code 使用场景检查清单、/tools/proposal-generator 一起使用。

适合谁

适合准备承接小型 bug 排查、报错解释、测试环境修复和交付说明的新手。你可以用 Claude Code 辅助定位，但最终要自己确认范围和证据。

也适合客户材料不完整时做预判的人。你可以先把缺失信息列出来，再决定是否报价诊断或修复。

不适合谁

不适合客户要求你直接进入生产后台、接触真实数据、保存密钥、处理付款或独立解决安全事故的任务。这些不适合普通 bug prompt。

也不适合完全没有复现条件的需求。没有错误原文和触发路径，就只能做初步分析，不能保证修复。

具体步骤

第一步，确认 bug 是否能复现。客户需要提供页面、命令、输入、错误截图或日志。不能复现时，报价应写成诊断。

第二步，确认 prompt 是否能脱敏。客户材料里如果有密钥、邮箱、订单、后台链接、客户数据，先替换成占位符。

第三步，确认是否低权限。能在本地或测试环境处理的 bug 更适合新手；必须生产操作的任务要谨慎。

第四步，确认修改范围。prompt 里要写“先分析，不直接大范围修改”。报价也要写清只处理一个明确问题。

第五步，确认验收方式。客户如何判断修好了？页面路径、测试数据、命令输出、截图或构建结果都可以作为验收依据。

报价建议

信息不完整时，先报价诊断包。诊断包包括：整理客户问题、生成合格 prompt、判断可能原因、列出需要客户补充的信息。不要在诊断阶段承诺最终修复。

信息完整且低风险时，可以报价小范围修复。交付物包括：修改说明、测试证据、未覆盖范围和客户验收步骤。不要把长期维护、生产部署、账号权限处理默认包含进去。

风险提醒

不要让客户把完整密钥或后台截图发给你“方便 AI 分析”。越是客户觉得方便的材料，越可能包含敏感信息。先要求脱敏，必要时让客户自己操作后台。

不要因为工具能生成代码就忽略授权。客户项目的权限、平台规则和数据边界，必须由人确认。

客户确认模板

为了判断是否适合用 Claude Code 辅助排查，请先确认：
1. bug 的复现步骤是什么？
2. 错误原文或日志是什么？
3. 当前环境是本地、测试还是生产？
4. 是否可以使用测试数据？
5. 是否涉及密钥、付款、真实用户数据或管理员权限？
6. 你希望怎样验收修复结果？

客户能回答这些问题，说明任务更容易进入小范围排查。客户不能回答时，先诊断更稳。

不同结论怎么回复

如果信息完整且低风险，可以回复：“我可以先按一个小范围修复处理，并提供测试结果和交付说明。”如果信息不完整，可以回复：“我建议先做诊断，确认复现路径和可能原因后再报价修复。”如果涉及高权限，可以回复：“这超出普通小单范围，需要明确授权和更严格复核。”

这种分类能让客户看到你在做风险判断，而不是简单拒绝。对新手来说，清楚判断范围比急着开始更重要。

验收边界

修 bug 的验收应该和 prompt 里的复现步骤对应。原来按某路径会失败，修复后按同一路径应该得到预期结果。不要把“看起来没报错”当成验收，也不要把生产环境未验证的问题写成已完成。

什么时候暂不接

如果客户要求你保存密钥、直接进入生产环境、处理真实付款、查看隐私数据，或者拒绝提供复现步骤却要求保证结果，都可以暂不接。你可以说明原因：当前信息不足以安全判断，继续处理需要测试环境或更明确授权。

暂不接不是浪费机会。长期看，避开不适合的新手任务，比硬接一个高风险任务更能保护你的作品集和信誉。

免责声明

本文仅供学习和项目流程参考，不构成安全、法律、财务或平台合规建议。Claude Code 功能和客户项目规则可能变化，发布前需要人工复核。项目前请确认授权、脱敏、测试环境和交付边界。

CTA：回复客户前，先用 /tools/proposal-generator 写一版范围说明，再用 /templates 补齐复现信息和验收方式。