企业官网建设流程全解析

1. 项目概述：当AI落地撞上“不会写代码”的现实墙

Coze、Dify、n8n——这三个名字最近在技术群、产品会议和创业团队的OKR里高频出现，几乎成了“让AI快速跑起来”的代名词。我上个月帮一家做跨境电商的客户搭自动化客服系统，老板第一句话不是问效果，而是：“能不能别让工程师天天改代码？我们招不到会Python又懂业务的全栈。”这句话背后，是成千上万中小团队的真实困境：大模型能力摆在那儿，但调用API、写提示词、串工作流、接数据库、做权限管理……每一步都卡在“需要写代码”这道门槛上。低代码不是新概念，但AI时代的低代码，核心诉求变了——它不再只是拖拽表单、生成CRUD，而是要能把大模型当“智能模块”嵌进业务流水线里，且不依赖深度开发。Coze主打“对话即产品”，Dify强调“知识即服务”，n8n则坚持“连接即智能”。它们不是替代开发者，而是把开发者从重复劳动中解放出来，去干更难的事。这篇文章不讲虚的“平台对比图”，也不堆砌参数，而是以一个真实上线的“销售线索自动分发+AI初筛+CRM同步”项目为切口，带你一层层剥开三者的底层设计逻辑、实操卡点、选型红线，以及——最关键的一点：什么场景下你必须换工具，什么情况下硬扛也能跑通。适合正在评估选型的产品经理、想快速验证AI想法的创业者、被业务方催着上线AI功能的后端/前端工程师，以及所有被“再改一行代码就上线”折磨过的技术负责人。

2. 核心思路拆解：为什么不是“哪个更好”，而是“谁在解决你的真问题”

2.1 本质差异：三款工具的“基因”完全不同

很多人一上来就比“谁的UI更炫”“谁的模板更多”“谁的中文支持更好”，这就像拿菜刀、手术刀和雕刻刀比“哪个更锋利”——脱离使用场景谈性能，纯属误导。它们的底层定位，决定了你根本没法用同一套标准去衡量。

• Coze的基因是“对话式应用工厂”。它从诞生起就锚定在“Bot”这个单一形态上，所有能力——知识库、插件、工作流、多轮对话管理——都是围绕“如何让一个Bot更像真人、更懂业务、更能自主决策”来构建的。它的“文件上传”功能，本质是给Bot喂私域资料；它的“扩展编程”，是让Bot在特定节点执行一段JS逻辑；它的“团队空间”，核心是多人协同调试同一个Bot的行为。Coze不是通用工作流引擎，它是高度垂直的对话智能体操作系统。所以当你看到“coze智能体”“coze对话流”这些热词时，背后是大量用户在用它快速搭建客服机器人、内部知识助手、甚至营销话术教练。它的优势在于“快”和“轻”，劣势在于“窄”——一旦需求跳出对话交互范畴（比如要定时拉取Excel数据、要生成PDF报告、要调用内部ERP的SOAP接口），Coze就会显得力不从心，因为它的架构没为这些留出入口。

• Dify的基因是“AI应用交付平台”。它把整个AI应用的生命周期——从模型选型、提示工程、知识库构建、评估测试、到上线发布、灰度监控——全部纳入一个可管理的闭环。Dify的“知识库流水线”不是简单上传PDF，而是内置了文档解析、向量化、chunk策略、重排序等一整套RAG工程链路；它的“工作流”不是图形化连线，而是基于YAML或可视化编排的、可版本控制的AI任务流；它的“本地部署教程”之所以被高频搜索，正是因为Dify的设计哲学是“企业级可控”——你可以完全掌控模型、数据、日志、权限。所以“dify本地部署教程”“dify企业版多租户”这些词热度高，说明用户要的不是玩具，而是能放进生产环境、符合安全审计要求的AI基础设施。Dify的强项是“稳”和“全”，弱项是“重”——对小团队来说，光是理解它的“应用-数据集-模型提供方-提示模板”四层抽象，就需要半天时间。

