用户访谈别问要不要功能，先改成场景提纲

教程定位

这篇教程解决什么问题

很多产品访谈看起来是在听用户，实际上是在让用户替团队点头。团队拿着一串待验证功能点进入会议室，问题从一开始就变成：“你需要批量导入吗？”“如果我们做审批流，你会用吗？”“这个看板是不是能解决你的管理问题？”用户通常不会当场反驳，尤其当访谈对象是客户、试用用户或熟人推荐来的受访者时，他们更容易顺着说“可以”“有用”“你们做出来我看看”。会议结束后，团队以为自己验证了需求，其实只是收集了一堆对功能名称的礼貌反馈。

这篇文章解决的是访谈提纲设计问题：把“是否需要某功能”的确认式问题，改写成围绕任务、场景、触发原因、现有替代方案和决策标准的开放问题。AI 在这里的价值不是替你判断用户到底要不要功能，也不是输出产品方案，而是帮你把功能清单拆回用户正在完成的工作，再生成一份能带进访谈的场景型提纲。

完成后，你会得到一份访谈提纲，包含开场说明、任务回溯、场景追问、触发原因、现有替代方案、选择标准、功能概念探测和避免诱导的检查项。它适合产品经理、创业团队负责人在访谈前准备问题，尤其适合那些已经有功能想法、但还不确定用户真实问题是否成立的阶段。

这篇不分析访谈数据，不总结用户洞察，不给功能优先级，不输出产品方案。它只做一件事：把一串功能问题改成一份更不容易诱导用户的访谈提纲。

使用场景

什么情况下最适合用这一套

你可能是产品经理，也可能是创业团队负责人。团队最近讨论了几个新功能：客户标签自动分组、审批提醒、数据看板、竞品价格监控、批量导入、权限模板。每个功能听起来都有理由，也都有人支持。销售说客户问过标签，运营说审批经常漏，老板觉得看板能提升续费，研发希望先做一个技术上比较顺的版本。

于是你准备约 8 个目标用户聊一轮。最自然的做法是把功能列成问题：“你们需要自动分组吗？”“如果有审批提醒，你会不会用？”“你希望看板展示哪些指标？”但这种提纲有两个问题。

第一个问题是它默认功能方向已经成立。用户还没讲自己的工作过程，你已经把答案放在问题里了。用户只需要对你的想法做评价，而不是讲出他们真实怎么做事、什么时候卡住、现在怎么替代、为什么没有换工具。

第二个问题是用户对未来功能的表态很便宜。说“会用”不等于真的会迁移流程，说“有帮助”不等于愿意付费，说“最好有”也不等于优先级高。尤其当问题带着产品名词时，用户可能并不知道你心里的实现方式，只是在回应一个听起来不错的概念。

更好的访谈提纲应该先退一步：不要从功能名开始，而是从用户的任务开始。比如不要先问“你需要客户标签自动分组吗”，而是问“你最近一次需要区分客户优先级是在什么时候？当时你怎么判断哪些客户要先跟？用到了哪些信息？哪些信息是临时补的？如果判断错了，会造成什么后果？”等用户把场景讲出来，再谨慎探测“如果系统能自动提示一组可能高优先级客户，你会怎么判断它是否可信？”

这份方法适合以下情况：

它不适合用来替代定量问卷，也不适合在已经有明确可用性测试任务时使用。如果你已经有原型，需要观察用户能否完成操作，那是可用性测试提纲；本文处理的是更早一层的需求访谈提纲。

• 团队已经有待验证功能点，但不想把访谈做成内部想法确认会。
• 访谈对象是目标用户、试用客户、流失客户或竞品用户，需要理解他们真实工作方式。
• 你担心团队问出“你需不需要”“你喜不喜欢”“你会不会用”这类答案很顺但价值很低的问题。
• 你需要一份提纲让老板、销售、产品、设计师都能看懂，并知道哪些问法不能碰。
• 你还没有进入产品方案设计阶段，只想先把需求场景问清楚。

材料准备

开始前先把材料和边界备齐

让 AI 生成提纲前，先准备五类输入。不要只给它一张功能清单，否则它很容易把每个功能扩写成“你是否需要某某能力”的变体。

