Coze工作流从入门到实战：毛坯房变效果图与公众号文章自动化

简介：这是一份面向扣子（Coze）平台开发者与学习者的工作流资源包，意在提供可直接参考的轻量级工作流文件与示例代码，解决初上手时缺乏实现模板的问题。压缩包共收录8个文件，总体积仅7KB，内容以PHP脚本为核心，包含发布示例、过期授权示例等实现片段，并辅以JSON配置文件、TXT/Markdown说明文档及LICENSE授权文件，结构紧凑且职责清晰。读者通过查阅README与config.json可快速掌握工作流的基本配置方式，结合KouZi.php及示例脚本能够理解授权校验、发布逻辑等关键写法的落地步骤，为自主搭建或二次修改工作流提供有效参照。虽然包内文件不多，但已形成从配置、实现到说明的完整闭环，尤其适合刚开始接触扣子工作流、希望用最小成本了解其运行机制的中初级开发者。该资源目前已有1195人浏览学习，可作为日常开发中的轻量参考，兼具实用价值。

1. 扣子（Coze）工作流：从毛坯房照片到公众号文章，为什么先搭流程再写提示词

扣子（Coze）的 Bot 搭起来不难，真正让人翻车的是工作流。很多人一开始跟我一样，直接在 Bot 里写提示词，结果图片理解、文件解析、多轮逻辑全挤在一个黑匣子里，改一次要调半天，调试输出像玄学。这份《扣子（Coze）工作流.zip》里的流程模板，本质是把「意图识别 → 工具调用 → 结果处理」拆成可视化节点，让毛坯房拍照生成效果图、自动写公众号文章这类任务变成可复现的流水线。它适合两类人：想给 Bot 加图像理解、文件上传处理能力的运营，和被复杂编排卡住、想把 prompt 从黑匣子里解放出来的开发者。拿到资源后不是解压看看，而是在工作台里把每个节点跑通，这比背 ten 条提示词都有用。

2. 工作流的底层逻辑：节点、变量与上下文传递

2.1 为什么 Coze 的编排模型和 Dify 不一样

用过 Dify 再回来用扣子，最直观的感受是 Coze 的节点更「模块化」。每个节点只干一件事：大模型节点做人话理解、代码节点做字符串处理、插件节点调外部 API，节点之间靠变量名传递数据，而不是靠一条隐形的上下文链。这种设计的优势在调试时特别明显——哪个节点输出不对，点开那个节点单独跑一遍就知道，不用把整条链路重新执行。

资源里给的模板基本都是「开始节点 → 意图判断 → 子工作流」的结构。开始节点定义了入口参数，比如图片链接、用户输入文本，后续节点通过{{input}}这类引用方式拿上一级的数据。节点输出的字段会显示在右侧面板，命名规范直接决定后续能不能顺利引用。

2.2 开始节点与变量命名：第一个习惯决定后续效率

我建议拿到 zip 解压后先不改逻辑，专心看清每个节点的输入输出字段。常见做法是把开始节点的参数名命名为user_query（用户原始输入）、image_url（图片地址）、history（多轮上下文），这样后面任何大模型节点都不用猜字段含义。

接下来理清节点间传递的中间变量。一个标准的生成效果图工作流会这样传递数据：

user_query → 大模型节点（提取户型描述）→ 插件节点（调用图像生成）→ 结果节点

第一个节点的输出结构是 JSON，输出名定义成cleaned_query，那么下一个节点引用时写{{cleaned_query}}就好。习惯上我会存成快照（Snapshot），因为一旦后面改节点，Coze 的自动保存会把之前的引用关系打乱，快照就是后悔药。

提示：变量名不要用中文和空格，Coze 在部分代码节点里对非 ASCII 变量名支持不稳定，报错时根本找不到原因。

2.3 意图识别节点：把用户的话转成结构化指令

扣子工作流里最值得抄作业的部分是「意图分类器」。它通常是一个大模型节点，输入是{{user_query}}，系统提示词里给五六个典型意图例子，要求模型只输出一个 JSON 格式的标签，比如{"intent": "效果图"}或{"intent": "文章生成"}。这样做的好处是后续节点可以按意图走分支，而不是把所有逻辑塞进一个大 prompt 里。

资源里如果带了「意图识别模板」，操作路径一般是：添加大模型节点 → 设置系统提示词 → 输出 JSON → 用「代码节点」解析 JSON 并做条件跳转。解析代码参考：

def main(intent_json: str) -> dict: import json try: intent_data = json.loads(intent_json) except json.JSONDecodeError: return {"intent": "fallback", "confidence": 0} intent = intent_data.get("intent", "fallback") return {"intent": intent, "confidence": intent_data.get("confidence", 0)}

这段脚本的核心是容错。大模型偶尔会输出非严格 JSON，最常见的是多了 markdown 代码块标记，解析失败就落到fallback分流，走默认回复。参数confidence决定是否触发边缘案例的二次确认逻辑，我一般把阈值设在 0.6，低于这个值就让 Bot 多问一句。

2.4 分支节点到底怎么用

