企业官网建设流程全解析

简介：围绕DeepSeek+Coze构建AI获客智能体，这份实战资料面向传统行业中小老板、创业者/个人IP及销售运营人员，完整覆盖从智能体定位、业务流程梳理、痛点分析、功能需求设计到工作流搭建、测试与发布的落地路径，聚焦短视频创作与低成本获客场景。资源以单个docx文档交付，压缩包约1.75MB；文档以蛋糕店老板短视频起号为例，结合DeepSeek对账号定位、对标账号拆解、选题库搭建、内容创作拍摄等环节逐一拆解，输出表格化的痛点分析与AI可协助事项。已有627人学习/下载，适合希望用AI替代重复性分析工作、实现日更短视频与转化率提升的读者。通读后可获得一套可直接迁移的智能体构建方法论：如何设计AI协助的具体任务、编写提示词、生成涵盖账号定位与人设选题方向的结构化报告，以及人工决策与AI提效如何分工配合。这份资料的价值在于把短视频获客从经验驱动变为流程驱动，将80%的分析工作交给AI，自己专注于创意与决策。

1. AI获客智能体不是聊天机器人：DeepSeek+Coze要解决的第一件事

很多团队把“AI获客智能体”理解成“能自动回复的客服”，结果上线第一天就翻车：用户问一句，它答一句，看起来像那么回事，两周过去一条有效线索都没带回来。我做过几个类似的获客项目后最深的体会是：获客智能体的瓶颈从来不在模型智商，而在流程设计。DeepSeek+Coze这个组合，DeepSeek负责用极低的成本提供接近商用水平的对话与推理，Coze负责把对话变成可编排、可监控、可落库的工作流——两者拼起来，目标不是“会聊天”，而是“在聊天里完成获客动作”：识别意向、推进沟通、产出结构化线索。这篇文章从定位到落地，把每一步的参数、节点和坑讲清楚，适合正在做销售自动化、私域运营或线索孵化，且打算用智能体替代一部分人工SOP的团队。

2. 先定位再选架构：AI获客智能体的业务边界与两种实现路径

2.1 定位清单：动手前先问清楚4个问题

Coze和DeepSeek都是工具，工具解决不了“定义不清”的问题。我一般会拉着业务负责人先把下面几个问题过一遍，每个问题都要有数字答案，不是“大概”“尽量”这种词。

第一个问题：一条“有效线索”长什么样？常见定义是“留了联系方式且表达过明确预算/时间/痛点”的用户。这个定义要落到可判断的条件上，比如：

第二个问题：智能体是“首轮接待”还是“全流程跟进”。首轮接待的意思是，智能体负责第一轮对话，识别出高意向用户后转给销售；全流程跟进则是智能体要完成多次触达，比如5天后回访、14天后发案例。两种定位对Coze工作流的复杂度要求完全不同，全流程要接定时任务和外部触达渠道，工作量和坑会翻倍。对第一次做这个方向的项目，我建议先把首轮接待做好，拿到数据和收益后再加跟进链路。

第三个问题：谁来维护这个智能体。Coze工作流不是写完就结束的，上线后知识库要更新、话术要迭代、被打断的节点要修。如果公司没有一个人愿意承担“智能体运营”这个角色，再好的方案也会在两周内烂掉。这个岗位不一定要会写代码，但要有过销售或运营经验，能看懂会话记录并改进提示词。

第四个问题：数据怎么回流。智能体产生的对话记录、意向分、跟进结果，最终要写进CRM还是钉钉表格、企业微信侧边栏？这个决定要在设计阶段做，因为Coze的节点输出结构要提前对应数据表字段，后期改字段结构比重新搭工作流还痛苦。

2.2 DeepSeek在Coze中的两种接入方式：API直连与双模型分工

把DeepSeek接进Coze，常见做法有两种。第一种是“Coze工作流里的HTTP请求节点直接调DeepSeek API”。这种方式最直接、最可控，DeepSeek的模型能力、输出格式、成本都掌握在我们手里，不依赖Coze内置模型的市场与参数。第二种是“Coze代码节点里封装一个DeepSeek调用函数”，适合要在调用前后做额外处理的场景，比如加缓存、加重试、记录token消耗、拦截敏感输入。我一般先用第一种快速验证，等流量大了再升级到第二种。

用HTTP请求节点时，核心参数建议这样设：

下面是我在Coze代码节点里调DeepSeek时常用的一段Python，Coze国内版的代码节点跑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": f"Bearer {api_key}", "Content-Type": "application/json" }, json=payload, timeout=30 ) 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 从会话到线索：埋点字段与线索评分模型

获客智能体产出的不是“对话记录”，而是“结构化线索”。我在设计输出节点时，会把线索字段固定成一套标准，宁可多记几个字段，也不要事后补数据。常用字段如下：

线索评分不能只看“聊到第几轮”。我踩过的坑是：一个用户聊了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组走原来的纯人工SOP，B组走“智能体首轮接待+人工承接”。除了“是否使用智能体”这一个变量，其他条件完全一致：同样的落地页、同样的线索评分标准、同样的销售跟进SOP。两周后对比四个指标：响应时长、有效线索量、高意向线索占比、线索获客成本。

这个测试有两个容易被忽视的细节。一是样本量别太小，每组至少跑50个有效会话，否则数据波动无法区分是智能体带来的差异还是随机噪声。二是销售对A/B两组的配合度——如果销售知道哪个用户是智能体接待的，会不自觉区别对待，测试结果就失真了。我通常对销售隐藏分组信息，只说“最近线索分配规则有调整”。测试结束看数据时，我习惯先看“线索获客成本”再看“有效线索量”，因为智能体可能确实带来了更多线索，但如果成本没降下来，商业上依然不成立。低成本地获客，这才是把DeepSeek+Coze这个组合用好的核心价值。

去年我给一家做企业培训的公司搭过同样的获客智能体，第一版上线后“高意向线索量”翻了3倍，销售却抱怨线索质量差，约见成功率不到原来的四成。复盘发现是意图识别阈值设得太松，把所有“问了价格”的用户都标成高意向，但真正能约到的人极少。后来把阈值从0.5调到0.72，线索量降了一半，成交率却回到正常水平。这个教训让我之后每次搭获客智能体，都要先跟销售确认“假阳性线索”的代价有多大，再决定阈值往哪边调。希望帮到你。

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