第一类是待验证功能点。功能点可以粗糙，但要写清楚团队心里的功能含义。例如“客户标签自动分组”最好补一句“系统根据客户行业、成交阶段、最近互动和金额自动推荐标签”，而不是只写四个字。AI 需要知道你想验证的功能边界，才能把它拆成相关任务和场景。

第二类是目标用户画像。至少包括角色、所在组织、工作目标、常见任务、是否有采购或决策权、目前使用的工具。访谈提纲不是通用聊天清单，同一个功能面对销售主管、销售运营、创始人、客服负责人，问题顺序和追问角度都不同。

第三类是业务假设。写清团队为什么想做这个功能。比如“我们认为销售主管每天都在手工判断客户优先级，耗时且容易漏跟”，或者“我们认为审批延迟是项目交付延期的重要原因”。假设要暴露出来，不能藏在提问里。AI 需要把假设转成待验证问题，而不是帮你把假设包装成用户会点头的问题。

第四类是历史反馈。包括客户原话、销售记录、客服工单、试用反馈、流失原因、过往访谈片段。每条最好标来源。比如“客户说标签太乱”是原话，和“销售判断客户需要自动打标签”不是同一种证据。AI 如果分不清证据层级，提纲就会变得很武断。

第五类是竞品线索。不是让 AI 做竞品分析，而是帮助它设计关于替代方案的问题。用户现在可能用 Excel、飞书表格、CRM 自带字段、竞品自动化规则、人工周会来解决同一个任务。访谈需要问出这些替代方案是怎么被选择、怎么被忍受、哪里不够好。

准备材料时，还要写清本次访谈的边界。比如：

| 输入项 | 应该写什么 | 不能只写什么 | | --- | --- | --- | | 待验证功能点 | 功能名、团队设想、希望验证的能力边界 | 只写“标签”“看板”“提醒” | | 目标用户画像 | 角色、任务、工具、决策影响力 | 只写“中小企业用户” | | 业务假设 | 团队认为问题存在的原因和影响 | 只写“用户可能需要” | | 历史反馈 | 原话、来源、时间、上下文 | 只写“很多客户反馈过” | | 竞品线索 | 用户可能正在用的替代方法 | 只写竞品名称 |

最后提醒一句：如果访谈涉及价格承诺、医疗法律、合同合规、劳动关系等高风险判断，AI 只能帮你准备开放问题，不能替你决定口径。访谈中的承诺、解释和后续决策都要由负责人复核。

实操流程

按这套步骤把工作跑起来

第一步，把功能点翻译成用户任务。

不要让 AI 直接为每个功能写问题，而是先要求它回答：“这个功能背后，用户可能在完成什么任务？”比如“审批提醒”背后的任务可能是跟进待审批事项、避免项目延期、催促相关负责人、确认风险是否升级；“数据看板”背后的任务可能是发现异常、向老板汇报、决定资源投入、判断活动是否继续。

这一步的输出应该是“功能点 -> 可能任务 -> 需要验证的场景”，而不是“功能点 -> 访谈问题”。如果任务都没有拆清楚，问题再开放也会漂。

第二步，把任务放进具体场景。

好的问题不问抽象偏好，而问最近一次真实经历。不要问“你们是否经常需要审批提醒”，可以问“最近一次因为审批没有及时处理而影响进度，是在什么情况下发生的？”不要问“你希望看板展示哪些指标”，可以问“你上次需要向老板解释业务异常时，临时查了哪些数据？”

AI 可以帮你为每个任务补齐场景要素：时间、触发事件、参与角色、使用工具、判断依据、后果。提纲里至少要有几类场景问题：最近一次、典型一次、最麻烦一次、不得不换方法的一次。

第三步，把“要不要功能”改成“现在怎么解决”。

用户是否需要某个功能，不如用户现在如何完成同一件事重要。现有替代方案会告诉你三件事：这个任务是否真实存在，用户为了它愿意付出多少成本，以及新功能需要比什么更好。

