用Coze工作流+GPT搭建自动化图文生成项目实战

简介：面向自媒体创作者与AI技术爱好者，这份docx文档完整记录了使用coze（coze.cn）与GPT搭建自动化图文生成项目的全过程，核心场景是批量生产《历史上的今天》类内容。文档从项目背景、想法拆解到实现步骤逐步展开，覆盖信源获取、Python爬虫编写、工作流筛选、大模型内容拓展、排版导出等关键环节，并附有可运行的爬虫与代码模块示例，适合希望用AI提升内容生产效率、具备基础编程认知的读者。资源包仅1个文件，类型为docx，大小约2.18MB，内容以文字说明与代码片段为主。已有2883人学习浏览，说明该实战路径具有一定参考价值。通过学习，读者可以掌握coze工作流与GPT节点配合的基本方法，理解如何将固定模板类内容自动化、批量化，并迁移到其他历史、资讯或科普类自媒体系列中。

1. 用 Coze + GPT 做《历史上的今天》图文：这个项目到底值不值得做

每天早上在历史账号上发一条“历史上的今天”，看着是复制粘贴，实际要查日期、核对年份、写一段有可读性的文案、找一张不别扭的配图，最后还要按平台尺寸排版。我刚开始做的时候，一条内容折腾四十分钟是常态。后来我把 coze.cn 的工作流和 GPT 模型节点串在一起，做了一个自动生成《历史上的今天》图文的自媒体项目。Coze 负责把定时触发、数据抓取、文案生成、绘图串成一条流水线，GPT 负责把干巴巴的事件记录变成能直接发的短文案。这个方案适合日更运营、历史类博主，也适合刚接触 Coze 工作流搭建的人拿来练手。

先说结论：这个方向值得做，核心价值不在“省一次查资料”，而在“每天稳定产出一条结构完整的图文草稿”。你只需要在发布前看一眼，改掉模型犯的史实错误就能发出去。后面我会把我实际搭过的节点顺序、参数和踩过的坑完整写出来，照着搭，两个小时能跑通第一版。

2. 先拆原理：Coze 工作流、GPT 模型节点和图文生成的完整链路

在搭工作流之前，先把概念理顺。Coze.cn 是一个 AI Agent 开发平台，它的核心单元叫“工作流”。工作流不是把一段 Python 脚本包一层界面，而是把多个功能节点用连线串起来，节点之间传一个 JSON 对象。GPT 在这个项目里不是“对话机器人”，而是工作流里的一个模型节点：给它一段输入，它吐一段输出，再交给下一个节点。理解这一点，后面所有配置就不会乱。

为什么不用一个 Python 脚本直接搞定？我早期试过。脚本要处理 HTTP 请求、JSON 解析、图片生成 API、文件保存，任何一个环节改需求都要动代码；如果接口返回结构变了，脚本直接崩。Coze 工作流的好处是每个节点独立，数据源坏了就换数据源、模型不合适就换模型，连线不用动。这是把“代码逻辑”变成“可视化流水线”的核心价值。

2.1 Coze.cn 在这个项目里扮演什么角色：工作流编排不是写死脚本

Coze 工作流里常用的节点类型有开始节点、定时触发节点、大模型节点、代码节点、HTTP 节点、插件节点、知识库节点。做《历史上的今天》图文，主要用到六种：

• 开始节点：定义输入参数，比如日期、平台类型、成片风格。
• 定时触发节点：每天自动跑，不需要手动点运行。
• HTTP 节点：去外部接口拉当天的历史事件数据。
• 代码节点：解析接口返回的 JSON，把事件列表清洗成模型能用的文本。
• 大模型节点：跑 GPT，生成文案和图片描述。
• 插件节点：调用图片生成能力，最后输出文件。

这六种节点串起来，就是一条“coze 工作流搭建”的典型样例。我一般会把“定时触发”放在开头，这样每天 5 点半它自动跑，不用我盯。真正让我决定用 Coze 而不是纯脚本的时刻是：有一次数据接口突然改版，返回字段从text变成了description，我只改了 HTTP 节点后面那个代码节点的映射逻辑，其余节点全都原样保留。这种维护成本，写脚本做不到。

2.2 GPT 模型节点在链路里做什么：不是聊天，是“生成函数”

GPT 在这个项目里被调用了不止一次，每次承担不同的“生成函数”角色。我把它拆成三个动作：

