用 Claude Code 项目前要问客户哪些问题

Claude Code 能帮新手更快读代码、定位文件和整理修改方案，但它不能替你问清客户需求。很多小单出问题，不是因为工具不够强，而是项目前没有问清复现路径、运行环境、权限边界和验收标准。客户说“帮我修一下”，这还不是可交付任务。

适合谁

适合准备用 Claude Code 辅助处理 bug、页面小改、配置文档、代码阅读和测试环境问题的新手。你不一定能马上修复，但要能先把客户需求问成可判断、可复现、可验收的任务。

也适合已经收到客户消息但不确定能不能接的人。先问问题不是拖延，而是在保护报价、交付和双方预期。信息越清楚，Claude Code 后面能发挥的作用越大。

不适合客户拒绝提供复现信息，却要求你承诺结果的任务。没有路径、错误、环境和验收标准，Claude Code 只能猜。

也不适合涉及客户密钥、生产数据、付款后台、管理员权限和隐私材料的高风险任务。遇到这些内容，要先确认授权和最小权限，不要直接让工具处理。

第一，问复现步骤：问题在哪个页面、哪个命令、哪个按钮或哪段流程出现？客户能不能稳定复现？如果不能复现，先做诊断。

第二，问错误原文：终端日志、浏览器控制台、接口响应、构建失败信息。要求客户先脱敏，不要发送完整密钥、后台链接或真实客户数据。

第三，问运行环境：本地、测试、预览还是生产；使用什么框架、部署平台、最近是否改过依赖或配置。

第四，问预期结果：客户希望修完后看到什么？页面跳转、接口返回、构建通过、文案显示还是某个流程完成。

第五，问权限边界：是否需要账号、密钥、数据库、付款后台或管理员权限。如果需要，优先让客户自己操作或提供测试环境。

第六，问验收方式：客户如何确认完成？截图、命令输出、预览链接、测试数据、交付说明都可以成为验收依据。

为了判断是否适合我处理，请先确认：
1. 问题的复现步骤是什么？
2. 错误原文或截图是什么？请先脱敏。
3. 当前环境是本地、测试、预览还是生产？
4. 最近是否有代码、依赖、部署或配置变更？
5. 是否涉及密钥、付款、真实数据或管理员权限？
6. 你希望最终怎样验收结果？

客户把信息补齐后，不要只存在聊天窗口里。建议整理成四行项目笔记：问题现象、已知环境、待确认风险、下一步动作。这样再把上下文交给 Claude Code 时，工具看到的是经过筛选的任务描述，而不是一长串聊天记录。

如果客户提供了截图或日志，先标注来源和时间。例如“2026-06-03，客户预览环境，点击保存后控制台报错”。这类记录能帮助你区分历史问题和当前问题，也方便后续交付时说明自己实际处理了哪一段。

还要单独写“本次不处理什么”。比如不处理正式数据库、不处理账号权限、不处理新增功能、不承诺长期维护。很多返工不是因为你没修，而是因为客户默认你会顺手处理旁边的问题。提前写清楚，后面会轻很多。

信息不足但客户愿意配合时，优先把任务拆成诊断单。诊断交付可以包括：复现记录、可能原因、需要补充的材料、是否适合继续修复。这样你仍然在交付价值，但没有把未知风险全部接到自己身上。

如果客户无法提供复现步骤，只能提供“感觉不对”“偶尔坏了”这类描述，也适合先诊断。Claude Code 可以帮助你阅读代码和列假设，但不能替客户证明问题一定存在。先诊断，是对双方时间负责。

不要让客户把完整敏感信息直接发给你。能用脱敏日志说明的，就不要看后台；能用测试数据复现的，就不要碰真实数据。

不要把“客户说很简单”当成事实。技术任务简单不简单，要看复现、权限、范围和验收，不看客户的主观判断。

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

CTA：回复客户前，先用 /tools/proposal-generator 起草问题清单，再去 /templates 补齐需求确认表；信息不足时先诊断，不直接承诺修复。