写公众号的朋友应该都有同感：最耗时间的往往不是“写”本身，而是写之前和写完之后那一堆琐碎的周边工作——定选题、拟标题、搭结构、想摘要、找配图、排版调样式，一套下来一个完整下午就没了。我试过用纯对话式AI去辅助，比如让ChatGPT直接输出全文再手动粘贴到公众号后台，结果排版要重新调一遍，配图还要另开工具找，体验非常割裂。
后来我把整条生产链路搬到了Coze（国内版叫“扣子”）的工作流里，实现了一个输入主题关键词、自动产出公众号图文成品的工作流，基本把选题到成稿中间80%的机械劳动吃掉了。这篇文章就是把这个工作流从设计、搭建到踩坑的完整过程拆开讲，适合已经在用Coze或者至少接触过低代码AI工具的人，想直接把工作流跑起来的话，按照文章中每一层的配置来抄作业就行。
1. 动手之前：先想清楚自动化到底解决什么问题
做任何自动化之前，我都建议先别急着打开平台拖节点，而是把手工流程拆开，看看哪些环节是真痛点、哪些环节自动化的性价比极低。公众号图文生产这件事，表面上就两步“写”和“发”，实际拆开是这么一串：
- 定选题方向，有时候还要找参考文章
- 列大纲，确定每部分要讲什么
- 逐段扩写成文，控制语气和信息密度
- 拟定标题和摘要，琢磨打开率
- 找配图或者做封面图
- 排版，调整标题层级、加粗、引用、代码块样式
- 检查一遍错别字和事实问题
- 登录公众号后台，粘贴、提交预览、发布
这几步里面，3、4、5、6这四步是典型的“重复性脑力劳动”，AI干得又快又稳。第1步也可以让AI辅助发散，但选题方向通常跟账号定位强相关，如果整个工作流是为固定垂直账号服务的，把选题约束写死在提示词里效果反而更好。第7步涉及事实核验和价值观把关，这个必须留人来做，机器只能做初筛。第8步从技术上说可以对接公众号API做到“自动存草稿”，但对大多数个人号主来说，手动粘贴几秒钟的事，没必要为省这一步去承担接口开发的复杂性。
1.1 人力生产一篇图文的实际消耗
我拿自己运营的一个垂直领域账号做过统计，不算调研和找资料，单从“有选题”到“排完版”，平均用时大概三个半小时。其中纯写作大约一个半小时，这是无论如何都省不掉的，因为个人创作者的核心价值就在观点和风格；剩下接近两个小时全部消耗在标题打磨、摘要措辞、配图寻找、排版调整上——这些恰恰是Coze工作流能承接的部分。搭好工作流之后，从输入一个选题关键词到最后拿到排好版的HTML内容，大概五分钟，人工需要做的只是读一遍、改几处语气、换掉一张不合适的图，整体时间直接砍到四十分钟以内。
1.2 为什么选Coze而不自己搭n8n或者写Python脚本
这里我不回避一个事实：能做的事其实n8n也能做，甚至纯写代码能做更多。但Coze在这里有几个关键优势是其他方案比不了的：
- 大模型节点原生内置，不需要自己去接各个模型的API、处理密钥和鉴权，平台里面选模型就直接用了，模型切换非常方便。
- 可视化工作流对生产和调试友好，一个节点一个节点的数据流看得很清楚，出问题能直接定位到是哪一步。
- 插件市场提供了大量现成能力，尤其是图片生成、文件处理这类，不用自己去对接外部服务。
- 团队空间方便多人协作，不需要一个人维护所有配置，编辑和审核的人都可以在同一个空间里各干各的。
当然Coze也不是万能的。如果你要做的自动化涉及复杂的条件循环、深度对接内部数据库、或者需要完全私有化部署，那我建议还是考虑dify自托管或者直接写代码。但就拿“公众号图文生产”这个场景来说，Coze的轻轻重度刚好合适——不需要去管基础设施，重点放在内容链路的设计上。
2. 整体架构：一条数据链路走完“主题到成稿”
工作流搭建的一个核心思路是：不要试图在一个大模型节点里同时干所有事，而是把任务拆分成多个节点，每个节点只负责一个明确的小目标。这么做的好处有三个：一是单次生成内容变短，出错的概率降低；二是每一步都可以检查，训练数据和风格可以分步调优；三是并行节点可以提升运行效率。
2.1 工作流的节点拓扑怎么设计
我的工作流核心结构是这样的：
- 开始节点：接收用户输入的主题（支持手动输入关键词，也支持上传文件，比如参考文档、历史文章风格示例）
- 大模型节点一：根据主题生成文章大纲，同时输出关键词列表
- 大模型节点二：根据大纲逐段扩写正文，这一步往往是串行调用多次，分段生成
- 大模型节点三：根据完整正文生成标题方案和摘要
- 代码节点：把Markdown正文转成适合公众号的HTML排版
- 插件节点：调用图片生成插件，根据主题和正文生成立意配图
- 结束节点：把所有产物打包输出
这里我建议把“生成大纲”和“扩写正文”做成分离的两个大模型节点，而不是让一个节点一口气输出全文。原因我在前面提过：一次性输出几千字长文，模型在后面的内容里很容易偏离大纲、出现重复表达，而且一次生成的内容过长，一旦中途报错，整次运行都白费了。分段生成的策略，是把“出错成本”拆散，最多重跑某一个段落，而不至于从头再来。
2.2 节点之间的数据流动约定
在Coze工作流里，节点与节点之间通过“引用上一个节点的输出”来传值，引用方式是在输入框里直接用{{节点名.输出字段}}这种格式。这里有一个容易踩的坑：如果你在提示词里引用了上一步的变量，但变量名拼写错了，或者节点的输出字段名变了，整个节点就会静默失败或输出异常。所以我在开始搭建的时候确立了一套命名的硬约定：
- 所有内容的正文变量统一叫
content - 大纲变量叫
outline - 标题变量叫
title_options - 摘要变量叫
summary - 配图提示词变量叫
cover_prompt - 最终输出HTML叫
final_html
这套命名贯穿所有节点，好处是后续调试的时候看到变量名就知道它属于哪一层，不用层层翻。尤其当工作流改过几次、节点数量变多之后，这套约定能省下大量排查时间。
2.3 并行分支的使用原则
Coze工作流支持并联节点。我的实践是：在正文还没生成完的时候，配图提示词其实已经可以由主题和大纲生成了，所以这里完全可以把“配图生成”和“正文扩写”设计成并行运行的两个分支，整体运行时间能从四到五分钟压缩到两到三分钟。但要小心的是，并行分支里的任何一个分支出错都会导致整个运行失败，所以并行的位置尽量放在行为比较稳定的节点之间，比如“生成配图提示词”和“生成正文第一段”之间并行，而不是把“JSON解析”这种容易出错的步骤也塞进并行分支里。
3. 关键节点落地：提示词、结构化输出与排版转换
整个工作流里，配置难度从低到高排列，最需要花心思的其实是三个地方：大模型节点的提示词、代码节点里的排版转换逻辑、图片生成节点的参数控制。
3.1 大模型节点的提示词怎么写才稳定
公众号图文自动生成，提示词的核心要求是“稳定输出指定结构”，尤其要避免模型自由发挥把格式搞乱。以生成大纲这个节点为例，我用的提示词模板大概是这样的：
你是一个公众号主笔，擅长撰写{领域}方向的深度文章。 请基于以下主题，输出一份文章大纲，要求： 1. 大纲结构包含：引言、主体分论点（3-5个）、总结 2. 每个分论点下给出1-2句说明 3. 同时输出5个与主题相关的配图提示词 4. 最后输出一个推荐标题列表（3个候选） 主题：{topic} 输出格式要求： 只输出JSON，不要输出任何解释性文字，不要用Markdown代码块包裹。 JSON结构如下： {"outline": "...", "points": ["...", "..."], "cover_prompts": ["...", "..."]}在Coze的大模型节点里，有一个很关键但容易被忽略的按钮叫“结构化输出”。打开这个功能后，系统会强制模型按你给定的JSON Schema来输出，而不是靠提示词去约束。这个功能强烈建议打开，因为模型在对话上下文变长之后，偶尔还是会不听话地把JSON塞进Markdown代码块里，导致下一步的代码节点解析失败。结构化输出相当于一个是硬约束的保险杠。
正文扩写节点的提示词跟大纲略有不同，它不需要输出JSON，只需要输出排版好的Markdown正文。我的做法是在提示词里给定每一段的字数和语气要求，并且明确要求只输出正文本身，不要输出“好的，以下是正文”这类废话。同时一定要在提示词里写上“禁止自行添加小标题之外的Markdown语法”这种限制词，否则模型经常会自己发挥，插一堆没用的一级标题或者分割线。
3.2 从Markdown到公众号排版的标准转换方案
这一步是整个工作流里我认为最有价值的环节，也是很多想自己搭的人最头疼的地方。公众号后台原生编辑器不支持直接粘贴Markdown，直接粘贴过来样式全丢。常规做法是用mdnice这类第三方工具手动转换，但在Coze工作流里，这个转换可以直接用代码节点完成。
我用的方案是拿Coze内置的Python代码节点，把上个节点输出的Markdown字符串转换成一份带行内样式的HTML。核心逻辑不复杂：
- 先按行读取Markdown内容
- 针对标题（## / ###）、粗体、斜体、引用、列表、代码块分别做正则替换
- 给不同元素套上公众号适用的CSS样式，比如标题颜色
#1a1a1a、引用块背景色#f5f5f5和左边框#3e8e7e - 生成完整的HTML字符串，写入结束节点输出
这里的难点不在正则替换本身，而在“图片”这种元素的处理。公众号排版里，图片通常需要单独处理尺寸和居中样式，但AI生成的配图需要先下载到本地再上传到公众号素材库，工作流做不到这一步，所以我最终选择的方案是：正文里图片位置留一个占位标签（例如[COVER_IMAGE]），等人工粘贴前再替换成公众号后台的图片。这不是技术偷懒，而是一个务实的取舍——与其花大力气去对接素材库接口，不如让人花十秒钟搞定这个动作。
3.3 配图生成节点的接入思路
配图我用的是Coze插件市场里现成的图片生成插件。整个配图环节最重要的是“喂给插件的提示词质量”，而不是插件本身。我在工作流里专门设置了一个大模型节点，用来把主题和文章大纲转成一个适合图片生成的详细提示词，这个提示词里面会包含主体、风格、构图、色调要求，例如：
生成一张公众号封面图，主体是一台笔记本电脑，屏幕上显示一棵树形状的思维导图， 周围漂浮着文字和符号元素，背景为浅灰色渐变，整体风格偏扁平化插画， 冷色调为主，画面留白，适合科技类公众号封面。这里要特别提醒的是封面尺寸。公众号封面有三处使用比例：一级消息的封面是2.35:1，次图是1:1，文章内插图则没有严格比例限制。我的实践是让图片节点直接生成接近1:1的方形主图，后续在公众号后台裁切时可以覆盖大部分场景，不追求一次到位。另外，AI配图的文字经常会生成错字，所以提示词里尽量别写需要出现具体中文文字的诉求，否则结果很容易翻车。
3.4 文件上传与下载的处理细节
Coze的开始节点支持用户上传文件，比如上传一份参考资料、一份历史风格样稿，这让工作流可以处理更复杂的输入场景。实际使用中，我通常上传两种文件：一是参考文章，让模型在生成时借鉴结构；二是账号历史文章，用于提取写作风格。
这里有一个细节要注意：文件上传后，并不是所有大模型节点都能直接读取文件内容。你需要先用一个“读取文件”或“文档解析”的插件节点，把文件内容提取成文本，然后再把它作为上下文变量传给后续的大模型节点。如果省略这一步，模型眼里这个文件基本等于不存在，出来的内容也不会贴合文件里的信息。
输出环节，结束节点可以同时输出文本内容和文件下载链接。我最终让工作流同时产出三样东西：渲染好的HTML文本（直接复制用）、Markdown原文（留档备份）、以及一份Word文档（很多编辑习惯拿Word改稿）。这个“一次运行三份产物”的组合，是在用了很多天之后才逐步加上的，最初只有HTML，后来发现同事改稿还是习惯Word，补上之后整个流转就顺畅了。
4. 实测阶段踩过的坑：一次完整的排查链路
工作流第一次跑通不代表能用，这个道理我在很多自动化项目里反复体会过。Coze工作流的搭建时间其实不长，真正花时间的是跑了几十次之后，把那些偶发性问题一个个揪出来处理掉。下面这几个坑，是我实测过程中真实遇到并且解决过的，排错链路写出来供参考。
4.1 内容生成一半就中断：token与节点超时的关联
我第一次跑完整工作流，卡在了正文扩写节点。现象是：运行到一半，节点报错，提示大概是“生成内容超过限制”，有时候干脆没有明确报错，就是节点一直转圈然后超时。
排查链路是这样的：先确认是哪一层的问题——把正文扩写节点的输出直接打印到日志，发现模型其实已经生成了大部分内容，但在接近结束的地方被截断了。这个现象说明是输出长度的限制，不是提示词的问题。Coze的大模型节点在底层调用的模型都有单次输出token上限，比如有些模型单次最多输出4096个token，换算成中文大概两千到三千个字。公众号文章正常是两千到四千字，一次输出显然放不下。
解决思路是把“一次扩写全文”改成“分段扩写”。做法是在工作流里加一个循环或者让大纲节点先输出分章节结构，然后逐个章节调用同一个扩写节点，把扩写结果拼接起来。Coze工作流里可以用批处理节点或代码节点来做拼接，不过更简单的替代方案是：把大纲拆成“上篇/下篇”两部分，用两个平行的扩写节点各写一半，再在后面的代码节点里合并成完整正文。我最终采用了后者，因为逻辑更直观，出问题时也更容易定位到具体是前半段还是后半段出问题。
4.2 结构化输出时好时坏：JSON解析的稳定性问题
第二个坑出现在“生成标题方案和摘要”这个节点。这个节点我让它输出一个JSON结构，里面包含三个候选标题、一个摘要、还有一组合适的标签。刚开始跑的时候，大部分情况下输出是对的，但偶尔会出现模型把JSON用Markdown代码块包起来的情况，或者JSON里多了一个逗号导致解析失败。这种偶发性的不稳定最讨厌，因为你不是每次都能碰上，等它真正坏了才发现。
我的解决方法是双重保险。第一重是上文中说过的，在节点设置里打开“结构化输出”，让平台强制约束JSON Schema。第二重是在后续的代码节点里，加一段容错解析逻辑：
- 先尝试直接
json.loads - 如果失败，用正则把字符串里的
json代码块标记剔除，再尝试解析 - 如果还失败，拿到的是纯文本，就按行拆分，手动提取标题和摘要字段
这段容错代码写完之后，节点的成功率从百分之七八十拉到了接近百分之九十九。这个经验也适用于其他平台：依赖大模型输出结构化数据时，永远要在下游留一个兜底解析逻辑，不要天真地以为模型每次都会听话。
4.3 图片尺寸和格式：公众号配图的实际约束
配图节点跑通之后，第一个问题是封面比例不对。图片生成插件默认生成的图大多是1:1或者4:3，但公众号首图的窗口比例是2.35:1，直接把图传上去会被裁掉一圈，经常把画面里想保留的主体给切掉。试过几次之后我决定不强行要求生成插件输出特定比例，而是在提示词里要求“主体位于画面中央，四周留出至少15%的空白区域”，这样即使被裁切，主体也不会丢。另外一个需要注意的点是生成图片的文件格式，公众号后台支持jpg、png、gif，有些插件默认输出webp格式，上传时会报错，需要在节点参数里显式指定输出格式为jpg或png。
4.4 文件节点偶发失败：字符编码和超时问题
最后一个是文件输出节点的问题。工作流在跑“生成Markdown原文”和“生成Word文档”这两个文件时，遇到过几次生成出来打开是乱码，以及文件生成超时的情况。乱码的根因基本都指向字符编码，文件节点在写入内容时默认可能用了非UTF-8编码，或者书写内容时包含了超长的未转义字符。我的解决办法是在写入前对文本做一次编码规整，同时在提示词里就要求模型不要输出非法控制字符。超时问题则主要出现在Word文档生成：当正文很长再加上大量样式，转换插件需要的时间会指数上升。解决方式是把Word生成做成可选开关——默认不生成Word，只有人工在开始节点勾选了“需要Word版”才执行后续分支，避免每次运行都背一个耗时的尾巴。
5. 进阶调整：从“能跑”到“真能用”
工作流跑通、稳定输出之后，离“每天愿意用它”还有一段距离。这个阶段我主要做了三件事：接入定时触发和批量处理、把审核和发布流程规划清楚、以及把运行成本和可观测性管起来。
5.1 定时触发与批量生成：从单篇生产到内容规划
Coze工作流支持触发器，可以按固定时间运行。我搭了一个“每日选题池”的运行方式：每周日晚间，工作流自动读取数据库里预先准备的一组选题关键词，批量跑出下周要用的七篇文章初稿。这其实涉及Coze的数据库组件——我把选题、状态、上次生成时间、当前负责人都放在一张表里，工作流每次运行前先查询状态为“待生成”的选题，生成完成后把状态改成“已生成”，下次运行就会自动跳过。这样做的好处是，我不需要每天去开工作流手动填参数，内容产出的节奏由系统按周维持。
5.2 团队空间与发布流程：AI初稿加人工审核
Coze的团队空间可以邀请协作者，我把“内容编辑”和“审核”分成了两个角色，分别赋予不同的权限。这里想多说一句：AI生成内容再怎么顺滑，发布前的审核环节绝对不能省。我的工作流每次生成完毕都会自动附带一个提醒字段，里面注明“本文由AI生成，请人工复核事实性信息、数据来源和品牌表述”，让任何拿到初稿的人心里都有数。
至于发布动作，我的方案是半自动：工作流把排好的HTML输出到浏览器，打开公众号后台的图文编辑器，直接粘贴带样式的内容，上传封面并预览，确认无误后点发布。为什么不完全对接公众号API？因为公众号的发布接口需要管理员权限，而且一旦接上就要考虑草稿管理、图片素材上传、标签同步等一系列周边问题，投入产出比很低，尤其是对个人或小团队来说，手动发布这两分钟完全可以接受。
5.3 成本控制与运行观测
运行成本方面，一条完整文章生成链路实际消耗的token数量，主要取决于正文长度和调用模型的价格档位。以一次生成约三千字正文的工作流为例，大模型节点总消耗大概在八千到一万两千token之间，不是小数目。省钱的经验有三条：
- 大纲节点和标题节点用便宜的轻量模型，只有正文扩写用高质量模型
- 结构化输出和示例尽量精简，示例内容本身也占token
- 尽量不要重复运行耗时的扩写节点，所以在提示词上花够时间，让一次成功率高一些，比反复测试省得多
可观测性方面，Coze工作流有运行日志和节点级输出查看，建议每次失败先看是哪个节点报错，再点进节点详情看输入输出。我在实际运维中还养成了一个习惯：每次调整提示词或流程后，都用同一批测试题跑一轮回归，对比前后版本的输出质量。自动化流程没过几天就可能需要微调，这很正常，关键在于每次改动都有迹可循，而不是在好几处同时改动的情况下，出了问题就不知道是谁引起的。
我个人的体会是，Coze搭公众号自动化生成工作流这件事，真正卡人的地方从来不是平台操作，而是你怎么把一个“写作任务”拆解成一连串环环相扣的“处理工序”。任务拆得清楚，节点设计自然清晰；拆得模糊，哪怕把模型换成最强力的，输出依然不稳定。这个工作流从第一版勉强能跑到现在的稳定版，中间迭代的次数不算少，但每次迭代都是围绕同一个目标：让人的精力从重复劳动中解放出来，用在真正需要判断、需要创造的那部分事情上。“AI初稿加人工把关”这个组合，放在今天做公众号内容生产，是我认为性价比最高的姿势。
