news 2026/9/30 3:26:06

DeepSeek+Coze搭建AI获客智能体:从成本、工作流到留资闭环

作者头像

张小明

前端开发工程师

1.2k 24
文章封面图
DeepSeek+Coze搭建AI获客智能体:从成本、工作流到留资闭环

简介:围绕DeepSeek与Coze搭建AI获客智能体的完整实战指南,面向传统行业中小老板、创业者/个人IP及销售运营人员,聚焦短视频起号与获客难题。资料从智能体定位与目标拆解入手,深度梳理账号定位、对标账号拆解、选题库搭建、内容创作等环节的痛点,并给出AI可介入的具体任务与人工配合事项;同时细化场景工作流,覆盖工作流创建、绑定、测试到发布的全过程,让读者可直接通过对话调用智能体。资源为单份docx文档,大小1.75MB,内容以文字讲解和流程拆解为主,并配有蛋糕店老板短视频起号的完整对话示例,便于对照迁移到自身业务。目前已有627人学习下载。通过DeepSeek完成爆款视频逻辑分析、结构化拆解报告生成等环节,可将80%重复性分析工作交给AI,显著提升短视频运营效率,为低成本获客提供可落地的参考方案。

1. 为什么用DeepSeek+Coze搭AI获客智能体:先算清成本和收益再动手

先说一个反直觉的结论:AI获客智能体上线后能不能跑出业绩,最先卡住的往往不是模型智商,而是回复速度和话术稳定性。深夜11点访客在官网留了手机号,销售第二天早上才回访,这条线索早就凉透了;而一个配置好的智能体能在10秒内接住对话,把“你是谁、卖什么、怎么联系”先确认下来。DeepSeek负责用低成本生成高质量回复,Coze(国内叫扣子)负责把知识库、工作流和表单、企微这些入口串成可落地的业务链路。这个组合解决的是小团队的销售困境:有产品但没专职销售,有流量却缺转化工具。整篇按定位、搭建、闭环、避坑、验证五个阶段讲,每个环节给出可直接抄的配置和代码。

2. 把获客定位翻译成智能体设定:从销售话术到系统规则

在Coze里新建一个智能体只需要一分钟,但绝大多数项目死在第一步——没想清楚智能体到底替销售完成哪个动作。所以我不急着写提示词,先花半天和业务方对齐定位。定位直接决定工作流的复杂度、知识库的粒度、转人工的时机,也决定这个智能体上线后是一个好用的销售助理,还是一个浪费算力的聊天机器人。

2.1 三种获客定位先选一个:线索筛选、产品答疑还是自动留资

同样是获客智能体,定位不同,工作流复杂度差一个量级。第一种是线索筛选,适合客单价高、决策周期长的B2B业务,智能体负责判断客户有没有预算、有没有时间窗口、有没有决策权,聊到关键节点就转人工;第二种是产品答疑,适合标品、SaaS、课程这类问题边界清晰的业务,客户带着明确问题进来,智能体从知识库里找答案,答完引导留资;第三种是自动留资,定位最轻,用话术钩子把“随便看看”的访客变成留下联系方式的线索,适合私域投放落地页。

选型时要盯住一个具体动作:客户进线后,你最希望智能体替销售完成哪一步?是要一份“接得住问题”的产品说明书,还是要一个“能筛出高意向客户”的前置销售?这个动作就是工作流终点,也是后续所有节点设计的依据。你也会看到有人用Dify这类开源框架搭类似的智能体,但Coze胜在发布渠道和插件生态,小团队快速上手更合适,不必一开始就上自部署框架。

2.2 用一份可复用的人设提示词把销售话术写成系统规则

定位定了,下一步不是写代码,是把销售脑子里的话术写成系统规则。常见做法是给智能体一份system prompt,把角色、业务边界、回答纪律都钉死。下面是我在Coze的“人设与回复逻辑”里常用的一套模板,可以直接替换公司名和产品名使用:

你是一个企业获客助理,目标是在对话中确认客户的真实需求并引导留资。 身份背景:你代表{公司名}的售前顾问,产品是{一句话产品说明}。 回答纪律: 1. 先回应客户问题,再用一个开放式问题挖掘需求,不要连续追问超过两个问题。 2. 涉及价格时,不报具体数字,只给出"基础版、专业版、企业版"档位描述,并反问预算区间。 3. 客户问竞品对比时,不贬低竞品,只陈述自家产品的适用场景和差异点。 4. 客户表现出明确购买意向(提到预算、时间、决策人)时,主动引导留资或转人工。 5. 不确定的问题,回答"这个问题我需要确认后回复你",不得编造功能。 6. 禁止承诺效果、收益、资质等未经验证的内容。