• n8n的基因是“自动化连接器网络”。它压根不碰大模型的推理、训练、知识库这些事，它的全部价值在于“连接”。n8n的“credentials”（凭证管理）是其灵魂——它把GitHub、Slack、Notion、MySQL、PostgreSQL、甚至自建HTTP API的认证方式，全部抽象成标准化的“节点”，你只需一次配置，后续所有流程复用。它的“工作流”是真正的无状态、可编排、可调试的异步任务流。当搜索词里出现“n8n企业级部署方案”“n8n使用ai agent”时，背后是用户在用n8n串联起“用户在Web表单提交线索 → n8n触发Dify API进行意图识别 → Dify返回结果 → n8n根据结果路由到不同Salesforce队列 → 同时调用Coze Bot发送欢迎消息”这样的跨平台、跨协议、跨权限体系的复杂链路。n8n的强项是“韧”和“广”，弱项是“浅”——它不帮你优化提示词，不帮你清洗知识库，不帮你做A/B测试，它只确保数据能准确、可靠、按规则地从A点送到B点。

提示：选型的第一步，永远不是打开三个官网看功能列表，而是拿出一张纸，写下你当前最急迫的3个具体需求。如果其中2个以上是“做一个能回答客户问题的Bot”，Coze是最快路径；如果核心诉求是“把公司三年的合同PDF变成可搜索、可引用的知识服务”，Dify是唯一选择；如果你的需求描述里反复出现“然后同步到XXX”“再通知XXX”“最后存入XXX”，那n8n就是你的地基。

2.2 选型决策树：用5个关键问题锁定答案

我给客户做选型咨询时，必问以下5个问题，答案组合直接指向最优解。这些问题不涉及技术细节，全是业务语言，产品经理和业务方都能参与判断：

1. 你的核心交付物是什么形态？

   • 是一个独立的聊天窗口（网页/小程序/APP内嵌Bot）？→ 倾向Coze。
   • 是一个嵌入现有系统（如CRM、ERP）的AI能力模块（例如“在客户详情页旁加一个‘智能摘要’按钮”）？→ 倾向Dify。
   • 是一套后台自动运行、无人值守的数据搬运与处理流程（例如“每天早上9点抓取竞品价格，分析波动，邮件通知运营”）？→ 倾向n8n。

2. 你的数据主权和合规要求有多高？

   • 可以接受数据上传到第三方云服务，只要不涉密？→ Coze或Dify云版均可。
   • 必须所有数据（包括原始文档、向量库、日志）100%留在自己服务器？→ Dify本地部署是成熟方案，Coze目前无官方私有化选项，n8n原生支持全栈私有化。
   • 需要满足等保三级、GDPR或行业特定审计？→ Dify和n8n的企业版提供完整的权限、审计、水印、加密方案，Coze云版对此类需求支持有限。

3. 你的团队技术栈和运维能力如何？

   • 团队只有1个前端，会写JS但不懂Docker？→ Coze的“扣子编程”扩展是最佳起点，几行JS就能增强Bot逻辑。
   • 有DevOps工程师，熟悉Kubernetes和CI/CD？→ Dify的Helm Chart和n8n的K8s Operator都是为这类团队设计的。
   • 完全没有专职运维，靠外包或云厂商托管？→ Dify的Docker Compose一键部署和n8n的Docker镜像最友好，Coze云版则完全免运维。

4. 你的AI能力需要多深的定制？

   • 主要靠调整提示词、上传文档、开关几个插件就能满足？→ Coze的“对话流”和Dify的“提示模板”足够。
   • 需要深度干预RAG流程（例如自定义chunk大小、替换embedding模型、添加重排序器）？→ Dify的“知识库高级设置”和“自定义LLM Provider”是刚需。
   • 需要将AI输出作为中间变量，参与复杂的条件分支、循环、聚合计算？→ n8n的“Function”节点和“IF”节点组合，比任何平台的“工作流”都灵活。

