客户访谈前，先用 AI 对齐背景、假设和追问边界

教程定位

这篇教程解决什么问题

客户访谈最怕的不是问题少，而是团队带着彼此矛盾的理解进会议室：销售以为客户最关心续费，产品以为客户卡在功能上，研究员以为这次是探索场景，会议一开始就各问各的。更糟的是，有人把销售备注里的判断当成事实，直接问出“你们是不是因为审批太复杂才不用”的诱导式问题，客户只能顺着回答，最后拿到一堆看似明确、实际偏掉的结论。

这篇文章解决的是访谈前 30 到 60 分钟的准备工作：把客户背景、当前使用情况、已知事实、待验证假设、不能诱导的问题边界整理成一份访谈准备简报。AI 在这里的价值不是替团队下结论，而是帮你把散落在客户资料、CRM 记录、产品使用数据、销售备注和访谈目标里的信息分层：哪些是事实，哪些只是销售或团队的观察，哪些可以变成开放式问题，哪些必须暂时放下，等客户自己讲出来。

完成后，你会得到一份可带进访谈会前会的简报，包括客户基本背景、产品使用阶段、信息可信度、核心假设、开放式追问、敏感问题提醒和团队分工。它聚焦访谈前准备，不处理访谈后的归因、结论分析或产品决策。

使用场景

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

你可能是产品经理，也可能是用户研究员。今天下午销售临时约到一个重要客户，对方愿意给 45 分钟聊使用体验。你手上有几份材料：客户官网介绍、CRM 里的商机记录、最近 30 天的产品使用数据、销售同事的备注，以及老板刚发来的“这次一定要搞清楚为什么用不起来”。

问题是，大家对这次访谈的理解并不一致。销售说客户“应该是觉得配置麻烦”；客户成功说“他们内部推不动”；产品研发看数据后觉得“可能是权限链路太长”；你自己则担心团队已经提前把答案写好了。访谈还没开始，会议纪要的结论就像已经排好了队。

这时需要做的不是让 AI 直接生成一套访谈问题，也不是把所有材料压缩成一页漂亮摘要。更好的做法是先让 AI 帮你拆分材料：事实归事实，线索归线索，假设归假设。尤其要提醒 AI，不要把销售备注当事实结论，不要把使用数据直接解释成用户动机，不要写“是不是因为……”这类会把答案塞进问题里的句子。

这份准备简报适合以下情况：

它不适合用来替代正式研究方案，也不适合在访谈后直接生成结论报告。如果访谈目标涉及价格承诺、合同谈判、医疗法律等高风险判断，AI 只能帮你整理信息，最终口径必须由负责人复核。

• 团队临时约到客户，准备时间短，但输入材料比较杂。
• 多个角色都会参加访谈，需要先统一背景和提问边界。
• 客户处在试用、续费、流失预警、扩容评估等关键阶段，团队容易带着商业压力提问。
• 你希望访谈问题开放，而不是把内部猜测包装成客户问题。
• 你需要在访谈前明确哪些问题可以问，哪些只能观察，哪些要避免诱导。

材料准备

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

在让 AI 工作前，先把材料按来源整理出来。不要一股脑粘进去，因为材料混在一起时，AI 很容易把“销售判断”“客户原话”“系统数据”“团队猜测”写成同一种确定语气。

建议准备五类输入。

第一类是客户资料。包括公司规模、行业、地区、业务模式、采购或使用部门、已知组织结构。如果信息来自官网、新闻稿或公开介绍，要标清来源。公开介绍通常会强调客户想展示的一面，不一定等于真实工作方式。

第二类是 CRM 记录。包括客户阶段、商机状态、合同金额区间、联系人角色、最近沟通时间、客户提出过的需求或异议。CRM 里的字段通常比较结构化，但也可能带有销售视角，比如“客户意向强”“老板很重视”。这类内容可以作为访谈线索，不能直接当事实。

