DeepSeek+Coze实战：搭建AI获客智能体的完整指南-育师

简介：一份围绕DeepSeek与Coze的AI获客智能体构建实战指南，面向传统行业中小老板、创业者/个人IP及销售运营人员，重点解决短视频获客中的账号定位、内容创作与数据分析难题。文档以搭建智能体的完整流程为主线，首先明确智能体效率提升、创意助手、分析专家的价值定位与预期目标，随后梳理短视频创作业务链路，涵盖账号搭建、对标拆解、选题库、内容拍摄、剪辑发布与数据分析等环节，并结合蛋糕店老板起号场景演示如何借助DeepSeek拆解痛点、生成选题与脚本建议，最终落地为可对话使用的Coze智能体。资源为1个docx格式文档，压缩包约1.75MB，结构清晰，适合按步骤对照操作。目前已有627人学习下载。阅读后能够获得账号定位方法论、对标账号拆解模板、场景工作流设计思路及DeepSeek提问示例，有助于将重复性分析工作交给AI，实现获客成本降低与短视频高频输出。

1. 获客智能体不是客服机器人：DeepSeek+Coze 这套组合到底在解决什么问题

把 DeepSeek 和 Coze 凑在一起做 AI 获客智能体，是我给客户做私域转化落地时最常用的组合。原因不复杂，DeepSeek 负责想，做意图判断、话术生成和客户分析；Coze 负责干，把线索清洗、流程流转和消息推送这些重复动作串成自动化链路。很多人以为获客智能体是客服机器人的升级版，实际差别非常大：客服是被动等人来问，获客是主动找对人、说对话、在对的时间触发下一步。这套方案适合的团队也很清晰：手里有源源不断的线索，但销售人力不够、新人话术参差不齐、跟进全靠手动。如果你正好卡在这个环节，下面这套从定位到落地的流程可以直接照着抄。

2. 先定业务边界：获客智能体到底该替销售干哪几件事

进入搭建之前，先把业务边界定清楚。很多团队做销售智能体失败，不是技术问题，是没想清楚让 AI 替人做哪些事。获客看起来是一件事，拆开其实是四个环节：线索清洗、意向预判、话术生成、跟进提醒。智能体不要想着四个一起上，先问自己一个问题：哪个环节最痛、线索量最大、并且规则相对清晰？从那个环节切入，比搭一个什么都聊的万能机器人靠谱得多。

2.1 获客智能体的四类任务拆解：线索清洗、意向预判、话术生成、跟进提醒

这个拆法来自两个观察。一是销售的日常动作里七八成是重复的，二是这些重复动作恰好都有明确的输入和输出，适合让 AI 来跑。线索清洗解决的是「数据进来是脏的」，意向预判解决的是「不知道先跟谁」，话术生成解决的是「开口第一句不知道说什么」，跟进提醒解决的是「转头就忘」。

线索清洗不只是纠错。从表单或 CRM 里导出的客户信息，常见手机号带横杠、城市写成“北京朝阳区”、行业字段空白。智能体做的第一件事是把这些字段标准化，再根据公开信息判断这条线索是不是一个「活体」：企业名称是否在异常名单里、邮箱域名是否匹配、来源渠道是否可信。这个环节我建议只做标准化和有效性校验，别想着把数据质量一次性做到完美，否则项目会陷在数据清洗里出不来。

意向预判是获客智能体最值钱的能力。同样一句「多少钱」，A 客户可能是随手问问，B 客户可能已经比完三家竞品只差报价。我的做法是把意向分成 S/A/B/C 四档，用两个维度打分，一个是用户主动说出的语言信号，比如「能不能今天约个演示」「我们月底要定供应商」，一个是行为信号，比如从哪个渠道进来、在官网页面上是否点击过价格页。语言信号优先，因为行为数据经常不全。

话术生成这里最容易做歪。智能体生成的不是一段广告，是一句能接住用户上一个问题的开场白。比如用户问「支持私有化部署吗」，合格的 AI 话术要先回答支持还是不支持，再反问一句「你的团队规模多大、对数据安全要求多高」，这才叫获客话术。一段话术里同时出现四五个卖点的，基本没人读。

跟进提醒做的不是替销售拍板，而是把决策依据摆到销售面前。比如「客户王经理上次主动提到了竞品 A，建议 3 天后跟进，附带一份对比表话术」——这个动作把销售脑子里不可见的东西变成了工作台里的一条待办。注意，这一步永远不要替销售直接发消息给客户，只做提醒和素材准备。

2.2 用一张「决策树」给场景划边界：哪些全自动、哪些必须转人工