比如团队想做“客户标签自动分组”，不要急着问用户是否需要自动标签。先问：“你们现在怎么判断一批客户里谁要优先跟进？”“这个判断通常由谁做？”“会看哪些字段或记录？”“哪些情况需要人工讨论？”“如果判断错了，后面怎么补救？”这些回答比一句“自动标签挺好”更能帮助团队判断功能是否有必要。

第四步，追问触发原因，而不是只问痛点。

很多访谈只问“你有什么痛点”，用户会说出一堆不满意，但你很难判断它是否重要。更稳的问法是追问触发原因：什么情况下这个问题会变得必须处理？什么信号出现时，你会停下手头工作去解决它？什么后果会让你找新工具？

触发原因能区分“有点烦”和“必须解决”。比如用户说审批慢，你要继续问：“慢到什么程度会影响交付？”“有没有哪次因为审批延迟导致客户投诉或内部升级？”“平时你们会忍过去，还是会找别的方法绕开？”这里的重点不是证明审批提醒有用，而是理解问题什么时候变成刚需。

第五步，加入决策标准问题。

如果用户真的要换方法、买工具或接受新功能，他们会按什么标准判断？这一步常被忽略，导致团队只知道用户有问题，却不知道产品要做到什么程度才被采纳。

你可以让 AI 为每个功能相关任务生成决策标准问题，比如：“你们判断一个自动推荐结果可信时，会看哪些证据？”“什么情况下你会继续人工判断，而不是接受系统建议？”“如果一个提醒功能每周误报两次，你能接受吗？”“你怎么判断一个看板值得每天打开？”这些问题能把访谈从“喜不喜欢”拉回“怎样才会用”。

第六步，再谨慎放入功能概念探测。

场景问题问完后，可以加入少量功能概念探测，但顺序要靠后，语气要中性。不要说“我们准备做一个很智能的自动分组，你会不会用？”可以说：“如果有一个工具根据客户阶段、最近互动和金额，给出一组优先跟进建议，你会先怎么判断它有没有用？”这不是让用户投票，而是观察他们的评估方式。

功能探测问题要限制数量。一般一场 45 分钟访谈，围绕 2 到 3 个核心任务足够了。不要把 8 个功能都塞进去，否则每个功能只能得到浅层态度。

第七步，让 AI 生成“避免诱导检查项”。

提纲最后必须有一段专门检查诱导。把所有“你是否需要”“你会不会用”“是不是因为”“如果我们做出来你愿不愿意付费”这类问题列出来，改成开放问法。这个检查项可以直接放在访谈文档末尾，提醒参会的人不要临场把问题问歪。

第八步，人工收口成一份能执行的提纲。

AI 给出的提纲通常会偏全，人工要做减法。保留最关键的 8 到 12 个主问题，每个主问题配 2 到 3 个追问。把问题按访谈顺序排好：开场背景、最近任务、具体过程、替代方案、触发原因、决策标准、功能概念探测、收尾确认。访谈不是审讯，不需要把所有问题问完；更重要的是沿着用户真实经历追下去。

输入示例

可以直接参考的输入材料

下面是一份可以直接粘给 AI 的材料样例。示例是虚构的，真实使用时请脱敏，并标清信息来源。

这个输入样例的关键是把“团队想做什么”和“用户可能正在完成什么任务”都说清楚。AI 不能凭一个功能名知道你的业务假设，也不能凭一个用户画像判断问题顺序。你给它越多上下文，它越能把提纲写成真实访谈能用的版本。

【本次任务】
我们要准备一份用户访谈提纲，用来验证几个功能背后的真实场景。请不要把提纲写成“用户是否需要这些功能”的问卷，而要把功能问题改写成围绕任务、场景、触发原因、替代方案和决策标准的开放问题。

【待验证功能点】
1. 客户标签自动分组
团队设想：系统根据客户行业、成交阶段、最近互动记录、金额规模，自动推荐“高优先级跟进”“需要复盘”“可能流失”等标签。

2. 审批超时提醒
团队设想：当报价、合同、特殊折扣等审批超过设定时间，系统自动提醒负责人和相关协作人。

3. 销售主管数据看板
团队设想：主管每天看到团队跟进量、重点客户状态、异常商机和下周预测。

