Grok Bot客户发现实操：从线索整理到批量打分的完整指南

Grok Bot用来做客户发现，本质上不是在微信里挂一个自动回复机器人，也不是用AI去猜谁是潜在客户。它真正能省力的是三件事：把零散线索整理成同一套画像、给线索打分排序、生成第一轮跟进素材。这篇文章会按我实际跑过的流程，从最小样例、批量处理、接入业务场景，一直讲到参数调整和排查顺序。如果你正在做B端销售、私域运营、独立开发者的付费用户调研，或者刚接手一个需要从零摸排客户的业务，这篇文章可以直接当操作手册用。

1. 客户发现这件事，Grok Bot到底帮你省在哪

客户发现最累的从来不是“找到一个人”，而是“搞清楚这个人值不值得跟、怎么跟、什么时候跟”。很多团队一天能拿到几百条线索，最后花在整理上的时间比沟通时间还长。

1.1 手工客户发现的三个典型卡点

第一个卡点是线索量大但画像模糊。一个销售每天能看几十条线索，但要把每条都整理成“要不要跟、先说哪句、下一次什么时候跟”，效率很低。大部分时间都花在机械重复的信息归类上。

第二个卡点是话术不统一。同一个产品，不同销售对同一条线索的理解不一样，开场白也完全不同。有的偏功能，有的偏价格，有的直接问预算。结果是线索被浪费了，还不知道问题出在谁身上。

第三个卡点是跟进没有沉淀。聊完一次就散了，客户到底关心什么、谁决策、什么时候采购，都只存在个人聊天记录里。换个人接手，所有信息等于重新摸一遍。

1.2 Grok Bot适合承担什么，不适合承担什么

Grok Bot适合承担的是信息整理、画像匹配、话术草稿、匹配度打分这几类工作。它的输入可以是一段网页介绍、一条填表记录、一封自动回复邮件、一份展会名单；输出可以是一条结构化的客户记录，包括匹配分、匹配理由、可跟进方向、建议话术。

它不适合承担的是直接联系客户、验证联系方式真实性、替销售做最终判断。Grok看到的信息可能过时，可能不完整，它生成的联系方式也需要二次核实。更不建议把它做成自动添加好友、自动群发消息的工具，这种用法既容易踩平台规则，也容易把品牌印象做坏。

1.3 一个最小可用的工作流大概长什么样

我建议第一次做客户发现，不要一上来就接CRM、做定时任务、开多机器人并发。先搭一个最小闭环：

1. 定义目标客户画像。
2. 准备一段原始线索文本。
3. 让Grok Bot输出一条结构化客户记录。
4. 人工检查这条记录是否可用。

这条闭环跑通之后，再去考虑批量、打分、定时、接入企业微信或CRM。很多项目失败，不是因为AI能力不够，而是把自动化范围一下子拉得太大，最后连日志和错误都不知道去哪儿看。

2. 动手前的准备：账号、数据、环境和合规边界

客户发现是一个涉及个人信息和商业判断的场景，准备工作不能只盯着“把API调通”。我一般会按四个部分来准备：账号与API、运行脚本的环境、线索数据、合规边界。

2.1 能跑通Grok Bot的最小环境

如果你只是个人测试，不需要专门的服务器。一个能跑Python的本地环境，加上一个能调用Grok模型的API密钥，基本就够了。如果你已经安装了支持OpenAI接口风格的客户端库，可以直接用它来调用Grok接口；如果还没有，可以用curl或者任何支持HTTP请求的语言做一次连通性测试。

下面是一个示例环境变量，实际配置要以你申请到的服务文档为准：

export GROK_API_KEY="your-api-key" export GROK_BASE_URL="https://api.example.com/v1" export GROK_MODEL="grok-model-name"

注意，我这里的域名和模型名是占位符。不同版本的Grok模型在接口路径、模型标识、上下文长度上会有差异，不要拿着示例配置直接用到生产环境。

2.2 线索数据怎么来、怎么存、怎么清洗