5. 你的长期演进路径是什么？

   • 目标是快速验证一个点子，3个月内看效果，不行就砍掉？→ Coze的“创建Bot→发布链接→分享测试”5分钟闭环，效率无敌。
   • 目标是构建公司级AI中台，未来要接入10+业务系统，支撑50+AI应用？→ Dify的“多应用管理”和n8n的“工作流市场”是可持续架构的基础。
   • 目标是让业务人员（非技术人员）能自主创建、修改、发布自动化流程？→ n8n的“User Management”和“Workflow Sharing”权限粒度最细，Coze的“团队空间”次之，Dify目前仍偏技术侧。

注意：不存在“永远正确”的选择。我见过客户先用Coze上线客服Bot，3个月后因知识库更新频繁、需对接内部审批流，果断将Bot后端迁移到Dify，再用n8n把Dify的API调用封装成标准节点供其他流程复用。这种“组合拳”才是真实世界的常态。

3. 核心细节解析与实操要点：避开那些官网绝不会告诉你的坑

3.1 Coze：对话流的“隐形天花板”与突破技巧

Coze的易用性是双刃剑。它的“对话流”可视化编辑器让你感觉一切尽在掌握，但实际深入后，会发现几处关键限制，而这些恰恰是决定项目成败的“隐形天花板”。

• 文件上传的格式与解析陷阱：
  热搜词“coze文件上传”背后，是大量用户踩过的坑。Coze支持PDF、Word、TXT、Markdown，但不支持Excel和PPT。更关键的是，它的文档解析并非“全文OCR”，而是依赖文本提取库（如pdfplumber）。这意味着：

  • 扫描版PDF（图片型）会被当作空白文件；
  • 表格内容会被打乱成无序段落；
  • 页眉页脚、页码、水印会被错误识别为正文。
    实测下来，一个100页的合同PDF，Coze解析后有效信息丢失率高达30%。破局技巧：在上传前，用开源工具pdf2image+pytesseract做预处理，将PDF转为高清图片，再用OCR提取纯文本，最后人工校对关键条款（如金额、日期、违约责任），保存为Cleaned.txt再上传。这不是Coze的缺陷，而是所有SaaS文档解析服务的共性，但Coze没在UI里提示你这一点。

• 工作流节点的“黑盒”与调试盲区：
  “coze工作流”允许你添加“HTTP请求”“数据库查询”等节点，但它的调试体验极差。当你在工作流中调用一个外部API失败时，Coze只显示“Node execution failed”，不返回任何HTTP状态码、响应头、错误日志。你无法判断是网络超时、认证失败、还是对方API返回了500。
  破局技巧：永远不要在Coze工作流里直接调用生产环境API。先用Postman或curl模拟请求，拿到完整响应；再在Coze工作流中，用“Function”节点写一段JS，手动发起fetch，并用try...catch捕获并console.log所有细节；最后，把这段JS逻辑封装成一个独立的、带详细日志的微服务（哪怕只是个Flask小API），让Coze只调用这个“日志友好型”服务。这多了一步，但省去了90%的排查时间。

• 团队协作的“空间”悖论：
  “coze 团队空间 在哪里”是高频搜索词，说明用户期待它像Git一样支持分支、合并、Code Review。但现实是，Coze的团队空间只是一个共享的Bot列表和知识库集合，所有成员对同一个Bot拥有完全相同的编辑权限，且无操作历史追溯。A同事改了提示词，B同事不知道；C同事删了某个插件，没人知道何时删的。
  破局技巧：把Coze当成“最终发布环境”，而非“开发环境”。所有Bot的开发、测试、版本管理，都在本地用VS Code完成。利用Coze的OpenAPI，写一个简单的CLI工具，实现coze push（将本地JSON配置推送到Coze）和coze pull（将线上配置拉回本地）。这样，你的Git仓库里存着所有Bot的完整历史，团队协作回归到熟悉的PR流程。