边界怎么定？拿一个月的历史聊天记录，把所有用户问法归类成二十来种高频意图，再逐个标三个状态：全自动、半自动、人工。不要凭空想，拿真实记录归类，不然做出的决策树会跟实际情况脱节。

举几个最常见的分支：用户问「怎么收费」，全自动，把标准价目表发过去，但如果对方问「能给几个点折扣」，立刻转人工，AI 不做任何承诺；用户问「能签对公合同吗」，直接转人工并附上销售名片；用户说「你们跟 XX 竞品比怎么样」，AI 可以给一套标准对比口径，但必须把原话原封不动记进线索档案，让销售看到客户真实关注点；用户表达负面情绪，比如「太贵了」「又是个套资料的网站」，立即转人工，AI 只做安抚，不做任何挽留式承诺。

这张表建好之后，工作流的骨架基本就定了。条件分支不需要写复杂的逻辑，用关键词和简单规则就能覆盖大半场景，真正拿不准的再交给大模型去判。

2.3 一句话定义智能体角色：写 Prompt 之前的必要准备

在 Coze 里一上来就狂写人设的，十有八九会翻车。我的习惯是先写一句话再动手。比如说这句话：你是一位有 8 年 B2B 软件销售经验的资深销售，你的目标是挖掘客户预算、决策链和痛点，并推进到预约演示环节。这一句话同时确定了语气、信息边界和工作目标。

为了让这句话能真正落进 Coze 的人设，我会先把它扩成一份 JSON 配置，再转成自然语言 Prompt。这样写的好处是，角色、目标、禁忌分开管理，后面想调哪个维度就调哪个维度，不会越改越乱。

{ "role": "资深B2B销售顾问", "target": "在5轮对话内挖掘预算、决策链和痛点，推进到预约远程演示", "tone": "专业、简洁、不使用感叹号", "forbidden": ["报价折扣", "承诺效果", "贬低竞品"], "first_turn_strategy": "先回应客户上一个问题，再追加一个开放性问题" }

注意 JSON 里的forbidden不是摆设。大模型天生爱讨好用户，你不在人设里明确禁止，它就敢在用户两句追问之后随口承诺效果。把这些红线写进去，至少能挡住一部分乱承诺。接下来，就拿着这份配置去 Coze 里创建智能体。

3. 在 Coze 上把智能体搭出来：节点顺序与 DeepSeek API 接入

边界定完，就可以动手了。选 Coze 做一个获客智能体的核心理由是：团队里没人会写代码，也不想维护一套前后端和数据库时，Coze 是能把智能体最快推到真实聊天渠道的载体。它在国内通常叫扣子，提供白画布式的工作流编排、插件市场、知识库和现成的发布渠道。对比 Dify 那类平台，Coze 对非技术团队更友好，Dify 更适合团队里有人愿意碰代码的情况。

3.1 创建智能体并配置人设：把销售方法论写进 System Prompt

创建步骤很简单：登录扣子平台，点「创建智能体」，填一个名字和一句话功能描述，然后在「人设与回复逻辑」里粘贴下面这段 Prompt。这段 Prompt 是上一节那份 JSON 的自然语言扩展，顺序有讲究：先定义身份，再给目标，最后写行为边界。

你是一位有8年B2B软件销售经验的资深销售顾问，当前任务是在对话中挖掘客户预算、决策链和核心痛点，并把客户推进到预约远程演示这一步。 对话守则： 1. 每一轮先回应客户上一句的具体内容，再往下问一个开放性问题。 2. 不主动报折扣，不承诺效果，不评价竞品。 3. 当客户直接问价格时，给出标准起步价并反问部署规模。 4. 当客户表达负面情绪时，立即转人工，不在对话框里过多解释。 5. 每次回答不超过120字。

强调一下第 1 条。大模型对话最容易出现的问题是一轮接一轮「另起炉灶」，上一句客户提到私有化部署，它下一句就跳到「我们产品支持多租户」，完全不接话。把「先回应上一句」写死，能显著减少这种机器感。

在「人设与回复逻辑」之外，还要顺手把「功能描述」填了，Coze 会用它来给智能体做渠道侧的预热回复，别留空。

3.2 搭一条「线索清洗工作流」：知识库、大模型节点、条件分支的用法

创建好智能体后，进入「工作流」页面新建一条流程。获客场景第一步不需要太复杂，一条线索清洗流就够了，结构如下：

在 Coze 画布上的连法是「开始 -> 大模型 -> 知识库 -> 条件分支 -> 结束」，知识库节点不是必须的，但如果产品有大量标准参数和 FAQ，挂一个知识库节点可以有效减少模型胡编。大模型节点里只需要让模型输出一个 JSON，字段包括intent、budget_signal、need_demo三个，后面的条件分支全靠这三个字段做路由。