第三类是产品使用数据。包括登录频率、关键功能使用次数、配置完成率、活跃成员数、最近一次使用时间、异常中断点。数据只能说明发生了什么，不能自动说明为什么。例如“连续 14 天没有创建新项目”可能是暂时没需求，也可能是配置卡住，还可能是用户改用别的工具。

第四类是销售备注和客户成功备注。这类材料最有现场感，也最容易误导。备注里常见“客户嫌麻烦”“客户不认可价值”“客户觉得太贵”“客户内部推不动”等表达。写入简报时必须降级为“待验证线索”，并且转成开放式问题，例如“你们当时推进到这一步后，接下来发生了什么？”

第五类是本次访谈目标。目标要写成这次要理解的工作问题，而不是想证明的结论。比如“理解试用客户从开通到首次完成配置的真实阻碍”比“证明配置流程太复杂”更好；“了解客户内部如何决定是否继续使用”比“确认客户是不是因为价格不续费”更好。

在提交给 AI 前，最好把敏感信息脱敏。公司名、联系人姓名、电话、合同金额、内部报价、真实账号 ID 都可以替换成代号。示例里使用虚构客户，不代表任何真实公司。

实操流程

按这套步骤把工作跑起来

第一步，先让 AI 做“材料分层”，不要马上生成问题。你可以要求 AI 把输入拆成四栏：已确认事实、行为数据、主观备注、待验证假设。这样做的目的，是防止它过早把材料写成一个顺滑故事。顺滑不等于准确，尤其在访谈准备里，过于顺滑的故事会让团队误以为自己已经理解客户。

第二步，要求 AI 标出每条信息的来源和可信度。可信度不是判断真假，而是提醒团队这条信息能被怎样使用。例如“近 30 天只有 2 名成员登录”来自产品后台，可信度高，可以用于描述行为；“客户觉得配置麻烦”来自销售备注，可信度中，只能作为追问线索；“客户没有价值感”来自团队推测，可信度低，不能直接出现在问题里。

第三步，把内部猜测改写成可验证假设。一个合格的假设应该包含三部分：可能发生的用户处境、需要验证的机制、访谈中可观察或可追问的信号。比如“客户配置卡住”太粗；改成“客户可能在首次配置角色权限时，需要跨部门确认权限边界，因此配置动作被推迟。需要验证：他们是否遇到权限责任不清、审批等待或担心误操作的问题。”

第四步，把假设转成开放式问题。开放式问题不是更客气的封闭问题，而是不给客户预设答案。不要问“是不是因为审批流程太复杂，所以你们没有继续配置？”可以问“上次配置停在权限设置后，你们内部接下来发生了什么？”不要问“你们觉得这个功能价值不明显吗？”可以问“你们当时期待这个功能帮你完成什么工作？后来实际用起来和预期有什么差别？”

第五步，列出追问边界。访谈前要明确哪些词不能问，哪些判断不能说，哪些问题要等客户自己提到后再追问。例如销售备注里写“老板不支持”，访谈时不能直接问“你们老板是不是不支持？”更稳妥的问法是“这个工具在团队内部推进时，通常需要哪些人参与决定？”如果客户主动提到负责人没有批准，再追问“当时负责人主要顾虑是什么？”

第六步，把简报压缩成访谈前能用的格式。参会人不需要读一篇长报告。他们需要知道：客户是谁，现在用到哪一步，我们知道什么但不知道为什么，这次最重要的 3 到 5 个假设是什么，每个假设对应哪些开放式问题，哪些问法会诱导客户，谁负责主问，谁负责记录。

第七步，人工复核。AI 生成后，产品经理或研究员必须逐条检查：有没有把销售备注写成事实，有没有把数据解释成动机，有没有出现“是不是”“你是否同意”“能不能证明”这类诱导语气，有没有把访谈目标写成销售推进话术。复核后，才可以发给参会团队。

输入示例

可以直接参考的输入材料

下面是一份可以直接粘给 AI 的材料样例。真实使用时请脱敏，并保留来源标签。