3.2 Dify：本地部署的“拉取镜像失败”与稳定之道

“dify拉取镜像失败”是Dify社区最常刷屏的问题。表面看是网络问题，深层原因是Dify的部署模型对基础设施有隐性要求，而官方文档对此语焉不详。

• 镜像拉取失败的三大元凶：

  1. Docker Hub限速：Dify的dify-main镜像托管在Docker Hub，免费账户有下载速率和频次限制。国内服务器直连，经常卡在Pulling fs layer。
  2. 镜像体积过大：Dify 1.17.1的dify-main镜像超过2GB，对磁盘IO和网络带宽是考验。
  3. 依赖镜像缺失：Dify依赖redis:alpine、postgres:15-alpine等多个基础镜像，如果本地Docker Registry没提前缓存，docker-compose up会逐个拉取，任何一个失败都会中断。

  破局技巧（亲测有效）：

  • 第一步，更换镜像源。在/etc/docker/daemon.json中添加国内加速器（如阿里云、腾讯云），重启Docker。
  • 第二步，离线预拉取。在一台网络通畅的机器上，执行：

    docker pull difyai/dify:1.17.1 docker pull redis:alpine docker pull postgres:15-alpine docker save difyai/dify:1.17.1 redis:alpine postgres:15-alpine > dify-offline.tar

    将dify-offline.tar拷贝到目标服务器，执行docker load < dify-offline.tar。
  • 第三步，精简启动。Dify默认启动所有服务（Web、Worker、Celery Beat），但初期验证只需Web服务。修改docker-compose.yml，注释掉worker和celery-beat服务，docker-compose up -d web即可秒启。

• 知识库流水线的“静默失败”与质量保障：
  Dify的“知识库流水线”强大，但也容易“静默失败”。例如，你上传一个包含100个PDF的知识库，Dify UI显示“处理完成”，但实际只有30个被成功向量化。原因可能是：

  • 某个PDF密码保护，解析器跳过；
  • 某个PDF编码异常，导致chunk切分失败；
  • 向量数据库（如Weaviate）连接不稳定，部分embedding写入失败。
    Dify不会告诉你哪30个失败了，只会给你一个笼统的“成功率70%”。
    破局技巧：启用Dify的LOG_LEVEL=DEBUG环境变量，查看docker logs -f dify-web。在日志中搜索document_processing_failed，你会看到详细的失败文档名和错误堆栈。更进一步，写一个Python脚本，定期调用Dify的Admin API（GET /api/v1/knowledge-bases/{kb_id}/documents），获取每个文档的indexing_status，自动生成日报邮件。这才是企业级知识库该有的可观测性。

• 多租户与权限的“灰色地带”：
  “dify社区版1.10多租户”是热门搜索，但Dify社区版的“多租户”仅指“一个Dify实例可管理多个独立知识库”，并非SaaS意义上的租户隔离。所有租户共享同一个数据库、同一个向量库、同一个模型API Key。这意味着：

  • 租户A的知识库，理论上可以被租户B的API调用访问（如果B拿到了A的API Key）；
  • 租户A的管理员，可以看到所有租户的系统日志。
    破局技巧：若真有严格多租户需求，必须上Dify企业版，或自行改造。社区版的务实做法是：用n8n作为API网关，在n8n里做租户鉴权、请求路由、配额限制。所有业务系统只对接n8n，n8n再根据Header里的X-Tenant-ID，决定调用哪个Dify知识库的API。这增加了架构复杂度，但换来了真正的租户边界。

3.3 n8n：中文支持的“表面功夫”与深度本地化

“n8n中文”是搜索热词，但n8n的中文支持停留在UI翻译层面。它的核心能力——节点逻辑、错误信息、日志输出——依然是英文。这对一线运维是巨大挑战。