3.3 用代码节点接入 DeepSeek API：最小可运行示例

如果 Coze 模型列表里已经有 DeepSeek，直接在模型节点里选就行。但经常遇到两种情况：账号所在区域找不到 DeepSeek 入口，或者你需要更精细的参数控制，比如单独调 temperature、单独管理密钥。这种情况就用代码节点自己封装一次 API 调用，下面是经过多次验证的最小可运行写法。

# 代码节点：调用 DeepSeek API 生成获客话术 import requests import json def main(context: dict) -> dict: user_info = context["user_info"] # 上游节点传入的客户画像 api_key = context["deepseek_key"] # 从智能体变量或密钥配置中读取 prompt = f""" 你是资深销售，客户信息如下：{json.dumps(user_info, ensure_ascii=False)} 请生成一段不超过80字的首次触达话术，先回应客户最关心的问题，再问一个问题。 """ resp = requests.post( "https://api.deepseek.com/chat/completions", headers={ "Authorization": f"Bearer {api_key}", "Content-Type": "application/json" }, json={ "model": "deepseek-chat", "messages": [{"role": "user", "content": prompt}], "temperature": 0.5, "max_tokens": 200 }, timeout=30 ) data = resp.json() return {"reply": data["choices"][0]["message"]["content"]}

说明几个参数。model用deepseek-chat对应通用对话模型，deepseek-reasoner对应深度推理模型，获客话术生成用前者就够。temperature设 0.5，是话术自然度和确定性的平衡点，太低会像机器人复读，太高容易跑偏乱承诺。timeout必须设，API 偶发变慢时宁可让流程走兜底话术，也不能让用户一直转圈。

另外，如果走 Function Calling 链路，注意 DeepSeek 的一个行为差异：工具调用的结果必须紧跟着下一条消息立即返回，中间不能插入其他角色消息，否则接口会报错。所以代码节点里拿到tool_calls之后必须马上把结果消息发回去。

3.4 发布到企微、飞书、公众号：渠道选择的三个判断标准

智能体做好之后，发布是最后一步。Coze 的发布渠道覆盖网页应用、微信公众号、飞书、企业微信、API 服务等。我选择渠道只看三条标准：线索从哪个渠道进来，就把智能体发到哪个渠道；销售日常在哪个工具里看客资，就把消息推到哪个工具；需要和现有 CRM 打通时，就直接发布成 API 服务，由你的后端去调。

比如线索主要来自公众号文章留资，那就发公众号，用户关注后自动触达。销售团队习惯用企业微信跟进客户，那就用企微侧边栏模式发布，销售手动触发智能体生成话术，而不是让 AI 直接乱加客户。这里要点明一个原则：获客智能体前期不要做「全自动私聊」，容易踩到用户反感甚至合规的雷，先做「销售触发、AI 辅助」更稳妥。

4. 调 DeepSeek 参数的三个必调项：别让模型乱发挥

模型接入之后，决定智能体像人还是像机器的，往往是几个参数。DeepSeek 的 API 参数和 OpenAI 兼容，最值得动的是temperature、top_p、max_tokens。很多人把这几个参数当成摆设，全用默认值，结果话术要不冷冰冰要不满天飞。下面按场景给出我的设定。

4.1 temperature 和 top_p：意图判断要低，话术生成要高

所有智能体项目里，我最先调的就是这两个值。换一个应用场景，你必须重新调一遍，不能一套参数吃遍所有功能。

| 场景 | temperature 推荐 | top_p 推荐 | 原因 | | 意图判断/线索清洗 | 0.1 - 0.3 | 0.7 | 需要确定性，不允许模型自由发挥 | | 话术生成/首次触达 | 0.6 - 0.8 | 0.9 | 保留自然度，让语气不至于像机器 | | 客户摘要提炼 | 0.3 | 0.8 | 压缩信息要保守，不要添油加醋 |

建议只调temperature，top_p保持 0.9 附近即可。两者同时往极端调会把输出质量搞得很不稳定，这个在 DeepSeek 上表现尤其明显，模型偶尔会在低温度下输出重复句子，遇到这种情况先检查 max_tokens 是不是给太少。

4.2 上下文长度与记忆策略：长上下文不是免费午餐

DeepSeek 支持的长上下文很大，但获客场景里把整段对话历史全喂进去，效果并不好。第一是慢，第二是贵，第三是模型容易被无效信息干扰，比如客户闲聊了两句天气，AI 就开始聊天气而忘了销售目标。正确的做法是：工作流内只传最近 3 轮对话加一份客户摘要。

