写公众号的朋友应该都有同感最耗时间的往往不是“写”本身而是写之前和写完之后那一堆琐碎的周边工作——定选题、拟标题、搭结构、想摘要、找配图、排版调样式一套下来一个完整下午就没了。我试过用纯对话式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初稿加人工把关”这个组合放在今天做公众号内容生产是我认为性价比最高的姿势。
写公众号的朋友应该都有同感最耗时间的往往不是“写”本身而是写之前和写完之后那一堆琐碎的周边工作——定选题、拟标题、搭结构、想摘要、找配图、排版调样式一套下来一个完整下午就没了。我试过用纯对话式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初稿加人工把关”这个组合放在今天做公众号内容生产是我认为性价比最高的姿势。