线索数据来源要合规，我不会去碰任何未经授权采集的数据。比较稳妥的来源有几类：客户自己填写的表单、线下展会换来的名片和名单、企业官网公开的新闻和招聘信息、行业报告里公开提到的公司名单、已有客户转介绍。

拿到原始数据之后，先做三件基础清洗工作：

• 去重。同一家公司可能出现在多个来源里，先按公司名或域名去重。
• 补全。缺官网、缺行业、缺规模的记录，先标出来，不要急着让模型去“猜”。
• 脱敏。如果数据里包含个人联系方式，存储前要按个人信息保护要求处理，能脱敏就脱敏，能不留就不留。

清洗后的数据我习惯统一存成CSV或表格文件，每一列都有固定含义。这样做的好处是，后面让Grok Bot批量分析时，不需要反复解释字段是什么。

2.3 合规边界：哪些事不能交给机器人干

这一条要放在所有操作之前。Grok Bot可以帮你生成话术，但“添加好友、发送消息、拉群、私信触达”这类动作，应该由真人执行，或者由你确认过的话术模板批量执行。不要让机器人在没有人工审核的情况下直接对外触达。

涉及个人信息的字段，比如姓名、手机号、微信号、邮箱，使用范围要严格控制。客户发现不是“越多越好”，而是“足够准确、足够相关、经过对方同意或基于公开且合理用途”。如果一条线索的获取方式本身有问题，后面再优化提示词和模型参数都补不回来。

3. 从一条线索开始：先跑通客户画像和话术生成

批量处理之前，一定要先跑通单条样本。这个步骤能帮你同时验证三件事：提示词模板是否清晰、Grok是否理解你的客户画像、输出格式是否方便后续处理。

3.1 把客户画像写成一个结构化提示词模板

客户画像越具体，Grok的匹配结果越有用。不要写“我们需要SaaS客户”这种模糊描述，要写出行业、公司规模、使用场景、决策角色和痛点关键词。

一个可用的画像描述，至少应该包含这些信息：

目标行业：企业服务、软件、制造业数字化 目标公司规模：20-200人 目标痛点：销售线索分散、客户跟进没有记录、团队协作工具割裂 目标角色：销售负责人、运营负责人、创始人 触发信号：招聘销售岗、新上线CRM类系统、官网出现“线索管理”关键词

然后把画像和原始线索一起放进提示词。下面是一个通用示例：

你是一个B端销售线索过滤器。 请根据以下客户画像，分析这条原始线索是否值得跟进。 客户画像： - 行业：企业服务、软件、制造业数字化 - 规模：20-200人 - 痛点：销售线索分散、客户跟进无记录、协同工具割裂 - 决策角色：销售负责人、运营负责人、创始人 - 触发信号：招聘销售岗、上线CRM系统、官网出现客户管理关键词 原始线索： {这里粘贴原始文本} 请输出结构化JSON，字段如下： - customer_name：客户名称 - source：线索来源 - match_score：匹配分，0到100 - match_reason：匹配理由，必须具体 - intent_signals：意图信号，列出原始线索里实际存在的信息 - risk_notes：风险提示，比如信息缺失、联系方式未验证 - first_message：第一次跟进话术草稿，200字以内 只输出JSON，不要输出解释。

3.2 第一次测试就输入一条样本，不要批量

我见过很多人在第一次跑的时候就输入100条线索，结果模型输出乱成一团，连问题出在提示词还是数据都分不清。

正确做法是先拿一条最普通的线索测试。比如：

公司：杭州某某科技有限公司 规模：官网显示约50人 来源：行业展会登记表 备注：该公司近一个月在招聘销售主管，官网提到“正在优化客户管理流程”

这条样本规模不大、信息密度不低，非常适合验证模型是否能抓取关键词。

3.3 判断输出是否可用的三个标准

单条输出出来之后，不要只看格式对不对，要看三个标准：