分支节点（Condition）可以实现多意图分流，但很多人滥用它。我的经验是分支嵌套别超过三层，否则维护成本指数级上升。更好的方式是：用代码节点做扁平化路由，输出一个next_node字段，然后一个大分支节点只按这个字段跳转。

比如写了next_node = "image_gen"，分支条件就只查这个值，然后再进对应子流程。这种写法在扣子社区越来越流行，因为它把逻辑判断收敛到了一个地方，后续想加意图，只需要改代码节点的字典映射。

3. 实战：用 imgunderstand 插件把毛坯房照片变成效果图

3.1 图片理解节点应该放在哪个位置

热搜里那句「毛坯房拍照就能生成效果图的扣子工作流」指的就是这个玩法。实现思路分两段：先用图像理解插件读懂照片里的空间结构、装修状态，再把结构化摘要交给图像生成插件出效果图。imgunderstand 是这类任务里最常用的视觉理解插件，工作流里第一个节点就是它。

具体参数参考：

注意image_url必须填可访问的公网地址，扣子里的图片输入默认是平台转存后的临时 URL，直接从用户消息拿到的链接有时限，跨节点传递前建议先下载到本地或转存。

3.2 把图像理解输出转成生成模型的输入

imgunderstand 的输出是长文本描述，图像生成节点需要的却是简短风格标签，比如「现代简约 浅灰墙面 木地板 自然光」。这个转换工作别用提示词硬压，最好走一遍代码节点，做关键词映射：

def transform(raw_desc: str) -> dict: style_map = { "浅色": "现代简约", "木地板": "原木风", "大理石": "轻奢" } style = "现代简约" for k, v in style_map.items(): if k in raw_desc: style = v break return {"style": style, "desc": raw_desc[:120]}

这段代码做了两件事：从原文里匹配风格关键词，同时截取前 120 个字符保证提示词不过长。图像生成模型对超长提示词并不友好，超出上下文后细节直接丢失。style放进生成节点的 prompt 开头，desc作为补充细节，效果稳定很多。

3.3 图像生成节点与尺寸参数设置

扣子工作流里的图像生成节点通常要求指定引擎，例如image_generation_v2。关键参数是宽高比，毛坯房照片一般是 4:3，效果图输出建议设为 1:1，方便后续直接用于公众号封面——公众号封面是 2.35:1，那就再加一步裁剪节点。这里我给个参数组合：质量q=2（减少生成噪点），步数steps=30，灵感引导guidance=7.5。太高会过锐化，太低会有水感。

如果你不想在三个节点之间来回调，有个更省事的方案：把「生成图片」拆成子工作流，主流程里用代码节点判断宽高比并传入。这样同样一个「毛坯房变效果图」模块，既能服务公众号封面，也能服务聊天窗口的方形图，复用率直接拉满。

3.4 多轮追问与兜底回复

图像生成这类任务最大的坑是图片链接失效，或者生成节点超时。工作流里的兜底逻辑要放在最后，不是等错误弹窗。常见做法是设定结果校验节点：拿到生成结果后，用代码节点检查 URL 前缀是否为https://，为空就返回预设好的兜底文案，告诉用户重新上传。

整套链路跑通之后，你会发现「毛坯房变效果图」的根本不在生成模型，而在前面的理解节点和中间状态转换。模板里的「工作流编码」节点，就是这种转换的标准化，新手用它减少试错，熟手拿它做多场景适配。

4. 公众号文章自动生成：把 markdown 转 word 的编排思路

4.1 自动生成公众号的需求拆解

朋友圈里最多人问的就是「怎么让扣子自动生成公众号文章」。这个任务链条比效果图长：选题 → 大纲 → 正文 → 排版 → 转格式 → 草稿导出。如果全部塞进一个提示词模板，输出质量没法稳定。正确做法是拆成四个串联子模块：选题收集、大纲生成、正文撰写、格式转换。每一段都配一个独立的提示词模板，当前节点的输出直接成为下个节点的输入。

这份资源里重点强调的是「用工作流代替一次性 Prompt」，它会在你输入一个主题词后自动跑完全流程，最后给一份.md文件和排版建议。

4.2 markdown 转 word 节点怎么落地

扣子并不原生支持把 markdown 转成 docx，真正能落地的是走「下载 md 文件 → API 转换」的路子。工作流里加一个 HTTP 请求节点，请求一个转换接口，这是社区最常用的方案。资源里给了两种路径：一种是用插件市场的 markdown 转换器，另一种是用代码节点调 REST API。后者更可控，参考代码：

import requests def markdown_to_docx(md_text: str, filename: str) -> str: api_url = "https://your-convert-service.example.cn/api/convert" resp = requests.post(api_url, json={"content": md_text}, timeout=30) if resp.status_code == 200: return resp.json().get("docx_url", "") return ""

这里的api_url不是任何特定平台，而是你自己可控的服务。如果没条件部署转换服务，退路是先生成 markdown 再让用户复制到本地 Word 自动转换——虽然少了「一键产出」的仪式感，但保证不翻车。

4.3 自动发布这块，扣子工作流最多做到什么程度