【目标用户画像】
主要访谈对象：B2B 软件公司的销售主管或创业公司负责人。
团队规模：销售 8 到 30 人。
工作目标：提高重点客户跟进质量、减少商机遗漏、及时发现销售过程异常。
当前工具：CRM、飞书表格、周会、销售个人记录。
决策影响力：部分受访者能决定是否启用新工具，部分只是功能使用者和建议者。

【业务假设】
假设 1：销售主管每天都需要判断哪些客户优先跟进，但现有 CRM 字段更新不及时，导致判断依赖经验和人工问询。
假设 2：报价和合同审批延迟会影响成交节奏，但团队不一定认为提醒功能是核心解决方案。
假设 3：主管想要看板，但真正需要的可能不是更多指标，而是异常提示和可追责的下一步动作。

【历史反馈】
来源：销售访谈记录，2026-06-12
- 客户 A 说：“我们不是没有字段，是字段没人维护，最后还是靠主管问。”
- 客户 B 说：“审批卡住的时候，销售会在群里催，但有时不知道该催谁。”
- 客户 C 说：“看板很多，但我每天打开的只有两个，一个看本月目标，一个看卡住的大单。”

来源：客服工单摘要
- 有 7 条反馈提到“客户标签太乱”。
- 有 4 条反馈提到“审批状态不清楚”。
- 有 3 条反馈提到“主管不知道团队每天在跟什么客户”。

【竞品和替代方案线索】
- 有些用户用飞书表格维护重点客户清单，每周人工更新。
- 有些用户在 CRM 里自定义字段，但字段标准不统一。
- 有些团队靠每天晨会口头同步异常客户。
- 某竞品提供自动评分，但有用户反馈“评分原因看不懂，所以主管不敢直接用”。

【希望输出】
请输出一份 45 分钟用户访谈提纲，面向销售主管或创业团队负责人。提纲要包含：
1. 开场说明。
2. 按访谈顺序排列的主问题和追问。
3. 每个问题对应想验证的任务或假设。
4. 把原本的功能问题改写成开放问题。
5. 至少 5 个禁止使用的诱导式问法，以及对应改写。
6. 不要分析访谈数据，不要输出产品方案，不要给功能优先级。

提示词

可复制使用的提示词

下面的提示词可以直接复制。把方括号里的内容替换成你的实际材料。

如果你的访谈时间只有 30 分钟，可以在提示词里要求 AI 把主问题压缩到 6 到 8 个。如果访谈对象不是同一类角色，要让 AI 分别生成提纲，不要把创始人、销售主管和一线销售的问题混在一份文档里。

你是一名谨慎的产品用户访谈提纲设计助手。请根据我提供的待验证功能点、目标用户画像、业务假设、历史反馈和竞品/替代方案线索，生成一份“场景型用户访谈提纲”。

这份提纲的目标不是让用户评价功能好不好，而是理解：
- 用户正在完成什么任务；
- 这个任务通常在什么场景下发生；
- 什么事件会触发用户必须处理它；
- 用户现在用什么替代方案；
- 用户如何判断一个新方法是否值得采用；
- 团队提出的功能概念应该如何中性探测。

重要规则：
1. 不要使用“你需不需要这个功能”“你会不会用”“你喜不喜欢”“如果我们做出来你是否愿意付费”作为主问题。
2. 不要把历史反馈中的团队判断当成用户事实。
3. 不要分析访谈数据，不要总结用户洞察，不要输出产品方案或功能优先级。
4. 每个问题都要尽量指向一次真实经历、具体任务或明确决策标准。
5. 功能概念探测只能放在场景和替代方案问题之后，且必须用中性表达。

请按以下结构输出：

A. 访谈目标和边界
- 本次访谈要理解什么
- 本次访谈不解决什么
- 需要避免的诱导风险

B. 功能点到用户任务的转换表
表格列出：待验证功能点、背后可能任务、对应业务假设、需要验证的场景、不能直接问的问题。

C. 45 分钟访谈提纲
按顺序给出：
- 开场和背景确认
- 最近一次任务回溯
- 过程和参与角色追问
- 现有替代方案追问
- 触发原因和后果追问
- 决策标准追问
- 中性功能概念探测
- 收尾确认