• 把英文或机翻的事件原文改写成 100 字以内的中文短文案；
• 把短文案再压缩成标题，控制在 20 字以内；
• 根据事件内容生成一张配图的图片描述词，英文、不超过 80 词。

这三个动作可以合成一个大模型节点，但我建议拆成两个或三个节点。拆开之后，单个节点输出长度可控、出错容易定位。比如图片描述词节点如果偶尔抽风，不会影响标题节点已经生成的结果。

下面是我在“文案生成节点”里反复打磨过的提示词模板，直接抄就能用：

你是自媒体历史频道的编辑。下面是一段“历史上的今天”事件原文，请改写成适合发布的短文案。 要求： 1. 先用 20 字以内写一个标题； 2. 再用 80～120 字写正文，语言口语化，不要堆年份； 3. 最后用 50 个英文单词以内写一句图片描述词，描述画面主体、光线、年代感，不要出现任何文字。 只输出 JSON，不要输出 Markdown 代码块，格式如下： {"title": "标题", "content": "正文", "image_prompt": "英文图片描述"} 事件原文： {{events_text}}

这段提示词看起来简单，真正的关键是“只输出 JSON”这六个字。如果少了这句话，GPT 经常会把整段回答包在 ```json 代码块里，下游解析节点直接报错。另外，{{events_text}}是 Coze 工作流的变量占位符，实际使用时会替换成代码节点传过来的事件列表。

2.3 《历史上的今天》图文链路：从日历数据到成片的四个环节

一条完整图文可以拆成四个环节：数据获取、文案生成、图片生成、排版输出。每个环节的输入输出如下：

四个环节必须解耦，不然任何一个环节失败都要整个重跑。我的做法是：每个节点都做容错处理——HTTP 节点超时了，就走知识库里的备用事件；GPT 节点返回空，就直接用事件原文前 80 个字当正文；图片生成失败，就沿用昨天的图。这样工作流永远不会因为一个环节的失败而整条中断，最多是当天的成片质量差一点。

这个链路本质上就是“多 AI 协作”：GPT 管文本，绘图插件管图片，Coze 工作流管调度和拼装。比起手动跑脚本，它能让你把每一次生成过程都留在运行日志里，哪个节点慢、哪个节点报错，一眼就能看到。

3. 从零搭建图文生成工作流：数据源、提示词与首个可用版本

原理清楚了，开始动手。这一章是照抄就能跑通的路径，我会按照“先准备数据源，再写解析代码，再配提示词，最后串节点”的顺序讲。第一次搭，不要追求功能多，先把一条最短路跑通。

3.1 准备数据源：日期接口与知识库的两种接法

“历史上的今天”的数据源有两种常见接法。第一种是 HTTP 接口：很多公开的“On This Day”服务，路径格式一般是/date/{month}/{day}，返回一个 JSON，里面包含当年今天发生的事件列表。在 Coze 的 HTTP 节点里填好 URL，方法选 GET，查询参数用开始节点传进来的month和day即可。

第二种是知识库：把一份历史事件 CSV 上传到 Coze 知识库，字段至少包含month、day、year、event四列。然后工作流里加一个“知识库检索节点”，输入当天的月日，让它把匹配的事件文本抽出来。这种方式适合做中文垂直内容，因为公开接口的数据大多是英文，后续翻译会损失信息。

我一般两种都接：先用 HTTP 接口试跑，跑通了再把值得保留的素材加固到知识库里，做成自己的事件池。第一次搭，建议先用 HTTP 接口，因为配置最简单。注意 HTTP 节点要设置超时时间，一般给 10 秒；如果接口连接失败，工作流会直接抛错，所以在 HTTP 节点后面一定要接一个“失败处理”代码节点，或者用 Coze 的条件节点做分支。

3.2 写第一个可跑的 Python 代码节点：解析日期与事件列表

HTTP 节点拿到的是整段响应体，需要清洗成 GPT 更好理解的文本。Coze 的代码节点运行 Python，入口函数一般是这样：

import json def main(event: dict) -> dict: today = event.get("today", "") parts = today.split("-") month = int(parts[1]) day = int(parts[2]) raw = event.get("http_response", "{}") data = json.loads(raw) events = data.get("data", {}).get("Events", [])[:5] items = [e.get("text", "") for e in events if e.get("text")] return { "month": month, "day": day, "events": items, "count": len(items) }

这段代码的作用是：从开始节点拿到标准日期，拆出月和日；把 HTTP 节点返回的 JSON 解析成 Python 对象；从data.Events里取前 5 条事件文本；最后把清洗后的列表返回给下游。注意event是上游节点传进来的参数字典，http_response是 HTTP 节点的输出字段名，不同的工作流版本字段名可能叫body或response，第一次跑可以先把 HTTP 节点的原始输出打印到日志里确认。

count这个字段很有用。我把count暴露出来，下游大模型节点就可以在提示词里写“如果没有事件，直接输出一句‘今天暂无可靠历史事件’”。这样即使接口当天没有返回数据，工作流也不会白跑一趟。

3.3 设计 GPT 提示词模板：一句话新闻体与图片描述分离

数据清洗完之后，进入 GPT 模型节点。我在 2.2 里给过完整提示词模板，这里重点讲两个容易出问题的设计。

第一个设计是“标题、正文、图片描述三合一”。很多人第一次搭喜欢让 GPT 分两次输出，先写文案再生成图片描述，这样要跑两遍模型，费时间费 token。三合一的好处是：GPT 在生成正文时已经看过事件原文，再生成图片描述时上下文是连贯的，不会出现“文案讲的是 19 世纪，图片描述却写成现代城市”的割裂感。

第二个设计是“图片描述必须用英文”。Coze 里的图片生成插件，比如接入 DALL·E 能力的节点，对英文提示词的理解能力通常比中文稳定。这不是玄学，而是模型训练数据的偏差。之前做中文章节测试，中文描述的出图错误率大约会高一倍，经常把“蒸汽机”画成“洗衣机”。用英文描述之后，虽然偶尔还会翻车，但整体出图质量明显提升。

3.4 组装工作流：把代码节点、模型节点和图片节点串起来

所有准备工作做完，在工作台里新建工作流，按下面顺序连线：

1. 开始节点：添加today字段，类型选字符串，默认值格式2025-06-15。
2. 定时触发节点：绑定开始节点，配置每天执行时间。
3. HTTP 节点：请求事件接口，把today的月日拆进 URL。
4. 代码节点：粘贴 3.2 的解析代码。
5. 大模型节点：选择 GPT 模型，提示词引用events列表。
6. 图片生成节点：输入字段绑定模型节点输出的image_prompt。
7. 输出节点：把标题、正文、图片 URL 打包输出。

节点与节点之间通过字段名映射传递参数。比如大模型节点输出的 JSON 是{"title": "xxx", "content": "yyy", "image_prompt": "zzz"}，那么在图片生成节点里，输入字段就写{{llm_output.image_prompt}}。不同模型节点的输出字段名可能不同，我习惯把大模型节点重命名为gpt_writer，这样引用的变量名就是{{gpt_writer.content}}，一眼能看懂。

连线完成之后先手动运行一次。不要直接挂定时任务，手动运行能看到每一节点的输入输出，方便定位问题。第一版跑通的标准是：输出节点里有标题、有正文、有一张图片 URL。

4. 调参和打磨：让生成内容从“能跑”到“能发”

工作流跑通只是第一步。真实运营场景里，内容要经得起发布。这一章讲我实际调过并且验证过的参数，按“模型参数、图片参数、调度参数、多 AI 协作”四块展开。

4.1 温度与 Top P：该硬的时候硬，该发散的时候发散

GPT 节点面板里有temperature和top_p两个关键参数。很多人看到“温度”两个字就只想到“随机性”，但在这个项目里，它的影响非常具体：

我踩过的坑是：一开始把三个节点全都设成 0.9，结果连续三天图片描述都偏向“未来科幻风”，跟历史内容完全不搭。后来把图片描述节点降到 0.3，出图风格才稳下来。道理很简单：文本内容可以有一些文采上的随机性，但图片描述一旦太发散，配图就跟文案对不上。

top_p我一般不动，保持默认值 1。什么时候要动？如果你发现模型反复输出同一句话，比如每篇正文结尾都是“这段历史告诉我们”，就把top_p降到 0.9，结合温度一起调。注意，温度和 top_p 不要同时调激进，要么固定 top_p 逐步加温度，要么固定温度逐步减 top_p，否则输出质量会像过山车，根本没有规律可循。

4.2 图片尺寸与排版参数：不同自媒体平台的适配经验

Coze 的图片生成节点通常会提供几个尺寸档位，常见的有 1024x1024、1024x1792、1792x1024。不要盲目选 1:1，要根据发布平台决定：

这里有个重要提醒：生成图片时，在图片描述词里明确加上“画面里不要出现任何文字”。AI 绘图模型对中文文字渲染能力很差，生成出来经常是错别字和乱码。如果发布需要标题压在图上，我通常用排版工具后期加文字，而不是让模型直接画字。

排版输出常见做法是让工作流把标题、正文、图片 URL 拼成一个 Markdown 文档，再转成 Word 存到素材库。Coze 社区里也有人专门做了“markdown 转 word 工作流”的模板，核心就是加一个文档转换插件。我自己的流程是输出 Markdown 原稿，发布时再复制到对应平台排版。因为不同平台的标点规范不一样，直接自动转 Word 反而会让引号变成英文的。

4.3 定时触发与批量生成：用调度器代替手动点运行

定时触发节点支持 cron 表达式，也支持简单的“每天几点”配置。我建议用 cron 表达式，可控性更强。

30 5 * * *

这串 cron 表示每天凌晨 5 点 30 分执行一次。注意 Coze.cn 在国内默认是东八区时间，所以不用额外做时区转换。为什么选 5 点半？因为这正好赶上 7 点到 8 点的通勤浏览高峰，运行完还有时间让我做人工抽检，再手动发出去。

如果你要一次生成未来一周的草稿，就不要用定时触发，而是把开始节点的today字段改成数组，然后在工作流里加一个循环节点。循环节点会遍历日期数组，每次迭代跑一次完整链路，把结果存成一条草稿。我实测过，一口气跑 7 天最合适，再多容易出现模型生成文案的套路化重复。

4.4 多 AI 协作：让摘要模型和精修模型各干一摊

很多新手以为用了 GPT 就用不上别的模型了，其实这个项目最适合的形态是“多模型分工”。我在正式用的版本里，文本生成用的是 GPT，同时挂了一个国产轻量模型做最终校验。校验节点不重新生成文案，只做两件事：检查标题超过 20 个字就截断；检查正文里有没有重复的空行。这样等于用一次很便宜的调用，兜住了主模型的低级错误。

“多 AI 协作”听起来高级，本质上就是给每个模型划定边界。主模型负责创造，校验模型负责挑错，图片模型负责视觉，各干一摊。Coze 工作流里每个模型节点都是独立配置的，你完全可以在 GPT 节点后面接一个条件判断节点：如果文本质量不足，再调另一个模型重写一次。这个分支逻辑用 Coze 的条件节点就能实现，不需要重新写代码。

5. 避坑指南：Coze 工作流里最容易翻车的 5 个地方

搭建和调参的过程里，我踩过不少坑。这一章挑 5 个最典型的，按“现象、原因、解决”写清楚。新手照着排查能少走好多弯路。

5.1 现象：历史事件张冠李戴，数据源把“今天”算错了

刚开始运行的时候，出现过 6 月 15 日的工作流，拉出来却是一堆 6 月 14 日的事件。原因是定时触发节点传下来的日期不是标准北京时间，而是服务器时间。服务器跑在 UTC，前端显示的是北京时间，但传给工作流的原始值没有转时区。

解决：在开始节点后加一个代码节点，强制取北京时间：

from datetime import datetime, timezone, timedelta def main(event: dict) -> dict: now = datetime.now(timezone(timedelta(hours=8))) today = now.strftime("%Y-%m-%d") return {"today": today}

这个代码节点会自动覆盖上游传进来的today字段，保证后续环节拿到的都是东八区当天。加完之后再也没有出现过日期错位。注意调试时手动运行也会触发这段代码，所以你不会看到错误日期——只有真跑定时任务时才会暴露，因此建议第一次挂定时后连续盯三天运行日志。

5.2 现象：GPT 输出乱码或 Markdown 符号没转义

模型输出的正文里时不时出现奇怪的加粗符号和代码块标记。原因有两个：一是提示词里没写“只输出 JSON，不要 Markdown 代码块”；二是模型节点输出长度限制不够，它把 JSON 截断到一半，导致解析失败。

解决：提示词加了“只输出 JSON”之后，再在代码节点里做一层兜底：

import json def clean_llm_output(raw: str) -> dict: raw = raw.strip() raw = raw.removeprefix("```json").removeprefix("```") raw = raw.removesuffix("```").strip() try: return json.loads(raw) except Exception: return { "title": "历史上的今天", "content": raw[:80], "image_prompt": "" }