这个输入样例的关键不是材料多，而是每段都带来源。你给 AI 的来源越清楚，它越容易在输出中保留边界；你给 AI 的材料越像一段已经下结论的故事，它越可能顺着故事继续编。

【本次访谈目标】
希望在 45 分钟客户访谈中，理解客户试用 21 天后仍未完成“部门权限配置”和“首个自动化流程发布”的原因。我们不希望直接问客户“是不是太复杂”，而是想了解他们实际推进过程、参与角色、卡点和下一步预期。

【客户资料】
客户代号：A 客户
行业：连锁职业教育
规模：约 80 家校区，总部 300 人左右，一线校区员工约 2500 人
主要业务：线下培训课程、企业内训、学员转化和续课
购买/试用部门：总部运营数字化小组
访谈对象：
- 王老师，运营数字化负责人，本次试用发起人
- 李老师，区域运营主管，参与过一次流程配置
- 赵老师，校区教务主管，最终使用者之一

【CRM 记录】
试用开始日期：2026-06-03
当前阶段：试用中，预计 2026-07-05 前决定是否进入采购评估
销售记录：
- 2026-06-10：客户希望先跑通“校区异常工单自动提醒”
- 2026-06-17：客户反馈总部和校区权限边界比较敏感
- 2026-06-24：销售备注“客户觉得配置成本偏高，可能没有足够动力继续推”
- 2026-06-29：销售备注“王老师说老板最近关注降本增效，但不一定愿意投入新系统”

【产品使用数据，最近 30 天】
- 已创建组织架构：总部 1 个，区域 5 个，校区 12 个，未覆盖全部校区
- 已邀请成员：18 人，其中近 7 天活跃 5 人
- 部门权限配置：创建过 3 次草稿，均未发布
- 自动化流程：创建过 2 个流程草稿，未发布
- 帮助文档访问：权限配置文档访问 9 次，自动化流程文档访问 3 次
- 最近一次关键操作：2026-06-25 17:40，李老师打开权限配置页面后退出

【客户成功备注】
- 客户成功同事认为客户内部角色多，可能需要总部、区域、校区多方确认
- 客户成功同事提醒：不要在访谈里直接说“你们内部协作效率低”
- 上次演示时，赵老师比较关注“校区能不能只看到自己的工单”

【产品团队已有猜测】
- 猜测 1：权限配置对连锁校区客户来说太抽象，导致他们不敢发布
- 猜测 2：试用发起人和实际使用者目标不同，所以流程推进慢
- 猜测 3：客户可能只是想了解方案，不一定真的要在试用期跑通
- 猜测 4：销售认为客户可能觉得价值不足，但目前没有客户原话支持

【希望输出】
请生成一份访谈准备简报，用于访谈前团队对齐。必须区分事实、备注、假设和开放式问题。不要把销售备注当事实结论。所有访谈问题都要开放，不要诱导用户。

提示词

可复制使用的提示词

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

如果你希望输出更短，可以把结构改成“一页版”。但不要删掉“信息分层表”和“禁止诱导式问法”，因为这两项正是防止访谈跑偏的保护栏。

你是一名谨慎的用户研究访谈准备助手。请根据我提供的客户资料、CRM 记录、产品使用数据、销售/客户成功备注和本次访谈目标，生成一份“访谈准备简报”。

重要原则：
1. 不要把销售备注、客户成功备注、团队猜测当成事实结论。
2. 产品使用数据只能说明行为发生了什么，不能直接推断用户动机。
3. 访谈问题必须开放，不能诱导用户回答预设答案。
4. 不要使用“是不是因为”“是否说明”“你们是不是觉得”“能不能证明我们判断”这类问法。
5. 如果某条信息只能作为线索，请明确标注“待验证”。
6. 输出用于访谈前准备，不要生成访谈后结论，不要替团队做采购、续费或产品优先级决策。

请按以下结构输出：

A. 一页版访谈背景摘要
- 客户基本背景
- 当前使用阶段
- 已知行为事实
- 目前最不确定的地方

B. 信息分层表
请用表格列出：信息、来源、类型（事实/行为数据/主观备注/团队猜测/待验证假设）、可用于访谈的方式、不能怎么用。