每个主问题请包含：
- 问题原文
- 可选追问
- 想验证的假设或任务
- 提问注意事项

D. 功能问题改写清单
把我原本可能想问的功能问题，改写成开放式问题。至少输出 8 组，格式为：
- 不建议问：
- 更建议问：
- 为什么这样改：

E. 避免诱导检查项
列出至少 5 个访谈中不能使用的诱导式问法，并给出替代问法。

F. 访谈前人工复核清单
提醒我在使用提纲前应该删减哪些问题、确认哪些信息、标注哪些敏感边界。

这是我的输入材料：
[粘贴待验证功能点、目标用户画像、业务假设、历史反馈、竞品或替代方案线索]

输出样例

AI 应该输出到什么程度

以下是使用上面输入样例后，AI 可能生成的一份初稿。注意：这是访谈前提纲，不代表真实访谈结论。

# 场景型用户访谈提纲：销售主管如何判断客户优先级、跟进审批和发现异常

教程正文

A. 访谈目标和边界

本次访谈希望理解销售主管或创业团队负责人在管理销售过程时，如何判断客户优先级、如何处理审批延迟、如何发现团队跟进异常，以及他们现在使用哪些替代方法。

本次访谈不要求受访者判断“是否需要自动标签、审批提醒或数据看板”，也不要求受访者为功能排优先级。功能概念只在后半段中性探测，用来理解受访者如何判断新方法是否可信。

需要避免的诱导风险：

• 不要问“你需不需要客户标签自动分组”。
• 不要问“审批提醒是不是能解决你们的问题”。
• 不要问“如果有销售看板你会每天看吗”。
• 不要把“字段没人维护”直接解释为“用户需要自动打标签”。

教程正文

B. 功能点到用户任务的转换表

| 待验证功能点 | 背后可能任务 | 对应业务假设 | 需要验证的场景 | 不能直接问的问题 | | --- | --- | --- | --- | --- | | 客户标签自动分组 | 判断哪些客户要优先跟进 | 主管依赖经验和人工询问，CRM 字段更新不及时 | 最近一次筛重点客户、复盘异常客户、安排销售跟进 | 你需要自动标签吗 | | 审批超时提醒 | 发现报价或合同审批卡住并推动处理 | 审批延迟影响成交节奏，但提醒未必是核心解法 | 最近一次审批影响成交、销售催审批、找不到负责人 | 有审批提醒你会用吗 | | 销售主管数据看板 | 发现团队异常并决定下一步动作 | 主管需要异常提示，不一定需要更多指标 | 最近一次向老板解释销售异常、周会前查数据、预测下周成交 | 你想看哪些指标 |

教程正文

C. 45 分钟访谈提纲

【1. 开场和背景确认，约 5 分钟】

主问题：先了解一下你现在管理销售过程的方式。你平时主要负责哪些销售管理动作？比如看重点客户、跟进大单、处理审批、开周会或向老板汇报。

可选追问：

想验证的任务：确认受访者是否真的承担客户优先级判断、审批推进和异常发现任务。

提问注意事项：不要在开场就提“标签、提醒、看板”等功能名。

【2. 最近一次判断客户优先级，约 8 分钟】

主问题：请回忆最近一次你需要判断一批客户里哪些要优先跟进的情况。当时是什么触发你做这个判断？

可选追问：

想验证的任务：验证客户优先级判断是否真实发生，以及现有 CRM 字段和人工沟通的作用。

提问注意事项：不要问“自动分组是不是能帮你节省时间”，先让受访者讲现在的判断过程。

【3. 现有替代方案追问，约 6 分钟】

主问题：除了 CRM，你们现在还会用什么方式维护重点客户或异常客户？比如表格、群消息、晨会、个人记录。

可选追问：

想验证的任务：理解现有替代方案，以及新功能要替代或补充的对象。

提问注意事项：不要把替代方案评价成“落后”或“低效”。

【4. 审批延迟和后果，约 7 分钟】

主问题：最近一次报价、合同或特殊折扣审批影响销售进度，是怎么发生的？

可选追问：

想验证的任务：理解审批延迟是否是高频且有后果的问题，以及提醒是否只是表层方案。