这段模板的关键在纪律部分的第4、5、6条:第4条对应获客链路里的留资判断,第5条是防幻觉的第一道闸,第6条是合规底线。模型参数也要跟着调,temperature建议放在0.3到0.5之间,太低回复机械,太高模型容易临场发挥;max_tokens按产品复杂度给,标品问答500到800就够,复杂方案放到1500,但越长越啰嗦,也越容易触发工作流超时。

提示词里用{占位符}而不是写死内容,是为了让同一个智能体能通过变量复制给不同产品线。Coze的变量可以在节点配置里预置,也可以由对话开始前的外部请求传入。我一般会把占位符清单列在提示词文件末尾,方便产品经理自己维护话术,不用每次改动都拉上开发。

2.3 话术边界与拒答策略:不该接的问题不硬接

获客智能体最容易翻车的地方是“什么都敢答”。真人销售在微信上可以含糊其辞,模型却很可能会一本正经地编一个优惠方案出来。拒答策略必须写进提示词,不能指望模型自觉。

以下场景不做具体回答,使用对应话术模板:

  • 客户索要书面承诺或合同条款:抱歉,合同细节需要销售顾问和你确认,我先把你的需求记录下来。
  • 客户询问内部折扣或“最低多少钱”:我们按档位定价,不同版本功能差异较大,方便告诉我你的使用场景吗?
  • 客户提出无关话题或情绪化表达:我这边主要处理{产品名}相关的问题,你可以随时问我产品功能。
  • 客户要求提供竞争对手方案:我更了解自家产品的适用场景,你可以说说目前最困扰你的问题。

这种“场景+固定话术”的写法,本质是在提示词里做路由,让模型先判断场景再取话术,比单纯写“不要乱说话”可靠得多。注意模板里不要写“我不是人”这类暴露AI身份的话——获客场景里,客户知道自己在和机器聊会明显降低留资意愿,这是实际跑出来的经验,不是玄学。

拒答策略写完要跑一遍测试清单:价格、折扣、合同、竞品、售后、无关话题,每个方向至少问三轮。Coze可以新建一个测试用的会话窗口,把这些话术直接贴上问,看智能体是否都走了对应模板。这一轮能挡掉绝大部分翻车,值得在上线前做。

3. 在Coze工作流里接DeepSeek:从单次对话到四步获客链路

3.1 模型节点配置:DeepSeek为什么值得放在主对话位

在Coze控制台新建智能体时,默认配置不一定是DeepSeek。通常需要在模型配置里添加自定义模型,填入DeepSeek的API Key和模型名。常见配置项如下:

| 配置项 | 推荐值 | 说明 | | base_url | https://api.deepseek.com | API接入地址 | | model(普通对话) | deepseek-chat | 响应快、成本低,主对话位使用 | | model(复杂分析) | deepseek-reasoner | 意图识别、需求拆解场景使用 | | temperature | 0.3-0.5 | 获客话术要稳,不要发散 | | 上下文窗口 | 32k-64k | 多轮获客对话足够保留关键历史 |

选型理由:DeepSeek的API成本比同档位模型低不少,推理质量在线,长上下文对获客对话尤其重要——客户从“随便问问”到“留资”可能跨二三十轮,窗口太小的模型聊到后面会把客户说过的预算和人数全忘掉。另一个理由是双模型配合:主对话用chat,快且省;深度分析用reasoner,只在意图识别和总结节点里出现。这样成本和体验都能兼顾。

3.2 用coze工作流编排“意图识别-知识库召回-生成回答-留资判断”四步

只把DeepSeek接在对话位上,等于做了个高级聊天机器人,不叫获客智能体。完整的获客链路至少要串四个节点,我通常这样编排:

| 节点顺序 | 节点类型 | 输入 | 输出 | 关键参数 | | 1 意图识别 | 大模型节点(reasoner) | 用户消息+对话摘要 | 意图标签 | 标签枚举:问产品/问价格/比竞品/要留资/闲聊 | | 2 知识库召回 | 知识库节点 | 意图标签+用户消息 | 相关文档片段 | top_k=5,相似度阈值0.6 | | 3 生成回答 | 大模型节点(chat) | 意图+文档片段+对话历史 | 回复文本+留资字段 | temperature=0.4,max_tokens=800 | | 4 留资判断 | 代码节点 | 回复文本+用户消息 | 是否留资+线索字段 | 命中手机号/微信号/公司名即置1 |