这段代码的逻辑是：先把模型输出里的代码块标记去掉，再尝试反序列化 JSON；如果解析失败，就把原文前 80 个字当正文返回，保证下游永远有内容可用。加了这个兜底之后，模型的偶然输出异常不会再让整条工作流中断。

5.3 现象：图片生成提示词被截断，配图跟文案对不上

图片描述节点设置max_tokens为 200，理论上够 50 个英文单词。但实际体验是：模型经常在输出 JSON 时先写了 title 和 content，留给image_prompt的 token 不够，导致生成的图片描述被截断，绘图节点拿到一段不完整的英文，画出来的图跟事件毫不相关。

解决：把图片描述节点独立拆分出来，单独成一个模型节点，max_tokens设置为 150，提示词里明确“只输出 50 词以内的英文图片描述，不要包含标题和正文”。这样即使描述被截断，也只有那一个节点受影响，标题和正文已经在上一个节点生成完毕，不会全盘重来。

5.4 现象：工作流跑完但文件没上传，素材库是空的

工作流显示成功，输出节点里也有图片 URL，但打开素材库发现什么都没有。原因是图片生成节点返回的 URL 只是临时的，域名带过期时间戳；我没有把它转存到 Coze 的文件节点，所以工作流结束 URL 就失效了。

解决：在图片生成节点后面接一个“文件上传节点”，把临时 URL 作为文件地址传进去，目标选择知识库或素材库，文件命名规则用日期加序号，例如2025-06-15_hist_01.png。这个节点的作用相当于“后悔药”：就算当天忘记下载，素材库里也已经留了一份副本。文件上传节点失败的常见原因是 URL 带了防护验证头，如果遇到这种情况，需要改用代码节点自己下载再传，我们项目里遇到过一次，后来直接绕过了出问题的插件。