C. 待验证假设清单
每条假设包含：
- 假设内容
- 为什么值得验证
- 支持线索
- 反向可能性
- 推荐开放式问题
- 禁止的诱导式问法

D. 访谈问题建议
按访谈顺序给出 8-12 个开放式问题，分为开场、过程回溯、角色协作、卡点澄清、下一步预期。每个问题后说明它验证哪个假设。

E. 追问边界和风险提醒
列出哪些说法不能直接问，哪些销售备注不能当事实，哪些问题需要等客户主动提到后再追问。

F. 参会团队分工建议
给出主问、补充追问、记录、销售旁听的建议，并提醒销售不要在研究访谈中抢先解释或推进成交。

这是输入材料：
[粘贴客户资料、CRM 记录、产品使用数据、销售备注、客户成功备注、本次访谈目标]

输出样例

AI 应该输出到什么程度

以下是使用上面输入样例后，AI 可能生成的一份初稿。注意：这是访谈前准备材料，不是客户真实结论。

# A 客户访谈准备简报

教程正文

A. 一页版访谈背景摘要

客户 A 是连锁职业教育客户，由总部运营数字化小组发起试用，涉及总部、区域和校区多层级角色。客户希望先跑通“校区异常工单自动提醒”，目前试用 21 天，尚未完成部门权限配置和首个自动化流程发布。

已知行为事实包括：客户已创建部分组织架构，邀请 18 名成员，近 7 天活跃 5 人；权限配置创建过 3 次草稿但均未发布；自动化流程创建过 2 个草稿但未发布；权限配置文档被访问 9 次。以上只能说明客户在权限和流程配置处有多次尝试，不能直接说明客户认为产品复杂或价值不足。

目前最不确定的地方是：权限配置未发布的原因、总部/区域/校区之间的决策和协作方式、试用发起人与实际使用者目标是否一致、客户对试用期内“跑通”的定义，以及采购评估前他们需要看到什么结果。

教程正文

B. 信息分层表

| 信息 | 来源 | 类型 | 可用于访谈的方式 | 不能怎么用 | |---|---|---|---|---| | 客户有总部、区域、校区多层级组织 | 客户资料 | 背景事实 | 询问不同层级在流程中的职责 | 不能直接判断组织复杂导致推进慢 | | 权限配置创建 3 次草稿但未发布 | 产品使用数据 | 行为数据 | 回溯最近一次配置过程 | 不能直接说客户“不会用”或“嫌麻烦” | | 权限配置文档访问 9 次 | 产品使用数据 | 行为数据 | 询问查文档时想解决什么问题 | 不能推断文档一定不清楚 | | “客户觉得配置成本偏高” | 销售备注 | 主观备注/待验证线索 | 转成关于推进成本的开放追问 | 不能当作客户原话 | | “老板可能不愿意投入新系统” | 销售备注 | 主观备注/待验证线索 | 询问内部评估通常需要哪些人参与 | 不能直接问老板是否不支持 | | 赵老师关注校区只能看到自己的工单 | 客户成功备注 | 现场观察线索 | 询问校区角色的数据可见范围需求 | 不能直接推断权限模型不满足 | | 团队猜测价值不足 | 产品团队猜测 | 团队猜测 | 暂时作为低优先级验证方向 | 不能在访谈中直接问“是不是价值不足” |

教程正文

C. 待验证假设清单

【假设 1：权限配置未发布，可能与多层级职责确认有关】

为什么值得验证：客户组织包含总部、区域、校区，销售记录提到权限边界敏感，产品数据中权限配置多次创建但未发布。

支持线索：权限草稿 3 次未发布；权限文档访问 9 次；赵老师关注校区可见范围。

反向可能性：未发布也可能是试用负责人暂时没有时间、试用目标变化、只是在演示环境探索，或团队已经用其他方式解决。

推荐开放式问题：

禁止的诱导式问法：

【假设 2：试用发起人和实际使用者对成功标准可能不同】

