Claude Code 项目客户问题检查清单

接 Claude Code 相关小单前，先用清单确认客户信息是否足够。工具可以帮你分析代码，但不能替你补全缺失需求。没有复现、没有环境、没有权限边界、没有验收标准，就不要急着报价完整修复。

建议先读 用 Claude Code 项目前要问客户哪些问题，再搭配 Claude Code Bug Prompt 检查清单 和 /templates 使用。

适合谁

适合准备接 bug 排查、页面小改、配置文档、代码阅读、部署问题诊断的新手。你需要把客户一句模糊需求，拆成可以判断风险和报价的问题。

也适合已经收到客户需求，但还不确定是直接修复、先诊断还是暂不承接的人。

不适合谁

不适合客户拒绝说明问题，却要求你直接承诺结果的任务。信息不足时，只能做诊断。

也不适合高权限任务。涉及真实数据、密钥、付款、管理员后台、安全事故时，需要更严格授权和复核。

具体步骤

1. 是否有客户原始描述？不要只保存自己理解后的版本。
2. 是否有复现步骤？页面、按钮、命令、输入内容和出现时机要清楚。
3. 是否有错误原文？截图、日志、状态码、终端输出都可以，但必须脱敏。
4. 是否有运行环境？本地、测试、预览、生产，不能混在一起。
5. 是否知道最近变更？代码、依赖、部署、配置、账号权限是否改过。
6. 是否明确预期结果？客户认为什么结果才算正常。
7. 是否明确实际结果？现在具体失败在哪里。
8. 是否涉及敏感权限？密钥、数据库、付款、客户数据和管理员权限都要标记。
9. 是否能用测试数据？不能用测试数据时，风险等级上升。
10. 是否有验收方式？客户如何确认完成。

客户回复模板

我可以先判断这个问题是否适合处理。为了避免范围不清，请先提供：
- 复现步骤
- 错误原文或截图
- 当前运行环境
- 预期结果和实际结果
- 是否涉及密钥、付款、真实数据或管理员权限
- 希望怎样验收

确认这些信息后，我会再给出诊断或小范围修复报价。

判断结论

信息完整、低权限、可测试：可以进入小范围报价。信息不完整但风险不高：先做诊断。涉及高权限或生产风险：暂不独立承接，或要求更正式授权和复核。

这个判断要写进自己的项目笔记。几次之后，你会更快识别哪些需求适合 Claude Code 辅助，哪些需求不能碰。

判断结果怎么写

不要只在心里判断“能接”或“不能接”，要把结论写成客户能理解的一句话。比如：“目前信息足够做一次小范围诊断，但还不足以承诺完整修复。”这句话比直接报价更稳，也能让客户知道下一步为什么是补材料。

如果可以接，结论也要限定范围：处理哪个页面、哪个报错、哪个命令、哪个文件类型，以及交付哪些证据。不要写成“我帮你修好项目”，而是写成“我先处理保存按钮失败这一处，并提供修改说明和测试结果”。

如果暂不接，也要给出可执行的补充条件。比如需要客户提供测试环境、脱敏日志、复现步骤或明确授权。这样你不是冷冰冰拒绝，而是把模糊需求重新推回可判断状态。

发送前自问

发给客户前，快速问自己三件事：第一，我有没有要求客户提供不必要的敏感信息；第二，我有没有把诊断和修复混在一个报价里；第三，我有没有写清楚验收方式。三件事都清楚，再继续沟通。

这一步看起来慢，但实际会省时间。因为后面 Claude Code 读取上下文、生成修复计划、整理交付说明时，都依赖前面的信息质量。前面问得稳，后面才跑得快。

风险提醒

不要因为客户着急就跳过问题确认。越急的任务越容易缺信息，越要先确认复现和权限。

不要把客户敏感材料直接复制到工具里。先脱敏，再整理成最小必要上下文。

免责声明

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

CTA：把这份清单复制到项目笔记；需要回复草稿时用 /tools/proposal-generator，需要模板时去 /templates。