解释一下这样设计的逻辑:意图识别和生成回答用的是两个不同角色,reasoner负责判断,chat负责说话,目的是让“判断”和“表达”解耦。判断错了还有知识库兜底,表达跑偏直接砸客户体验。留资判断不用模型而用代码节点,是因为正则匹配手机号、邮箱、微信号比模型“觉得像”可靠得多。

如果不想每轮都跑完整四步,在意图识别节点后面加一个条件判断:意图为“闲聊”时直接走生成回答节点,跳过知识库。这种分支写法能省一次知识库调用,对成本和响应速度都有帮助。Coze里用条件判断节点即可实现。

3.3 知识库与文件上传:产品资料的分块与召回边界

Coze的知识库支持上传PDF、Word、网页链接,平台会自动切片。但自动切片的结果不一定适合检索:一个PDF段落里混了功能、价格、售后三种信息,召回时模型拿到的是信息不纯的片段,回答自然混乱。所以上传前先手动整理,常见做法是:

  • 把长文档拆成“产品功能”“价格方案”“售后政策”“常见问题”四类,分别建知识库,在工作流里按意图标签选择查哪个库。
  • 每段控制在300到500字,超出部分在切片时容易被截断。
  • 段落开头用“问题+答案”的格式,例如“Q:支持私有化部署吗?A:支持,标准版含私有化部署方案”,这种格式召回命中率明显更高。

知识库召回节点的相似度阈值从0.5开始试:低了召回无关内容,高了漏召回。判断依据是日志里的召回片段——如果片段相关但排序靠后,把阈值调低扩大召回;如果召回一堆不相关内容,就调高到0.7左右。top_k默认5够用,知识库条目少的场景可以降到3,减少噪音。

3.4 动手验证:用Python脚本先测通DeepSeek API

在Coze配节点之前,先用Python把DeepSeek API测通。这样能把模型问题和工作流问题隔离开,省得后面排查时两头猜。常见做法是用OpenAI兼容格式调用:

from openai import OpenAI client = OpenAI( api_key="sk-你的key", base_url="https://api.deepseek.com" ) resp = client.chat.completions.create( model="deepseek-chat", messages=[ {"role": "system", "content": "你是获客助理,只回答与产品相关的问题。"}, {"role": "user", "content": "你们这款软件支持几个人用?"} ], temperature=0.4, max_tokens=500 ) print(resp.choices[0].message.content)

这里直接用OpenAI SDK,因为DeepSeek的接口兼容OpenAI格式,不用额外引库。装依赖用pip install openai就行。关键参数要和Coze模型节点里保持一致,否则会出现“脚本里测得好好的,一上工作流就变样”的情况。temperature定了就不要两边各写各的,max_tokens也是。

脚本跑通后,把同一份system prompt放到Coze里,再用不同问题各问十轮,记录回答稳定性和响应时间。deepseek-chat在低并发时响应通常在1到3秒,超过5秒就要检查prompt是不是太长,或者服务端是否限流。这一步做完,模型层面就没有黑匣子了,后面出问题可以直接锁定在工作流配置上。

4. 从对话到线索:获客智能体的数据闭环与人工兜底

4.1 用Webhook把留资数据推到自己的服务器

智能体聊得再好,线索攥在Coze里不流出来,业务侧就用不起来。常见做法是在工作流末尾加一个Webhook节点或代码节点,把留资判断节点的输出POST到自己的服务器。接收端越简单越好,我一般用Flask写:

from flask import Flask, request import json app = Flask(__name__) @app.route("/lead/hook", methods=["POST"]) def receive_lead(): data = request.get_json() name = data.get("name", "") phone = data.get("phone", "") intent = data.get("intent", "") message = data.get("message", "") # 在这里写入CRM或推送企业微信通知 with open("leads.jsonl", "a", encoding="utf-8") as f: f.write(json.dumps(data, ensure_ascii=False) + "\n") return {"code": 0, "msg": "ok"} if __name__ == "__main__": app.run(host="0.0.0.0", port=8000)

这个脚本只干两件事:接收POST请求、把线索追加到本地文件。部署到服务器后,在Coze工作流的Webhook节点里填上接口地址即可打通。字段名要在Coze的代码节点里提前约定,我用的是name、phone、intent、message这套命名,两端保持一致,否则接收端取不到值。

两个实际坑提前说:一是接口要处理重复推送,同一个线索可能因为重试被推两次,处理方式是记录唯一键(比如phone加当天日期),重复就跳过;二是手机号校验,不要轻信模型输出的号码格式,服务端用正则再验一遍,否则CRM里会进一堆假号码。

4.2 转人工的时机判断:先让智能体聊,还是先让销售接?