为什么值得验证：试用由总部运营数字化小组发起，但最终使用者包括区域运营和校区教务，且不同角色关注点不同。

支持线索：王老师为试用发起人，李老师参与配置，赵老师关注校区可见范围。

反向可能性：三类角色可能目标一致，只是访谈材料没有记录完整；也可能当前未发布主要因为时间安排，而非目标分歧。

推荐开放式问题：

禁止的诱导式问法：

【假设 3：客户对试用期内要跑通什么，还没有形成共同定义】

为什么值得验证：CRM 显示客户希望跑通异常工单提醒，但产品数据中流程仍停留在草稿状态。

支持线索：2 个自动化流程草稿未发布；试用期临近采购评估；关键动作停在配置页面。

反向可能性：客户可能已经在线下完成评估，不需要在系统里发布；也可能他们只是在等待内部数据或人员名单。

推荐开放式问题：

禁止的诱导式问法：

• “你们上次配置权限时，通常会先确认哪些角色能看到哪些信息？”
• “从创建权限草稿到决定是否发布，中间需要哪些人参与？”
• “你们看到权限配置页面时，最需要先弄清楚的是什么？”
• “是不是因为权限配置太复杂，所以你们不敢发布？”
• “你们是不是内部审批太慢？”
• “这次试用在总部、区域和校区三个层面，各自最希望看到什么结果？”
• “如果要判断这个流程值得继续推进，你们会看哪些信号？”
• “校区老师第一次使用时，最希望系统先帮他们减少哪类工作？”
• “你们是不是总部想推，但校区不想用？”
• “是不是实际使用者没有动力？”
• “你们最初说想跑通异常工单自动提醒时，心里预期的完整过程是什么样的？”
• “目前已经完成的部分里，哪些让你们觉得接近目标？哪些还没有？”
• “如果试用结束前只能验证一件事，你们最想验证什么？”
• “是不是因为流程配置太麻烦，所以没有发布？”
• “你们是不是还没看到价值？”

教程正文

D. 访谈问题建议

1. “我们先对齐一下，这次试用最初是从哪个具体业务问题开始的？”用于了解初始任务，不预设原因。
2. “从 6 月初开通到现在，你们内部大概经历了哪些推进步骤？”用于回溯真实过程。
3. “在总部、区域、校区之间，谁通常会参与流程和权限的确认？”用于理解角色协作。
4. “你们创建权限草稿时，当时想先解决哪类可见范围或责任边界问题？”用于验证权限假设。
5. “上次打开权限配置页面后，接下来发生了什么？”用于回到行为现场。
6. “你们查看帮助文档时，主要是在找哪类答案？”用于理解文档和配置认知。
7. “如果一个校区老师开始使用这个流程，他最担心或最期待的地方可能是什么？”用于理解最终用户视角。
8. “现在还没有发布流程草稿，背后有哪些待确认事项？”用于澄清卡点。
9. “采购评估前，你们希望看到什么结果，才会觉得试用是有效的？”用于理解下一步标准。
10. “还有哪些我们没有问到、但会影响你们继续推进的因素？”用于开放收尾。

教程正文

E. 追问边界和风险提醒

• 不要把“客户觉得配置成本偏高”说成客户原话，应改为询问“你们推进配置时，投入最多的是哪一部分时间或沟通？”
• 不要直接问“老板是不是不支持”，应先了解内部评估流程和参与角色。
• 不要直接问“是不是价值不足”，可以问“你们希望看到哪些变化，才会觉得这个工具值得继续投入？”
• 不要用产品后台数据质问客户，例如“你们为什么 6 月 25 日打开页面后退出？”更合适的问法是“我们看到最近一次配置停在权限页面，方便回忆一下当时的情境吗？”
• 如果客户主动提到审批、预算、老板态度，再顺着追问具体过程；如果客户没有提到，不要把销售备注里的判断强塞进问题。

教程正文

F. 参会团队分工建议