客户摘要不是缓存，是每轮对话后用大模型重新生成的结构化档案。下面这段代码是放在 Coze 代码节点里的摘要更新逻辑，每轮对话末尾执行一次。

# 代码节点：把本轮对话压缩成客户摘要 import requests import json def main(context: dict) -> dict: prev = context.get("customer_summary", "") new_turn = context.get("last_dialogue", "") api_key = context.get("deepseek_key") messages = [ {"role": "system", "content": "你是客户档案管理员，用100字以内更新客户摘要，保留预算、决策链、痛点、竞品和下一步计划。"}, {"role": "user", "content": f"已有摘要：{prev}\n本轮对话：{new_turn}"} ] resp = requests.post( "https://api.deepseek.com/chat/completions", headers={"Authorization": f"Bearer {api_key}"}, json={ "model": "deepseek-chat", "messages": messages, "temperature": 0.3, "max_tokens": 150, }, timeout=20, ) try: updated = resp.json()["choices"][0]["message"]["content"] except Exception: updated = prev # 调用失败时保留旧摘要，不让流程断掉 return {"customer_summary": updated}

注意timeout=20和except兜底。摘要更新是辅助动作，不是用户直接看到的响应，它超时了不应该影响主流程。在 Coze 里把这个代码节点的输出存进变量customer_summary，下一轮对话就能在 Prompt 里读到「客户是制造业、预算中位、关注续费机制、已经对比了至少两家竞品」这类高密度信息。

4.3 成本与延迟控制：模型分级与超时保护

获客智能体跑起来之后，最容易让人肉疼的是成本账单。一次普通提问如果每次都走完整工作流、每个节点都调一次大模型，单次成本确实不高，但一个月几万次对话下来就不好看了。我的做法是分级：能用规则处理的绝不调模型，能用小模型处理的绝不用大模型。

# 意图分流：避免每条消息都走完整大模型链路 INTENT_FAQ = "faq" INTENT_DEMO = "demo_request" INTENT_COMPLEX = "complex" def route(message: str) -> str: if any(k in message for k in ["价格", "怎么卖", "收费"]): return INTENT_FAQ if any(k in message for k in ["演示", "约时间", "试用"]): return INTENT_DEMO return INTENT_COMPLEX

这套分级思路落地到 Coze 上，就是在「开始」节点后面加一个「条件分支」，优先处理高频标准问题，只有识别到「约演示」「比方案」这类高价值意图时，才调用 DeepSeek 生成个性化回复。至于本地部署 DeepSeek，我的看法是，API 调用在成本和维护上已经足够划算，中小团队没必要碰本地部署，省下的钱不够付服务器电费和运维时间。

5. 从能跑到好用：获客智能体落地必踩的 5 个坑与排错记录

搭建阶段的每一步都可以照着文档来，但等它真正跑在线上，各种意外才陆续冒头。下面这 5 个坑是我在不同项目里踩过不止一次的，按现象、原因、解决一个个说。

5.1 坑：JSON 解析崩溃，意向判断节点直接断流

现象：工作流日志显示大模型节点已经正常返回结果，但下游代码节点报json.decoder.JSONDecodeError，整个流程中断，用户只收到一句「系统开小差」。

原因：两个，一是max_tokens给得太短，模型话没说完就被截断；二是模型把 JSON 包进了 Markdown 代码围栏，代码节点拿到的是```json ... ```，直接json.loads当然失败。

解决：给足 max_tokens，解析前先剥离围栏，再做容错，只截取第一个{到最后一个}之间的内容：

import json def safe_parse(text: str) -> dict: text = text.strip() if text.startswith("```"): lines = text.split("\n") lines = lines[1:] if lines[0].startswith("```") else lines text = "\n".join(lines) if text.endswith("```"): text = text[:-3] start = text.find("{") end = text.rfind("}") if start == -1 or end == -1: return {} try: return json.loads(text[start:end + 1]) except json.JSONDecodeError: return {}

这段代码放进代码节点后，最坏情况也只是返回空字典，让流程走「无法判断」的兜底分支，而不是整个链路中断。空结果比崩掉好，因为空结果可以被记录成一条日志，继续往下分析。

5.2 坑：知识库分块太小，精确参数查不到

现象：客户问「你们最大支持多少并发」，智能体回复「这个需要您联系销售深入了解」，但产品手册里明明写着一组并发数。

原因：上传到 Coze 知识库的产品手册被默认切成小块，一条包含服务器配置和并发数的表格数据被拆散到多个 chunk 里，向量检索召回的片段缺了关键数字。

