简介围绕DeepSeekCoze构建AI获客智能体这份实战资料面向传统行业中小老板、创业者/个人IP及销售运营人员完整覆盖从智能体定位、业务流程梳理、痛点分析、功能需求设计到工作流搭建、测试与发布的落地路径聚焦短视频创作与低成本获客场景。资源以单个docx文档交付压缩包约1.75MB文档以蛋糕店老板短视频起号为例结合DeepSeek对账号定位、对标账号拆解、选题库搭建、内容创作拍摄等环节逐一拆解输出表格化的痛点分析与AI可协助事项。已有627人学习/下载适合希望用AI替代重复性分析工作、实现日更短视频与转化率提升的读者。通读后可获得一套可直接迁移的智能体构建方法论如何设计AI协助的具体任务、编写提示词、生成涵盖账号定位与人设选题方向的结构化报告以及人工决策与AI提效如何分工配合。这份资料的价值在于把短视频获客从经验驱动变为流程驱动将80%的分析工作交给AI自己专注于创意与决策。1. AI获客智能体不是聊天机器人DeepSeekCoze要解决的第一件事很多团队把“AI获客智能体”理解成“能自动回复的客服”结果上线第一天就翻车用户问一句它答一句看起来像那么回事两周过去一条有效线索都没带回来。我做过几个类似的获客项目后最深的体会是获客智能体的瓶颈从来不在模型智商而在流程设计。DeepSeekCoze这个组合DeepSeek负责用极低的成本提供接近商用水平的对话与推理Coze负责把对话变成可编排、可监控、可落库的工作流——两者拼起来目标不是“会聊天”而是“在聊天里完成获客动作”识别意向、推进沟通、产出结构化线索。这篇文章从定位到落地把每一步的参数、节点和坑讲清楚适合正在做销售自动化、私域运营或线索孵化且打算用智能体替代一部分人工SOP的团队。2. 先定位再选架构AI获客智能体的业务边界与两种实现路径2.1 定位清单动手前先问清楚4个问题Coze和DeepSeek都是工具工具解决不了“定义不清”的问题。我一般会拉着业务负责人先把下面几个问题过一遍每个问题都要有数字答案不是“大概”“尽量”这种词。第一个问题一条“有效线索”长什么样常见定义是“留了联系方式且表达过明确预算/时间/痛点”的用户。这个定义要落到可判断的条件上比如判断维度示例条件说明联系方式留下了手机号/微信/邮箱没留联系方式聊得再好也不算线索需求信号明确提到“多少钱”“什么时候能上”泛泛问“你们做什么”不算时间信号提到“这个月”“Q3”“尽快”时间词是购买意向的关键间接指标预算信号提到“预算”“报价”“大概什么价位”有预算词且追问价格倾向立刻升为高意向第二个问题智能体是“首轮接待”还是“全流程跟进”。首轮接待的意思是智能体负责第一轮对话识别出高意向用户后转给销售全流程跟进则是智能体要完成多次触达比如5天后回访、14天后发案例。两种定位对Coze工作流的复杂度要求完全不同全流程要接定时任务和外部触达渠道工作量和坑会翻倍。对第一次做这个方向的项目我建议先把首轮接待做好拿到数据和收益后再加跟进链路。第三个问题谁来维护这个智能体。Coze工作流不是写完就结束的上线后知识库要更新、话术要迭代、被打断的节点要修。如果公司没有一个人愿意承担“智能体运营”这个角色再好的方案也会在两周内烂掉。这个岗位不一定要会写代码但要有过销售或运营经验能看懂会话记录并改进提示词。第四个问题数据怎么回流。智能体产生的对话记录、意向分、跟进结果最终要写进CRM还是钉钉表格、企业微信侧边栏这个决定要在设计阶段做因为Coze的节点输出结构要提前对应数据表字段后期改字段结构比重新搭工作流还痛苦。2.2 DeepSeek在Coze中的两种接入方式API直连与双模型分工把DeepSeek接进Coze常见做法有两种。第一种是“Coze工作流里的HTTP请求节点直接调DeepSeek API”。这种方式最直接、最可控DeepSeek的模型能力、输出格式、成本都掌握在我们手里不依赖Coze内置模型的市场与参数。第二种是“Coze代码节点里封装一个DeepSeek调用函数”适合要在调用前后做额外处理的场景比如加缓存、加重试、记录token消耗、拦截敏感输入。我一般先用第一种快速验证等流量大了再升级到第二种。用HTTP请求节点时核心参数建议这样设参数推荐值理由modeldeepseek-chat对话和意图识别场景够用成本远低于deepseek-reasonertemperature0.3获客场景要稳定的话术一致性不是要创作自由top_p0.9配合低temperature输出风格不飘max_tokens512控制单次回复长度避免话痨式输出拖慢整个工作流response_format{type: json_object}强制返回结构化JSON下游节点才好取值下面是我在Coze代码节点里调DeepSeek时常用的一段PythonCoze国内版的代码节点跑Python依赖库可用requests# Coze代码节点调用DeepSeek API并解析结构化结果 import json import requests # API Key不要硬编码在Coze的“环境变量/密钥”里面配置 api_key env[DEEPSEEK_API_KEY] system_prompt 你是企业端的AI获客助手。你的任务是在对话中识别用户的意向程度 并按固定JSON结构输出结果不要输出任何解释。 payload { model: deepseek-chat, messages: [ {role: system, content: system_prompt}, # user_text和session_history来自上游节点的变量 {role: user, content: user_text} ], temperature: 0.3, max_tokens: 512, response_format: {type: json_object} } try: resp requests.post( https://api.deepseek.com/chat/completions, headers{ Authorization: fBearer {api_key}, Content-Type: application/json }, jsonpayload, timeout30 ) resp.raise_for_status() content resp.json()[choices][0][message][content] # 强制按JSON解析解析失败就给一个兜底结构 result json.loads(content) except Exception as e: result { intent: unclear, intention_score: 0.0, contact_info: None, next_action: ask_more }这段代码的逻辑很简单把Coze上游传过来的用户文本塞进DeepSeek让DeepSeek按固定JSON结构输出再在代码里做一次JSON解析兜底。重点在兜底分支——在线上的真实环境里DeepSeek偶尔会返回非JSON的文本比如追问用户权限问题、被安全策略拦截这时候如果不兜底Coze下游节点会直接报错导致整个工作流中断。参数上要注意temperature不要超过0.5获客场景话术越稳定越好max_tokens设置成512足够覆盖一两次追问设太大不仅费token还会让超时风险升高。第二种“双模型分工”是在Coze里让DeepSeek和Coze内置模型各管一段。Coze国内版内置模型在中文口语对话上响应快、成本低适合做表层寒暄和一般应答DeepSeek放在后置节点专门做意图打分和线索结构化。这个分工的好处是把“高频低价值”的闲聊交给便宜的模型把“低频高价值”的分析交给更强更可控的DeepSeek。判断时机可以在工作流中加一个条件分支首轮用户消息进来先过内置模型做简单分类命中疑似线索关键词的再调DeepSeek深度分析。这样能把DeepSeek的调用量砍掉6成以上账单数字会好看很多。3. 用Coze工作流搭出第一个AI获客智能体从节点说明到第一版可测流程3.1 Coze工作流节点编排开场→意图识别→话术生成→线索落地Coze工作流和单纯聊天机器人最大的区别是“可编排”每个环节都是独立节点数据在节点之间显式流动这意味着我们可以只调中间某一环而不是把整个对话逻辑糊在一个超大提示词里。第一版工作流我建议按如下节点顺序搭别一股脑叠花活开始节点 → 接收用户消息 → 预处理代码节点 → LLM意图识别节点DeepSeek → 条件分支节点 → 高意向分支生成跟进话术 写入线索数据 → 低意向分支生成培育话术 → 结束节点每个节点的职责要单一。预处理代码节点负责把用户文本清洗一下去空行、去掉无意义的“嗯”“好的”、提取昵称和信息避免脏文本影响DeepSeek判断。LLM意图识别节点就是上一章那段Python代码做的事输出意图分和结构化标签。条件分支节点判断“意图分是否≥0.6”0.6这个阈值是第一版默认值上线后用真实会话数据再调——阈值太高会导致大量真实线索被放进培育池阈值太低又会让销售收到一堆假阳性线索。节点之间的变量命名要保持一致。我在项目里吃过亏上游节点输出叫“user_intention_score”下游条件分支里却写成“intention_score”Coze不会报错但条件判断永远走默认分支所有用户都被扔进高意向池当天收了40条垃圾线索。排查了半小时才找到是变量名拼写不一致。所以搭完工作流后第一件事是把每个节点的变量名和数据流画一遍确认上游输出和下游引用完全对齐。3.2 System Prompt模板把“销售的话术”固化成可复用的参数获客智能体的System Prompt和一般聊天机器人不一样不能只写“你是一个友好助手”。要写清楚三件事你是谁的服务者、你要从对话中得到什么、以及得到之后怎么输出。下面是我在获客项目里用的模板骨架按JSON结构化写节点解析方便{ role: AI获客助手, background: 面向B2B企业服务公司负责小程序/H5页面的首轮用户接待, task: 识别潜在客户意向收集联系方式推进到销售跟进, rules: [ 不主动编造产品价格、案例数据, 用户表达抗拒时不强行推销先记录原因, 每轮回复不超过80字, 不回答与业务无关的问题统一回复这个问题我记录下来了可以让顾问具体回答 ], output: { intent: high_interest|mid_interest|low_interest|unclear, intention_score: 0到1之间的浮点数, message: 本轮回复话术, contact_info: {phone: null, wechat: null, company: null}, pain_points: [用户原始表达的关键词列表] } }这个结构里有几个参数值得细说。rules里的“不主动编造产品价格”是必填项因为大模型在没有知识库支撑时最容易一本正经地报错价格而后端销售发现报价对不上时信任直接崩掉。回复长度控制在80字以内是为了不让智能体话痨——真实销售首轮沟通很少发长段落回太多反而降低用户回复意愿。output里的intention_score要和prompt里明确打分标准否则模型给分是玄学。我一般会在rules后面附加一段打分说明用户主动问价格、演示、时间、预算score加0.2-0.4明显在比价或已有供应商score减0.1-0.3提到“随便看看”“不需要”score直接0.2以下。把评分标准写进prompt比靠模型自己“理解”意向稳定得多。3.3 多轮对话与追问逻辑不满足“意向分≥阈值”就继续问单轮对话跑通之后紧接着的问题是用户在首轮往往不会主动留下联系方式必须靠追问。追问不能瞎问要按销售SOP的顺序来。我常用一个“缺口判断法”先把判断意向所需的信息列成清单比如联系方式、预算、采购时间、决策角色然后每一轮检查清单里有哪一项是空的只追问缺失项不重复问已拿到的东西。在Coze工作流里实现这个逻辑我会在DeepSeek节点后面加一个“缺口维护”代码节点维护一个JSON格式的会话状态# Coze代码节点根据当前已收集信息决定下一轮追问目标 import json # session_state由上游传入保存着本轮已获得的线索字段 session_state { contact_info: {phone: None, wechat: None}, budget: None, timeline: None, decision_role: None } # 按优先级判断缺口联系方式 预算 时间 决策角色 priority_order [ (contact_info.phone, 方便留个手机号吗销售顾问电话沟通更快), (contact_info.wechat, 加个微信吧我把产品资料发你), (budget, 你们这边预算大概在什么范围我帮你看哪款合适), (timeline, 预计什么时候需要上线), (decision_role, 这个项目最终是您这边定还是有其他同事一起评估) ] target None for field, question in priority_order: value session_state for key in field.split(.): if isinstance(value, dict): value value.get(key) else: value None if value is None: target question break # target为空代表所有信息都已收集交给下游转人工 result {next_question: target or ALL_INFO_READY}这段代码看着简单关键在priority_order这个列表的顺序。销售实战里“留电话”永远是最先要的但很多智能体一上来就问“你们预算多少”用户立刻警觉流失。先用低敏感问题暖场、再冲高敏感信息这种顺序是销售SOP沉淀出来的写成代码就是上面这个优先级列表。每轮跑完这个节点把新拿到的字段合并回session_state再送到DeepSeek生成下一轮话术就能形成“问缺口→收集→再问缺口”的循环。还要注意循环退出条件Coze工作流默认不会无限循环但多轮追问场景需要在一个节点上设置最大轮数比如3轮。3轮没拿全信息就转人工别让用户被绕烦了直接关页面。这个参数放到开始节点或结束节点配置不同Coze版本位置上略有差异但逻辑都是“达到轮数强制走结束分支”。4. 知识库与数据生产给智能体装存储器给线索装上打包袋4.1 搭建产品知识库文档切片的边界参数与更新策略获客智能体不能只靠System Prompt里的几句话产品功能、价格套餐、客户案例、常见问题都要靠知识库支撑。我在Coze知识库里传文档时最常踩的坑是切片粒度。切片太大比如整篇文章一个切片检索命中后DeepSeek要消化大量无关内容回答会变得又长又空切片太小比如一句话一个切片检索容易丢掉上下文答案是碎的。我一般按“一个完整业务主题”来切而不是按固定字数切。比如“私有化部署的版本差异”单独一段“API调用限制与频率”单独一段每段控制在300-600字。Coze知识库支持自定义分隔符和分段规则我习惯用“### 标题级别 固定段落长度”双重控制。分隔符用Markdown的二级标题##、三级标题###因为产品文档大多用Markdown结构写标题和正文的隶属关系天然对检索有益。分段长度上限理解好理解太短会拆散上下文太长会让检索召回的内容互相打架。知识库更新是另一件容易被忽略的事。很多团队上线时把文档传一次就再也不管三个月后产品已改版智能体还在用旧话术报旧价格。我建议把知识库视为代码库来管产品每次发版运营把变更点整理成一页变更说明手工或脚本触发更新Coze知识库中的对应条目。更新频率不用高两周一次足够了。更新后必须跑一遍回测拿上个月真实会话里的高频问题做测试集比对智能体回答是否变化。回测是唯一能拦住“更新反而改坏了”这件事的手段。4.2 从会话到线索埋点字段与线索评分模型获客智能体产出的不是“对话记录”而是“结构化线索”。我在设计输出节点时会把线索字段固定成一套标准宁可多记几个字段也不要事后补数据。常用字段如下字段名类型示例备注session_idstring20240521_001每次会话唯一用于关联对话记录user_idstringwx_89ab来自渠道平台的用户标识channelstringofficial_website区分官网/公众号/企微intention_scorefloat0.72DeepSeek输出的意向分intent_labelstringhigh_interest高/中/低意向标签contact_phone/wechatstring/null138xxxx用户主动留资脱敏后存储pain_pointslist[价格太高, 需要私有化]原始关键词供销售快速理解created_atdatetime2024-05-21 10:32标准时间戳线索评分不能只看“聊到第几轮”。我踩过的坑是一个用户聊了8轮但全是闲聊生意一点没有另一个用户问了一句“支持私有化部署吗”就走反而是精准商机。所以评分模型里我加了两个修正项命中产品关键特性词库加权重命中“询价、对比、时间、预算”这类商业信号加权重纯寒暄词不加分。这些修正逻辑可以全部写在DeepSeek的prompt里也可以抽出来做成独立代码节点——后者更容易之后调参因为不用反复改prompt触发平台审核。埋点落库方式第一版我建议走“Coze输出节点 → Webhook → 后端接口 → 数据库”的最简单链路先不要上复杂消息队列。如果公司没有后端资源也可以用Coze集成的表格插件先把线索写到在线表格里人工定期导出到CRM。在线表格方案的优势是零开发成本当天就能看到线索数据隐患是并发量大时会丢数据所以只适合一天线索量在几十条以内的阶段。5. 上线前的常见问题排查Coze工作流与DeepSeek联动的5个硬坑5.1 会话记忆越聊越乱为什么第6轮开始胡说现象用户前几轮聊得好好的到第6轮左右智能体突然忘了用户刚说过“预算是10万”开始推荐500万起的企业版方案。原因Coze对不同渠道的会话记忆机制不一样有些渠道默认只能携带最近几轮消息而DeepSeek节点如果每次只拿“最近一条消息”去分析上下文自然丢。更隐蔽的是如果上游代码节点没有正确把历史消息拼进messages数组DeepSeek看到的每一轮都是“孤零零的一句话”。解决在调用DeepSeek的代码节点里显式拼接会话历史而不是只传当前消息。具体做法是维护一个全局变量session_history每轮结束后把最新的assistant回复和user消息追加进去。注意控制历史长度我一般保留最近6轮超出6轮就把最早的对话做一次“摘要压缩”——用Coze内置模型把旧对话聚合成摘要再拼回上下文。5.2 发布到公众号/企业微信后用户点菜单和关键词触发结果不一致现象在Coze里测试一切正常发布到公众号后用户发“人工客服”四个字智能体回了产品广告。原因公众号消息分为事件消息关注、点击菜单和文本消息关键词触发不同消息类型在Coze里对应不同的触发条件测试时用文本对话线上用户用点击菜单走的是另一条入口链路数据没有跑到同一个工作流节点。解决发布前把渠道端所有入口类型各测一遍关注后的欢迎语、菜单点击、关键词回复、发送图片、发送语音。每一种入口都要绑定到正确的Coze工作流版本并确认最终都汇入同一个意图识别节点。这个坑在上线前最容易漏因为Coze测试台只模拟纯文本会话。5.3 DeepSeek返回超时或限流把工作流拖垮了现象白天10点到15点会话响应突然变慢有些用户在页面上等10秒还没回话直接关页面走了。Coze工作流里超时节点频繁报警。原因DeepSeek的API在高峰期会出现延迟波动而且Coze的HTTP请求节点默认超时时间并不长一旦请求慢下游所有节点全部卡住。这是我早期项目里最痛的一次翻车当时在线用户冲上来把并发打满连续挂了20分钟。解决做两层防御。第一层在DeepSeek调用节点外层包一层重试逻辑但重试次数只设1次且超时时间降到10秒宁可这次问不到也不要拖死整条工作流。第二层在Coze工作流里加一个“降级分支”当DeepSeek节点返回超时不要直接结束会话而是走一个内置模型的简化回应内容是“收到你的消息了稍后顾问会联系你”——无功能但维系住用户等待意愿。降级分支的配置放在条件节点里判断“is_timeout true”。5.4 知识库明明有答案智能体却答非所问现象用户在知识库里有一条“提供免费试用版”智能体却回答“试用功能暂时未开放”回看日志发现知识库命中率很低。原因用户口语表达和文档原文书面语差距太大。文档写的是“免费试用”用户说的是“能不能不花钱先看看”——向量检索对同义词和日常表达的匹配没有想象中强。另一个原因是知识库文档没有按检索友好结构组织整篇塞在一起。解决给知识库补一层“说法映射表”整理30-50条用户高频提问的同义说法分别映射到文档标准术语。比如用户说“多少钱”映射到“价格/费用”用户说“能不能便宜”映射到“套餐折扣”。映射表既可以作为知识库条目预置也可以在Coze代码节点里做一次文本改写后再检索。补完之后答非所问的概率会明显下降。5.5 测试环境好好的上线第一天线索数据全乱现象测试时线索表字段整整齐齐上线第一小时收到一批脏数据电话号码字段出现“电话是”“大概”意向分为负值。原因线上用户输入千奇百怪DeepSeek在压力下开始输出不符合JSON schema的内容而代码节点的解析逻辑只考虑了正常情况没有对字符串字段做清洗。解决在线索落地节点前加一个“数据清洗”代码节点对关键字段逐项做类型校验phone必须匹配手机号正则intention_score必须落在0-1区间不合法就置空或置默认值。清洗节点宁可丢数据也不要入库脏数据。遇到过配错正则把“400-800-1234”这种销售热线也洗掉的情况后来把规则改成“匹配大陆手机号或座机格式均可”但这事说明清洗正则要按获客渠道的实际输入来调整。6. 上线两周后我建议你做这件事用双变量对比测出智能体的真实获客率智能体上线两周、手头积累了几十条会话记录之后先别急着迭代话术做一次双变量对比测试验证这个方向到底值不值得继续投入。做法是把同一渠道、同一人群池的新用户随机分成两组A组走原来的纯人工SOPB组走“智能体首轮接待人工承接”。除了“是否使用智能体”这一个变量其他条件完全一致同样的落地页、同样的线索评分标准、同样的销售跟进SOP。两周后对比四个指标响应时长、有效线索量、高意向线索占比、线索获客成本。这个测试有两个容易被忽视的细节。一是样本量别太小每组至少跑50个有效会话否则数据波动无法区分是智能体带来的差异还是随机噪声。二是销售对A/B两组的配合度——如果销售知道哪个用户是智能体接待的会不自觉区别对待测试结果就失真了。我通常对销售隐藏分组信息只说“最近线索分配规则有调整”。测试结束看数据时我习惯先看“线索获客成本”再看“有效线索量”因为智能体可能确实带来了更多线索但如果成本没降下来商业上依然不成立。低成本地获客这才是把DeepSeekCoze这个组合用好的核心价值。去年我给一家做企业培训的公司搭过同样的获客智能体第一版上线后“高意向线索量”翻了3倍销售却抱怨线索质量差约见成功率不到原来的四成。复盘发现是意图识别阈值设得太松把所有“问了价格”的用户都标成高意向但真正能约到的人极少。后来把阈值从0.5调到0.72线索量降了一半成交率却回到正常水平。这个教训让我之后每次搭获客智能体都要先跟销售确认“假阳性线索”的代价有多大再决定阈值往哪边调。希望帮到你。本文还有配套的精品资源点击获取