1. 匹配理由是否具体。如果match_reason写的是“行业相关、可能需要”，说明画像没有真正发挥作用。好的匹配理由应该能引用线索里的具体信息，比如“近一个月在招聘销售主管”。
2. 意图信号是否可追溯。intent_signals里的每一条都应该能在原始线索里找到对应内容，不能是模型自己脑补的。
3. 话术是否克制。理想的话术草稿应该从客户的公开状态切入，比如“看到贵司正在招聘销售主管，可能也在优化客户管理流程”，而不是一上来就吹嘘产品。

如果这三个标准里有任何一个不达标，先改提示词，再换模型版本，不要直接开始批量处理。

4. 用Grok Bot做批量客户发现和优先级打分

单条跑通之后，批量就是把这些能力复用到表格数据上。这里的关键不是“让Grok多读几条”，而是把输入、输出、失败处理都标准化。

4.1 把线索源整理成统一输入格式

我建议把每条线索做成一行，字段统一。下面是一个可参考的CSV结构：

company,website,source,notes 杭州某某科技有限公司,https://example.com,展会,近一个月在招聘销售主管，官网提到优化客户管理 上海某软件有限公司,https://another-example.com,官网表单,留言说想找一套销售跟进工具

不要在这个阶段塞太多自由文本。Grok的指令跟随虽然强，但输入字段越统一，输出的结构越稳定。公司名、官网、来源、备注这几个字段分开，后面也能减少重复调用。

4.2 分批处理与结构化输出JSON

批量处理时，我一般不会一次喂几十条。更稳妥的方式是循环逐条调用，每次输出变成一条JSON记录，最后汇总到数组里。

import json import time from openai import OpenAI client = OpenAI( api_key=api_key, base_url=base_url, ) def analyze_one(client, model, row): prompt = build_prompt(row) resp = client.chat.completions.create( model=model, messages=[{"role": "user", "content": prompt}], temperature=0.3, ) return resp.choices[0].message.content records = [] logs = [] for idx, row in enumerate(rows[:10]): try: text = analyze_one(client, model, row) data = json.loads(clean_json(text)) records.append(data) logs.append({"index": idx, "status": "ok"}) except Exception as e: logs.append({"index": idx, "status": "error", "error": str(e)}) time.sleep(1)

这里的build_prompt就是把第3节的画像模板和单条线索拼起来。clean_json是清理输出中多余内容的小函数，因为有的版本会在JSON前后加代码块标记或其他文字。

4.3 怎么给线索排序：匹配分数、动机信号、跟进难度

每一批跑完之后，不要把结果直接扔给销售，要先按分数和信号做分层。

我常用的一组分段标准：

匹配分只是一个参考，真正决定是否跟进的是intent_signals。比如一个客户匹配分只有65，但明显在招聘销售管理岗，这就比一个匹配分80但没有任何意图信号的客户更值得聊。

跟进难度也很重要。如果线索里没有官网、没有联系方式，即使分数很高，也要先做好信息验证。我一般会在结果里加一列“待补充项”，把缺失字段标出来。

4.4 人工复核环节不能省

批量输出的结果是“候选名单”，不是“答案”。我建议每次批量跑完后，把高优和中优线索抽出来，让熟悉业务的同事快速过一遍。重点看三件事：

• match_reason是否读了原始线索里的核心信息。
• first_message是否符合品牌语气。
• risk_notes里提到的信息缺失项是否已经补充。

这一步的时间成本不高，但能避免很多因为模型幻觉导致的错误判断。

5. 接入微信、企微或CRM场景的合规落地方式

客户发现做到后面，一定会遇到一个问题：这些结果怎么和日常的客户沟通衔接。很多人会直接搜“Grok Bot 微信 Bot”，但我建议先想清楚一个边界：Bot是辅助人，还是代替人。

5.1 微信Bot常见误区：不是自动加人，也不是群发

把客户发现接入微信生态，最大的误区是把它理解成“自动加人、自动群发、自动回复”。这类做法风险很高，一方面可能违反平台规则，另一方面也容易让客户体验变得很差。