• Credentials（凭证）管理的“中文幻觉”：
  n8n的“credentials”是其安全基石，但它的UI翻译存在严重错漏。例如，OAuth2 Generic节点的“Authorization URL”被翻译成“授权网址”，但实际配置时，你必须填入标准的OAuth2 URL（如https://accounts.google.com/o/oauth2/v2/auth），填“授权网址”会直接报错。更麻烦的是，当凭证配置错误时，n8n只在日志里输出Error: invalid_grant，中文用户根本不知道这是“授权码已过期”还是“重定向URI不匹配”。
  破局技巧：永远以英文文档为准。在n8n UI右上角，点击用户头像 → “Settings” → “Language” → 切换为“English”。虽然UI变英文，但所有节点的配置说明、错误提示、日志都变得精准可查。同时，在团队Wiki里，建立一份《n8n中文配置速查表》，把高频节点（如HTTP Request、Cron、Database）的每个字段，用中文标注“标准值”“常见错误”“调试方法”，这才是真正提升效率的做法。

• 工作流调试的“断点缺失”之痛：
  n8n的工作流是异步的，节点间通过JSON传递数据。当你发现第5个节点输出异常时，传统IDE的“断点调试”在这里失效。你只能靠在每个节点后加一个“Debug”节点，把数据打印到日志里，再肉眼比对。对于一个20个节点的复杂工作流，这无异于大海捞针。
  破局技巧：善用n8n的“Execute Workflow”功能。在工作流编辑页，点击右上角“…”，选择“Execute Workflow”，然后手动输入一个JSON payload，模拟上游数据。这样，你可以单步执行整个工作流，每个节点的输入输出都清晰可见，还能在任意节点暂停、修改数据、继续执行。这相当于给n8n装上了IDE级别的调试器。另外，强烈推荐安装社区节点n8n-nodes-debugger，它能在工作流中插入一个“Debugger”节点，点击即可在UI里实时查看上下文变量，比纯日志高效十倍。

• 企业级部署的“高可用”幻象：
  “n8n企业级部署方案”搜索量高，但n8n开源版的高可用（HA）是伪命题。它的核心服务n8n是单进程的，无法像Nginx那样做负载均衡。你部署10个n8n实例，它们之间不共享执行队列、不共享凭证、不共享工作流状态。一个工作流在实例A上触发，不可能在实例B上执行。
  破局技巧：真正的企业级部署，必须引入消息队列（如Redis或RabbitMQ）作为中央任务队列。你需要：

  1. 部署一个独立的Redis集群；
  2. 修改n8n的generic配置，将queue.bull.redis指向该集群；
  3. 启动多个n8n实例，都连接到同一个Redis队列；
  4. 所有工作流的执行，都由Redis统一调度，实例只负责消费任务。
     这需要一定的DevOps能力，但这是n8n HA的唯一正解。官方文档对此轻描淡写，但社区实践早已证明此路可行。

4. 实操过程与核心环节实现：一个销售线索分发系统的完整构建

4.1 项目背景与架构设计

客户是一家B2B SaaS公司，每天通过官网表单、微信公众号、线下展会收集约200条销售线索。线索需按地域、行业、预算等级，分发给对应销售代表，并由AI对线索做初步资质审核（如公司规模、官网可信度、联系人职位），生成简要报告。过去靠销售助理手工分发，平均响应时间4小时，线索流失率35%。目标：将响应时间压缩至15分钟内，流失率降至10%以下。

经过前述5个问题的诊断，我们确定采用Coze + Dify + n8n 组合架构：

• Coze：作为面向客户的“线索提交Bot”，嵌入官网和微信公众号，提供友好的对话式表单填写体验；
• Dify：作为AI审核引擎，加载公司公开信息、行业白皮书、销售SOP知识库，对每条线索生成结构化评估报告；
• n8n：作为中枢调度器，接收Coze的线索数据，调用Dify API，解析Dify返回的JSON报告，执行分发逻辑（查CRM、路由、发邮件、发企微通知），并记录全链路日志。