不是所有客户都该让智能体聊到底。我的判断标准是:客户出现强购买信号立刻转人工,还在比价、了解功能的让智能体继续。强购买信号的典型特征包括主动问价格、问实施周期、问能不能先签合同、主动留下联系方式。

Coze里实现转人工有两条路。一条是在留资判断节点里输出turn_human字段,值为1时触发企业微信通知节点,把对话摘要推到销售群;另一条是让智能体在回复里带上“我帮你安排顾问”的引导语,由客户决定。前者适合客单价高的业务,后者适合流量型业务。不要两种同时上,容易乱。

转人工时一定要把对话摘要一起推给销售。销售拿着“这个客户问了私有化部署和预算50万”再打电话,和拿着一个干巴巴的手机号打过去,成交率差一倍。摘要可以在Coze里用变量把多轮关键信息累积起来,转人工时一次性取出。

4.3 线索打分:用结构化输出区分“高意向”和“随便问问”

线索打分是获客智能体和聊天机器人的分水岭。做法是让DeepSeek把对话结论输出成固定结构的JSON,再由代码节点依据字段计算意向分。输出结构一般长这样:

{ "score": 72, "level": "high", "signals": ["主动问价格", "提到预算范围", "询问实施周期"], "next_action": "2小时内电话回访" }

score是0到100的意向分,level是high、mid、low三档,signals记录触发评分的具体信号,next_action给销售一个建议动作。在Coze的大模型节点里,把输出格式定义为JSON并喂一个示例,模型就会按这个结构返回。如果是DeepSeek API直连,可以在请求参数里加response_format={"type": "json_object"}强制输出,避免模型夹带解释文字。

打分节点放哪里要看对话轮数:一轮就要判断意向,直接合并进意图识别节点;聊了七八轮才判断,单独做“总结+打分”节点更合理,因为那时要处理的历史上下文已经不小。阈值先用经验值,60分以上转人工,40到60分进培育池,40分以下标记为低意向,不浪费销售时间。跑两周后根据实际成交率再调这三个区间,比拍脑袋定要靠谱。

5. 避坑指南:DeepSeek+Coze获客智能体常见的5个翻车点

下面这五个坑是多个项目里反复出现的,基本覆盖了获客智能体从搭建到上线的大部分返工原因。每条按现象、原因、解决三个动作拆,方便你对号入座。

5.1 模型幻觉:智能体向客户承诺了不存在的功能

现象:客户问“支持对接SAP吗”,知识库里根本没有这一条,模型却回答“支持,我们有标准接口”。

原因:模型为了维持对话的连贯性,倾向于给出肯定答复,尤其当前文聊得比较热络时,它会把“编一个接口”当成延续对话的合理动作。

解决:在提示词里明确“未知功能必须说需要确认”,同时把知识库召回设成必检环节,先检索再回答。最稳妥的做法是在知识库节点后面加一个判断:召回为空或相似度低于阈值时,直接输出固定话术“这个功能我需要和技术确认后回复你”,不让主模型自由发挥。

5.2 多轮对话上下文丢失:客户聊了10轮后智能体“失忆”

现象:客户第8轮说“预算30万左右”,第10轮谈论方案时,智能体又反问“您的预算大概是多少”。

原因:Coze工作流的上下文默认只保留最近若干轮,或者代码节点没有把历史关键信息回传给模型,老信息被挤出了窗口。

解决:在代码节点里维护一个summary变量,客户提过预算、城市、人数、时间等关键信息,全部追加进去;每轮生成回答前把这个变量拼进system prompt。这个变量相当于智能体的“工作笔记”,比指望模型自己在上下文里记要可靠得多。

5.3 知识库召回不准:FAQ答非所问

现象:客户问“能不能开发票”,召回的是产品功能介绍,回答完全跑偏。

原因:原始文档段落太大,一个段落混了多个主题;或者相似度阈值设得太松,把不相关内容也拉进来了。

解决:上传前把FAQ改写成“一问一答”格式,每段只放一个问题和对应答案,控制在300到500字。阈值从0.6往回调——召回相关但排序靠后就调低,扩大召回范围;召回了一堆不相关的就调高。用Coze后台的日志看每次召回命中了哪些片段,判断阈值方向。

5.4 工作流节点超时:DeepSeek推理慢导致Coze报错

现象:工作流日志频繁出现timeout,客户那边表现为“智能体半天不回复”。

原因:Coze单次工作流执行有超时上限,deepseek-reasoner在长上下文场景单次要十秒以上,很容易撞上限。