提问注意事项：不要问“有超时提醒是不是就好了”。

【5. 看板和异常发现，约 7 分钟】

主问题：最近一次你需要向老板或团队解释销售异常时，你是怎么准备数据的？

可选追问：

想验证的任务：理解受访者真正打开看板的触发原因，以及看板和后续动作的关系。

提问注意事项：不要让问题停留在“想看哪些指标”，要追到指标如何影响判断。

【6. 决策标准，约 6 分钟】

主问题：如果一个工具告诉你“这批客户建议优先跟进”或“这个审批已经异常”，你会怎么判断它值不值得相信？

可选追问：

想验证的任务：理解用户采用自动化建议、提醒和看板的标准。

提问注意事项：这里可以开始中性探测功能概念，但不要推销方案。

【7. 中性功能概念探测，约 4 分钟】

主问题：如果有一个工具根据客户阶段、最近互动、金额和销售记录，给出一组可能需要优先跟进的客户，你会先怎么试用或验证它是否靠谱？

可选追问：

想验证的任务：探测自动标签/自动分组概念的评估方式，而不是让用户投票。

提问注意事项：不要问“你会不会买”或“你愿意付多少钱”。

【8. 收尾确认，约 2 分钟】

主问题：如果只改善销售管理过程里的一个环节，你觉得最值得先改善的是哪里？为什么？

可选追问：

想验证的任务：确认用户自己认为的优先问题，并为后续访谈或观察做准备。

提问注意事项：不要把收尾做成功能投票。

• 这些动作里，哪些是你每天都会做的，哪些是每周固定做的？
• 你通常会打开哪些工具或资料？
• 哪些信息是系统里有的，哪些需要临时问人？
• 你当时看了哪些信息？
• 哪些信息是可信的，哪些需要再问销售确认？
• 有没有出现字段不准、记录缺失或销售说法不一致的情况？
• 最后你怎么决定谁先跟、谁后跟？
• 这些方法是谁维护的？
• 多久更新一次？
• 什么情况下这些方法会失效？
• 你为什么还保留这些方法，而不是完全依赖 CRM？
• 当时是谁发现审批卡住的？
• 你们怎么判断该催谁？
• 催促通常发生在什么渠道？
• 审批延迟到什么程度会影响客户或成交？
• 有没有时候你们会选择绕开流程或先口头确认？
• 你先看哪些指标？
• 哪些指标看了也不能直接说明问题？
• 你需要追问销售哪些情况？
• 最后你要做的决定是什么？
• 有没有哪些看板你已经不看了？为什么？
• 你需要看到哪些解释或证据？
• 什么情况下你会忽略系统建议，继续人工判断？
• 如果系统偶尔提醒错，你能接受到什么程度？
• 你希望它给出结论，还是给出线索让你判断？
• 你会拿它和什么结果对比？
• 谁会决定是否采用这个建议？
• 它必须解释到什么程度，你才愿意让团队参考？
• 这个问题现在不解决会带来什么影响？
• 你们过去尝试过解决吗？
• 下次如果继续聊，你愿意带一份真实流程或表格给我们看吗？

教程正文

D. 功能问题改写清单

更建议问：最近一次你需要从一批客户里挑出优先跟进对象，是怎么判断的？ 为什么这样改：从功能评价改成真实任务回溯。

更建议问：如果有人给你一份客户优先级建议，你会看哪些证据判断它是否可靠？ 为什么这样改：验证采用标准，而不是收集口头意愿。

更建议问：你上次发现 CRM 字段和实际情况不一致时，后来怎么处理？ 为什么这样改：避免把团队假设塞进问题里。

更建议问：最近一次审批慢到影响销售进度，中间发生了哪些动作？ 为什么这样改：先理解机制，再判断提醒是否相关。

更建议问：你最近一次用数据解释销售异常时，哪些信息真正影响了判断？ 为什么这样改：从指标偏好改成决策过程。

更建议问：什么情况下你会主动打开销售数据，而不是等周会再看？ 为什么这样改：验证触发场景，而不是让用户承诺未来行为。

更建议问：你们用过或看过类似自动评分时，哪些地方让你愿意参考，哪些地方让你不放心？ 为什么这样改：从评价竞品改成理解信任标准。