5.5 现象：定时触发偶尔漏跑，日志里找不到报错

工作流不是每天都能跑成功，偶尔某天日志显示“已触发”，但节点列表里没有任何执行记录。排查发现，问题出在定时触发节点同时绑定了太多工作流，或者模型节点的免费并发资源不够，触发器把任务放进队列后超时释放了。

解决：在大模型节点面板把“超时时间”调到 60 秒，开启“失败自动重试 1 次”。另外，不要把多个工作流共用一个定时触发，最好一个工作流单独配置触发器。如果某天发现漏跑，手动点一次运行就行，不要反复重试触发器，否则可能会把后面几天的配额都挤掉。

6. 进阶玩法：把单篇图文升级成半自动内容管线

单篇图文跑通之后，可以往“素材积累”和“质量抽检”两个方向升级。

6.1 用文件上传和知识库做历史事件素材沉淀

每次工作流跑完，不要让数据只躺在运行日志里。接一个文件上传节点，把当天的事件原文、GPT 生成的标题、正文、图片 URL 打包成一个 JSON 文件，传到 Coze 知识库。文件名按日期命名，比如20250615.json。做一个月之后，知识库里就有 30 份结构化素材，可以拿来复盘：哪些标题点击率高，哪些图片风格符合账号调性。更重要的是，知识库里的数据能反过来作为备用数据源，在公开接口不稳定时顶上。

6.2 验证生成质量：人工抽检四步法

自动化流程再顺畅，发布前也得人工抽检。我给自己定了四步清单：

这套清单看起来简单，但真能拦住大多数翻车。我刚开始跑这个工作流时，连续三天没检查，结果把一条 19 世纪的事件配了一张明显是 21 世纪建筑风格的图，直接翻车。后来每次跑完先看图片，再读正文，再对年份，最后确认日期，形成习惯之后没有出过硬伤。

最后的习惯是把抽检结果记录在当天的日志里。哪怕只是写一个“通过”或者“图片重绘”，也能在月底复盘时看出模型哪些地方容易犯错。比如我一个月后发现图片描述节点在“机械设备”类事件上出图偏差率最高，于是在图片描述提示词里单独加了一句“保留当时机械结构的原始质感”，效果立竿见影。

这个项目做到现在，已经成了我每天早晨的固定节奏：工作流自动跑，我抽检五分钟，然后发布。省下的不是时间，而是每天查资料、想文案、找配图那些重复劳动。如果你也在做日更内容库，希望这个方案能帮你把发布前的准备时间压缩到十分钟以内。希望帮到你。

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