Claude Code 项目前客户问题不清楚时怎么判断范围

客户问题不清楚时，新手不要马上让 Claude Code 开始改。项目前要先判断：信息是否足够、任务是否低风险、是否适合诊断、是否能写出验收方式。很多时候，客户需要的第一步不是修复，而是把问题讲清楚。

这篇适合和 Claude Code 项目客户问题检查清单、Claude Code Bug Prompt 检查清单、/tools/proposal-generator 一起使用。

适合谁

适合收到模糊代码需求的新手。比如客户只说“页面坏了”“部署失败”“AI 工具不能用”，但没有提供错误和复现路径。

也适合准备把报价拆成诊断和修复两段的人。信息不足时，先诊断比直接承诺修复更稳。

不适合谁

不适合客户要求你在没有授权的情况下进入后台、处理生产数据、保存密钥或修改付款设置的情况。这些不是普通小单范围。

也不适合客户拒绝提供必要信息却要求固定结果的任务。没有基本信息，无法可靠判断范围。

具体步骤

第一步，判断是否能复现。能复现，才有进入修复的基础；不能复现，先做诊断和信息收集。

第二步，判断是否低权限。只需要公开页面、测试环境、脱敏日志的任务更适合新手；需要管理员权限的任务要谨慎。

第三步，判断是否小范围。一个页面、一个报错、一段配置、一份文档可以继续；整套系统、长期维护、全部性能优化不适合直接接。

第四步，判断是否可测试。修完后能否用命令、截图、预览链接或测试数据验证？没有验证方式，就不要写“修复完成”。

第五步，判断是否适合先诊断。信息不足但风险不高，可以先交付一份诊断报告，列出可能原因和下一步材料。

报价写法

信息不足时，可以写：“我建议先做一轮诊断，确认复现路径、错误原因和风险范围。诊断交付包括问题记录、可能原因、需要补充的材料和是否适合继续修复。”

信息完整时，可以写：“我可以处理一个明确问题，交付修改说明、测试结果和未覆盖范围。”不要把生产部署、账号权限处理、长期维护和新增功能默认包含进去。

客户回复模板

目前信息还不足以确认完整修复范围。我可以先做诊断，确认：
1. 问题是否可复现；
2. 可能相关文件或配置；
3. 是否需要权限或测试环境；
4. 后续是否适合小范围修复。

这类回复能把模糊需求转成可执行的下一步。

诊断交付怎么写

诊断单不要写成“我试试看”。更稳的写法是列出交付物：一份问题记录、一组可能原因、需要客户补充的材料、是否建议继续修复。这样客户知道自己买到的是判断和方向，不会误解成完整修复。

诊断完成后，如果问题适合继续做，再单独报价修复。修复报价里写清楚本次只处理哪个现象，是否包含测试，是否包含部署，是否包含后续微调。把两个阶段分开，能减少未知代码库带来的风险。

暂不承接的表达

遇到权限、数据或生产影响过高的任务，可以温和但明确地说：“这个范围需要更正式的授权和复核，我不适合直接独立处理。”如果客户能提供测试环境、脱敏日志和明确验收方式，再重新判断是否能做诊断。

不要为了维持对话而含糊答应。模糊答应会让客户以为你已经承担结果，后面任何异常都可能变成你的责任。把边界说清楚，反而更像一个可靠的自由职业者。

风险提醒

不要让 Claude Code 替你判断客户授权。工具能读代码，但不能知道客户是否允许你访问某些数据或后台。授权和风险边界必须由人确认。

不要因为客户急就跳过范围判断。越急的任务，越需要把责任边界写清楚。

免责声明

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

CTA：客户问题不清楚时，先用 /tools/proposal-generator 起草诊断回复，再用 /templates 补齐需求确认表。