解决：表格类内容单独存一份文档再上传，把分块大小调到 200 字以上；同时在知识库节点里把检索策略从「向量检索」改成「混合检索」，让关键词精确匹配优先命中。如果数据是结构化表单，干脆不要用知识库，写一个代码节点直连数据库或接口查询，准确率更高。

5.3 坑：一次普通提问跑完整条链路，单笔成本翻十倍

现象：用户就问一句「你们最近放假吗」，工作流把意图识别、知识库检索、话术生成全跑了一遍，账单比预期高。

原因：没有在流程最前面做低成本过滤，把需求消息和高价值线索一视同仁地送进了完整工作流。

解决：在「开始」节点后面紧接一个条件分支，用关键词命中最简单的「放假、地址、怎么走」这类问题，直接返回标准答案，不进大模型节点。放完假这类问题之后还要确认一条：只有命中demo_request的对话，才允许进入完整 DeepSeek 生成链路。这样调整之后，单次对话的平均成本能降一半以上。

5.4 坑：Coze 模型列表里根本没有 DeepSeek

现象：在智能体的模型设置里翻遍了模型列表，只看到豆包、Kimi 这些，找不到 DeepSeek；或者偶尔找到了，第二天又消失。

原因：Coze 平台的模型列表是按账号区域、版本灰度动态开放的，不是所有账号都能直接看到 DeepSeek 入口，这是平台侧的设置问题，不是你的账配错了。

解决：不依赖平台入口，直接走自定义插件或代码节点方式接入 DeepSeek API。这跟 3.3 节的做法一致，用deepseek-chat和deepseek-reasoner两个模型名，自己控制所有参数。顺带提一句，不要因为平台限制就转头去折腾 Coze 开源版本地部署，开源版缺插件市场、缺现成工作流模板，为了接一个模型把整个平台栈都换成自维护的，性价比很低。

5.5 坑：话术千篇一律，用户一眼看穿是机器人

现象：同一批导入的线索，每个人都收到「您好，请问您对我们的产品感兴趣吗」，回复率惨淡。

原因：Prompt 里根本没有客户字段，模型拿不到客户名字、公司、行业、来源渠道，只能生成模板套话。

解决：在话术生成前，把线索字段注入 Prompt。上一章代码里的user_info至少包含company_name、industry、source_channel、previous_message四项。注意，注入客户真实数据之前先做脱敏，导出线索时去掉手机号、身份证这类敏感字段，只保留跟对话直接相关的信息；获客智能体可以处理生意，但数据合规的底线是整个项目能不能继续的前提。

6. 落地之后怎么验证效果：用对话日志把智能体调成「销冠脑子」

智能体上线只是开始，真正的工作是每周盯日志、做对比、调一个变量。这里讲三个我一直在用的验证方法。

6.1 从 Coze 对话日志里找「沉默样本」

Coze 的对话日志会记录每次工作流的完整输入输出，包括每个节点的耗时和结果。我每次迭代前会花半小时翻日志，专找「用户说了话，但没有到达任何高价值节点」的样本。比如日志里显示某类用户第一句话就被条件分支判成invalid，但点进去看原话是「你们是外包团队吗」——这说明分支条件写得太粗，把「确认合作模式」这种高意向问题丢掉了。这就是日志的价值，它能让你定位到是流程断掉还是模型答错。

6.2 用 A/B 测试验证话术：同一批线索，两种开场白

改话术不能拍脑袋，要用数据说话。我的做法是在 Coze 里复制一份智能体做 B 版，共享同一个知识库和意图判断节点，只改话术模板，然后把进来的新线索按 50/50 分流。跑一周看这张表：

| 实验组 | 话术风格 | 送达数 | 回复率 | 预约演示数 | | 模板A | 自我介绍+产品卖点 | 200 | 8% | 6 | | 模板B | 回应来源渠道+开放问题 | 200 | 14% | 12 |

只看回复率还不够，预约演示数才是获客智能体的北极星指标。回复率高但预约演示少，说明话术吸引了闲聊但没抓住采购意向；两个数都高，才值得把 B 版合并回主版本。

6.3 我的一个习惯：每周只调一个变量

最后分享一个踩过坑之后养成的习惯。有一回我同时改了 Prompt、知识库分块和 temperature 三个地方，结果话术回复率跌了，但完全找不到是谁的锅，只能全部回滚重新试。从那以后我给自己定了条铁律：一次只调一个变量，改了什么、为什么改、预期是什么，记在日志里。这样每次效果波动都能对上因果，好的改动留下来，坏的改动回滚，项目是匀速前进的。做获客智能体这件事，慢就是快，希望帮到你。

本文还有配套的精品资源，点击获取