要确保扣子工作流稳定高效运行，仅靠拖拽节点远远不够。正确的做法是：先理清流程再动手创建——登录coze.cn，进入工作空间，打开资源库，点击+资源，选择工作流，填写名称（必须以字母、数字或下划线开头）和描述，确认创建。这个步骤看似简单，但许多用户却在开始节点上栽了跟头。默认情况下，开始节点只提供一个String输入框，如果需要接收文件、数组或多字段结构化数据，必须在创建时就勾选对应类型并设为必填，否则后续无法引用该变量，修改时只能删除整个工作流重新创建。

核心要点总结：避免滥用LLM节点，Condition分支超过3个必须拆分，Loop节点必须设置上限；性能优化有五个实操步骤——加计时诊断节点、合并相邻Code节点、插件调用前加缓存判断、LLM输出强制JSON Schema、静态资源走CDN。

先理清流程再拖拽节点

不要急于往画布里拖拽节点。建议先在纸上或白板上绘制完整的流程路径：用户输入什么，经过哪些步骤处理，每个分支的判断条件是什么，最终输出的格式要求有哪些。如果忽略这一步，后续90%的返工都由此产生。

开始节点默认只提供一个String输入框，如果需要接收文件、数组或多字段结构化数据，【必须在创建时就勾选对应类型并设为必填】，否则后续无法引用该变量，修改时只能删除整个工作流重新创建。

核心节点选型与避坑指南

方法一：LLM节点不是万能解决方案

不要将所有文本处理任务都交给LLM节点。例如JSON字段提取、字符串截取、日期格式转换——这些操作用Code节点三行代码就能完成，强行使用LLM不仅速度慢，还可能因温度值波动导致结果不一致。

方法二：Condition节点超过3个分支必须拆

当你发现Condition节点里写了“如果A就走1，如果B就走2，如果C就走3，如果D就走4，否则走5”——请立即停止。这种写法会导致调试时无法清晰分辨哪条路径被触发。正确做法是：前两个条件走主干分支，其余条件封装成独立子工作流，通过Workflow节点调用。

方法三：Loop节点不设上限=定时消耗token

循环处理列表时，务必在Loop节点配置中手动设置“最大循环次数”。见过最严重的一次：一个包含27条数据的数组被反复执行了186轮，单次运行消耗4200 tokens，账单直接跳涨三倍。

性能优化五步实操

第一步：加计时诊断节点

在每个业务节点（LLM/Plugin/Code）输出后，追加一行 elapsed: Date.now()，传递给下游；最后接一个纯诊断用的Code节点，运行以下脚本：

function main({ timings }) {
  const report = Object.entries(timings || {})
    .sort((a, b) => b[1] - a[1])
    .map(([node, ms]) => `${node}: ${(ms / 1000).toFixed(1)}s`)
    .join('\n');
  return { report };
}

第二步：合并相邻Code节点

三个串行Code节点（解析→取字段→拼字符串）耗时约0.3秒，加上0.15秒启动开销；合并成一个后，耗时降至0.18秒以内，并且避免了两次变量序列化损耗。

第三步：插件调用前加缓存判断

如果插件功能是查询天气、搜索新闻这类结果变化较慢的服务，在调用前插入一个Code节点，用当前日期加关键词生成cacheKey，检查本地变量是否存在。如果存在，则跳过插件直接获取缓存，节省3–8秒等待时间。

第四步：大模型输出强制JSON Schema

在LLM节点配置中开启“结构化输出”，并粘贴标准JSON Schema。如果不这样做，模型可能在返回末尾额外添加一句“以上就是全部内容”，导致下游JSON.parse()直接报错中断。

第五步：静态资源走CDN不走工作流

生成海报、导出PDF、压缩图片等操作，不要使用Image节点或Code节点硬扛。直接调用已部署好的HTTP API，将压力从扣子运行时剥离出去。HTTP节点本身不计费，而Image节点每张图都会消耗tokens。