更建议问：如果这个问题长期不解决，会给团队带来哪些成本？过去你们为解决它投入过什么？ 为什么这样改：先理解问题价值和既有投入，不在需求访谈里直接做价格承诺。

1. 不建议问：你需要客户标签自动分组吗？
2. 不建议问：如果系统自动打标签，你会用吗？
3. 不建议问：你们是不是因为 CRM 字段不准，所以需要自动分组？
4. 不建议问：审批超时提醒是不是能解决审批慢？
5. 不建议问：销售看板应该展示哪些指标？
6. 不建议问：如果我们做一个异常看板，你会每天看吗？
7. 不建议问：你觉得竞品的自动评分好不好？
8. 不建议问：你愿意为这些功能付费吗？

教程正文

E. 避免诱导检查项

• 把“是不是因为”改成“当时发生了什么”。
• 把“你需不需要”改成“你现在怎么处理”。
• 把“你会不会用”改成“你会如何判断它是否值得用”。
• 把“这个功能有没有帮助”改成“这个任务现在最难的环节在哪里”。
• 把“你愿意付费吗”改成“这个问题不解决会造成什么影响，过去是否投入过人力或工具”。

教程正文

F. 访谈前人工复核清单

• 主问题是否控制在 8 到 12 个，避免 45 分钟内问不完。
• 每个问题是否指向真实经历、当前做法、触发原因或决策标准。
• 功能概念探测是否放在后半段，而不是开场。
• 是否删掉了“需要吗、会用吗、喜欢吗、是不是因为”等诱导句。
• 是否标注了哪些历史反馈是原话，哪些只是团队判断。
• 是否提醒参会同事不要在访谈中解释功能、推销方案或承诺交付。

这个输出样例还需要人工删减和调整。比如如果你的受访者不是销售主管，而是一线销售，就要把“主管看板”和“向老板解释异常”的问题换成一线销售真实任务；如果你的核心功能只有一个，就不要保留三条功能线索，避免访谈太散。

人工验收

人要怎么检查和改到可用

AI 生成的提纲不能直接照读。访谈提纲的质量，取决于人工是否把问题压到足够具体、足够中性、足够能追问。

第一，检查每个问题是不是能让用户讲出一次真实经历。凡是用户可以只回答“需要”“不需要”“会”“不会”“还行”的问题，都要重写。好问题通常会包含“最近一次”“当时”“怎么做”“谁参与”“后来发生什么”“你怎么判断”。

第二，检查功能概念是否出现太早。如果开场 10 分钟内就问功能，用户会被你的产品想法带着走。更稳妥的顺序是先听任务和现有方法，再听触发原因和后果，最后才用中性方式探测功能概念。

第三，检查是否把团队假设写成了事实。比如“用户因为 CRM 字段不准，所以需要自动标签”只是团队假设。提纲里应该写成：“当你发现 CRM 字段和实际情况不一致时，你会怎么处理？”让用户讲出事实，再由团队后续分析。

第四，检查问题数量。45 分钟访谈不要超过 12 个主问题。一个好问题追下去可能要 5 分钟，如果提纲有 30 个问题，访谈者就会为了赶进度跳过追问，最后只得到表面答案。

第五，检查角色匹配。创业团队负责人、销售主管、一线销售、销售运营看到的任务不一样。不要用同一份提纲问所有人。可以保留同一个访谈目标，但要调整问题的语言和顺序。

第六，检查参会人员边界。老板、销售、研发旁听访谈时，很容易忍不住解释“我们这个功能其实可以解决”。提纲里要写清：访谈中不要推销，不要辩解，不要承诺排期，不要把用户的随口表态当成立项依据。

第七，检查输出是否仍然是提纲。AI 有时会顺手写“因此建议优先做自动标签”或“产品方案可以分三期”。这类内容要删掉。本文的产物是场景型用户访谈提纲，不是访谈分析报告，也不是产品路线图。

失败反例

这些失败反例要提前避开

【反例 1：把功能清单包装成礼貌问卷】

错误写法：

