扣子（Coze）的工作流把一段每次都要重说的步骤固定成一条能反复跑的路径。它适合流程稳定、判断点不多的任务；如果每次走法都不一样，做成工作流反而更难维护。判断标准很直接：这件事上周做过、这周还要做、下周大概率还是同样几步，就值得搭。
先判断这件事该不该做成工作流
三类任务适合：格式固定的内容加工，比如把会议记录整理成固定结构的纪要；需要串联外部能力的查询，比如查库存、查物流再汇总；带明确分支的受理，先判断类型再走不同处理。三类不适合：开放式研究、需要大量临场判断的写作、一句话就能问完的问题。
一个可操作的量化口径：步骤在 3 步以上、每周重复 5 次以上、每步的输入输出能用一句话说清。三条同时满足再动手。少一条，先用单个智能体配一段提示词跑两周，看它到底卡在哪一步，比一上来画流程图省事。
节点按一次判断切，不按一个动作切
常见做法是一个动作一个节点：取数、清洗、改写、排版各占一个，很快堆到十几个，改一处要顺着连线找半天。更稳的切法是按判断点切：需要做选择的地方独立成节点，纯计算和纯改写合并在一起。
扣子的节点大致分这几类：开始节点定义输入参数，大模型节点负责理解与生成，插件节点调外部能力，知识库节点做检索，代码节点处理确定性逻辑，选择器做条件分支，循环节点处理列表，结束节点定义输出。一套典型流程通常落在 4 到 6 个节点，超过 10 个就该怀疑切得太碎。
变量是节点之间唯一的通道
节点之间不共享上下文，只通过变量传递。上一个节点的输出如果没有被显式引用，下一个节点拿到的就是空值，这是跑起来拿不到数据最常见的原因。
做法是给每个节点写清三行：输入从哪个变量来、输出叫什么名字、类型是什么。开始节点把用户输入定义成有名字的参数，后面所有节点都引用这几个名字，而不是让模型自由理解上面那段。需要结构化结果时，让大模型节点输出 JSON，再在代码节点里解析和校验，解析失败就转入兜底分支。变量命名用 raw_text、summary 这类能看出内容的名字，别用 var1，调试时一眼能看出断在哪一环。
分支和兜底要画在纸上
选择器的条件要穷举。分类任务最容易漏的是都不属于：三类之外还有第四类，模型硬分就会分错。先加一条其他，再决定这一支是转人工、返回固定话术，还是落到一张收集表。
兜底至少三层：插件超时，重试一次仍失败就给替代话术；模型输出不合格式，解析失败走重问一次；变量为空，在开始节点设默认值或必填校验。这三层不做，上线后头一次遇到异常就整条中断，用户看到的是一个一直在转的加载圈。
调试从单节点开始，用固定样例
不要整条流程一起跑。扣子的单个节点支持试运行，可以手填输入看输出：从开始节点往后，逐个节点喂固定样例，确认每个节点输出长什么样，再接下一个。
样例准备三条就够：一条正常输入、一条超长或带格式的输入、一条空输入。同一组样例贯穿整个调试过程，任何改动带来的变化都可对比。整条跑通之后再换真实数据，否则分不清是节点有问题还是数据有问题。顺序上建议从后往前再验一遍：先确认结束节点拿到的东西对不对，再倒推哪个节点没给到。
四类任务的搭法对照
| 任务类型 | 节点组合 | 调试重点 | 成本大头 |
|---|---|---|---|
| 内容加工 | 开始 → 大模型改写 → 代码校验格式 → 结束 | 输出格式是否稳定、长度是否超限 | 大模型节点的输入长度 |
| 资料问答 | 开始 → 知识库检索 → 大模型带引用作答 → 结束 | 检索不到时的兜底话术 | 检索条数与拼进提示词的篇幅 |
| 外部查询 | 开始 → 插件 → 代码清洗 → 大模型汇总 → 结束 | 插件超时与返回字段缺失 | 插件调用次数 |
| 分类受理 | 开始 → 大模型分类 → 选择器 → 分支处理 → 结束 | 其他类占比是否过高 | 分类被重复调用 |
资料问答那一行最容易被低估的是知识库。检索质量取决于文档怎么切、标题怎么写，做法与团队共享知识库的整理相通：按主题分库，每篇只讲一件事，标题带上用户会说的词。
它做不到什么
工作流不擅长处理每次都不一样的任务。步骤一旦要临场加减，写死的分支就会漏。它也不会自己发现上游变了：插件接口改字段、知识库文档过期、模型版本更新导致输出风格变化，都要人定期回看。
另外两点常被高估。一是准确率，多节点串联会把每一步的小误差叠加，五个节点各 95% 的准确率，整条链路的结果明显低于 95%。二是成本，循环节点会把单次消耗放大数倍，把整篇长文档塞进大模型节点也会显著抬高费用。上线前按最坏情况估一遍一次跑多少 token、一天跑多少次，比只看单次价格有用。流程里要出配图和套版物料，素材口径要与品牌素材库的团队协作一致：模板集中管，流程只调用。
上线前速查
- 步骤 3 步以上、每周 5 次以上、每步输入输出能一句话说清，才值得搭
- 节点按判断点切，一套流程控制在 4 到 6 个
- 每个节点写清：输入来自哪个变量、输出叫什么、什么类型
- 兜底三层：插件超时、格式解析失败、变量为空
- 三条固定样例：正常、超长、空输入
- 成本按最坏情况估算，重点看循环节点
三个容易被追问的点
问：先在草稿里搭，还是直接新建一个工作流？答：新建。草稿里改来改去容易留下废弃节点和断开的连线，排查很麻烦。定稿后再复制到正式空间，提示词怎么改成能稳定输出的版本，可以参考提示词库的改编方法。
问：一个工作流能不能同时服务多个渠道？答：能，但要把渠道差异收在开始节点。不同渠道的输入长度、可用格式、用户习惯都不同，把这些做成参数，比给每个渠道复制一份流程好维护。
问：上线后怎么知道是哪一步退化了？答：给每次运行留输入输出快照，按节点记耗时和失败原因。看出问题集中在哪个节点再改那一个，不要整条重搭。
