在实际做产品的过程中客户发现Customer Discovery往往比功能开发更早决定项目生死。它的目标不是问用户“你想要什么”而是验证“我们假设谁需要、为什么需要、愿意付出什么成本”这些前提是否成立。很多团队的问题不是不重视访谈而是整个流程太依赖人的经验和手工整理访谈提纲临时拼凑记录散在笔记里几十条反馈无法横向对比最后只得出“用户好像都需要”这种没有信息量的结论。Grok Bot 这类 AI 助手可以在流程里承担“思考伙伴和文本处理器”的角色把访谈前的准备、访谈后的整理和分析压缩到几十分钟内完成。这篇文章以“Grok Bot 简单实用的客户发现方法”为主线先讲 Grok Bot 在客户发现流程中的定位和边界再给出一套完整的五环节工作流然后逐个环节给出提示词、输出模板、结构化表和落地路径。文章会覆盖如何生成用户画像、如何设计访谈提纲、如何把口语化记录整理成结构化数据、如何沉淀到数据库并补充常见问题和最佳实践。读完可以直接按这套思路开展一次真实的客户访谈计划而不是停留在“用 AI 聊天”的层面。1. 先明确 Grok Bot 在客户发现流程中的定位1.1 客户发现的两条核心原则验证而非收集客户发现不是传统的市场调研。市场调研统计“有多少人想要 A 功能”客户发现则要求验证一条具体的假设例如“小微店主愿意每周花 30 分钟用自动记账工具来减少月底报税时的反复核对”。在一个完整的客户发现周期里真正要拿到的是三类证据用户身份访谈对象是谁是否属于目标用户。痛点场景用户在什么场景下遇到问题付出过什么成本。付费意愿和替代方案用户现在用什么办法解决是否愿意为了改变它付出金钱或时间。如果只问“你需要这个功能吗”得到的基本都是礼貌性肯定。客户发现要求把问题落到具体场景、具体频率和具体代价上这需要一套结构化的提问和记录方法。1.2 Grok Bot 适合做什么不适合做什么Grok Bot 是 xAI 推出的对话式 AI 助手擅长多轮对话、长文本分析、结构化输出和意图归纳。它在客户发现中的价值集中在三类任务生成草稿根据产品构想生成用户假设、访谈提纲、问卷初稿。整理文本把一段口语句子整理成“用户身份、痛点、现有方案”等字段。聚类归纳把几十条反馈按主题聚类并标注证据强度。但它有明显的边界不能替代真实用户访谈。AI 无法替你接触用户也无法保证它生成的用户特征描述来自真实市场。不能确认事实。Grok 可能编造用户原话或引用凡是涉及真实证据的内容必须人工核对。不能替代商业判断。最终的“验证通过/推翻”必须由人来做AI 只提供证据组织方式。因此在整条流程里Grok Bot 是“加速器”不是“决策者”。所有 AI 输出都要经过人工复核。1.3 五环节工作流总览为了让 Grok Bot 真正可用可以把客户发现拆成五个可重复执行、可单独验收的环节环节输入输出人工把关点1. 生成用户假设产品构想一句话5 类目标用户、待验证假设清单确认人群与业务相关2. 设计访谈提纲目标用户特征分场景的开放性问题清单剔除引导性问题3. 访谈记录整理原始访谈文本统一字段的结构化记录核对原话与摘录4. 痛点聚类多条结构化记录聚类主题、关键词、证据强度判断聚类是否合理5. 生成验证任务聚类结果下一步访谈或实验任务排定优先级这条主线的关键设计原则是每一环节的输入和输出都是结构化的Grok 只负责处理中间过程人负责判断两头。这样即使 AI 偶尔给出有偏差的回答也可以快速定位出错在哪一步。2. 第一个环节用 Grok 生成目标用户画像和待验证假设2.1 提示词的基本结构用 Grok 做客户发现时提示词质量决定输出质量。一个清晰的提示词至少包含四个部分角色让 Grok 明确自己站在什么视角。上下文产品构想、目标市场、已掌握的限制条件。任务要生成什么数量要求是什么。输出格式要求用标题、列表、表格或 JSON 输出。常见建议是提供“一句话产品构想”越具体越好。例如“为小微企业提供自动记账和税务提醒工具”就比“做企业服务”准确得多。2.2 画像生成示例下面是一个可以直接复制的提示词示例你是一名专注早期产品验证的顾问。请基于以下内容生成客户发现计划 产品构想为个体户和小微企业提供自动记账和税务提醒工具。 产品定位重点解决月末对账和报税截止日期遗忘的问题。 尚未验证的核心假设小微经营者最需要的是节省记账时间 而不是记账精度。 请输出 1. 5 类最值得访谈的目标用户每类用一段话描述身份、工作场景和痛点。 2. 每类用户身上最值得优先验证的一个假设。 3. 每类用户建议优先访谈的 3 个问题。 4. 你认为最值得先启动访谈的一类用户并说明理由。 输出格式用 Markdown 标题分层假设用表格列出。这个提示词的关键在于同时给出了“产品构想”和“尚未验证的假设”。如果不给假设Grok 只会泛泛罗列人群给了假设它才能围绕验证目标来组织问题。2.3 把假设变成可验证的清单生成结果后需要人工整理成一张“假设验证清单”。典型的字段包括字段说明示例假设编号方便后续引用H-01假设内容必须可验证小微店主每周至少花 2 小时做手工对账目标人群假设对谁成立月流水 5 万到 50 万的个体户验证方式访谈、问卷、实验10 次目标用户访谈验证标准多少证据算通过至少 7 人明确提到对账耗时和报错验证结论通过/推翻/待定待启动这里要注意一个常见坑不要用 Grok 生成用户描述就把它当成真实的用户原话。Grok 生成的是“推理草稿”只能帮你设计方案不能帮你证明假设成立。把验证标准写清楚比多生成几轮画像更重要。3. 第二个环节设计访谈提纲和问卷3.1 用 Grok 生成访谈提纲初稿访谈提纲的核心是“让用户讲具体事件”而不是“让用户做产品评审”。好的访谈问题通常是开放式的例如你最近一次核对账目是什么时候当时花了多久报税截止日前你会做哪些准备哪些环节最容易出错如果这个工具能自动识别票据你最担心什么可以让 Grok 基于上一环节的目标用户生成完整提纲请为下面的目标用户设计一份 30 分钟的客户访谈提纲 用户画像月流水 10 万到 50 万的美容店店主年龄 30 到 45 岁 主要用手机记账没有专职财务人员。 待验证假设店主最痛的是报税截止前的集中工作量而不是日常记流水。 要求 1. 分成开场、背景了解、关键场景、痛点深挖、结束五个部分。 2. 每个部分列出 3 到 5 个问题。 3. 问题要尽量开放避免引导用户顺着我的预设回答。 4. 每个问题后面用括号标注“这个问题想验证什么假设”。 输出为 Markdown 列表。Grok 会在每个问题后面补一句“验证意图”这非常有用。实际访谈时你可以先不把意图说给用户听但自己在对话里始终保持方向。3.2 自动检查引导性问题访谈提纲最大的问题不是问题太少而是问题自带答案。例如“你是不是觉得月末对账很麻烦”就是一个典型的引导性问题用户很容易顺着回答“是”但这并不代表真实痛感强。可以继续让 Grok 做一轮质检下面是一份访谈提纲请逐条判断是否存在引导性问题、 双重问题、封闭式问题。对每条问题给出修改建议。 访谈提纲 [粘贴上一步生成的提纲] 输出格式表格列为“原问题、问题类型、风险、修改建议”。这一步的本质是让 AI 充当审稿人。要注意Grok 的判断不一定全对但至少能帮你快速发现“问得太窄”的地方。3.3 问卷和访谈的取舍问卷适合扩大样本量访谈适合深挖原因。Grok 可以帮助生成问卷初稿但问卷的选项设计比文案更重要。设计选项时要注意频率类问题用区间选项不要用“经常/偶尔”这种含糊词。痛点强度使用 1 到 5 分并写明语义。每个题目只能验证一个维度。请针对“小微经营者报税准备时长”设计 5 道问卷题目 包含频率题、时长题、强度题和开放题。每个选项要具体、 互斥频率和时长使用明确区间。4. 第三个环节把访谈记录整理成结构化字段4.1 为什么不能把记录丢在聊天软件里访谈结束后最常犯的错误是把原始记录存在微信、飞书或本地笔记里散落各处无法按用户、按假设、按痛点横向检索。要对比 10 次访谈前提是每一次访谈都被转换成相同结构的记录。我建议定义一套固定的字段然后让 Grok 按这套字段整理。字段包括用户身份、使用场景、当前做法、痛点描述、期望结果、可验证信号、访谈备注。其中“可验证信号”是指用户原话里能证明假设强弱的证据例如“我上个月因为错过截止日被罚了 300 元”。4.2 记录整理提示词下面是一段客户访谈记录请按指定字段整理。 访谈记录 [粘贴原始记录文本] 输出要求 1. 用户身份用一句话概括访谈对象。 2. 关键场景用户在什么情况下遇到问题。 3. 当前做法用户现在如何解决。 4. 痛点描述原话摘录 概括原话要加引号。 5. 期望结果用户希望达到什么状态。 6. 可验证信号能证明问题真实性的细节比如花费时间、 支付过的费用、重复发生次数。 7. 不确定项记录中模糊、缺失、需要再次确认的信息。 如果原始记录中某项信息不存在请填写“记录中未提及” 不要自行补全。最后一句“不要自行补全”非常重要。大语言模型倾向于把缺失信息补成合理内容在客户发现这种需要真实证据的场景里这会造成严重误导。4.3 让多段记录保持格式一致整理多份访谈时建议让 Grok 统一输出 JSON方便后续写入数据库{ interview_id: INT-001, user_segment: 美容店店主, key_scene: 月底核对微信和支付宝流水, current_solution: 导出手工 Excel 逐笔核对, pain_point_quote: 光对账就花了一个晚上还对不平, pain_point_summary: 对账时间成本高错误难以定位, expected_outcome: 自动匹配流水并标注差异, signal_detail: 每月至少 4 小时用于对账发现 2 笔差错, unknown_items: [是否愿意为此付费未确认] }输出 JSON 后需要检查字段是否完整、原话是否真实存在。如果原文没有“光对账就花了一个晚上”这句话那这条记录就是无效的。5. 第四个环节用 Grok 聚类痛点、汇总证据5.1 把多条记录合并分析当访谈次数达到 8 到 15 次后原始记录已经很多靠肉眼很难横向比较。可以让 Grok 做一次聚类下面是 12 段客户访谈的结构化记录请按“用户痛点”做聚类分析。 要求 1. 每个聚类给出名称、出现次数、典型原话摘录。 2. 对每个聚类标注证据强度强、中、弱。 强表示有具体事件或数字支持弱表示只是单次主观表述。 3. 指出哪些聚类与核心假设相关哪些是衍生需求。 4. 最后给出一个建议下一步最应该验证哪个聚类。 记录 [粘贴多段 JSON 或字段化的记录]聚类结果可以整理成一张表痛点主题出现次数典型原话证据强度与核心假设关系月末对账耗时8“每次对账都要两三个小时”强直接相关漏报税截止日5“去年逾期被罚过一次”强直接相关票据保存混乱6“小票经常丢月底找不到”中衍生需求5.2 防止 Grok 过度归纳聚类是 AI 最容易“过度归纳”的环节。它可能把两个不相关的反馈拧成一个主题也可能忽略语气中的负面程度。人工复核时重点关注同一聚类的原话是否真的描述了同一类问题。出现次数是否被放大或缩小。是否有某个聚类来自同一个访谈对象被误当成多人反馈。如果某个聚类只依赖一条记录应标记为“待更多证据”不能进入结论。5.3 结论要区分“相关”和“因果”即使聚类结果看起来很有说服力也不能直接说“用户需要自动对账功能”。访谈能证明的是“用户表达了这个痛点”不能证明“用户会为解决方案付费”。所以在结论输出中建议使用“证据支持较强”“暂时无法判断”这类表述而不是“用户确定需要”。6. 第五个环节把验证结果沉淀成结构化数据6.1 数据环境的选择如果只是个人进行 5 次以内访谈可以用表格文件管理如果团队协作、多个月连续积累访谈数据建议进入数据库。学习环境可以直接用 SQLite 或本地 MySQL生产环境还需要设计权限、备份和数据导入导出。6.2 最小表结构下面是一张用于客户发现记录的最小表结构可直接作为设计参考CREATE TABLE customer_discovery ( id BIGINT PRIMARY KEY AUTO_INCREMENT, interview_id VARCHAR(32) NOT NULL, user_segment VARCHAR(100) NOT NULL, key_scene VARCHAR(255), current_solution VARCHAR(500), pain_point_quote TEXT, pain_point_summary VARCHAR(500), expected_outcome VARCHAR(500), signal_detail VARCHAR(500), signal_level TINYINT COMMENT 3强, 2中, 1弱, hypothesis_code VARCHAR(16), source VARCHAR(100), created_at DATETIME DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, INDEX idx_hypothesis (hypothesis_code), INDEX idx_segment (user_segment) );字段中的hypothesis_code用于关联第一部分定义的假设编号例如 H-01。这样后续可以通过一条 SQL 查询某个假设关联的所有证据SELECT user_segment, pain_point_summary, signal_detail FROM customer_discovery WHERE hypothesis_code H-01 ORDER BY signal_level DESC, created_at ASC;6.3 从 Grok 输出到数据库的落地方式如果团队已经接入了 Grok 的 API可以把整理环节做成一个半自动脚本读取访谈原始文本。调用 Grok 生成结构化 JSON。人工在界面核对 JSON 字段。确认后写入数据库。API 请求的基本形态类似于curl -X POST https://api.example.com/v1/chat/completions \ -H Authorization: Bearer YOUR_API_KEY \ -H Content-Type: application/json \ -d { model: grok-model, messages: [ {role: user, content: 请将下面的访谈记录整理成 JSON 格式...} ] }实际接口地址和模型标识以官方当前文档为准这里只演示请求骨架。生产环境还应该记录请求日志、处理超时、限流、重试和成本统计不能直接把每次访谈文本都发送给模型后不落日志。7. 常见问题排查为什么 Grok 的回答总是不好用7.1 回答泛泛而谈缺少具体信息现象生成的用户画像都是“忙碌的白领”“中小企业主”这类空泛描述。原因通常是提示词里的产品构想太模糊或没有给出限制条件。处理方式补充目标人群、地理范围、业务规模、预算范围。要求输出必须包含“具体事件、具体频率、具体成本”。让 Grok 先提问补全信息再生成结果。7.2 输出格式不稳定每次结构都不一样现象有时输出表格有时输出列表无法直接导入数据库。处理方式在提示词末尾明确写死输出格式。要求“只输出 JSON不要包含解释”。代码处理时增加 JSON 解析失败的异常处理并设置人工回退流程。7.3 编造用户原话或统计数据现象整理记录时出现了原文没有的引号内容聚类时出现“80% 用户认为”这种统计结论。原因是大语言模型会依据概率补全内容这被称为幻觉现象。处理方式提示词中强制声明“未提及的内容写未提及”。人工核对所有引号内容与原录音或原文。禁止 AI 输出比例、人数等统计类结论统计只能由人工基于真实记录完成。7.4 上下文太长导致回答质量下降现象把 10 段访谈记录一次性塞进提示词结果只重点分析了前面的内容后面的漏掉了。处理方式分批处理每次 3 到 5 段。先让 Grok 输出每段的精简结果再合并做聚类。保持提示词中输出模板稳定方便后续拼接。下表总结了常见问题的排查路径现象优先检查处理建议回答空泛产品构想是否具体补充限制条件和示例格式乱输出格式是否明确指定 JSON 或表格模板出现编造内容是否有真实原话依据人工核对并加限制词长文本质量下降单次输入长度分片处理再合并API 调用失败鉴权、模型名、限流查接口文档和错误码日志8. 最佳实践与扩展方向8.1 客户发现现场检查清单每次开展客户发现前建议按下面的清单确认产品构想是否浓缩成一句话。是否定义了一条核心假设并写清楚了验证标准。目标用户是否足够具体达到可以约访的粒度。访谈提纲是否避免了引导性问题。是否准备了统一的记录字段模板。是否约定了访谈记录保存位置和权限。是否安排了专门的人工复核角色。是否预留了“证据不足继续访谈”的选项而不是急着下结论。这份清单的价值在于把客户发现从“开会聊天”变成“可复核的验证项目”。8.2 学习环境与生产环境的差别个人学习和团队生产在同一个方法论下落地方式差别很大。方面学习/个人实践团队/生产环境数据量几次访谈每月数十次存储表格、笔记数据库加权限控制AI 接入网页对话复制粘贴API 调用加日志流程手工提示词模板管理、版本管理质量控制单人核对双人复核、抽样检查成本忽略需要监控 token 和费用无论哪种环境都必须保留原始访谈记录这是后续所有分析的证据基础。8.3 可以把这套流程扩展到哪里这套“Grok Bot 辅助客户发现”的方法可以扩展到相邻场景竞品用户评论的痛点聚类把电商、应用商店、社区评论交给 Grok 聚类。客服工单归类把历史工单按问题类型和影响范围归类。产品反馈周报把每周用户反馈生成结构化摘要。面试市场调查在招聘信息中提取岗位需求变化。扩展的关键仍然是同一个原则AI 负责整理和归纳人负责真实性复核和最终决策。只要保持这个边界Grok Bot 就能稳定地成为客户发现流程中的高效辅助工具。在真正启动项目前最值得做的不是继续优化提示词而是约第一批真实用户做访谈。把本文的流程走一遍记录下那些让 AI 输出失效的地方再回来调整自己的模板。熟练之后整套客户发现会让你从“凭感觉判断”转向“用证据判断”这才是使用 Grok Bot 最大的价值。
在实际做产品的过程中客户发现Customer Discovery往往比功能开发更早决定项目生死。它的目标不是问用户“你想要什么”而是验证“我们假设谁需要、为什么需要、愿意付出什么成本”这些前提是否成立。很多团队的问题不是不重视访谈而是整个流程太依赖人的经验和手工整理访谈提纲临时拼凑记录散在笔记里几十条反馈无法横向对比最后只得出“用户好像都需要”这种没有信息量的结论。Grok Bot 这类 AI 助手可以在流程里承担“思考伙伴和文本处理器”的角色把访谈前的准备、访谈后的整理和分析压缩到几十分钟内完成。这篇文章以“Grok Bot 简单实用的客户发现方法”为主线先讲 Grok Bot 在客户发现流程中的定位和边界再给出一套完整的五环节工作流然后逐个环节给出提示词、输出模板、结构化表和落地路径。文章会覆盖如何生成用户画像、如何设计访谈提纲、如何把口语化记录整理成结构化数据、如何沉淀到数据库并补充常见问题和最佳实践。读完可以直接按这套思路开展一次真实的客户访谈计划而不是停留在“用 AI 聊天”的层面。1. 先明确 Grok Bot 在客户发现流程中的定位1.1 客户发现的两条核心原则验证而非收集客户发现不是传统的市场调研。市场调研统计“有多少人想要 A 功能”客户发现则要求验证一条具体的假设例如“小微店主愿意每周花 30 分钟用自动记账工具来减少月底报税时的反复核对”。在一个完整的客户发现周期里真正要拿到的是三类证据用户身份访谈对象是谁是否属于目标用户。痛点场景用户在什么场景下遇到问题付出过什么成本。付费意愿和替代方案用户现在用什么办法解决是否愿意为了改变它付出金钱或时间。如果只问“你需要这个功能吗”得到的基本都是礼貌性肯定。客户发现要求把问题落到具体场景、具体频率和具体代价上这需要一套结构化的提问和记录方法。1.2 Grok Bot 适合做什么不适合做什么Grok Bot 是 xAI 推出的对话式 AI 助手擅长多轮对话、长文本分析、结构化输出和意图归纳。它在客户发现中的价值集中在三类任务生成草稿根据产品构想生成用户假设、访谈提纲、问卷初稿。整理文本把一段口语句子整理成“用户身份、痛点、现有方案”等字段。聚类归纳把几十条反馈按主题聚类并标注证据强度。但它有明显的边界不能替代真实用户访谈。AI 无法替你接触用户也无法保证它生成的用户特征描述来自真实市场。不能确认事实。Grok 可能编造用户原话或引用凡是涉及真实证据的内容必须人工核对。不能替代商业判断。最终的“验证通过/推翻”必须由人来做AI 只提供证据组织方式。因此在整条流程里Grok Bot 是“加速器”不是“决策者”。所有 AI 输出都要经过人工复核。1.3 五环节工作流总览为了让 Grok Bot 真正可用可以把客户发现拆成五个可重复执行、可单独验收的环节环节输入输出人工把关点1. 生成用户假设产品构想一句话5 类目标用户、待验证假设清单确认人群与业务相关2. 设计访谈提纲目标用户特征分场景的开放性问题清单剔除引导性问题3. 访谈记录整理原始访谈文本统一字段的结构化记录核对原话与摘录4. 痛点聚类多条结构化记录聚类主题、关键词、证据强度判断聚类是否合理5. 生成验证任务聚类结果下一步访谈或实验任务排定优先级这条主线的关键设计原则是每一环节的输入和输出都是结构化的Grok 只负责处理中间过程人负责判断两头。这样即使 AI 偶尔给出有偏差的回答也可以快速定位出错在哪一步。2. 第一个环节用 Grok 生成目标用户画像和待验证假设2.1 提示词的基本结构用 Grok 做客户发现时提示词质量决定输出质量。一个清晰的提示词至少包含四个部分角色让 Grok 明确自己站在什么视角。上下文产品构想、目标市场、已掌握的限制条件。任务要生成什么数量要求是什么。输出格式要求用标题、列表、表格或 JSON 输出。常见建议是提供“一句话产品构想”越具体越好。例如“为小微企业提供自动记账和税务提醒工具”就比“做企业服务”准确得多。2.2 画像生成示例下面是一个可以直接复制的提示词示例你是一名专注早期产品验证的顾问。请基于以下内容生成客户发现计划 产品构想为个体户和小微企业提供自动记账和税务提醒工具。 产品定位重点解决月末对账和报税截止日期遗忘的问题。 尚未验证的核心假设小微经营者最需要的是节省记账时间 而不是记账精度。 请输出 1. 5 类最值得访谈的目标用户每类用一段话描述身份、工作场景和痛点。 2. 每类用户身上最值得优先验证的一个假设。 3. 每类用户建议优先访谈的 3 个问题。 4. 你认为最值得先启动访谈的一类用户并说明理由。 输出格式用 Markdown 标题分层假设用表格列出。这个提示词的关键在于同时给出了“产品构想”和“尚未验证的假设”。如果不给假设Grok 只会泛泛罗列人群给了假设它才能围绕验证目标来组织问题。2.3 把假设变成可验证的清单生成结果后需要人工整理成一张“假设验证清单”。典型的字段包括字段说明示例假设编号方便后续引用H-01假设内容必须可验证小微店主每周至少花 2 小时做手工对账目标人群假设对谁成立月流水 5 万到 50 万的个体户验证方式访谈、问卷、实验10 次目标用户访谈验证标准多少证据算通过至少 7 人明确提到对账耗时和报错验证结论通过/推翻/待定待启动这里要注意一个常见坑不要用 Grok 生成用户描述就把它当成真实的用户原话。Grok 生成的是“推理草稿”只能帮你设计方案不能帮你证明假设成立。把验证标准写清楚比多生成几轮画像更重要。3. 第二个环节设计访谈提纲和问卷3.1 用 Grok 生成访谈提纲初稿访谈提纲的核心是“让用户讲具体事件”而不是“让用户做产品评审”。好的访谈问题通常是开放式的例如你最近一次核对账目是什么时候当时花了多久报税截止日前你会做哪些准备哪些环节最容易出错如果这个工具能自动识别票据你最担心什么可以让 Grok 基于上一环节的目标用户生成完整提纲请为下面的目标用户设计一份 30 分钟的客户访谈提纲 用户画像月流水 10 万到 50 万的美容店店主年龄 30 到 45 岁 主要用手机记账没有专职财务人员。 待验证假设店主最痛的是报税截止前的集中工作量而不是日常记流水。 要求 1. 分成开场、背景了解、关键场景、痛点深挖、结束五个部分。 2. 每个部分列出 3 到 5 个问题。 3. 问题要尽量开放避免引导用户顺着我的预设回答。 4. 每个问题后面用括号标注“这个问题想验证什么假设”。 输出为 Markdown 列表。Grok 会在每个问题后面补一句“验证意图”这非常有用。实际访谈时你可以先不把意图说给用户听但自己在对话里始终保持方向。3.2 自动检查引导性问题访谈提纲最大的问题不是问题太少而是问题自带答案。例如“你是不是觉得月末对账很麻烦”就是一个典型的引导性问题用户很容易顺着回答“是”但这并不代表真实痛感强。可以继续让 Grok 做一轮质检下面是一份访谈提纲请逐条判断是否存在引导性问题、 双重问题、封闭式问题。对每条问题给出修改建议。 访谈提纲 [粘贴上一步生成的提纲] 输出格式表格列为“原问题、问题类型、风险、修改建议”。这一步的本质是让 AI 充当审稿人。要注意Grok 的判断不一定全对但至少能帮你快速发现“问得太窄”的地方。3.3 问卷和访谈的取舍问卷适合扩大样本量访谈适合深挖原因。Grok 可以帮助生成问卷初稿但问卷的选项设计比文案更重要。设计选项时要注意频率类问题用区间选项不要用“经常/偶尔”这种含糊词。痛点强度使用 1 到 5 分并写明语义。每个题目只能验证一个维度。请针对“小微经营者报税准备时长”设计 5 道问卷题目 包含频率题、时长题、强度题和开放题。每个选项要具体、 互斥频率和时长使用明确区间。4. 第三个环节把访谈记录整理成结构化字段4.1 为什么不能把记录丢在聊天软件里访谈结束后最常犯的错误是把原始记录存在微信、飞书或本地笔记里散落各处无法按用户、按假设、按痛点横向检索。要对比 10 次访谈前提是每一次访谈都被转换成相同结构的记录。我建议定义一套固定的字段然后让 Grok 按这套字段整理。字段包括用户身份、使用场景、当前做法、痛点描述、期望结果、可验证信号、访谈备注。其中“可验证信号”是指用户原话里能证明假设强弱的证据例如“我上个月因为错过截止日被罚了 300 元”。4.2 记录整理提示词下面是一段客户访谈记录请按指定字段整理。 访谈记录 [粘贴原始记录文本] 输出要求 1. 用户身份用一句话概括访谈对象。 2. 关键场景用户在什么情况下遇到问题。 3. 当前做法用户现在如何解决。 4. 痛点描述原话摘录 概括原话要加引号。 5. 期望结果用户希望达到什么状态。 6. 可验证信号能证明问题真实性的细节比如花费时间、 支付过的费用、重复发生次数。 7. 不确定项记录中模糊、缺失、需要再次确认的信息。 如果原始记录中某项信息不存在请填写“记录中未提及” 不要自行补全。最后一句“不要自行补全”非常重要。大语言模型倾向于把缺失信息补成合理内容在客户发现这种需要真实证据的场景里这会造成严重误导。4.3 让多段记录保持格式一致整理多份访谈时建议让 Grok 统一输出 JSON方便后续写入数据库{ interview_id: INT-001, user_segment: 美容店店主, key_scene: 月底核对微信和支付宝流水, current_solution: 导出手工 Excel 逐笔核对, pain_point_quote: 光对账就花了一个晚上还对不平, pain_point_summary: 对账时间成本高错误难以定位, expected_outcome: 自动匹配流水并标注差异, signal_detail: 每月至少 4 小时用于对账发现 2 笔差错, unknown_items: [是否愿意为此付费未确认] }输出 JSON 后需要检查字段是否完整、原话是否真实存在。如果原文没有“光对账就花了一个晚上”这句话那这条记录就是无效的。5. 第四个环节用 Grok 聚类痛点、汇总证据5.1 把多条记录合并分析当访谈次数达到 8 到 15 次后原始记录已经很多靠肉眼很难横向比较。可以让 Grok 做一次聚类下面是 12 段客户访谈的结构化记录请按“用户痛点”做聚类分析。 要求 1. 每个聚类给出名称、出现次数、典型原话摘录。 2. 对每个聚类标注证据强度强、中、弱。 强表示有具体事件或数字支持弱表示只是单次主观表述。 3. 指出哪些聚类与核心假设相关哪些是衍生需求。 4. 最后给出一个建议下一步最应该验证哪个聚类。 记录 [粘贴多段 JSON 或字段化的记录]聚类结果可以整理成一张表痛点主题出现次数典型原话证据强度与核心假设关系月末对账耗时8“每次对账都要两三个小时”强直接相关漏报税截止日5“去年逾期被罚过一次”强直接相关票据保存混乱6“小票经常丢月底找不到”中衍生需求5.2 防止 Grok 过度归纳聚类是 AI 最容易“过度归纳”的环节。它可能把两个不相关的反馈拧成一个主题也可能忽略语气中的负面程度。人工复核时重点关注同一聚类的原话是否真的描述了同一类问题。出现次数是否被放大或缩小。是否有某个聚类来自同一个访谈对象被误当成多人反馈。如果某个聚类只依赖一条记录应标记为“待更多证据”不能进入结论。5.3 结论要区分“相关”和“因果”即使聚类结果看起来很有说服力也不能直接说“用户需要自动对账功能”。访谈能证明的是“用户表达了这个痛点”不能证明“用户会为解决方案付费”。所以在结论输出中建议使用“证据支持较强”“暂时无法判断”这类表述而不是“用户确定需要”。6. 第五个环节把验证结果沉淀成结构化数据6.1 数据环境的选择如果只是个人进行 5 次以内访谈可以用表格文件管理如果团队协作、多个月连续积累访谈数据建议进入数据库。学习环境可以直接用 SQLite 或本地 MySQL生产环境还需要设计权限、备份和数据导入导出。6.2 最小表结构下面是一张用于客户发现记录的最小表结构可直接作为设计参考CREATE TABLE customer_discovery ( id BIGINT PRIMARY KEY AUTO_INCREMENT, interview_id VARCHAR(32) NOT NULL, user_segment VARCHAR(100) NOT NULL, key_scene VARCHAR(255), current_solution VARCHAR(500), pain_point_quote TEXT, pain_point_summary VARCHAR(500), expected_outcome VARCHAR(500), signal_detail VARCHAR(500), signal_level TINYINT COMMENT 3强, 2中, 1弱, hypothesis_code VARCHAR(16), source VARCHAR(100), created_at DATETIME DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, INDEX idx_hypothesis (hypothesis_code), INDEX idx_segment (user_segment) );字段中的hypothesis_code用于关联第一部分定义的假设编号例如 H-01。这样后续可以通过一条 SQL 查询某个假设关联的所有证据SELECT user_segment, pain_point_summary, signal_detail FROM customer_discovery WHERE hypothesis_code H-01 ORDER BY signal_level DESC, created_at ASC;6.3 从 Grok 输出到数据库的落地方式如果团队已经接入了 Grok 的 API可以把整理环节做成一个半自动脚本读取访谈原始文本。调用 Grok 生成结构化 JSON。人工在界面核对 JSON 字段。确认后写入数据库。API 请求的基本形态类似于curl -X POST https://api.example.com/v1/chat/completions \ -H Authorization: Bearer YOUR_API_KEY \ -H Content-Type: application/json \ -d { model: grok-model, messages: [ {role: user, content: 请将下面的访谈记录整理成 JSON 格式...} ] }实际接口地址和模型标识以官方当前文档为准这里只演示请求骨架。生产环境还应该记录请求日志、处理超时、限流、重试和成本统计不能直接把每次访谈文本都发送给模型后不落日志。7. 常见问题排查为什么 Grok 的回答总是不好用7.1 回答泛泛而谈缺少具体信息现象生成的用户画像都是“忙碌的白领”“中小企业主”这类空泛描述。原因通常是提示词里的产品构想太模糊或没有给出限制条件。处理方式补充目标人群、地理范围、业务规模、预算范围。要求输出必须包含“具体事件、具体频率、具体成本”。让 Grok 先提问补全信息再生成结果。7.2 输出格式不稳定每次结构都不一样现象有时输出表格有时输出列表无法直接导入数据库。处理方式在提示词末尾明确写死输出格式。要求“只输出 JSON不要包含解释”。代码处理时增加 JSON 解析失败的异常处理并设置人工回退流程。7.3 编造用户原话或统计数据现象整理记录时出现了原文没有的引号内容聚类时出现“80% 用户认为”这种统计结论。原因是大语言模型会依据概率补全内容这被称为幻觉现象。处理方式提示词中强制声明“未提及的内容写未提及”。人工核对所有引号内容与原录音或原文。禁止 AI 输出比例、人数等统计类结论统计只能由人工基于真实记录完成。7.4 上下文太长导致回答质量下降现象把 10 段访谈记录一次性塞进提示词结果只重点分析了前面的内容后面的漏掉了。处理方式分批处理每次 3 到 5 段。先让 Grok 输出每段的精简结果再合并做聚类。保持提示词中输出模板稳定方便后续拼接。下表总结了常见问题的排查路径现象优先检查处理建议回答空泛产品构想是否具体补充限制条件和示例格式乱输出格式是否明确指定 JSON 或表格模板出现编造内容是否有真实原话依据人工核对并加限制词长文本质量下降单次输入长度分片处理再合并API 调用失败鉴权、模型名、限流查接口文档和错误码日志8. 最佳实践与扩展方向8.1 客户发现现场检查清单每次开展客户发现前建议按下面的清单确认产品构想是否浓缩成一句话。是否定义了一条核心假设并写清楚了验证标准。目标用户是否足够具体达到可以约访的粒度。访谈提纲是否避免了引导性问题。是否准备了统一的记录字段模板。是否约定了访谈记录保存位置和权限。是否安排了专门的人工复核角色。是否预留了“证据不足继续访谈”的选项而不是急着下结论。这份清单的价值在于把客户发现从“开会聊天”变成“可复核的验证项目”。8.2 学习环境与生产环境的差别个人学习和团队生产在同一个方法论下落地方式差别很大。方面学习/个人实践团队/生产环境数据量几次访谈每月数十次存储表格、笔记数据库加权限控制AI 接入网页对话复制粘贴API 调用加日志流程手工提示词模板管理、版本管理质量控制单人核对双人复核、抽样检查成本忽略需要监控 token 和费用无论哪种环境都必须保留原始访谈记录这是后续所有分析的证据基础。8.3 可以把这套流程扩展到哪里这套“Grok Bot 辅助客户发现”的方法可以扩展到相邻场景竞品用户评论的痛点聚类把电商、应用商店、社区评论交给 Grok 聚类。客服工单归类把历史工单按问题类型和影响范围归类。产品反馈周报把每周用户反馈生成结构化摘要。面试市场调查在招聘信息中提取岗位需求变化。扩展的关键仍然是同一个原则AI 负责整理和归纳人负责真实性复核和最终决策。只要保持这个边界Grok Bot 就能稳定地成为客户发现流程中的高效辅助工具。在真正启动项目前最值得做的不是继续优化提示词而是约第一批真实用户做访谈。把本文的流程走一遍记录下那些让 AI 输出失效的地方再回来调整自己的模板。熟练之后整套客户发现会让你从“凭感觉判断”转向“用证据判断”这才是使用 Grok Bot 最大的价值。
![[光学原理与应用-521]：对光的错误理解与纠偏](http://pic.xiahunao.cn/yaotu/[光学原理与应用-521]：对光的错误理解与纠偏)