整个系统不碰客户核心CRM（Salesforce），所有集成通过其公开API完成，符合客户的安全红线。

4.2 Coze端：打造零摩擦的线索入口

步骤1：创建Bot并配置对话流

• 在Coze控制台，新建Bot，命名为“Sales-Lead-Collector”。
• 在“对话流”中，删除默认节点，添加“Start” → “Ask Question”（问公司名称）→ “Ask Question”（问联系人姓名）→ “Ask Question”（问联系电话）→ “Ask Question”（问预算范围，用选项：10万以下/10-50万/50万以上）→ “Ask Question”（问行业，用选项：金融/制造/零售/互联网/其他）。
• 关键技巧：在每个“Ask Question”节点，开启“Required”并设置“Validation Regex”，例如电话号码用^1[3-9]\d{9}$，避免无效数据污染下游。

步骤2：对接n8n Webhook

• 在“对话流”末尾，添加“HTTP Request”节点。
• Method选POST，URL填n8n的Webhook地址（如https://your-n8n.com/webhook/lead-collect）。
• Body选JSON，内容为：

  { "company": "{{ $input.first().json.company }}", "contact_name": "{{ $input.first().json.contact_name }}", "phone": "{{ $input.first().json.phone }}", "budget": "{{ $input.first().json.budget }}", "industry": "{{ $input.first().json.industry }}" }

• 避坑点：Coze的$input.first().json.xxx语法，必须确保上游节点确实输出了json格式。如果上游是“Text”节点，需先用“Function”节点转换：return { json: { company: $input.first().text } };。

步骤3：发布与嵌入

• 发布Bot，获取“Web Embed”代码。
• 将代码粘贴到官网表单页面的<body>底部。
• 在微信公众号后台，将Bot的“分享链接”设置为菜单栏入口。
• 实测心得：Coze Bot在微信内加载慢（首次需3-5秒），建议在公众号菜单文案中加一句“请稍候，AI正在为您准备专属表单”，降低用户流失。

4.3 Dify端：构建可信赖的AI审核引擎

步骤1：本地部署Dify 1.17.1

• 按前述“离线预拉取”方案，在服务器上执行：

  # 解压Dify源码 tar -xzf dify-main-1.17.1.tar.gz cd dify-main-1.17.1 # 复制环境变量模板 cp .env.example .env # 编辑.env，设置： # DATABASE_URL=postgresql://dify:dify@postgres:5432/dify # REDIS_URL=redis://redis:6379/0 # SECRET_KEY=your-strong-secret-key # MODEL_PROVIDER=anthropic # 或 openai, azure # ANTHROPIC_API_KEY=your-key # 启动（仅Web） docker-compose up -d web

步骤2：创建知识库与流水线

• 登录Dify Web UI（http://your-server:3000），创建知识库“Sales-SOP-KB”。
• 上传3份核心文档：《销售线索分级标准V2.1》《重点行业客户画像》《竞品公司资质核查指南》。
• 在“高级设置”中：
  • Chunk Size设为512（平衡精度与召回）；
  • Embedding Model选text-embedding-3-small（成本与效果平衡）；
  • 开启“Automatic Chunking”和“Content Cleaning”。
• 创建应用“Lead-Reviewer”，选择“Chat App”类型，绑定此知识库。

步骤3：设计提示词与API

• 在“Prompt”编辑区，写入：

  你是一位资深B2B销售专家，请根据提供的线索信息和知识库，严格按以下JSON格式输出评估报告： { "score": 0-100的整数, "reason": "不超过100字的评分依据", "risk_level": "低/中/高", "next_step": "立即跟进/24小时内跟进/暂存观察" } 线索信息：公司={{company}}，联系人={{contact_name}}，电话={{phone}}，预算={{budget}}，行业={{industry}}