我更推荐把微信Bot定位成“人工运营的辅助编辑器”。它不做自动触达，只做内容预生成和信息整理。运营人员需要给某个客户发消息时，从Grok Bot生成的话术库里挑一条，人工确认后再发送。

5.2 能做的合规闭环：话术预生成、标签建议、跟进记录

在合规前提下，Grok Bot可以帮助完成这样一套闭环：

第一步，根据线索分析结果，给客户打标签。标签可以包括行业、规模、痛点、意图信号、优先级。

第二步，为不同标签生成不同的首次沟通话术。比如，对“正在招聘销售主管”的公司，话术从组织扩张切入；对“官网刚上线客户管理模块”的公司，话术从产品选型切入。

第三步，每次沟通结束后，把聊天摘要交给Grok Bot，让它生成结构化跟进记录。记录里包含沟通时间、客户关注点、下一步动作、负责人提醒。

这套闭环的好处是，所有动作都有人工确认环节，信息也沉淀到表格或CRM里。

5.3 和现有CRM或表格工具衔接

如果你的团队已经有CRM系统，不要试图让Grok直接写进CRM数据库。更稳妥的方式是先把结果输出成JSON或CSV，再导入CRM，或者通过API做单向写入。

如果你用的是企业微信或个人微信，配合一个简单的表格工具就够了。表格里至少要有这些列：

• 客户名称
• 线索来源
• 匹配分
• 意图信号
• 首次跟进时间
• 跟进结果
• 下次跟进时间

这样即使Grok Bot暂时停用，业务记录也还在，不会卡在某个客户端或脚本里。

6. 关键参数和调优判断：版本、温度、批量、并发

客户发现这个场景对输出的要求是“稳定大于创意”。这就决定了参数不能为了酷炫效果而激进。

6.1 模型版本差异怎么处理

我在实际使用中发现，不同版本的模型在指令跟随、上下文长度、响应速度上差别不小。比如材料里提到的Grok 4.6这类较新版本，往往在长上下文和结构化输出上更好用，但新版本刚上线时有时会碰到服务端压力大、临时提示切换或等待的情况。

遇到这种提示，不用急着改代码。先降低请求频率，错峰跑，或者换回你已验证过的稳定版本。不要在业务高峰期去测一个刚上线的新版本。

如果你用的版本支持类似“Grok Build”的工作流编排能力，建议把“画像定义、线索读取、结果输出、分数清洗”这几个环节做成模板。不同版本之间，Build的能力有差异：有的偏界面化编排，有的偏脚本触发，落地前先看当前版本文档，不要照搬别的版本截图操作。

6.2 温度、上下文、输出格式相关参数

客户发现场景里，我通常把temperature设置在0.2到0.4之间。温度太高，同一批线索跑出来的话术差异会很大；温度太低，又可能让话术变得生硬。0.3是一个经过较多验证的起点。

max_tokens要按输出长度设置。客户发现的结果通常是一段JSON加一段话术，几百个token足够。不要设得过大，否则单次请求变慢，批量耗时会被拉长。

如果让Grok输出JSON放在代码字符串里，一定要在提示词里反复强调“只输出JSON，不要Markdown，不要解释”。否则你会在清洗环节浪费大量时间。

6.3 批量处理的数量和并发控制

批量数量不是越多越好。我建议第一批先跑10条，确认输出稳定后，再逐步增加到20条、50条。这里不要一上来就开100条并发，很多报错和卡顿都是并发太高引起的。

并发控制要看你的API额度和服务端限制。更稳妥的节奏是：

• 单条顺序执行，每条之间留1秒间隔。
• 如果连续10条都成功，再考虑并发2到3个。
• 如果出现429或超时，立即降回顺序执行。

批量任务失败后，要有重试机制。不要把失败的记录丢掉，先记录到日志，再在下一次运行时单独重试。

6.4 每次跑完要记录哪些指标

我建议每组任务跑完，都记录下面几项指标：