• 主问：用户研究员，负责保持问题开放，控制节奏。
• 补充追问：产品经理，围绕权限、流程发布和角色协作补充事实问题。
• 记录：客户成功，记录客户原话、行为过程和未验证假设，不写过度结论。
• 旁听：销售可以补充背景，但不建议在研究访谈中推进成交、解释价格或替客户回答。

这份输出样例已经把“客户觉得配置成本高”“老板可能不愿意投入”等备注降级为待验证线索。真正访谈时，团队还要根据客户现场回答继续追问，不能拿样例问题逐字机械朗读。

人工验收

人要怎么检查和改到可用

AI 生成的访谈准备简报必须人工检查。你可以按下面的顺序改。

第一，检查事实和备注有没有混在一起。凡是来自 CRM 的结构化字段、产品后台数据、客户原话，可以保留较确定的描述；凡是来自销售判断、客户成功感受、团队猜测，都要写成“线索”“可能”“待验证”。如果 AI 写出“客户认为配置成本高”，你要改成“销售备注显示客户可能关注配置投入，需在访谈中验证”。

第二，检查有没有把数据解释成动机。比如“权限文档访问 9 次”只能说明客户访问过文档，不能直接写成“客户看不懂权限配置”。你可以让问题回到当时动作：“你们查看文档时，主要想确认什么？”这样既使用了数据，又没有替用户解释原因。

第三，检查问题是否开放。诱导式问题常常有几个信号：以“是不是”开头；把内部猜测塞进问题；让客户在两个坏选项里选一个；用“你们是否认可我们的判断”这种确认式语言。开放式问题通常要求客户描述过程、回忆场景、解释决策、比较预期和实际。

第四，检查有没有商业压力污染研究问题。如果本次访谈和续费、采购评估有关，团队很容易问出“要怎样你们才会买”或者“现在不推进的最大阻力是不是预算”。这些问题不是完全不能问，但它们属于销售或商业沟通，不应替代用户研究中的行为回溯。访谈准备简报要把研究问题和销售推进问题分开。

第五，检查是否给每个假设留了反向可能性。没有反向可能性的假设，很容易变成结论。例如“客户权限配置卡住”至少要保留几种反向可能：客户只是试用环境探索、当前业务暂缓、负责人出差、线下已经达成共识但系统未同步、客户其实没有权限问题而是缺少流程模板。

第六，检查追问边界是否足够具体。不要只写“避免诱导”，要写清楚哪些句子不能说，以及替代问法是什么。比如不能问“你们是不是内部协作效率低”，替代为“这个流程从总部到校区推进时，通常会经过哪些沟通环节？”不能问“老板是不是不支持”，替代为“这类系统进入采购评估前，通常需要哪些角色参与判断？”

第七，检查参会分工是否保护访谈质量。销售可以提供背景，但不应在客户回答前替客户解释；产品经理可以追问具体功能场景，但不应急着介绍方案；记录人要区分客户原话和自己的解释。会前最好约定一个提醒机制：一旦有人问出诱导式问题，主问可以温和地把问题拉回开放回溯。

第八，检查简报是否足够短。准备简报不是研究报告。访谈前团队真正会看的内容应该是一页摘要、三到五个核心假设、十个以内的主问题和明确的禁止问法。长材料可以作为附录，但不要让参会人临场翻找重点。

失败反例

这些失败反例要提前避开

反例一：把销售备注当事实。

错误写法：“客户觉得配置成本偏高，所以本次访谈要确认他们为什么嫌麻烦。”

问题在于，“配置成本偏高”来自销售备注，不一定是客户原话，也不一定代表真实原因。更好的写法是：“销售备注提到客户可能关注配置投入，本次需通过过程回溯验证他们在哪些环节投入了时间、沟通或决策成本。”

反例二：把行为数据直接解释成心理动机。

错误写法：“客户 3 次创建权限草稿都没有发布，说明他们不敢使用权限功能。”

数据只能说明草稿未发布，不能说明“不敢”。更好的追问是：“你们创建权限草稿后，通常还需要确认哪些事项，才会决定发布？”