• 保存后，在“API Keys”中创建一个Key，记下Authorization: Bearer <key>。
• 关键验证：用curl测试API：

  curl -X POST "http://localhost:3000/api/v1/chat-messages" \ -H "Authorization: Bearer <key>" \ -H "Content-Type: application/json" \ -d '{ "inputs": {"company":"ABC科技","contact_name":"张三","phone":"13800138000","budget":"10-50万","industry":"互联网"}, "query": "请评估此线索", "response_mode": "blocking" }'

  确保返回200和正确的JSON结构。

4.4 n8n端：编织坚不可摧的自动化神经

步骤1：创建Webhook触发器

• 新建工作流，添加“Webhook”节点。
• Method选POST，Path填/webhook/lead-collect，Response Mode选Send Back Response。
• 在“Response Parameters”中，Body填：{"status": "received", "id": "{{$node["Webhook"].json["id"]}}"}，确保Coze收到即时确认。

步骤2：调用Dify API

• 添加“HTTP Request”节点，连接Webhook。
• Method选POST，URL填http://dify-web:3000/api/v1/chat-messages（注意：这里是Docker内部网络地址，不是公网）。
• Headers加：Authorization: Bearer <dify-api-key>和Content-Type: application/json。
• Body填：

  { "inputs": { "company": "{{$node["Webhook"].json["company"]}}", "contact_name": "{{$node["Webhook"].json["contact_name"]}}", "phone": "{{$node["Webhook"].json["phone"]}}", "budget": "{{$node["Webhook"].json["budget"]}}", "industry": "{{$node["Webhook"].json["industry"]}}" }, "query": "请评估此线索", "response_mode": "blocking" }

• 关键配置：在“Options” → “Retry on Fail”中，设置Max Attempts为3，Interval为1000ms。这是应对Dify偶尔的502错误的必备保险。

步骤3：解析与分发

• 添加“Function”节点，解析Dify返回的JSON：

  // 获取Dify响应 const response = $input.first().json; // 解析JSON字符串（Dify返回的是字符串化的JSON） const report = JSON.parse(response.answer); // 设置输出 return [ { json: { lead_id: $input.first().json.id, score: report.score, risk_level: report.risk_level, next_step: report.next_step, company: $input.first().json.company, contact_name: $input.first().json.contact_name, phone: $input.first().json.phone } } ];

• 添加“IF”节点，根据score分流：
  • score >= 80→ 高优先级；
  • 60 <= score < 80→ 中优先级；
  • score < 60→ 低优先级。
• 每个分支后，接“Salesforce”节点（需先配置Credentials），执行Create Record，将线索写入Salesforce Lead对象，并填充Score__c、Risk_Level__c等自定义字段。
• 同时，接“Email”节点（SMTP配置），向销售代表发送邮件，主题为“【高优】新线索：{{ $input.first().json.company }}”，正文包含Dify报告摘要。
• 最后，接“Enterprise WeChat”节点，向销售代表的企微发送通知卡片，点击可直达Salesforce记录。

步骤4：错误处理与监控

• 在每个关键节点（HTTP Request、Salesforce、Email）后，添加“Catch”节点。
• “Catch”节点连接到一个“Telegram”节点，发送告警：“线索分发失败！ID: {{$input.first().json.id}}，错误：{{$error.message}}”。
• 添加“Cron”节点，每天凌晨2点触发，调用n8n的Admin API，统计昨日工作流执行次数、成功率、平均耗时，生成报表发给技术负责人。
• 终极保障：在n8n的settings中，开启EXECUTIONS_DATA_PRUNE，设置pruneDataAfterHours: 24，防止日志无限膨胀拖垮服务器。

5. 常见问题与排查技巧实录：来自真实战场的血泪经验

5.1 Coze高频问题速查表

5.2 Dify本地部署问题速查表