这类问题看起来清楚，实际信息量很低。用户可以很快回答“需要”“有帮助”“看情况”，但团队无法知道用户现在如何完成任务、问题何时发生、现有方法为什么不够、什么标准下才会采用新方法。

修改方向：先问真实任务，再问现有替代方案，最后才做功能概念探测。比如把“你需要客户标签自动分组吗”改成“最近一次你需要判断客户优先级时，具体看了哪些信息？哪些信息需要临时确认？”

【反例 2：用“是不是因为”把团队答案塞给用户】

错误写法：

这类问法会让用户顺着你的解释回答。就算用户说“对”，你也不知道这是他们真实经历，还是他们觉得你的说法也有道理。它验证的不是需求，而是你的表述能力。

修改方向：把原因拆开问。比如“上次字段不准确是在什么情况下发现的？”“你当时怎么补充信息？”“如果没有补充，会影响什么判断？”让用户自己讲出原因链。

【反例 3：太早展示功能概念，导致访谈变推销】

错误写法：

这类问题会让用户开始评价你的方案，而不是回忆自己的工作。尤其当提问者是创始人或产品负责人时，用户可能会照顾你的期待，说一些不够真实的正面评价。

修改方向：先问“你现在如何判断优先级”，再问“你如何判断一个推荐是否可信”。如果确实要展示概念，也要放在后半段，并提醒用户可以直接指出不可信、不适用或不愿意用的地方。

【反例 4：把竞品线索变成竞品评价会】

错误写法：

这会把访谈带到功能对比和主观评价上。用户可能会说出一些有趣意见，但你很难判断它们和真实任务有什么关系。

修改方向：围绕替代方案问。比如“你们用过自动评分时，哪些结果会被主管采纳？”“哪些结果需要人工复核？”“有没有出现过评分看起来高，但销售实际判断不该跟的情况？”

【反例 5：访谈结束后马上让 AI 给产品方案】

错误写法：

这超出了本文产物边界。提纲设计只负责让访谈更开放、更可追问。访谈完成后，还需要整理记录、区分事实和解释、比较不同用户之间的模式，再进入需求判断。让 AI 在访谈前就给方案，很容易把团队再次带回“证明自己想做的功能”。

修改方向：把提纲、记录、分析和方案分成不同步骤。本文只完成第一步：生成场景型用户访谈提纲。

1. 你需要客户标签自动分组吗？
2. 你觉得审批提醒有帮助吗？
3. 你希望数据看板展示哪些指标？
4. 如果这些功能上线，你会使用吗？

你们是不是因为 CRM 字段不准确，所以才希望系统自动打标签？
你们是不是因为审批流程太长，所以需要超时提醒？
你是不是觉得现在的看板不够直观？

我们准备做一个智能客户优先级推荐，它会综合客户行业、金额、互动频率和成交阶段。你觉得这个功能怎么样？

你觉得竞品 A 的自动评分好不好？
你希望我们比竞品多做哪些功能？
竞品有哪些地方不如我们？

根据这份提纲和访谈目标，请直接给出功能优先级和产品方案。

主题边界

它和相邻主题的区别

这篇文章关注“访谈前的问题设计”。它的交付物是一份场景型用户访谈提纲，帮助团队把功能清单改写成任务、场景、触发原因、替代方案和决策标准相关的开放问题。

它不同于“访谈前背景和假设简报”。那类内容重点是整理客户资料、使用数据、销售备注和待验证假设，让参会团队在访谈前统一上下文；本文假设你已经知道要验证哪些功能点，重点是把这些功能点改成不诱导用户的提问顺序和追问方式。

它也不同于“访谈数据分析”。本文不处理录音、纪要、标签、洞察归纳或证据权重，不判断某个功能是否应该做。访谈数据分析要在访谈完成后进行，需要比较多位用户的回答和行为证据。

它更不同于“产品方案设计”。本文不会输出需求文档、原型结构、功能优先级或路线图。即使 AI 输出样例里出现了功能概念探测，也只是为了设计问题，让用户讲出评估标准，而不是让 AI 替团队定方案。

所以，这篇的差异化很明确：当团队已经拿着一串想问用户的功能点时，先用它把“要不要功能”的封闭问题，改成一份能进入真实工作场景的访谈提纲。