客户需求澄清与项目范围锁定器

核心目标

把零散、口语化、不断变化的客户需求，转化为一份双方能够确认、报价、排期、执行、验收和变更留痕的项目范围文件。

本技能不替用户凭空承诺价格、工期、法律责任或技术可行性；遇到信息不足时，必须标记为“待确认”，不得自行补造事实。

适用输入

• 微信、钉钉、飞书等聊天记录
• 客户语音或会议录音转写
• 项目需求说明与历史版本
• 报价前沟通记录
• 设计或制作修改意见
• 已确认方案与后续追加需求
• 参考图片、案例或竞品说明

适用于软件开发、网站与小程序、AI产品、海报画册、品牌设计、短视频与漫剧、活动赛事、广告投放、内容代运营、咨询培训和自由职业接单。

工作原则

1. 原话优先：先提取客户明确表达，不把推测写成已确认事项。
2. 事实与推断分开：明确区分“已确认、部分确认、待确认、冲突、已变更”。
3. 冲突必须显性化：数量、日期、功能、规格或预算冲突时，不替客户选择。
4. 交付物导向：所有需求尽量落到可交付、可检查的成果。
5. 验收可操作：避免只使用“高级、大气、好看、差不多”等主观词。
6. 范围边界完整：同时列出“包含、暂不包含、待确认”。
7. 变更必须留痕：新增、删减、替换和推翻已确认内容应进入变更记录。
8. 不虚构价格与工期：缺少成本依据时，只列报价影响因素。
9. 不替代正式合同：重要交易由负责人或专业人员复核。
10. 默认隐藏与任务无关的手机号、身份证号、账号和密钥。

标准工作流

第一步：建立来源清单

无时间、无版本或无法确认来源时，标记为“未知”。

第二步：提取项目基本信息

• 项目名称
• 客户或需求方
• 服务方
• 项目负责人
• 最终确认人
• 项目目标
• 目标用户
• 使用场景
• 计划交付或上线时间
• 已知预算
• 当前阶段
• 参考案例
• 明确禁止项
• 历史已确认版本

任何缺失项进入“信息缺口”。

第三步：建立需求证据台账

状态仅使用：已确认、部分确认、待确认、相互冲突、已否决、已变更。

第四步：拆解需求

目标与场景

• 解决什么问题
• 希望产生什么结果
• 谁使用
• 在什么场景使用
• 成功标准是什么

交付内容

• 交付物名称
• 数量
• 尺寸、比例或规格
• 文件格式
• 使用平台
• 语言版本
• 是否包含源文件
• 是否包含部署、安装、培训、上传或售后
• 是否需要商业授权素材

功能与内容

• 必须功能
• 可选功能
• 明确不要的功能
• 页面、模块、镜头或物料列表
• 文案、图片、视频和数据来源
• 第三方接口
• 登录、支付、分享、权限、后台和审核要求

时间与商务边界

• 开始、首稿、反馈、修改、交付和上线时间
• 预算与报价方式
• 付款节点
• 修改轮次
• 售后周期
• 第三方费用
• 差旅、现场和加急费用

第五步：识别模糊表达

重点标记：高级、大气、科技感、年轻化、尽快、差不多、全套、完整、都要、基本功能、类似即可、优化一下、丰富一点、做到满意、后面再说、预算不高、一键完成、全自动。

每项模糊表达都转化为可回答的追问。按需读取 references/question-bank.md。

第六步：检查冲突与缺口

至少检查：

• 同一交付物数量不一致
• 尺寸、比例、格式或平台不一致
• 功能列表前后变化
• 时间早于必要前置任务
• 预算与范围明显不匹配
• “简单版”却包含复杂系统能力
• 同时要求极快、极高质量和极低成本
• 内容丰富与页面极简冲突
• 需要源文件但未说明范围
• 需要上线但未明确账号、域名、服务器或审核主体
• 多位负责人意见冲突
• 没有最终确认人
• 没有验收方式
• 没有修改轮次
• 没有说明素材由谁提供

不得自行消除冲突。

第七步：生成客户追问清单

问题要求：

• 一问解决一个关键不确定点
• 优先询问会影响报价、工期、方案和验收的事项
• 尽量提供选项
• 标记“不回答会造成的影响”

分为：开工前必须确认、报价前必须确认、执行中可确认、可以暂缓。

第八步：锁定项目范围

本次包含

只放已确认或用户明确要求纳入的内容。

本次暂不包含

包括未报价内容、第三方费用、长期运营、额外页面、额外城市、额外尺寸、额外平台、素材购买、上线后新增功能以及超出约定轮次的修改。

待确认

任何尚未确定但会影响范围、报价、工期或验收的事项。

按需读取 references/scope-boundary-rules.md。

第九步：生成交付物清单

交付物必须可单独识别，不能只写“整套项目”。

第十步：建立验收标准

优先使用数量、尺寸、格式、功能是否可用、页面或模块是否完整、内容是否与确认稿一致、兼容范围、性能范围、审核状态、修改轮次和客户确认方式。

主观风格要求应转化为参考案例、色彩、字体方向、禁止元素、视觉关键词优先级和首稿确认节点。

不得承诺“绝对无Bug”“保证爆款”“百分百通过审核”等不可控结果。

第十一步：分析报价与排期影响因素

只列依据，不擅自报价：

• 交付物数量
• 页面、镜头或素材数量
• 功能复杂度
• 接口数量
• 修改轮次
• 是否需要源文件
• 是否需要部署、上架或现场执行
• 是否需要原创拍摄、插画、配音或版权素材
• 是否加急
• 是否多语言、多平台、多尺寸
• 是否长期维护
• 客户素材是否完整
• 审批层级和反馈速度

输出基础范围、可选增配项、潜在增项、第三方费用和暂无法估价项。

第十二步：建立修改与变更机制

正常修改：在原目标、原功能、原数量和原风格方向内调整。

需求变更包括：新增页面、功能、镜头、尺寸或城市；改变已确认方向；更换目标用户；增加平台、接口、部署或现场服务；推翻已确认稿；增加素材制作；改变交付格式；压缩交付时间；增加修改轮次。

需求变更不得混入原范围，应生成变更单。

第十三步：生成客户确认文本

内容包括：

• 当前确认内容
• 待确认问题
• 本次暂不包含内容
• 交付与验收方式
• 修改规则
• 新增需求处理方式
• 请求客户明确回复“确认”或逐项修订

按需读取 templates/client-confirmation-message.md。

默认输出

1. 项目需求摘要
2. 已确认需求
3. 冲突与信息缺口
4. 客户追问清单
5. 本次包含、暂不包含、待确认
6. 交付物清单
7. 验收标准
8. 时间节点与依赖
9. 报价影响因素
10. 修改规则和变更机制
11. 风险提示
12. 可直接发送的客户确认文本

模式

快速模式

只输出：一句话项目目标、已确认内容、五个最关键缺口、本次包含/不包含、客户确认文本。

标准模式

完整执行默认输出。

变更对比模式

用户提供旧版本与新沟通内容时：建立旧范围基线；提取新增、删除、替换和未决事项；评估工期、成本、交付和验收影响；生成需求变更单及二次确认文本。

行业专项规则

按需读取：

• references/design-and-content.md
• references/software-and-ai.md
• references/video-and-events.md

禁止事项

• 不把未确认内容写成双方已同意
• 不自行选择冲突版本
• 不虚构报价、工期、人员和技术能力
• 不承诺法律效力
• 不隐瞒新增范围
• 不把客户的合理修正一概定义为恶意增项
• 不使用攻击、指责或对抗性语气