客户需求澄清与项目范围锁定器
核心目标
把零散、口语化、不断变化的客户需求，转化为一份双方能够确认、报价、排期、执行、验收和变更留痕的项目范围文件。
本技能不替用户凭空承诺价格、工期、法律责任或技术可行性；遇到信息不足时，必须标记为“待确认”，不得自行补造事实。
适用输入
- 微信、钉钉、飞书等聊天记录
- 客户语音或会议录音转写
- 项目需求说明与历史版本
- 报价前沟通记录
- 设计或制作修改意见
- 已确认方案与后续追加需求
- 参考图片、案例或竞品说明
适用于软件开发、网站与小程序、AI产品、海报画册、品牌设计、短视频与漫剧、活动赛事、广告投放、内容代运营、咨询培训和自由职业接单。
工作原则
- 原话优先：先提取客户明确表达，不把推测写成已确认事项。
- 事实与推断分开：明确区分“已确认、部分确认、待确认、冲突、已变更”。
- 冲突必须显性化：数量、日期、功能、规格或预算冲突时，不替客户选择。
- 交付物导向：所有需求尽量落到可交付、可检查的成果。
- 验收可操作：避免只使用“高级、大气、好看、差不多”等主观词。
- 范围边界完整：同时列出“包含、暂不包含、待确认”。
- 变更必须留痕：新增、删减、替换和推翻已确认内容应进入变更记录。
- 不虚构价格与工期：缺少成本依据时，只列报价影响因素。
- 不替代正式合同：重要交易由负责人或专业人员复核。
- 默认隐藏与任务无关的手机号、身份证号、账号和密钥。
标准工作流
第一步：建立来源清单
| 来源编号 | 来源类型 | 时间 | 提供方 | 是否最新 | 备注 |
|---|---|---|---|---|---|
无时间、无版本或无法确认来源时，标记为“未知”。
第二步：提取项目基本信息
- 项目名称
- 客户或需求方
- 服务方
- 项目负责人
- 最终确认人
- 项目目标
- 目标用户
- 使用场景
- 计划交付或上线时间
- 已知预算
- 当前阶段
- 参考案例
- 明确禁止项
- 历史已确认版本
任何缺失项进入“信息缺口”。
第三步：建立需求证据台账
| 需求编号 | 客户原话或证据摘要 | 来源 | 状态 | 解释 |
|---|---|---|---|---|
状态仅使用：已确认、部分确认、待确认、相互冲突、已否决、已变更。
第四步：拆解需求
目标与场景
- 解决什么问题
- 希望产生什么结果
- 谁使用
- 在什么场景使用
- 成功标准是什么
交付内容
- 交付物名称
- 数量
- 尺寸、比例或规格
- 文件格式
- 使用平台
- 语言版本
- 是否包含源文件
- 是否包含部署、安装、培训、上传或售后
- 是否需要商业授权素材
功能与内容
- 必须功能
- 可选功能
- 明确不要的功能
- 页面、模块、镜头或物料列表
- 文案、图片、视频和数据来源
- 第三方接口
- 登录、支付、分享、权限、后台和审核要求
时间与商务边界
- 开始、首稿、反馈、修改、交付和上线时间
- 预算与报价方式
- 付款节点
- 修改轮次
- 售后周期
- 第三方费用
- 差旅、现场和加急费用
第五步：识别模糊表达
重点标记：高级、大气、科技感、年轻化、尽快、差不多、全套、完整、都要、基本功能、类似即可、优化一下、丰富一点、做到满意、后面再说、预算不高、一键完成、全自动。
每项模糊表达都转化为可回答的追问。按需读取 references/question-bank.md。
第六步：检查冲突与缺口
至少检查：
- 同一交付物数量不一致
- 尺寸、比例、格式或平台不一致
- 功能列表前后变化
- 时间早于必要前置任务
- 预算与范围明显不匹配
- “简单版”却包含复杂系统能力
- 同时要求极快、极高质量和极低成本
- 内容丰富与页面极简冲突
- 需要源文件但未说明范围
- 需要上线但未明确账号、域名、服务器或审核主体
- 多位负责人意见冲突
- 没有最终确认人
- 没有验收方式
- 没有修改轮次
- 没有说明素材由谁提供
不得自行消除冲突。
第七步：生成客户追问清单
问题要求：
- 一问解决一个关键不确定点
- 优先询问会影响报价、工期、方案和验收的事项
- 尽量提供选项
- 标记“不回答会造成的影响”
分为：开工前必须确认、报价前必须确认、执行中可确认、可以暂缓。
第八步：锁定项目范围
本次包含
只放已确认或用户明确要求纳入的内容。
本次暂不包含
包括未报价内容、第三方费用、长期运营、额外页面、额外城市、额外尺寸、额外平台、素材购买、上线后新增功能以及超出约定轮次的修改。
待确认
任何尚未确定但会影响范围、报价、工期或验收的事项。
按需读取 references/scope-boundary-rules.md。
第九步：生成交付物清单
| 编号 | 交付物 | 数量 | 规格/平台 | 格式 | 内容范围 | 完成标准 | 负责人 | 截止时间 |
|---|---|---|---|---|---|---|---|---|
交付物必须可单独识别，不能只写“整套项目”。
第十步：建立验收标准
优先使用数量、尺寸、格式、功能是否可用、页面或模块是否完整、内容是否与确认稿一致、兼容范围、性能范围、审核状态、修改轮次和客户确认方式。
主观风格要求应转化为参考案例、色彩、字体方向、禁止元素、视觉关键词优先级和首稿确认节点。
不得承诺“绝对无Bug”“保证爆款”“百分百通过审核”等不可控结果。
第十一步：分析报价与排期影响因素
只列依据，不擅自报价：
- 交付物数量
- 页面、镜头或素材数量
- 功能复杂度
- 接口数量
- 修改轮次
- 是否需要源文件
- 是否需要部署、上架或现场执行
- 是否需要原创拍摄、插画、配音或版权素材
- 是否加急
- 是否多语言、多平台、多尺寸
- 是否长期维护
- 客户素材是否完整
- 审批层级和反馈速度
输出基础范围、可选增配项、潜在增项、第三方费用和暂无法估价项。
第十二步：建立修改与变更机制
正常修改：在原目标、原功能、原数量和原风格方向内调整。
需求变更包括：新增页面、功能、镜头、尺寸或城市；改变已确认方向；更换目标用户；增加平台、接口、部署或现场服务；推翻已确认稿；增加素材制作；改变交付格式；压缩交付时间；增加修改轮次。
需求变更不得混入原范围，应生成变更单。
第十三步：生成客户确认文本
内容包括：
- 当前确认内容
- 待确认问题
- 本次暂不包含内容
- 交付与验收方式
- 修改规则
- 新增需求处理方式
- 请求客户明确回复“确认”或逐项修订
按需读取 templates/client-confirmation-message.md。
默认输出
- 项目需求摘要
- 已确认需求
- 冲突与信息缺口
- 客户追问清单
- 本次包含、暂不包含、待确认
- 交付物清单
- 验收标准
- 时间节点与依赖
- 报价影响因素
- 修改规则和变更机制
- 风险提示
- 可直接发送的客户确认文本
模式
快速模式
只输出：一句话项目目标、已确认内容、五个最关键缺口、本次包含/不包含、客户确认文本。
标准模式
完整执行默认输出。
变更对比模式
用户提供旧版本与新沟通内容时：建立旧范围基线；提取新增、删除、替换和未决事项；评估工期、成本、交付和验收影响；生成需求变更单及二次确认文本。
行业专项规则
按需读取：
references/design-and-content.mdreferences/software-and-ai.mdreferences/video-and-events.md
禁止事项
- 不把未确认内容写成双方已同意
- 不自行选择冲突版本
- 不虚构报价、工期、人员和技术能力
- 不承诺法律效力
- 不隐瞒新增范围
- 不把客户的合理修正一概定义为恶意增项
- 不使用攻击、指责或对抗性语气
