客户需求沟通表新手检查清单

客户需求沟通表不是越长越专业。真正有用的表单，要能帮你判断三件事：客户到底要什么、你能不能做、交付后怎么验收。如果这三件事还不清楚，就不要急着报价。

这份清单是草稿，适合和 客户需求沟通表怎么问才清楚、/templates 和 /tools/proposal-generator 搭配使用。所有客户信息都应先脱敏再放进 AI 工具。

适合谁

适合准备接第一个小项目的新手，尤其是网页修改、模板整理、文案修改、简单脚本、报错诊断和工具配置类任务。

也适合接到客户消息后不知道怎么回的人。你可以先按清单判断缺什么，再发一段简短追问。

不适合谁

不适合高风险项目，例如生产环境修改、支付流程、登录系统、数据库、隐私数据、账号权限和安全问题。这些需要单独评估。

也不适合用来替代合同或正式需求文档。清单只是第一轮判断工具，不是完整法律文件。

具体步骤

1. 复制客户原始需求，保留时间和上下文。
2. 用一句话复述目标，确认客户是否认可。
3. 列出现有材料：链接、截图、仓库、文档、素材、参考页。
4. 标出缺失材料：没有验收标准、没有权限说明、没有截止时间等。
5. 判断风险：是否涉及真实用户、付款、账号、数据或平台规则。
6. 写追问：只问本轮判断必须知道的问题。
7. 收到回复后再决定报价、拒绝或先做诊断。

表单字段清单

• 项目目标：
• 当前问题：
• 参考样例：
• 已有材料：
• 需要交付：
• 验收标准：
• 截止时间：
• 权限和账号：
• 是否涉及真实数据：
• 修改轮次：
• 未覆盖范围：
• 需要人工复核：

字段不一定全部发给客户，但你自己要先知道哪些为空。空得越多，越不适合直接报价。

必问问题

必须问的问题通常不超过五个：目标是什么、材料在哪里、结果怎么验收、是否涉及敏感权限、什么时候需要完成。其他问题可以等第一轮诊断后再问，避免客户被长表单吓走。

如果客户回答很模糊，可以继续追问一个具体例子。例如“你说页面不好看，是指按钮颜色、文字排版、移动端重叠，还是整体风格？”这种问题比“你想怎么改？”更容易得到有用答案。

精简版消息

如果客户不喜欢填表，可以发精简版：“请发我当前页面或文件、希望变成什么样、是否有参考、交付时看什么结果、是否涉及账号或真实数据。”这五个点已经能过滤大部分不清楚的任务。

等客户愿意继续沟通后，再补完整字段。新手不要把表单当成障碍，表单的目的只是让双方对同一件事有共同记录。

暂停条件

如果客户要求你接触验证码、后台账号、生产数据库、支付配置、用户隐私或绕开正常平台流程，应立即暂停。把这些事项记录为风险点，等待人工复核。

如果客户拒绝说明验收标准，也不要直接承诺完成。没有验收标准的项目，很容易在交付后变成无限修改。

复盘记录

每次客户回复后，可以把这次需求分成三列：已经确认、仍需追问、暂不处理。已经确认的内容用于报价；仍需追问的内容用于下一条消息；暂不处理的内容写进未覆盖范围。这样做可以避免你把所有信息都混在一段聊天里，后面找不到依据。

如果项目最终没有接，也值得保留一条记录：为什么没接，是材料不足、风险过高、预算不匹配，还是自己能力暂时不够。下一次遇到类似需求时，这条记录会比临时判断更可靠。

风险提醒

不要把客户原始资料直接贴进 AI 工具。先去掉姓名、邮箱、账号、链接 token、订单号、客户业务细节和未公开数据。需求沟通可以借助工具，但隐私判断必须由人负责。

不要把“客户说简单”当成范围判断。简单只是客户感受，真正决定难度的是材料、权限、技术环境、验收标准和风险。

免责声明

本文仅供学习和项目沟通参考，不构成法律、安全或平台合规建议。发布前请人工复核模板字段、隐私说明和适用场景。

CTA：先从 /templates 下载需求表；需要写追问时，用 /tools/proposal-generator 出初稿，再按本文清单删减。