解决:把reasoner留在意图识别节点,主对话用chat模型。长文档总结场景拆成多次短调用,不要指望一次调用处理上万字。如果业务确实需要长时间推理,可以改成“先回复客户已收到,再异步推送结果”的交互模式,但获客场景里实时感优先,一般不建议这么设计。

5.5 合规视角与平台限制:获客话术别踩红线

现象:智能体出话太激进,比如承诺“保证30天内见效”“全网最低价”,客户不买账,反而留下虚假宣传的把柄;拿到手机号后立刻推送营销信息,也容易吃投诉。

原因:模型本身没有广告法意识,提示词不约束,它就会顺着客户期望生成承诺。获客场景涉及大量用户联系方式,处理不当还会碰到隐私问题。

解决:提示词里禁止效果承诺、禁止贬低竞品、禁止编造资质。客户电话、微信、公司字段只用于本次对话记录,不要跨渠道复用,也不要从外部导入号码直接群发。Coze平台对部分行业有审核要求,话术上架前先自查一轮。另外别被“本地部署”带偏节奏,获客场景用云端托管足够,等有严格数据隔离要求时再考虑私有化方案。

6. 上线后的效果验证:用对话日志喂出更好的获客话术

智能体上线不是工作结束,是数据喂养的开始。我上线后第一周不做任何优化,只做三件事:导出全部聊天记录、标记对话流失点、找出被客户追问但答不上来的问题。Coze后台可以导出对话日志,也可以从Webhook服务端拿全量数据,两份数据交叉着看。

第一,两版话术A/B测试。在Coze里复制同一个智能体,只改开场白或引导留资的某一句话,两个版本各接一半流量跑三天,对比留资率。获客话术好不好,数据说了算,不要凭感觉。第二,回溯流失点。把对话按轮数拆开,统计客户在哪一轮之后不再回复。如果大量流失集中在第5轮,大概率是第4轮的回答出了问题,要么太啰嗦,要么答非所问。这个指标比整体留资率更能定位病根。第三,把真实成交对话回填知识库。每周挑三到五条销售和客户的成交聊天记录,把“销售说了什么促成成交”缩写成一问一答格式喂进知识库。这是成本最低的优化手段,也是把销冠的个人能力沉淀成系统资产的过程。

我现在的习惯是,任何话术改动上线前,先自己拿两部手机把全流程走一遍,一部当客户、一部当智能体,专挑刁钻问题问,这一遍能挡掉七八成翻车。获客智能体没有一步到位的方案,但你可以让它在你的业务里一步步变准。希望帮到你。

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

版权声明: 本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若内容造成侵权/违法违规/事实不符,请联系邮箱:809451989@qq.com进行投诉反馈,一经查实,立即删除!
网站建设 2026/9/30 3:25:57

Linux进程从入门到排障:状态、通信与杀手锏一次讲清

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

作者头像 李华
网站建设 2026/9/30 3:25:30

Qt中QStackedWidget的实现示例

前言做桌面应用的时候,"在同一块区域里切换不同内容"几乎是刚需:登录页和主界面之间切换、设置对话框左侧点一下右边换一页、安装向导的上一步下一步、多标签页工具……如果你每换一页就 new 一个窗口或者手动 hide()/show() 一堆 widget&…

作者头像 李华
网站建设 2026/9/30 3:24:57

Chrome插件高效配置指南:安全下载渠道与6款必备扩展推荐

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

作者头像 李华
网站建设 2026/9/30 3:24:39

PhotoScan相机标定实战:用空三反解镜头畸变模型

简介:本资源是一份面向摄影测量与三维建模初学者及从业者的实操指南,聚焦PhotoScan(现为Metashape)中相机标定与镜头畸变改正两大核心环节,解决因标定不准或畸变未校正导致三维模型精度下降的典型问题。文档以流程化方…

作者头像 李华
网站建设 2026/9/30 3:24:19

Ubuntu 20.04 LTS 安装与初始化全链路指南

简介:本资源是一份面向Linux初学者、技术爱好者及开发者的Ubuntu 20.04 LTS操作系统落地实践指南,系统解决从零安装到基础配置的全流程问题,覆盖BIOS/UEFI启动设置、Rufus制作启动盘、双系统共存方案、磁盘分区策略、APT包管理实战及桌面环境…

作者头像 李华
网站建设 2026/9/30 3:23:59

Docker安装MySQL数据持久化实战:从容器删不丢到网络排查

开头这里直接交代一个很多人会忽略但非常关键的事:使用Docker安装MySQL,难点不在“安装”本身,而在“数据持久化”。我见过太多朋友,一条docker run命令跑起来,数据库一切正常,结果某天容器被清理或者镜像重…

作者头像 李华