反例三：问题里提前塞答案。

错误写法：“你们是不是因为权限配置太复杂，所以一直没有发布？”

这会把客户推向“复杂”这个答案。更好的问法是：“上次权限配置停在草稿后，接下来发生了什么？”如果客户自己提到复杂，再追问复杂在哪里。

反例四：用商业目标替代研究目标。

错误写法：“本次访谈要搞清楚客户怎样才会采购。”

这会让访谈变成销售推进，客户也可能进入谈判状态。更好的研究目标是：“理解客户在试用期内如何判断这个流程是否值得继续推进，以及哪些结果会影响采购评估。”

反例五：把团队猜测包装成客户问题。

错误写法：“由于试用发起人和实际使用者目标不同，访谈要重点问校区为什么不配合。”

这里的“目标不同”和“不配合”都没有被验证，而且语气带有责备。更好的写法是：“需要了解总部、区域、校区在本次试用中的目标和职责是否一致，以及推进过程中各自承担了哪些动作。”

反例六：只生成问题清单，不生成背景对齐。

错误写法：直接给出 20 个访谈问题，没有说明客户是谁、用到哪一步、哪些信息可信、哪些是假设。

这样参会人仍然可能各按各的理解追问。访谈准备简报必须先对齐背景，再给问题。问题是服务假设的，不是孤立存在的。

反例七：追问边界写得太空。

错误写法：“注意不要诱导客户，保持客观。”

这句话正确但没法执行。更好的写法是列出具体禁句和替代问法，例如“不要问‘老板是不是不支持’，改问‘这类工具进入评估时通常需要哪些人参与判断？’”

反例八：让 AI 直接判断客户是否会续费。

错误写法：“请根据这些材料判断客户续费概率，并给出下一步销售策略。”

这超出了访谈准备简报的边界。AI 可以整理风险线索和待验证问题，但不能替团队做商业判断，更不能把未验证备注变成客户结论。

反例九：把问题写成审问。

错误写法：“为什么你们 6 月 25 日打开权限页面后又退出？当时是谁没有推进？”

这会让客户防御。更好的问法是：“我们看到最近一次配置停在权限页面，方便一起回忆一下当时你们想完成什么、后来为什么先停下来吗？”

反例十：忽略实际使用者。

错误写法：“只访谈试用发起人，围绕采购评估问完即可。”

如果最终使用者是校区教务或区域运营，只问发起人可能错过真实工作流。准备简报应标注不同角色的已知信息和待问问题，避免把一个人的看法当成组织结论。

主题边界

它和相邻主题的区别

这篇文章只处理访谈前准备，核心产物是一份“访谈准备简报”：它帮助团队在访谈开始前对齐客户背景、材料来源、待验证假设、开放式问题和追问边界。

它不是“访谈问题库”文章。问题库通常围绕某类通用场景给出可复用问题，而这篇强调从具体客户材料出发，把 CRM、使用数据和备注拆成事实与假设，再为本次访谈生成问题。

它不是“访谈纪要整理”文章。纪要整理发生在访谈之后，需要从客户原话中提炼发现、证据和下一步动作；本篇不处理访谈后分析，也不把假设验证结果写成结论。

它也不是“销售续费风险分析”文章。虽然输入里可能包含续费、采购评估、销售备注，但本文不会让 AI 判断客户会不会买、该怎么推进成交，而是提醒团队在研究访谈中避免商业压力带来的诱导。

它更不是“产品数据归因分析”文章。产品使用数据在这里只是访谈准备线索，用来帮助回溯具体行为现场；真正原因必须通过开放式访谈验证，不能由后台数据单独得出。

最重要的边界是：访谈前可以有假设，但不能带着答案去找客户确认。AI 可以帮你把假设写清楚，也可以帮你把诱导式问法改成开放式问题；但它不能替客户说话，不能替团队下结论，不能把销售备注包装成事实。只要守住这条线，临时约来的客户访谈也能从“大家各问各的”变成一次有准备、有边界、能听见真实过程的对话。