最近很多读者在后台留言说自己一直在用 ChatGPT 这类通用对话工具但一旦遇到需要“多步骤、有判断、要对接内部数据”的职场任务就发现大模型单靠对话根本搞不定。也有不少同学听说过 Coze、Dify但分不清两者到底有啥区别更不知道该先用哪个、怎么用。这篇文章我准备把 Coze 和 Dify 的工作流能力放到一起讲用一个完整的职场案例从平台选择、环境准备、节点设计到最终跑通全程带你实操一遍。文章会尽量避开那种“只讲概念、不动手”的写法每一步都给出可复制的提示词、配置项和运行逻辑。零基础的同学可以按步骤照做已经在用 AI 工具的开发者也能从中获得一些工程化落地的思路。1. 背景与核心概念1.1 为什么职场 AI 需要工作流先想一个很常见的场景你在公司每周都要写周报需要从聊天记录、项目文档、运维平台里收集信息再按固定模板总结成周报最后还要翻译成英文版发送给外方负责人。这件事看起来简单但实际做起来很烦因为大模型一次对话只能做“一轮输入、一轮输出”它不会主动去查你昨天的 git 提交记录也不会自动按照公司周报模板调整格式。单纯的对话式 AI 在这里就暴露了短板它缺少“流程编排”能力也就是把大任务拆成多个小步骤并在步骤之间传递数据、做判断、调工具。所谓工作流Workflow就是把 AI 能力编排成一个可重复执行的流程。你可以把它理解成一条生产线原料进来经过若干道工序每一步输出给下一步最后产出成品。工作流中的每个节点可以是大模型调用、代码执行、条件判断、HTTP 请求、数据库查询也可以是知识库检索。这样做的最大好处是稳定、可控、可复用而这恰恰是企业级应用最看重的东西。1.2 Coze扣子到底是什么Coze 是字节跳动推出的 AI 智能体开发平台国内版叫“扣子”。这个平台最大的特点是上手门槛极低它把大模型、插件、知识库、工作流、定时任务、卡片消息等能力做成了可视化积木。你不需要写太多后端代码拖拽节点、填写参数、写提示词就能发布一个可用的 Bot 或工作流。Coze 的优势体现在几个方面内置了大量国内可用的插件比如新闻搜索、图片生成、天气查询、网页解析等省去了自己对接 API 的麻烦。支持发布到飞书、微信公众号、抖音等渠道非常适合国内办公生态。工作流编辑器做得比较友好对非程序员很友好。不过Coze 也有自己的限制。比如它作为一个托管平台底层模型、插件调用逻辑、数据存储位置都是平台帮你管理的你做深度定制时会有边界。对于企业内网部署、私有化数据、深度定制模型路由这类需求Coze 就不太合适了。1.3 Dify 又是什么Dify 是一个开源的大模型应用开发平台可以理解为一套“自托管的 AI 应用后端”。它同样提供可视化编排但更强调开发者的掌控力。你可以通过 Docker 一键部署在自己的服务器上数据自己管、模型自己配甚至可以把平台能力通过 API 暴露给你现有的业务系统。Dify 的核心能力包括应用编排支持 Agent智能体、Chatflow对话流、Workflow工作流三种模式。知识库支持文档上传、分段、向量化方便做 RAG检索增强生成。模型管理支持 OpenAI、Azure OpenAI、各类国产大模型、本地模型等多种接入方式。开源生态环境允许时可以自由修改源码也可以调用 API 做二次开发。所以Coze 和 Dify 并不完全是替代关系更像是在“快速搭建”和“深度掌控”之间做取舍。个人用、做原型、发布到国内办公软件Coze 很顺手企业私有化、数据合规要求高、需要深度集成到自己系统里时Dify 更合适。1.4 两者的工作流设计差异尽管 Coze 和 Dify 都有可视化工作流但设计逻辑有差异。Coze 的工作流更偏向“Bot 内部流程”。你通常是在做一个智能体的过程中把某个环节扩展成一个工作流比如先让 Bot 判断用户意图然后进入不同工作流处理。Coze 对插件的支持非常丰富流程节点之间连接比较简单适合快速做原型。Dify 的工作流则更偏向“独立应用”。你可以创建一个纯粹的 Workflow 应用直接通过 API 触发也可以把它嵌入到 Chatflow 的某个节点中。Dify 的节点类型也更偏后端工程比如代码节点支持 Python/Node.jsHTTP 节点可以做请求转发逻辑判断节点可以写复杂条件。从学习角度看建议你先玩熟 Coze 的工作流理解节点、变量、连接这些基本概念再到 Dify 里去落地更正式的应用。两者概念相通一通百通。2. 环境准备与版本说明2.1 注册和登录如果你用的是 Coze 国内版直接访问扣子官网用手机号或抖音账号登录即可。Coze 海外版coze.com对网络环境有额外要求而且模型和插件生态跟国内版差异较大不建议新手一上来就用海外版。本文示例均以 Coze 国内版为准你在操作时界面可能会有细微差别但核心流程一致。Dify 方面有两种使用方式访问 Dify 官方云服务cloud.dify.ai注册账号后可以直接使用适合快速体验。在自有服务器上用 Docker 部署社区版适合数据敏感或个人开发环境。本文以 Docker 本地部署为例因为社区版的功能完整且是很多公司实际落地的方案。2.2 Docker 环境Dify 社区版通常通过 Docker Compose 启动。你需要先安装 Docker 和 Docker Compose 插件。以下是各平台的基础准备Windows安装 Docker Desktop并确保 WSL2 后端可用。macOS安装 Docker Desktop for Mac。LinuxUbuntu/Debian 为例安装 docker-ce 和 docker-compose-plugin。安装完成后检查版本docker --version docker compose version本文不写死具体版本因为 Dify 迭代速度很快你应当按照官方仓库的最新发布版本操作。只要 Docker 环境正常下面的启动命令是通用的。2.3 启动 Dify 社区版Dify 官方提供了完整的 docker 目录包含后端 API、Worker、Web 前端、PostgreSQL、Redis、Weaviate 等组件。启动步骤如下# 1. 克隆或下载 Dify 源码包 git clone https://github.com/langgenius/dify.git # 2. 进入 docker 目录 cd dify/docker # 3. 复制环境变量文件 cp .env.example .env # 4. 构建并启动容器 docker compose up -d第一次启动需要拉取多个镜像耗时取决于网络环境。启动完成后浏览器访问 http://localhost 即可打开 Dify 控制台。如果端口被占用可以修改.env文件中的EXPOSE_NGINX_PORT变量。这里提醒一下Dify 部署完成后还需要在控制台里配置模型供应商。你可以填入自己的 OpenAI API Key、DeepSeek API Key、通义千问 API Key 等。具体用哪个模型取决于你的应用场景和成本预算。2.4 大模型 API Key无论使用 Coze 还是 Dify都需要模型能力。Coze 国内版默认集成了豆包等模型你不太需要关心模型 API Key但在 Dify 里模型是需要自己配置的。如果你没有可用的模型服务可以考虑以下几个方向国内大模型厂商提供的 OpenAI 兼容接口例如 DeepSeek、智谱、通义千问等。本地部署 Ollama 开源模型。公司内部已有的大模型网关。不同模型对提示词的理解能力有差异本文中的提示词示例以通用模型为基准编写切换到具体模型时建议先跑几轮测试再微调。2.5 示例项目整体规划为了把 Coze 和 Dify 都讲透我们做一个常见的职场任务自动生成项目周报。需求背景是这样的输入本周的项目进展要点可以是零散笔记也可以是结构化数据。输出一篇符合公司规范的项目周报包括本周进展、风险与问题、下周计划三部分。进阶需求根据风险描述自动判断风险等级高/中/低并在周报中突出显示。这个任务非常适合用工作流来演示因为它包含典型的步骤文本预处理把用户输入整理成标准格式。信息抽取从笔记中提取进展、风险、计划。逻辑判断对风险进行分级。内容生成按照模板生成周报。可选优化生成摘要或翻译版本。接下来我们先用 Coze 来实现这套流程再在 Dify 中用另一种方式复现最后对比两者的差异。3. 工作流核心原理拆解3.1 工作流的基本组成一个工作流通常由三部分组成触发方式、节点和连接。触发方式决定了工作流什么时候开始运行节点是每一步处理逻辑的载体连接则定义了数据如何流动。用函数来类比def generate_weekly_report(raw_notes: str) - str: # 节点1信息抽取 progress, risks, plans extract_info(raw_notes) # 节点2风险分级 risk_level judge_risk(risks) # 节点3模板生成 report format_report(progress, risks, plans, risk_level) return report可以看到同一个函数里每一步都是确定的输入是什么、输出是什么、依赖哪个节点一目了然。这就是工作流“可视化编程”的核心思想。3.2 节点类型在 Coze 和 Dify 中常见的节点类型包括节点类型作用典型使用场景开始节点定义工作流的输入变量接收用户原始输入大模型节点调用 LLM 执行文本处理信息抽取、内容生成代码节点执行 Python/JS 逻辑数据清洗、格式转换条件判断节点根据条件走不同分支风险等级分流知识库检索节点检索向量数据库引用公司规范文档HTTP 请求节点调用外部 API推送周报到钉钉/飞书结束节点定义最终输出返回生成的周报文本不同平台的节点命名可能会有差异比如 Coze 里叫“意图识别”Dify 里叫“问题分类器”但本质上都是条件分支的变种。你只要掌握了“输入-处理-输出”这个模型任何节点都能快速上手。3.3 变量的作用域新手最容易踩的坑就是变量引用。工作流节点之间传递数据靠的是变量名。比如大模型节点输出一个字段叫report_content后续节点要用它就得写{{report_content}}或从节点输出里选中这个字段。在 Coze 中节点之间用连线传递数据变量面板会提示可用字段。在 Dify 中你可以在节点右侧的“变量”面板里看到上游节点的全部输出字段也可以直接输入{{#节点ID.output#}}来引用。这种做法比硬编码好在哪假设你最后要在周报末尾加上一个“风险等级为高”的提醒这个提醒文本是由风险分级节点决定的。如果工作流写死了“风险低”那下次遇到高风险场景就会出错。用变量引用之后这个提醒会随着分级节点的输出自动变化。3.4 提示词在工作流中的设计方法大模型节点是整个工作流的核心而提示词决定了模型的输出质量。工作流中的提示词与普通聊天提示词有一个重要区别它必须面向“结构化输入输出”。我们来看一个信息抽取节点的提示词示例你是项目周报助手。请从用户的原始笔记中抽取以下字段 1. 本周进展 progress一段话总结 2. 风险与问题 risks列表形式每项一句话 3. 下周计划 plans列表形式每项一句话 要求 - 只输出 JSON 格式不要输出任何解释 - 如果某项没有内容对应字段输出空列表或“无” 原始笔记 {{input}} 输出格式 {progress: ..., risks: [...], plans: [...]}这段提示词有几个关键点明确角色。定义了输出字段和格式。限制了输出内容防止模型“自由发挥”。使用变量{{input}}接收上游数据。在工作流里提示词就是把人的业务逻辑“翻译”给模型听。你设计得越精确后续节点的处理就越省事。4. 完整实战案例在 Coze 中搭建项目周报工作流4.1 需求分析与整体流程在 Coze 中我们先创建一个空白工作流命名为“项目周报生成器”。整个流程设计如下用户输入原始笔记 ↓ [开始节点] 定义 input 变量 ↓ [信息抽取节点] 大模型调用输出结构化 JSON ↓ [风险分级节点] 条件判断根据 risks 内容判断风险等级 ↓ [周报生成节点] 大模型调用按模板生成最终周报 ↓ [结束节点] 输出周报文本这里的信息抽取节点和风险分级节点是核心。为什么要把信息抽取和周报生成拆成两个大模型调用而不是一次完成因为一次完成虽然快但输出不稳定。你把抽取和生成分开后抽取结果可以被风险分级节点复用而且后续如果业务方要求周报模板调整只需要修改生成节点的提示词即可不需要动抽取逻辑。4.2 创建项目结构登录 Coze 控制台后点击“工作流”选项卡新建工作流。命名为“项目周报生成器”描述填写“根据用户的零散笔记生成结构化项目周报”。创建成功后你会看到画布上有开始节点和结束节点。4.3 配置开始节点点击开始节点添加输入变量变量名input类型String描述用户输入的原始项目笔记这个变量会作为工作流的入口数据。4.4 编写信息抽取节点从节点库中拖入一个大模型节点连接在开始节点后面。节点名称改为“信息抽取”。模型选择国内版 Coze 默认提供豆包系列模型你可以选择性价比高的版本。如果你在自定义配置中接入了其他模型也可以切换。系统提示词你是一个项目周报信息抽取器。用户会输入一段项目笔记你需要从中提取以下内容 - progress: 本周完成的事项用一段话描述 - risks: 风险与问题用列表列出每一项不超过20个字 - plans: 下周计划用列表列出每一项不超过20个字 只输出 JSON不要输出任何解释。JSON 格式如下 {progress: 本周完成了..., risks: [风险1, 风险2], plans: [计划1, 计划2]} 如果笔记中没有某项内容对应字段输出空数组或暂无。用户提示词项目笔记内容如下 {{input}} 请提取并输出 JSON。变量{{input}}就是开始节点里定义的输入变量。Coze 中你可以点击输入框左侧的“插入变量”按钮选择上游节点输出也可以手动输入。4.5 编写风险分级节点拖入一个“条件判断”节点连接在信息抽取节点后面。条件判断节点在 Coze 中可以基于上游节点输出的某个字段做判断。选择条件字段信息抽取节点的输出中的risks字段。判断逻辑条件如果 risks 列表中包含“严重”“阻塞”“延期”等关键词或字段值非空则判断为“高”。否则判断为“低”。严格来说用条件判断节点做关键词匹配是可以的但规则写起来比较繁琐。更优雅的方式是再调用一次大模型节点让模型输出一个风险等级。我们这里选择第二种方式加一个大模型节点命名为“风险等级评估”接收信息抽取节点的 JSON输出风险等级high/medium/low和简短理由。提示词你是风险分析师。根据以下项目周报信息中的风险项判断整体风险等级。 风险项 {{risks}} 输出格式JSON {level: high, reason: 存在XX风险可能导致项目延期} 要求 - level 只能是 high / medium / low 之一 - reason 不超过30个字这样做的好处是判断逻辑更灵活不会因为关键词不全而漏判。4.6 编写周报生成节点再拖入一个大模型节点命名为“周报生成”。这个节点会把前面的信息汇总并按照公司模板生成最终周报。系统提示词你是项目周报编写专家。请根据以下信息生成一份结构化项目周报。 本周进展 {{progress}} 风险与问题 {{risks}} 风险等级 {{risk_level}} 风险说明 {{risk_reason}} 下周计划 {{plans}} 周报格式要求 1. 标题项目周报第X周 2. 一、本周进展用 3-5 条要点描述每条不超过 50 字 3. 二、风险与问题列出风险项并标注整体风险等级如果风险等级为 high请在开头加一句“需管理层重点关注” 4. 三、下周计划用列表展示 输出要求 - 使用 Markdown 格式 - 语气专业、简洁 - 不要输出额外解释用户提示词请根据上述信息生成项目周报。注意这里的{{progress}}、{{risks}}并不是开始节点的输入而是信息抽取节点的输出字段。在 Coze 中你需要选中信息抽取节点从它的输出列表中选择对应字段插入。4.7 配置结束节点并运行验证结束节点里添加一个输出变量命名为report变量值为“周报生成”节点的输出文本。这样工作流运行结束后调用方拿到的就是一个完整的 Markdown 周报。点击画布右上角的“试运行”按钮在测试面板输入以下原始笔记本周完成了用户登录模块的重构修复了三个历史 bug性能测试通过。 风险第三方支付接口回调经常超时可能会影响下周上线计划。 下周计划完成支付模块联调开始编写压测报告。点击运行后观察每一步节点的输出。正常情况下信息抽取节点输出包含 progress、risks、plans 的 JSON。风险等级评估节点输出 risk_level 为 high因为存在“影响上线计划”的风险描述。周报生成节点按照模板输出 Markdown 周报并在风险部分提示“需管理层重点关注”。输出的周报大致如下# 项目周报第X周 ## 一、本周进展 - 完成用户登录模块重构 - 修复三个历史 bug - 性能测试通过 ## 二、风险与问题 整体风险等级高需管理层重点关注 - 第三方支付接口回调经常超时可能影响下周上线计划 ## 三、下周计划 - 完成支付模块联调 - 开始编写压测报告到这里一个 Coze 工作流就跑通了。4.8 发布与调用工作流调试通过后点击“发布”按钮。发布后你可以把工作流绑定到一个 Bot 中也可以在工作流页面查看“API 访问凭证”通过 HTTP 方式调用。如果你是开发者想通过 API 调用这个工作流核心步骤如下在 Coze 工作流页面获取 API 凭证。使用POST /v1/workflow/run接口传入工作流 ID 和用户输入。“用户输入”需要按开始节点定义的参数格式传递{ input: 用户输入的原始项目笔记 }这里的 API 细节会随 Coze 版本更新变化实际对接时以平台文档为准。5. 在 Dify 中复现知识库与 Workflow 应用5.1 Dify 中的工作流类型Dify 支持两种应用形态Chatflow 和 Workflow。区别在于Chatflow 适合对话类应用消息有上下文记忆适合聊天机器人、客服助手。Workflow 适合批处理任务输入输出都是结构化的适合周报生成、内容审核、文档处理等一次性或 API 触发场景。我们这里生成周报的场景用 Workflow 更合适因为任务和任务之间没有多轮对话的需要。5.2 在 Dify 中创建工作流应用登录 Dify 控制台后点击“创建空白应用”选择“工作流”类型命名为“项目周报生成器”。进入编排页面后画布默认有“开始”和“结束”节点。在 Dify 中开始节点也要定义输入变量。点击开始节点添加变量名notes类型段落Paragraph描述用户输入的原始项目笔记5.3 添加信息抽取节点点击画布中的“”号选择“LLM”节点。在 LLM 节点中选择模型供应商和具体模型。如果你配置了多个模型供应商可以按需求选择。系统提示词你是项目周报信息抽取器。根据用户输入的笔记输出 JSON 格式的抽取结果。 JSON 格式 {progress: ..., risks: [...], plans: [...]}上下文内容{{#start.notes#}}在 Dify 的 LLM 节点里除了系统提示词和用户提示词还有“变量”区域。你需要把开始节点的notes变量加到某个提示词部分让模型能读到用户输入。5.4 添加代码节点做数据处理Dify 的优势之一是有代码节点可以写 Python 或 Node.js。我们可以在信息抽取之后加一个“代码节点”用来清洗 JSON 输出确保字段格式正确。比如抽取节点输出的文本可能带有多余的 Markdown 代码块标记需要用代码节点处理import json import re def main(raw_output: str) - dict: # 去掉可能的代码块标记 text raw_output.strip() text re.sub(r^(json)?, , text).strip() text re.sub(r$, , text).strip() data json.loads(text) return { progress: data.get(progress, ), risks: data.get(risks, []), plans: data.get(plans, []), }这段代码会把大模型输出解析成字典然后输出给下一节点使用。注意 Dify 代码节点的输入输出变量需要在上方面板里定义不能直接读取上游节点变量需要先在输入变量区域添加。这里解释一下为什么需要代码节点大模型输出 JSON 时偶尔会在首尾添加 Markdown 代码块标记导致后续节点解析失败。用一个 Python 代码节点做“清洗”能大幅提高工作流稳定性。5.5 添加条件分支Dify 中“条件分支”节点位于逻辑节点下。点击“”选择“条件分支”。分支条件可以基于代码节点输出的risks内容做判断。Dify 支持变量比较比如判断risks数组中是否包含某个关键词。但数组包含判断的表达式会比较复杂如果不想写复杂的条件也可以继续用 LLM 节点做风险分级。这里我们复用 LLM 节点做风险分级命名为“风险等级评估”输入为代码节点输出的risks列表输出等级 JSON。5.6 添加周报生成节点再添加一个 LLM 节点命名为“周报生成”。将信息抽取节点的输出、风险等级节点的输出都作为变量传入提示词。Dify 中引用变量的方式是在输入框中输入{{#节点ID.output#}}或者在变量面板点击选择。不同版本的 Dify 界面会略有差异但核心逻辑一致。周报生成的提示词与 Coze 版本保持一致。5.7 配置结束节点在结束节点中添加输出变量report指向“周报生成”节点的输出文本。点击页面右上角“运行”按钮填入测试笔记检查每一步输出。如果一切正常你会看到工作流输出一份 Markdown 周报。5.8 发布为 API 服务Dify 的 Workflow 应用发布后可以在“API 访问”页面找到 API 密钥和调用地址。使用 curl 方式调用curl -X POST http://your-dify-server/v1/workflows/run \ -H Authorization: Bearer app-xxxxxxxx \ -H Content-Type: application/json \ -d { inputs: { notes: 本周完成了登录模块重构修复了三个 bug。风险支付接口超时可能导致延期。 }, response_mode: blocking, user: test-user }接口返回的data.outputs.report字段就是生成的周报内容。这里补充一句Dify 的 API 调用方式会随版本升级变化生产环境对接前一定要查看你当前版本的官方 API 文档。5.9 在 Dify 中利用知识库增强周报生成如果你的公司有历史周报模板、项目规范文档可以把这些文档上传到 Dify 的知识库中然后在周报生成节点开启“知识库检索”能力让模型引用公司规范来生成内容。操作步骤在 Dify 控制台进入“知识库”创建知识库。上传公司周报模板文档、项目命名规范文档等。配置分段方式和索引方式。在 LLM 节点中找到“上下文”区域关联这个知识库。这样周报生成节点在生成内容时会先检索知识库里最相关的文档片段再结合用户笔记生成周报。相比纯靠模型“背规则”这种方式更符合企业真实场景而且当公司规则更新时只需更新知识库文档不需要改提示词。6. 常见问题与排查思路以下是 Coze 和 Dify 工作流搭建过程中的高频问题整理成表格方便查阅问题现象常见原因解决思路工作流运行报错“变量不存在”节点输出字段名拼错或引用了下游节点变量检查节点变量面板确认输出字段名与自己输入的一致LLM 节点返回的不是合法 JSON模型输出带有解释文字或 Markdown 标记在提示词中严格限制输出格式或用代码节点做清洗中文内容被截断模型最大 token 限制不够调整模型参数中的最大输出 token或拆分任务条件分支始终走默认分支条件表达式写错或变量类型不匹配在分支节点前加代码节点把数据统一成字符串再判断Dify Docker 部署后无法访问端口被占用或容器未完全启动执行docker compose logs -f查看日志确认所有容器状态为 healthyCoze 工作流发布后 Bot 调用失败没有绑定正确的 Bot或工作流参数名不匹配回到工作流页面确认开始节点变量名与 Bot 输入参数一致API 调用返回 401/403API Key 缺失、错误或没有权限检查请求头 Authorization确认 Key 是从对应平台生成输出周报格式与模板不一致模板提示词写得太模糊或模型版本差异在提示词中给出完整示例并说明“必须严格按照示例格式输出”除了表格中的问题再补充一个最常见也最容易忽视的排查思路先分步测试。很多同学一上来就点“运行整个工作流”结果报错了盯着画布发呆。建议每个节点单独测试。在 Coze 中你可以先把某个节点的输出“断点”打开看到中间结果我的输入数据传给大模型之后它到底生成了什么如果大模型节点已经返回了垃圾内容后面所有节点都会受影响。在 Dify 中也是这样运行日志会显示每个节点的输入和输出。你可以逐个节点检查快速定位是哪一个环节出了问题。7. 最佳实践与工程建议7.1 提示词与代码分离在工作流里提示词是“业务逻辑”代码节点是“技术实现”。建议把提示词中容易变化的部分单独提取出来比如周报模板、风险等级定义、输出格式示例。这样当模板调整时只需要改提示词不需要动整个流程。如果团队里没有专门的 AI 工程师你甚至可以把提示词维护在一个在线文档里由业务人员更新再复制到工作流节点中。这样降低了维护风险。7.2 每个大模型节点都要定义输出格式大模型节点的输出格式直接影响后续节点。建议所有大模型节点都要求输出 JSON并在提示词里给出一个示例。这能大幅减少后续代码节点的解析难度。如果你的模型输出 JSON 不稳定可以在代码节点里做一层容错。比如json.loads失败时用正则尝试提取 JSON 片段如果仍然失败返回一个默认值。import json import re def parse_json_robust(text: str) - dict: text text.strip() try: return json.loads(text) except Exception: match re.search(r\{.*\}, text, re.S) if match: return json.loads(match.group()) return {}这种容错代码虽然不复杂但在生产环境很有必要能避免模型输出波动导致整个工作流崩溃。7.3 记录日志与可观测性生产环境使用工作流时至少要记录以下信息工作流的入参和出参。每个大模型节点的 token 消耗。关键节点的执行耗时。失败节点的错误信息。Dify 在后台会自动记录运行日志Coze 也有运行记录功能。如果你是二次开发自己写后端调 API建议把返回值完整落库方便后续排查。7.4 API Key 与敏感信息安全工作流中经常会用到外部 API Key比如企业微信机器人、数据库连接、第三方服务。这些信息千万不能写死在提示词里也不能暴露在前端配置中。正确做法Dify 中通过环境变量配置密钥代码节点中通过系统变量读取。Coze 中优先使用平台提供的“密钥”或“变量”能力避免明文写在插件参数里。永远不要把 API Key 发给大模型也不要让模型输出敏感配置。7.5 控制 token 成本工作流中如果有多个大模型节点token 消耗会成倍增加。以周报生成为例信息抽取、风险分级、周报生成三次调用可能一次运行消耗几千 token。如果每天被调用几百次成本不是小数目。控制成本的方法尽量用小模型做抽取和分类大模型只负责最终生成。合并简单节点。比如风险分级如果只是判断是否包含某些词用代码节点 正则就够了不需要调用大模型。在提示词中限制输出长度比如“不超过100字”减少重复输出。对历史任务结果做缓存如果输入相同直接返回缓存结果。7.6 工作流的版本管理工作流是会迭代的。今天模板改了明天提示词优化了后天加了一个判断节点。如果没有版本管理很容易出现“线上跑的还是旧流程新流程没发布”的尴尬。Coze 和 Dify 都支持发布版本。建议养成两个习惯每次修改后先复制一份旧版本再编辑防止改坏了回不去。发布时写清楚修改说明比如“优化风险等级提示词增加延期关键词识别”。在 Dify 中还可以把不同版本发布到不同环境比如开发环境、测试环境、生产环境实现更规范的发布流程。7.7 从“能做出来”到“能稳定运行”工作流和传统程序一样从“能跑”到“稳定跑”之间还有很长的路。核心关注点有三个输入异常怎么处理、模型输出波动怎么容错、下游依赖不可用怎么办。我的建议是在工作流入口处加一个“输入校验”节点用代码判断用户的输入是否满足要求。比如周报生成场景如果输入内容少于 10 个字直接返回“输入内容太短无法生成周报”而不是让大模型硬生成一堆空话。在出口处再做一次“合规检查”比如检查输出是否包含敏感词、是否符合长度要求。这样每一步都有保障工作流才能真正交给业务方长期使用。8. 总结与后续学习建议通过上面的实操你应该已经掌握了 Coze 和 Dify 两类平台的工作流搭建方法Coze 适合快速搭建、原型验证、对接国内办公软件生态拖拽式操作对新手很友好。Dify 适合企业私有化部署、深度二次开发、需要结合知识库和 API 集成到现有系统的场景。工作流的核心思路是一致的拆解任务、定义节点、传递变量、控制输出。掌握了这个思路换任何平台都能快速上手。下一步建议你重点练习三个方向把你手头最重复的一项工作流程化比如日报周报、简历筛选、会议纪要整理、内容审核先画流程图再用 Coze 或 Dify 实现。学习知识库RAG的使用把公司规范文档、历史数据导入知识库让工作流输出更贴合实际业务。找一些需要调用外部 API 的场景比如把工作流结果推送到飞书、钉钉、企业微信或者连接数据库实现智能查询。这类场景能帮你把 AI 能力真正嵌入业务流程。如果使用过程中遇到问题优先看两个地方工作流的运行日志和官方文档。日志能告诉你哪个节点出错文档能告诉你正确的参数格式。AI 工作流这个方向变化很快保持动手实践的习惯比囤一堆教程更重要。