需要明确边界：扣子的 Web 端不提供公号平台发布组件，工作流能做的只是生成草稿文件并给你下载链接，真正发布这一步还是要人工操作。工作流的意义在于把「想选题」到「拿到成稿」从一整天压缩到五分钟，而不是替代编辑审核。

那资源里为什么提到「自动生成公众号文章并发布」？我的理解是，它在工作流里预留了「人工审核」节点，通过代码节点生成带高亮标记的封面图，最后的动作是让你复制粘贴，而不是一键推送。

4.4 从 zip 里提取可复用的「工作流编码」思路

源码资源里经常出现一个名为「工作流编码」的文件夹，里面其实就是一套通用的节点配置规范。它规定了大模型节点的输入输出 ID、代码节点的入口写法和错误处理。实操时你应该抽出现成的节点连接关系，而不是把整条链路复制粘贴到另一个 Bot。核心可复用部分包括：

• 用户输入的标准化处理节点
• 上下文记忆切换节点
• 长文本分段生成节点的超时配置

我每次做新 Bot 都是先从这个 zipped 模板里点选节点搭骨架，再修改提示词，效率比自己从空白画布拖高很多。

5. 避坑排查：Coze 工作流里最常翻车的 5 个问题

5.1 现象：节点输出是空的，但路径看起来没问题

原因大多出在变量引用名对不上。你在 B 节点写了{{aa}}，但 A 节点的输出字段实际叫AA，Coze 不会像编译器一样立刻报错，它只会在运行时静默生成空值。解决方法是逐一打开每个节点的输出面板，核对字段明，重点看开头字母的大小写和下划线。

注意：资源里的模板字段名是按 demo 场景命名的，复制到自己 Bot 后，只要动了前置节点的输出名，后面全部要联动修改，别只改一处。

5.2 现象：大模型节点经常输出 JSON 解析失败

扣子里的大模型节点默认输出文本，不是结构化数据，就算你在提示词里写「只输出 JSON」，它偶尔也会多讲两句。解决是在大模型节点后强制挂一个「代码节点」，对输出做清洗：

def clean_llm_output(raw: str) -> dict: import re, json match = re.search(r"\{.*\}", raw, re.DOTALL) if not match: return {"error": True, "message": "no_json_found"} try: return json.loads(match.group()) except Exception: return {"error": True, "message": "invalid_json"}

这段代码是二次保险，防止输入为空时，后面的分支节点忙乱。参数re.DOTALL是为了匹配跨行 JSON，实测大模型经常在 JSON 里加换行，没有这个会在 50% 的情况下翻车。

5.3 现象：代码节点跑得好好的，但一改提示词就报错

这种通常不是代码写错，而是输入字段变成了空字符串。原因在于 Coze 的变量引用是惰性求值，上游节点如果超时或者返回默认值，下游不会感知到「异常」，只有等到写代码节点里KeyError才爆出来。治本的方法是每个可能为空的输入先加默认值参数：

input_text = data.get("content", "") or ""

5.4 现象：插件节点一直转圈，最后超时

扣子插件节点默认超时时长很短，图片生成类任务很容易超限。可以把「重试机制」包在外层——用循环节点最多跑三次，每次间隔拉长。注意 Coze 对单次运行时长有平台限制，重试间隔加太多会导致整个工作流失败，我一般设 3 秒到 5 秒之间，循环上限 3。

5.5 现象：上传的文件在跨节点后变成乱码

扣子的文件上传分两种：一种走upload接口拿到 URL，一种是直接把二进制传进节点。后者跨子工作流时大概率变成字符串乱码，因为工作流序列化会强制转文本。解决方式是设计节点时统一要求「文件 URL」入口，而不是文件对象。资源里的模板在输入参数定义上做得不错，值得抄。

6. 用 zip 资源做版本管理：导出、快照与跨 Bot 复用

我对工作流资源的第一反应永远是看它的「可迁移性」。扣子工作台的导出功能会生成一个 JSON 结构，但真正的项目资源往往附带多个 Bot 配置、插件依赖说明和一个主流程图文件。拿到这份扣子（Coze）工作流.zip后的标准动作是：先解压确认目录结构，再逐个文件对照说明，最后导入工作台跑通。

我习惯性地把「已调好的节点组合」当成代码库管理。每个稳定方案保存一个独立 zip，命名用「场景+日期+核心插件」三段式，比如article_md_20240218_img. 以后搭同类需求直接解压，把旧节点拖进新画布改参数，比从头拖拽省一半时间。导出时记得把插件开关一起保存，否则换一台电脑，插件装不上整个流程就瘫了。

导入进来后还有一步验证要做：检查「提示词版本」是否与当前 Bot 匹配。扣子的提示词是在 Bot 指令里写的，工作流只是执行层，两者版本不同步时，AI 花半天生成的内容可能和指令完全无关。我的做法是导出一份.md提示词快照，与实际工作流文件名一一对应，杜绝只存流程忘了存文案的问题。

从那以后我每次解压新工作流资源，都会强制走一遍「清空测试数据 → 跑最小单元 → 模拟完整链路」三步验证，再进入实际使用。这份资源里的模板也让我把同类任务的交付时间从一天压到两小时，希望帮到你。

本文还有配套的精品资源，点击获取