玩转大模型（三）：Coze 与 Dify 十个真实工作流案例，同一业务两种实现的差异全记录
玩转大模型（三）：Coze 与 Dify 十个真实工作流案例，同一业务两种实现的差异全记录
💡第三天全是实战：一批商户经营场景的 AI 案例，同一个业务在 Coze 和 Dify 上各做一遍。
看教程时最容易产生一种错觉——“节点连起来不就完了”。真自己搭就会撞上：Excel 到底怎么进工作流、批处理的外层输出为什么配不了、同步运行为什么 180 秒必挂、迭代节点为什么单独测试就报错。
这篇不做案例罗列，重点放在两件事：同一业务在两个平台上的实现差异，以及那些课件里明确写出来的坑。
1. 十个案例，四类业务
这批案例覆盖一个商户日常经营的四类需求：
| 业务域 | 案例 | 平台 | 核心能力 |
|---|---|---|---|
| 内容产出 | 一键生成行业调研 PPT | Coze | 联网检索 + JSON 大纲 + iSlide 模板生成 |
| 一键生成行业调研报告 | Dify | 搜索 + 抓取 + 迭代撰写 + 邮件投递 | |
| 营销物料 | 复刻爆款视频 | Coze | 链接解析 → 分镜 → 文生图 → 图生视频 |
| 产品营销海报生成 | Coze | 生图/改图 + 叠图 + 数据表持久化 | |
| 商品营销卖点提炼 | Coze | 1 Agent + 5 工作流 + 5 知识库 | |
| 经营数据 | 客服对话记录分析 | Coze / Dify | Excel 解析 + 批处理三路并行 LLM |
| 商品评论分析 | Coze / Dify | CSV 解析 + 四维分析 + 报告输出 | |
| 企业内部流转 | 客户投诉分类助手 | Dify + 钉钉 | 四级问题分类 + 群机器人推送 |
其中"客服对话记录分析"和"商品评论分析"是同一业务在两个平台各实现一遍，差异最有参考价值。
1.1 一条完整的 PPT 生成链路长什么样
以 Coze 的"一键生成行业调研 PPT"为例，节点顺序是：
开始(theme,style) → 文本处理(拼"XX行业发展现状") → getToutiaoNews(插件) → 代码(抽 URL) → 批处理[LinkReaderPlugin 读正文] → 大模型(生成大纲 JSON) → get_themes(iSlide 取主题) → 代码(取模板 id) → generate_presentation → download_presentation → 结束(输出 ppt_link)大模型节点用的是DeepSeek-R1/250528，responseFormat=2（强制 JSON 输出）。提示词里给了sections → contents → items → title/subtitle的四层嵌套示例——下游是程序，所以输出格式必须是硬约束，不能靠"请输出 JSON"这种软要求。
代码节点在 Coze 里的写法是统一签名，这类细节教程经常不写：
asyncdefmain(args:Args)->Output:params=args.params url_list=[i['url']foriinparams["input"]]ret:Output={"url_list":url_list}returnretDify 侧则是def main(...) -> dict，返回值的键名就是输出变量名：
defmain(json:list)->dict:return{"result":json[0]['organic_results']}两套签名不通用，从 Coze 迁到 Dify 时代码节点必须重写。
2. 同一业务，两个平台的真实差异
这是第三天最值钱的部分。以"客服对话记录分析"为例，两边都是Excel → 拆行 → 三路并行 LLM（问题分类 / 内容总结 / 情感分析）→ 聚合，但实现路径完全不同：
| 维度 | Coze | Dify |
|---|---|---|
| 文件入口 | readExcel插件，传在线链接（Agent 会把上传文件转成 URL） | 开始节点直接收file变量，工具excel2json |
| 批量处理 | 批处理节点，体内扇出 | 迭代节点，parallel_nums可设 1~10 |
| 输出约束 | 大模型节点responseFormat=2，或靠提示词硬约束 | structured_output_enabled+JSON Schema |
| 下游取值 | 解析文本 | 直接引用…structured_output变量 |
| 中间态提示 | 输出节点（“请稍等~正在智能分析评论ing”） | answer直接回复节点，只有 Chatflow 支持多处输出 |
| 交互收集输入 | 问答节点（选项回答可做分支路由）+变量赋值 | 无对等节点，靠 question-classifier / parameter-extractor |
| 数据持久化 | 应用内数据表+SQL自定义节点 | 本批案例未涉及表存储 |
| 变量写法 | {{theme}}、{{String1}} | {{#节点ID.字段#}}，输入/唤起变量菜单 |
最关键的一条差异是结构化输出。Dify 可以把"情感分析"的返回声明成 schema：
{"type":"object","properties":{"rank":{"type":"string"},"reason":{"type":"string"}}}下游代码节点直接取.structured_output.rank，不用正则解析文本。Coze 只能靠提示词约束 + 代码节点兜底，所以课程在 Dify 版的分类提示词里额外加了一句：“请严格按格式输出，必须包含 product、content、experience 三项”——有 schema 时这句话甚至可以省掉。
Q1：Excel/CSV 到底怎么进工作流？
两边思路不同。Coze 是链接驱动：用户上传文件给 Agent，Agent 转成在线 URL 传给工作流，所以开头必须做合法性校验：
# 校验输入是否为 csv 链接ret:Output={"is_csv":'.csv'inparams["url"]}再用选择器分流，非 csv 走"请正确上传.csv格式文件"。Dify 是变量驱动：开始节点直接声明type=file或type=document，配文档提取器节点。但 Dify 的文档提取器输出不稳定——课件原话是"有时是字符串，有时是只有一个元素的字符串数组"，所以还得加一层归一化代码：
defmain(text_arr:list):text=text_arr[0]ifisinstance(text_arr,list)elsetext_arrreturn{"result":text}Q2：为什么商品评论分析在 Dify 上要用 Chatflow？
课件给的理由很具体：Dify 的 Workflow 只能接收一次输入、输出一次，而这个案例要边分析边打印进度提示，只有 Chatflow（advanced-chat）能做到多处answer输出。代价是 Chatflow没有结束节点，而且"对话流不能单独发送文件，必须搭配文字"。
顺带把课程给出的对照表抄全，这个选型判断以后用得上：
| 特性 | Chatflow 对话流 | Workflow 工作流 |
|---|---|---|
| 核心目标 | 实时交互、自然语言对话 | 批量处理与自动化 |
| 交互模式 | 多轮对话，可追问 | 单次执行 |
| 上下文记忆 | 支持（sys.conversation_id） | 不支持，无状态 |
| 输出方式 | 流式、多处输出 | 执行完一次性返回 |
| 触发机制 | 用户实时输入 | 定时任务、API 事件、文件上传 |
| 典型场景 | 客服咨询、教育问诊、创意协作 | 报表生成、数据清洗、批量 API 调用 |
四步决策：需要多次输入 → Chatflow；批量处理 → Workflow；结果要分步展示 → Chatflow；需要定时/事件触发 → Workflow。
3. 三个值得抄的设计模式
3.1 分类树：question-classifier 串成级联
Dify 的"客户投诉分类助手"是四级分类树，纯靠问题分类器串起来：
feedback → 一级[用户投诉|设备故障|需要配件补给] → 二级[服务|质量] / [软件|硬件] / [螺丝|钢板|木板] → 总结助手(LLM) → 钉钉群机器人 → 结束两个细节：分叉必须配多个结束节点（案例里有 结束/结束2/结束3）；总结节点的提示词直接把上游分类结果插进来：
你是一个总结助手，将下面的问题进行总结 一级分类：{{#….class_name#}}，二级分类：{{#….class_name#}}，用户反馈：{{#开始.feedback#}}3.2 卖点 → 买点：把营销方法论固化成提示词
"商品营销卖点提炼"是这批案例里最复杂的一个，1 个 Agent 路由 5 个工作流：
main_flow → set_product_name_and_desc → selling_point_generation → selling2buying_point → red_book_and_video_script卖点用三步法：通用性 / 独特性 / 保障性，每步的约束各不相同——通用性要"剔除非通用性卖点（价格优势、一次性活动）“，独特性要"有明确竞争壁垒，如技术专利、独特资源”，保障性关注"风险降低 / 信任证明 / 长期承诺"。统一收尾是"每个卖点 15 字以内"。
买点转化这一步是精髓：买点要从用户视角出发，通过情感化表达、场景化描述，把产品价值延伸到情绪价值层面。课程把情绪拆成五类，用文本处理节点按选择拼提示词：
| 情绪点 | 触发词 |
|---|---|
| 痛点 | 迫切性、亟待解决、恐惧 |
| 爽点 | 满足感、即时反馈、明显效果、成就感 |
| 痒点 | 从众、稀缺、社交驱动、向往 |
| 兴奋点 | 意外惊喜、独特体验、创新体验 |
| 安全点 | 安全感、信任感、可靠 |
小红书文案节点的约束硬到夸张，但正是这种硬度才出效果：标题少于 20 字、正文 500~1000 字、标签至少 8 个、语言年轻化用女生口吻、禁用中文句号、避免"最/第一/极限/世界级"等绝对化词、必须命中热词白名单，并给 3 个 few-shot 示例。
3.3 知识库当素材库：检索 + 随机关键词
red_book_and_video_script挂了5 个知识库（抖音热点、微博热点、脚本开头技巧、脚本结尾技巧、高质量营销文案技巧），流程是：
循环[是否继续生成] → 知识库检索(热点) → 选择器(是否用到热点) → 问答(选小红书文案 or 短视频脚本) → 代码节点随机选技巧关键词 → 知识库检索(对应技巧库) → 大模型生成 → 输出随机选关键词这一步用代码实现（时间戳 + 基础随机数取模），比让模型"随机给一个"稳定得多。把不确定性交给代码、把创造性交给模型，这个分工我认为是这批案例里最值得学的一条。
Coze 的检索方式有三种：向量检索、全文检索、混合检索（推荐，附重排序）——和第二篇 Dify 知识库的结论完全一致，两个平台在检索策略上收敛了。
4. 坑清单：课件里明确写出来的那几条
| # | 坑 | 现象 / 解法 |
|---|---|---|
| 1 | Coze 同步运行 3 分钟上限 | 复刻爆款视频必超 180s 失败；只有智能体调用工作流才能设异步（异步上限 24h），异步并发过大还会code:429限流 |
| 2 | 文生图节点偶发超时 | 加选择器判断是否成功，失败走第二个完全相同的生图节点，再用变量聚合汇到下游 |
| 3 | 批处理/迭代外层输出配不了 | 必须先把体内节点配完，才能配外层输出。Coze 和 Dify 都有这个限制，课程两处都专门标注 |
| 4 | Dify 迭代节点单独测试必报错 | 课件判定为平台 bug：每个 item 本是 dict，但单节点测试时变量被转成字符串，无法传对象，只能整体运行 |
| 5 | Dify 上游输出会缓存 | 上游节点跑成功后输出被缓存，下游单独运行时自动取上游输出作为输入。缓存按节点组织，可查看可删除——调试结果不对先怀疑缓存 |
| 6 | Coze 转义地狱 | readExcel输出是带转义的字符串，批处理里要先input.replace('\\\\\"', '"')再json.loads |
| 7 | BOT_USER_INPUT是保留变量 | Coze 里要求用户输入变量名必须用它，否则可能赋不进工作流入参；它也不会出现在 Agent 调用日志的arguments里 |
| 8 | 子工作流传参要求字段名对齐 | 从数据表product_list取数填参数时，开始节点参数名必须与数据表字段名一致（name/description） |
| 9 | Dify 在线版调国内模型失败率高 | 服务器在国外，DeepSeek 官方 API 实测多次超时，课程最终统一切到内置gpt-4o-mini；OpenAI 兼容供应商URL 结尾必须带/v1 |
| 10 | Coze 模型会被下架轮换 | 课件写明DeepSeek-V3-0324、豆包·1.5·Pro·32k等会失效，“替换功能类似的模型即可” |
| 11 | 抖音链接解析常被反爬 | LinkReaderPlugin对抖音链接频繁失败，只能多试或换来源 |
| 12 | 钉钉机器人 ACCESS TOKEN 只填值 | 要填 Webhook 里access_token=后面那串，不是整条 URL；且必须是自己是管理员的组织内的群 |
| 13 | Agent 上下文被失败任务污染 | 多次失败后上下文混乱，课程的做法是删掉智能体重建，而不是继续改 |
还有两个易忽略的小技巧：Coze 的 UI 组件状态表达式里，变量前加!表示"非"（!workflow.loading实现"工作流未运行时隐藏"）；工作流必须先发布才能挂给 Agent；发布到商店别人只能体验不能复制，要让人看到编排细节得发布为模板。
最后总结
- 平台差异的本质是"结构化能力"。Dify 有 JSON Schema、有 Chatflow 多处输出、有节点级缓存；Coze 有问答节点做交互、有数据表做持久化、有 UI 组件做低代码前端。做数据批处理选 Dify，做面向用户的轻应用选 Coze。
- 工作流的稳定性来自"把不确定性交给代码"。校验、路由、随机、聚合、重试全部用代码和选择器节点，模型只负责生成。
- 提示词的硬度决定下游能不能自动接。输出格式必须是硬约束（schema 或明确字段清单），字数、禁用词、白名单都要写死。
- 13 条坑里至少 6 条是平台限制而非写法问题（3 分钟同步上限、迭代单测 bug、上游缓存、模型下架、反爬、发布权限）。遇到"怎么改都不对"先怀疑平台。
本系列：第一篇 大模型概述与落地选型 / 第二篇 RAG 与低代码智能体 / 第三篇 工作流案例集（本篇）/ 第四篇 API 调用与私有化部署。
参考资料
[1] Coze 扣子官网
[2] Dify 官网
[3] Dify 插件市场 - GitHub
[4] Firecrawl
[5] 钉钉开放平台 - 自定义机器人
[6] iSlide
[7] DeepSeek 开放平台
本文整理自《尚硅谷大模型智能体线上速成班 V2.0》Day03《低代码智能体开发案例集》课件与工作流导出文件，节点链路、参数与坑均取自课件原文。