• 成功条数和失败条数。
• 平均单条耗时。
• JSON解析失败数量。
• 匹配分数分布。
• 输出中是否有明显幻觉，比如引用不存在的联系方式。

这些指标累积下来，能帮你判断是该调整提示词、换模型，还是改批量策略。否则你只会觉得“结果偶尔好偶尔坏”，却找不到规律。

7. 常见问题排查：从报错到结果不可用

在客户发现这个项目上，大部分“Grok Bot不好用”其实不是模型问题，而是流程和数据处理问题。遇到问题，按下面的顺序排查。

7.1 请求失败类的典型原因

如果出现401或403，先检查API密钥是否正确、是否过期、是否有对应模型的调用权限。很多时候问题出在环境变量没加载，或者密钥复制时多了空格。

如果出现429，说明请求频率超过服务端限制。优先降低并发和请求频率，不要立刻调整模型参数。如果提示“high demand”或“please switch”，说明服务端负载高，可以错峰重试或切换到备用模型。

如果出现超时，先看单次请求是不是因为输出太长、输入太长导致的。客户发现场景里，输入线索不要超过几百字，输出尽量控制在500 token以内。

7.2 输出JSON不合法、字段缺失

这是最常见的问题。现象是能跑通，但解析时崩溃。

先看模型输出里是否多了代码块标记，比如json和。清洗函数要把这些标记去掉。

再看字段是否完整。有些版本可能漏掉risk_notes或first_message。可以在提示词里加一句“必须包含所有字段，缺失字段填空字符串”，然后在代码里对字段做缺省处理。

7.3 结果空洞、像套话

如果匹配理由总是“行业相关、可能有需求”，说明提示词里的画像描述不够具体，或者原始线索本身信息太少。

解决办法是把客户画像里的触发信号写得再细一点，比如“官网出现客户管理关键词”“近30天发布销售岗位”。同时，如果原始线索只有一句话，就不要指望模型输出太厚的分析。

7.4 批量跑着跑着卡住

批量任务卡住，不要先怀疑模型。按这个顺序查：

1. 看日志：是某一条报错卡住，还是所有请求都无响应。
2. 看输出目录：确认结果是否已经写了部分记录。
3. 看资源占用：本地运行是否CPU打满、内存不足。
4. 看API余额和频率限制：是不是连续请求触发了限流。

如果卡在中间，最简单的办法是加一个超时和重试机制，把单条请求超时控制在30秒以内。

7.5 排查顺序清单

8. 我的落地建议和边界提醒

最后说几条经验性的建议。不是每个项目都适合上完整自动化，客户发现也一样。

8.1 默认从小而稳开始

我个人建议先把单条任务跑稳，再考虑批量和接口。每增加一个环节，排查成本都会翻倍。不要在设计Grok Bot的第一天就想着接入企业微信、自动同步CRM、每天定时跑全量线索。

先从“输入一段文本、输出一条记录”开始，确认结果稳定，再逐步加约束和自动化。

8.2 哪些信号说明可以加大批量

当你连续跑三四轮批量任务，失败率都在5%以下、输出JSON解析率接近100%、匹配理由不再空洞时，再考虑加大批量或接入更多渠道。

如果你的数据源、客户画像、话术模板经常变，建议先不要做大批量定时任务。因为每次变化都可能影响输出质量，最好先跑小样本验证。

8.3 客户发现这件事的长期优化方向

长期来看，Grok Bot在客户发现里的角色会越来越像一个“业务分析员”：它处理初筛、整理、起草，人在上面做判断和触达。优化方向不只是更好的模型，还包括：

• 沉淀一套更完整的客户画像模板，让每个新同事都能用。
• 把历史跟进结果回喂给Grok，让它学习哪些信号真的能转化成客户。
• 把我们验证过的输入输出格式做成内部规范，而不是每次临时改提示词。

踩过几次坑之后我发现，很多问题不是Grok的能力不够，而是前置环境、输入材料和人工复核没有处理好。先把这三个基础打牢，后面任何版本升级都会顺很多。